From nobody Wed Jul 1 02:23:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5953E1AD0B7 for ; Wed, 1 Jul 2015 02:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Nf5QD8TjiWU for ; Wed, 1 Jul 2015 02:23:21 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA741AD071 for ; Wed, 1 Jul 2015 02:23:20 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-3e-5593b186511c Received: from ESGSCHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CD.21.12828.681B3955; Wed, 1 Jul 2015 11:23:18 +0200 (CEST) Received: from ESGSCMB103.ericsson.se ([169.254.3.71]) by ESGSCHC006.ericsson.se ([146.11.116.83]) with mapi id 14.03.0210.002; Wed, 1 Jul 2015 17:23:14 +0800 From: Mandy Liu To: "netconf@ietf.org" Thread-Topic: About grouping changed-by-parms definition in RFC6470 Thread-Index: AdCz3ik/l2y7snXqTLuNFTFR8vTddQ== Date: Wed, 1 Jul 2015 09:23:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.7] Content-Type: multipart/alternative; boundary="_000_D970584466921040BD10823F192C30B9382CD921ESGSCMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvjW7bxsmhBssOmltM3XSb1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGRMOdzEV/I+puLt0E2sDY2NwFyMHh4SAicSa9sQuRk4gU0zi wr31bF2MXBxCAkcZJVYtfMEE4SwCcqb9YAepYhPQkHj8ahKYLSKgKdE46wMrSBEzSNGLmReY QRLCAnYSM3o2M0MUOUssOfqZEcLWk+jtaWEG2cwioCKx+WwKSJhXwFdi6qSHbCA2I9AV30+t YQKxmQXEJW49mc8EcZ2AxJI955khbFGJl4//sULYChJz/z1lhqjPl1iz8DETxExBiZMzn7BM YBSehWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMosWpxcW56UbGeqlF mcnFxfl5enmpJZsYgbFycMtv3R2Mq187HmIU4GBU4uFd4Dk5VIg1say4MvcQozQHi5I474zN eaFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGNX/fXVJO/iG9d36cjbFn0kszyyb4r0Ca1bP aOR4K35ZvPn9jIJHgXPsPFJnyBxvvSkm7LlvYdqsKkUJ58PnF5QWR2uGxTcmScmxyoWGqNbP npYVmfP0UI630vk7xgqqi1OW57Y98VhkyKw148YFtwVHE/e9DZk7J43fepNXTMnHMoNP20we KLEUZyQaajEXFScCAC9rLPN2AgAA Archived-At: Cc: Adrian Pan , Harry Huang , Qifeng Zhang , Wei Luo S Subject: [Netconf] About grouping changed-by-parms definition in RFC6470 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 09:23:23 -0000 --_000_D970584466921040BD10823F192C30B9382CD921ESGSCMB103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy and NETCONF WG, The grouping "changed-by-parms" is defined in RFC 6470 below. Per my unders= tanding there should be a case "by-server" in the choice "server-or-user". = What is the intention that "leaf server" is used in it? grouping changed-by-parms { description "Common parameters to identify the source of a change event, such as a configuration or capability change."; container changed-by { description "Indicates the source of the change. If caused by internal action, then the empty leaf 'server' will be present. If caused by a management session, then the name, remote host address, and session ID of the session that made the change will be reported."; choice server-or-user { mandatory true; leaf server { type empty; description "If present, the change was caused by the server."; } case by-user { uses common-session-parms; } } // choice server-or-user } // container changed-by-parms } Thanks, Mandy --_000_D970584466921040BD10823F192C30B9382CD921ESGSCMB103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy and NETCONF WG,

 

The grouping “changed-by-parms” is defin= ed in RFC 6470 below. Per my understanding there should be a case “by= -server” in the choice “server-or-user”. What is the inte= ntion that “leaf server” is used in it?

 

grouping ch= anged-by-parms {

  = ;     description

  = ;       "Common parameters to identify t= he source

  = ;        of a change event, such as a co= nfiguration

  = ;        or capability change.";

 =

  = ;     container changed-by {

  = ;       description

  = ;         "Indicates the sourc= e of the change.

  = ;          If caused by intern= al action, then the

  = ;          empty leaf 'server'= will be present.

  = ;          If caused by a mana= gement session, then

  = ;          the name, remote ho= st address, and session ID

  = ;          of the session that= made the change will be reported.";

  = ;       choice server-or-user {

  = ;         mandatory true;

  = ;         leaf server {

  = ;           type empty;

  = ;           description

  = ;             &= quot;If present, the change was caused

  = ;            &n= bsp; by the server.";

  = ;         }

 =

  = ;         case by-user {=

  = ;           uses common-s= ession-parms;

  = ;         }

  = ;       } // choice server-or-user=

  = ;     } // container changed-by-parms=

  = ;   }

 =

Thanks,

Mandy

--_000_D970584466921040BD10823F192C30B9382CD921ESGSCMB103erics_-- From nobody Wed Jul 1 02:27:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055A21B2AD6; Wed, 1 Jul 2015 02:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 gPLO1qQ0pzsg; Wed, 1 Jul 2015 02:27:42 -0700 (PDT) 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 300BA1B2AA3; Wed, 1 Jul 2015 02:27:42 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 0B80BDE2F33D9; Wed, 1 Jul 2015 09:27:39 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t619RaID028893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 11:27:37 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 11:27:36 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Susan Hares , "'Mahesh Jethanandani'" Thread-Topic: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) Thread-Index: AQHQs3iywoO7BP7k/EicVuTrMAAx6p3Fa4wAgADr2RA= Date: Wed, 1 Jul 2015 09:27:35 +0000 Message-ID: References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> In-Reply-To: <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , "'BRUNGARD, DEBORAH A'" , 'Netconf' , 'NETMOD Working Group' Subject: Re: [Netconf] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 09:27:44 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gU3VzYW4sDQotICAgICAgICAgIFRvcG9sb2d5IG1vZGVsIHdoaWNoIGlzIGEgY29tcG9z aXRlIG9mOg0KbyAgIEdlbmVyaWMgdG9wb2xvZ3kgbW9kZWw6IGRyYWZ0LWlldGYtaTJycy15YW5n LW5ldHdvcmstdG9wby0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8vPg0KbyAgIEwzIHRvcG9sb2d5IG1vZGVsOiBkcmFm dC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS8+DQpvICAgTDIgdG9wb2xv Z3kgbW9kZWw6IGRyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5ldHdvcmstdG9wb2xvZ3ktMDA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDItbmV0 d29yay10b3BvbG9neS8+DQpvICAgTDEgVG9wb2xvZ3kgbW9kZWw6IGRyYWZ0LXpoYW5nLWkycnMt bDEtdG9wby15YW5nLW1vZGVsLTAxICgtMDIgcmVsZWFzZWQgbGF0ZXIgdGhpcyB3ZWVrKS4NCm8g ICBTZXJ2aWNlIHRvcG9sb2d5IG1vZGVsOiBkcmFmdC1oYXJlcy1pMnJzLXNlcnZpY2UtdG9wby15 YW5nLW1vZGVsLTAwIChyZWxlYXNlZCBvbiBXZWRuZXNkYXkpDQoNCkF0IHRoaXMgdGltZSwgbm9u ZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxzIHV0aWxpemUgVHJhZmZpYyBlbmdpbmVlcmluZy4gIEl0 IGlzIGFudGljaXBhdGVkIHRoYXQgdGhlc2UgbW9kZWxzIHdpbGwgc3VwcG9ydCB0cmFmZmljIGVu Z2luZWVyaW5nLg0KDQpSZWFkaW5nIHRoaXMgLCBteSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZXJl IGlzIGludGVudGlvbiBmb3IgVHJhZmZpYyBFbmdpbmVlcmluZyBwYXJ0IG9mIHRvcG9sb2d5IG1v ZGVsIHRvIGV4cGxvaXQvY29vcmRpbmF0ZSB3aXRoIFRlYXMgLCBhbmQgcGFydGljdWxhcmx5IHdp dGgNCiBkcmFmdC1saXUtdGVhcy15YW5nLXRlLXRvcG8gb3IgdG8gcHJvY2VlZCB3aXRoIGRpc3Rp bmN0IGNvbnRyaWJ1dGlvbnMgaW50ZXJuYWwgdG8gSTJSUy4NCg0KVGhhbmtzDQpTZXJnaW8NCg0K --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206 MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZl cnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTg5 MjMwMjU1NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTEzMjQ0Mjc4NzIgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IklUIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIFN1c2FuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4tPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+ VG9wb2xvZ3kNCiBtb2RlbCB3aGljaCBpcyBhIGNvbXBvc2l0ZSBvZjo8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PC9zcGFu PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5HZW5lcmlj DQogdG9wb2xvZ3kgbW9kZWw6Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8vIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtjb2xvcjojM0QyMkIzO2JhY2tncm91bmQ6d2hpdGU7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmRyYWZ0LWlldGYtaTJycy15YW5nLW5ldHdvcmstdG9wby0wMTwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0Ij48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPm88L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIy MjtiYWNrZ3JvdW5kOndoaXRlIj5MMw0KIHRvcG9sb2d5IG1vZGVsOjwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2NvbG9yOiMzRDIyQjM7YmFja2dyb3VuZDojRjlGOUY5O3RleHQtZGVj b3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0wMDwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOiNG OUY5RjkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy MjIyO2JhY2tncm91bmQ6d2hpdGUiPkwyDQogdG9wb2xvZ3kgbW9kZWw6Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMi1u ZXR3b3JrLXRvcG9sb2d5LyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzNE MjJCMztiYWNrZ3JvdW5kOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWky cnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAwPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFj a2dyb3VuZDp3aGl0ZSI+TDENCiBUb3BvbG9neSBtb2RlbDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtemhhbmctaTJycy1sMS10b3BvLXlhbmctbW9kZWwtMDEN CiAoLTAyIHJlbGVhc2VkIGxhdGVyIHRoaXMgd2VlaykuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPlNlcnZpY2UN CiB0b3BvbG9neSBtb2RlbDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ ZHJhZnQtaGFyZXMtaTJycy1zZXJ2aWNlLXRvcG8teWFuZy1tb2RlbC0wMA0KIChyZWxlYXNlZCBv biBXZWRuZXNkYXkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjM2LjBw dDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0IHRoaXMg dGltZSwgbm9uZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxzIHV0aWxpemUgVHJhZmZpYyBlbmdpbmVl cmluZy4mbmJzcDsgSXQgaXMgYW50aWNpcGF0ZWQgdGhhdCB0aGVzZSBtb2RlbHMgd2lsbCBzdXBw b3J0IHRyYWZmaWMgZW5naW5lZXJpbmcuICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVhZGluZyB0 aGlzICwgbXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGVyZSBpcyBpbnRlbnRpb24gZm9yIFRyYWZm aWMgRW5naW5lZXJpbmcgcGFydCBvZiB0b3BvbG9neSBtb2RlbCB0byBleHBsb2l0L2Nvb3JkaW5h dGUgd2l0aCBUZWFzICwgYW5kIHBhcnRpY3VsYXJseSB3aXRoDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwO2RyYWZ0LWxpdS10ZWFzLXlhbmctdGUtdG9wbyBvciB0byBwcm9jZWVk IHdpdGggZGlzdGluY3QgY29udHJpYnV0aW9ucyBpbnRlcm5hbCB0byBJMlJTLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZXJnaW88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_-- From nobody Wed Jul 1 07:14:26 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9122F1A89C6 for ; Wed, 1 Jul 2015 07:14:25 -0700 (PDT) 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 lSxRisD9iJFh for ; Wed, 1 Jul 2015 07:14:23 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C158F1A89D3 for ; Wed, 1 Jul 2015 07:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7556; q=dns/txt; s=iport; t=1435760062; x=1436969662; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4OxP/EsFJ2xDDjj3Zql7Hi/vgW1pWvP031JTL2/HFXE=; b=fMtvv4V1RzfD0c/MVJ3OZrGW1b6ZPFkg+FY+UhmVLZerYd/0vSsdLnJk 0qansR0avyqwJiH+MQN1VB+rhGkzPleyuYmVKx8RR5okh1IM2swm8D4UU 0Guwy8enOgUwjKuAfAdvzBT17tqt2DJfScXGPTVy45shQAmimVza/4pq3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgBABy9ZNV/xbLJq1YA4NlX78bCoUuSgKCGwEBAQEBAYELhCIBAQEEAQEBNTYKAQwCAgsQAQMBAQEBCRYEBAcJAwIBAgEJDB8JCAYBDAYCAQEXiBQNzCUBAQEBAQEBAQEBAQEBAQEBAQEBAQETBASLRoQ0AQEFGCMQBwYLhBoBBIUegWeNC4RdglmCCYIigTqEFIJrIowMg10mY4FagT88MQGBC4E8AQEB X-IronPort-AV: E=Sophos;i="5.15,386,1432598400"; d="scan'208";a="546705301" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 01 Jul 2015 14:14:18 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t61EEFSf006799; Wed, 1 Jul 2015 14:14:15 GMT To: "Romascanu, Dan (Dan)" , Juergen Schoenwaelder , Andy Bierman References: <20150629150721.GA2587@elstar.local> <20150629175438.GC2841@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CA78DC1@AZ-FFEXMB04.global.avaya.com> From: Benoit Claise Message-ID: <5593F5B6.7090201@cisco.com> Date: Wed, 1 Jul 2015 16:14:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA78DC1@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joel jaeggli , Netconf , ISE Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 14:14:25 -0000 Dear all, Some background: Tal asked multiple times the NETCONF WG to provide feedback on his draft. Almost none surfaced. I was not inclined to AD sponsor it. Based on the lack of interest, there would be little reason for me to support this draft. Then I mentioned ISE. I have to admit that I didn't pay attention to the IANA section, which requests IANA to assign a codepoint in the NETCONF URNs registry. The IANA entry for that registry is: Network Configuration Protocol (NETCONF) Capability URNs Capability URNs RFC 6241 IETF Standards Action As Nevil Bronwlee (ISE) mentioned: The IESG is the Registrant Contact for this registry, which means that this should be published as in Individual - i.e. sponsored by an Area Director - RFC. At that point, I mentioned that I had to re-read the draft. In the meantime, Joel agreed to AD sponsor the draft. So what do we do now? Regards, Benoit > I believe that you should make your (Juergen's, Andy's) concerns known to the IETF mail list. This being an AD-sponsored I-D that seems to be the place to comment. > > Regards, > > Dan > > >> -----Original Message----- >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen >> Schoenwaelder >> Sent: Monday, June 29, 2015 8:55 PM >> To: Andy Bierman >> Cc: Netconf >> Subject: Re: [Netconf] [FOWARDING] Last Call: > capability-05.txt> (Time Capability in NETCONF) to Experimental RFC >> >> Technically, I believe the solution is not really desirable. Figure 4 says you >> send an RPC and then wait potentially days or weeks for a matching RPC >> reply and in between you get notifications (which travel over a very different >> communication channel). But yeah, let people experiment with this if they >> want to. >> >> What I do not get is why this idea requires to get an entry in the capabilities >> registry and thus is AD sponsored. I do not think that NETCONF requires that >> experimental capabilities need to be registered with IANA. >> >> /js >> >> On Mon, Jun 29, 2015 at 10:27:03AM -0700, Andy Bierman wrote: >>> Hi, >>> >>> >>> Is this an AD-sponsored draft? >>> >>> This draft was "interesting" but not enough to be prioritized ahead of >>> other work being done in the NETCONF WG. >>> >>> The draft mixes server measurement of RPC execution time with a "cron" >>> function. The rationale for this grab-bag of time-related >>> functionality is not entirely clear. >>> >>> This work does not have any consensus within the NETCONF WG. >>> It does seem a little surprising that it is being published without >>> even asking the NETCONF WG for comments. >>> >>> I don't have any problem with Experimental RFCs as long as it is clear >>> this is not a product of the NETCONF WG. >>> >>> >>> >>> Andy >>> >>> >>> >>> On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>> >>>> Hi, >>>> >>>> just to make sure everybody here has seen this. >>>> >>>> /js >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >> > 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O >> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Q87IdLt8nKswJo- >> EKyD24gL4IKoQu5XOXa5aeKohufY&s=YOeonUh8hkmY4VdCwSpkZk593aUNn >> haxHAeGUDKyUV0&e= > >>>> >>>> ---------- Forwarded message ---------- >>>> From: The IESG >>>> To: IETF-Announce >>>> Cc: >>>> Date: Mon, 29 Jun 2015 07:58:22 -0700 >>>> Subject: Last Call: (Time >>>> Capability in NETCONF) to Experimental RFC >>>> >>>> The IESG has received a request from an individual submitter to >>>> consider the following document: >>>> - 'Time Capability in NETCONF' >>>> as Experimental RFC >>>> >>>> The IESG plans to make a decision in the next few weeks, and >>>> solicits final comments on this action. Please send substantive >>>> comments to the ietf@ietf.org mailing lists by 2015-07-29. >>>> Exceptionally, comments may be sent to iesg@ietf.org instead. In >>>> either case, please retain the beginning of the Subject line to allow >> automated sorting. >>>> Abstract >>>> >>>> >>>> This document defines a capability-based extension to the Network >>>> Configuration Protocol (NETCONF) that allows time-triggered >>>> configuration and management operations. This extension allows >>>> NETCONF clients to invoke configuration updates according to >>>> scheduled times, and allows NETCONF servers to attach timestamps to >>>> the data they send to NETCONF clients. >>>> >>>> >>>> The Network Configuration Protocol (NETCONF) Capability URNs >>>> registry requires a standards action in order to populate the >>>> registry. This document was taken out of the ISE stream and brought >>>> forward as an AD sponsored individual-submission to address this >>>> consideration. >>>> >>>> >>>> The file can be obtained via >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet >>>> f.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >> 2Dcapability_&d=AwICAg&c=BFpWQ >> w8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA& >> m=Q8 >>>> 7IdLt8nKswJo- >> EKyD24gL4IKoQu5XOXa5aeKohufY&s=xXpTwBGoKzQwCICBcvA-IOLm >>>> fEd8emgt7EGVyAmzJ2s&e= >>>> >>>> IESG discussion can be tracked via >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet >>>> f.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >> 2Dcapability_ballot_&d=AwICAg& >> c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrp >> hpBs >>>> FA&m=Q87IdLt8nKswJo- >> EKyD24gL4IKoQu5XOXa5aeKohufY&s=5XcQnG3n5R4D-qUiv >>>> 2DD-r67mQdOk39an9qW5Eb86Z8&e= >>>> >>>> >>>> No IPR declarations have been submitted directly on this I-D. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_ma >> ilman_listinfo_netconf&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGx >> R31 >>>> OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Q87IdLt8nKswJo- >> EKyD24gL4IKoQu5X >>>> OXa5aeKohufY&s=1RLb- >> m80wIXpLUu28LFybr6Sy0KTrI_zhriR7mQWflo&e= >>>> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> > 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O >> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Q87IdLt8nKswJo- >> EKyD24gL4IKoQu5XOXa5aeKohufY&s=YOeonUh8hkmY4VdCwSpkZk593aUNn >> haxHAeGUDKyUV0&e= > >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_netconf&d=AwICAg&c=BFpWQw8bsu >> Kpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Q87I >> dLt8nKswJo-EKyD24gL4IKoQu5XOXa5aeKohufY&s=1RLb- >> m80wIXpLUu28LFybr6Sy0KTrI_zhriR7mQWflo&e= > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > From nobody Wed Jul 1 08:09:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C8C1A8915 for ; Wed, 1 Jul 2015 08:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9qvO1hWnPD9 for ; Wed, 1 Jul 2015 08:09:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B8F1A9071 for ; Wed, 1 Jul 2015 08:09:02 -0700 (PDT) Received: from CO2PR05CA037.namprd05.prod.outlook.com (10.141.241.165) by BLUPR05MB707.namprd05.prod.outlook.com (10.141.207.19) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 15:09:00 +0000 Received: from BY2FFO11FD024.protection.gbl (2a01:111:f400:7c0c::122) by CO2PR05CA037.outlook.office365.com (2a01:111:e400:1429::37) with Microsoft SMTP Server (TLS) id 15.1.201.16 via Frontend Transport; Wed, 1 Jul 2015 15:08:59 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ericsson.com; dkim=none (message not signed) header.d=none; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BY2FFO11FD024.mail.protection.outlook.com (10.1.15.213) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Wed, 1 Jul 2015 15:08:59 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 1 Jul 2015 08:08:51 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t61F8oD89228; Wed, 1 Jul 2015 08:08:50 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t61F764t019786; Wed, 1 Jul 2015 11:07:07 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201507011507.t61F764t019786@idle.juniper.net> To: Mandy Liu In-Reply-To: Date: Wed, 1 Jul 2015 11:07:06 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD024; 1:RNzNhoF79yNkzp+RFBj3VQQ/90129WmqTYy55OPzLQokLyP5TLVbydo80jbttXGHBERvRPze38aJ2Tt2KsATWBzd3xhuHLQW5WN0MBZWRGMtY2TsEemC7taZ2yO8gFZdSV/mQ1J6PWIMcv9B4zaTwZgRyXFORQwMcAw5miEo2BiA9eZ/WCaSLGLBaB5SgYi6YSSwylBoFlP+FfcyetOiAxgZIDiGEhupK1lRrIGoePPOhVzsD8hl6SEW7sqcoBOg2mmjIs2HLhwzBewERrysbiiOeMKqsNzVmuuiCkoQ+Vg= X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(164054003)(189002)(199003)(105596002)(92566002)(230783001)(106466001)(86362001)(2950100001)(189998001)(5001960100002)(50986999)(76506005)(54356999)(5003600100002)(558084003)(50466002)(48376002)(77156002)(62966003)(77096005)(46102003)(87936001)(47776003)(6806004)(53416004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB707; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB707; 2:2WmUvy1T6IkdzpM9T5tqDxhG3Upcoi8jgnoFFZYFCcQlBBtcGCz12GftZn0FM6/u; 3:dtvxqPD52tXq4+oWz2ConvXbmFLf7LrCQbgLrkTXGBoQkvmRRDSf2yrqnXd3GWihpTTTUrtwdSDcGqFhOHy8R3FBlsVT3l2VCF4odNDB52oOhyip9kYYlK4e1oKKaN+2NefOzKNKL2xGnv0+oe6CR3Njj/NNMjuUPdeMZ4Lsv93sWlRyusbO7m7VIlj+F6C606EvNea24IFZTCKHcvik9nv4aJgFZovH+6rr0ZyrLPs=; 20:UNeLfXPNG30vMlYDMCWqjjuGjasf2sHIl8olSQPKtO+SDyNxj5b6JTzqCglMwUwQpO/IowAYQxtoSF21KB82sTSBBKNxnR8GvekB6TJkki1RqqFM3N2wLNPTmlZwCV8vBBbedPcywfbZYGozeX38cBKr+m0hYYyJBKTGUK13heCkDKaGu9xXm9mI+q0Bb3oXVD7fhwi4cAyUCx3zLX5RLvAp8RR8VzU4ayUnUlzeaKdZyLIazheSG6oym3IiR2rJTNcBs53dWSYvtVe8Yzn5epDRrcDTitdlIodR3r88DwC9ahPF9IMWDIh3UiDTaIPiVMtcctswz5x0y8MI82/hwvgigy7U/yDyfwLVL9R1euFKVVV6/LUSYZuJQts4s81Yb7nYG2oge5xFCIONIW0Y0vP6qC+0BRFgA78dKI5jO4ZcVbCasGkJURC2EUcKneEZwFnPxVBH0OeZ3OvGu9BmOisiADe3jOcbejNXt7zjdT8MwZloHcokp3h/IRGoRBGv X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB707; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB707; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB707; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB707; 4:idxFzEF7X5p8o3XCLPZsG3ycecDs63Tqgqoa+UEKxqzVSvbMu2j+68ww7QfOj3xCa+Kf2ggeQFL5opav+arlWLQfqmxMReQCzEVa6PrkxoET35PABKG0Wkakrk/OAjCZYREDiiHb7eKW3ZSFaEqFiTGqUVH9gjlHTTDaFynvvIehOwm9T5AiXcCdecXal7m1MMo6BPb6wS+fshoC5o3kWN/+6vd5DTxb7uIUlsNLs7DWMKoZPvoY8cbYmpCAqxFatLQFNbSXIA6YmCC2XetjlGA8jVpMFwXTtJqG6AlM9PA= X-Forefront-PRVS: 0624A2429E X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB707; 23:Pw2drZfp4pSBGT3PrITg0ICkvq4Z691yLSnueq5boMV9bzenMbUJb2wIgEwstDbssziBPNc7mjFq5qd0Ssjr7jQwuFmY/qTIAV79NNpeT3HMSuFRW0O/znjd8vr7aAqXLjecE8d7abblUg2hmeHqrnqbUnODhy1VQluRGT132b9TvHLx+SZzNrANNurCE/p3j6FaCiv8UbuqEsir7QpPfc1/5AtLAuQbc7mByYtiGzAZQV98LUdLmp6m/gMk+FPait5Ny8P05dTdRhHXAfUo0nXcKiwNVr4W5ilFTkHQ+lzFZHgFUp7KtN3AqzAGPHq6jwwe9ZoJUqfPUuTgCrhPceyEW0d3jq9gSMdnQ9ecmdu4MxQ+oQnEdotOO3GAneahzWgnSfpSCR0GEpTQJwUosH7l6NJu+KXfYEAjZ6juRKarI90eAyoeNy7+3zOubnzP9Nfto3L7vH5QWcYr92DDbZuBVUvclOYse5cnxeMbgahNQckGkHE5IX446V+fNPDahokse/QXDs6WBna6DOLBhWbRVWZb+wye1COIu54m3sqwGs2p4pWo17yzdpkGqEWnvapAtSxLGrJXySPC0+c1WHgJVc7bS6PX7rUKELZOiSIeac8vN1datWO7d/2hzNgOve11rhtJfZYJyjqD2vBFgiMDg1POZ/oI2mYct1QJBIH7Cmdeofp/+0qpGmLIavLbojjzvnbHkT304BfIp4shakGEfLpGTFubRnZYdFbPdqwsdQE4r+AGCvPXwI1UPSUAv6bJ8/Dlu8jk1sJXbQ2p4g==; 5:4R7IQZ9iGaw8GeQTCXsbdktufqvrxPoolZioTmq7/x1knPjOEHViHNKDMnvScZcYVF0se3SGOnd7lgQ/xK3hQiDDyX8GYYCmqm25xau2lhmg/ozFIMrOE6cI/7uKPKPw2AlQPbxNx35b3VLc0MNQSA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB707; 24:MFU33ca2qJrvo6//a7LijALCZiX7yXgVkq1y4SCJYjR+vDL0O7+bjYUc4Kcy1QCz5Ss5L55W3puUtCr48QhQutpQlhU7xNiouYfJ0Z79cyw=; 20:885zojQ6VyA/S3d86YzF1OI8gUTqV83jLnKJQbW6MYlXE3JsvIZM6APdGof9Pb1d3diYSjDhB5IYNIwoIPfsww== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2015 15:08:59.5146 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB707 Archived-At: Cc: Adrian Pan , Harry Huang , Qifeng Zhang , "netconf@ietf.org" , Wei Luo S Subject: Re: [Netconf] About grouping changed-by-parms definition in RFC6470 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 15:09:52 -0000 Mandy Liu writes: >The grouping "changed-by-parms" is defined in RFC 6470 below. Per my unders= >tanding there should be a case "by-server" in the choice "server-or-user". = Also "parms" seems like an odd terminology to use. "nodes" or "data" might be less odd. Thanks, Phil From nobody Wed Jul 1 08:22:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952181A9045 for ; Wed, 1 Jul 2015 08:22:06 -0700 (PDT) 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 F8o8BiFA-AVQ for ; Wed, 1 Jul 2015 08:22:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9E61A1ABF for ; Wed, 1 Jul 2015 08:22:02 -0700 (PDT) Received: from mars.tail-f.com (unknown [173.38.220.39]) by mail.tail-f.com (Postfix) with ESMTPSA id 56CB91AE049A; Wed, 1 Jul 2015 17:22:00 +0200 (CEST) Message-ID: <55940597.3020905@tail-f.com> Date: Wed, 01 Jul 2015 17:21:59 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Phil Shafer References: <201507011507.t61F764t019786@idle.juniper.net> In-Reply-To: <201507011507.t61F764t019786@idle.juniper.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Adrian Pan , Mandy Liu , Wei Luo S , Qifeng Zhang , "netconf@ietf.org" , Harry Huang Subject: Re: [Netconf] About grouping changed-by-parms definition in RFC6470 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 15:22:06 -0000 On 2015-07-01 17:07, Phil Shafer wrote: > Mandy Liu writes: >> The grouping "changed-by-parms" is defined in RFC 6470 below. Per my unders= >> tanding there should be a case "by-server" in the choice "server-or-user". = The 'server' leaf implies a case called 'server' per the shorthand rule in RFC 6020 sect 7.9.2. Wrapping it in a redundant 'case by-server { }' would perhaps be a bit more symmetric, but it is irrelevant for the actual interface. (I.e. the 'changed-by' container will have either the 'server' leaf or the 'username', 'session-id', and 'source-host' leafs.) > Also "parms" seems like an odd terminology to use. "nodes" or "data" > might be less odd. The grouping description says "Common parameters to identify the source of a change event, such as a configuration or capability change."; - and that's what it is. The actually changed nodes are not part of this grouping. --Per Hedeland From nobody Wed Jul 1 13:27:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EF21A8755 for ; Wed, 1 Jul 2015 13:27:06 -0700 (PDT) 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, 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 Y_rZ4s817Thx for ; Wed, 1 Jul 2015 13:27:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41321A8731 for ; Wed, 1 Jul 2015 13:27:03 -0700 (PDT) Received: from BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) by BN1PR05MB485.namprd05.prod.outlook.com (10.141.59.143) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 20:26:46 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 20:26:31 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.85]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.85]) with mapi id 15.01.0195.005; Wed, 1 Jul 2015 20:26:31 +0000 From: Kent Watsen To: Mahesh Jethanandani , Netconf Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 Thread-Index: AQHQr8/wgNbw1Xb4ekWUZVRu4N+Yqp3G1b2A Date: Wed, 1 Jul 2015 20:26:31 +0000 Message-ID: References: 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 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:L7KAvGgvfK3/T08K2mmHGGsyKtUFPdFqXWeQRYT7PDI5kMtI/712Sb4JZyax7JdJYq5VyYNODOUIxdwxxzJNlOqj2L+zDphkWWIzau3d7XuGJXdY7A/oiAkRYHkHwCKd0DuuFdZ0MLt4ACnB6O0hkw==; 24:ZE0I3UvFGiVp3hmfE4rDMYRX3BzFJSPkA5LpAB/MQ06zoFnGg0rasIFR3WAO2JGoA8BlWX4r3MdyMWTRHbSUsdMnEydSM1jxsfD6newjtRE=; 20:pi5gWcW7UdS/dWhLkpsNLophYsz3QHUvbpnfvlGxpo3QCtaE3j7jL7zfW9NZBjjEb2wb8RiT+Z2txqX6qe9JwA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB485; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(377454003)(164054003)(2950100001)(106116001)(46102003)(2900100001)(76176999)(50986999)(19580405001)(19580395003)(2656002)(87936001)(92566002)(99286002)(230783001)(15975445007)(19617315012)(102836002)(83506001)(86362001)(16236675004)(77156002)(40100003)(189998001)(107886002)(54356999)(5001770100001)(66066001)(5001960100002)(36756003)(62966003)(5002640100001)(122556002)(4001350100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D1B9C3F7B62D0kwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 20:26:31.7617 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454 X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB485; 2:Z8jK5kdWwpTaD+peJ6wr5ahfMmJ4RDNYeh8+kLI/tfR/OWv+qYTXGPhWv0X54FlK; 3:RBaaqLqmpLAgT1c9N+ptoIViiLxWXPkMkvQ+E/MC7TsxalsvrQbDxYd/hZwAaAcVSG5lhN/hYWuDol4jLAKum1dPp9+HdftfgxxVqt2JxEFETS49OOugoJYvfkA1aR4Fj3iDw78gCGB5ZyOPU0pdkQ==; 23:i7jPkcMs7eVpu/6OvBLvfIg2yCl0OSNMQsewCF2eSp9gkuUgzMNecWpO4kNBp2LF/u5zmYoum7nlwk9gF6zENcVInhr8nNwcXFDcNRcgivuasw5VtK/DuAD+JknjIBdT2JxLPVP+azOXRMUBJxgIPsrXqu1x0WjgDzLMe4HEwy+MIYMmsnpQaMKREw1ykSd6GEDW36fJmReKSVeuwKc0t+1FxrCYL5FrxnAhEh8kkoLcyecvUhjAD0sel0yUl9qL X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 20:27:06 -0000 --_000_D1B9C3F7B62D0kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Simultaneously, the author on this draft should state to the mailing > list whether there is any IPR associated with this draft or not. The only IPR I am aware of on this draft is the same as linked by datatrack= er here: https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-netconf-call-hom= e&submit=3Ddraft Thanks, Kent From: Mahesh Jethanandani > Date: Friday, June 26, 2015 at 1:21 AM To: "netconf@ietf.org" > Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 Dear NETCONF participants, This e-mail is a notification to start a NETCONF WG Last Call for the docum= ent "NETCONF Call Home and RESTCONF Call Home". The document can be found at: draft-ietf-netconf-call-home-07. Please review the document, provide comments, and indicate your support for= the draft by Friday July 3 (your timezone). The comments can be in the for= m of: * "I have reviewed the I-D Blah and I have found issues with it" * "I have reviewed I-D Blah and I found no issues" Simultaneously, the author on this draft should state to the mailing list w= hether there is any IPR associated with this draft or not. Thanks Mahesh and Mehmet (Co-chairs, NETCONF WG) --_000_D1B9C3F7B62D0kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1E884246636B824F96924AD5175813B2@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
> Simultaneously, the author on this draft should state to the mail= ing 
> list whether there is any IPR associated with this draft or not.<= /div>

The only IPR I am aware of on this draft is the same as linked by datatrack= er here:


Thanks,
Kent



From: Mahesh Jethanandani <mjethanandani@gmail.com>
Date: Friday, June 26, 2015 at 1:21= AM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] WG Last Call for= draft-ietf-netconf-call-home-07

Dear NETCONF participants,

This e-mail is a notification to start a NETCONF WG Last Call for the docum= ent "NETCONF Call Home and RESTCONF Call Home”.

The document can be found at: draft-ietf-netconf-call-home-07<= /a>.

Please review the document, provide comments, and indicate = your support for the draft by Friday July 3 (your timezone). The comments c= an be in the form of:

  • “I have reviewed the I-D Blah and I have found issues = with it”
  • “I have reviewed I-D Blah and I fou= nd no issues”

Simultaneously, the author on this draft should state to th= e mailing list whether there is any IPR associated with this draft or not.<= /div>

Thanks

Mahesh and Mehmet
(Co-chairs, NETCONF WG)




--_000_D1B9C3F7B62D0kwatsenjunipernet_-- From nobody Wed Jul 1 13:40:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16E51A8AFE for ; Wed, 1 Jul 2015 13:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cvhDphy4Pd3 for ; Wed, 1 Jul 2015 13:40:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEBAA1A8824 for ; Wed, 1 Jul 2015 13:40:30 -0700 (PDT) Received: from BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) by BN1PR05MB296.namprd05.prod.outlook.com (10.141.64.23) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 20:40:15 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 20:40:14 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.85]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.85]) with mapi id 15.01.0195.005; Wed, 1 Jul 2015 20:40:14 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? Thread-Index: AQHQnylRVSAYbzmnCkGtm2Dh3wuOiJ2dKNsAgADRUoCAH8DLAIAJP+oA Date: Wed, 1 Jul 2015 20:40:14 +0000 Message-ID: References: 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 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:/rhZZu0YzEqcXirHi/GcttE2+unUKoVso6+ev5KVNjy9YQTA6RVBMeLjYCr6znjvRrdHm7vzKPsKKLqyIKub7vZ+VzvLjGcxtfYZkKsYcsGiINI8yPRtm9lpC7VWxv9PeOUq7VcFoeS4Hzm2AT7cdA==; 24:ByrZlTqDLNtLf8a33ommquAsl2ZS/s883I1ucLq1Gdf0OggAd8EL8yw1fAqt2K1AfMcqtKC4kaXNopfqxVzzhXVyYYalJR+nVas1K2JmzlM=; 20:7HZt/lTisrFWPMIUVtbPt+e9p/89CR86ny4RKfl7B3q/EuCNkob6i6y6jWq/7EP9YPPMmch2CkY+nmE/aW7ImQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB296; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(479174004)(51704005)(377454003)(24454002)(76104003)(450100001)(77156002)(107886002)(189998001)(40100003)(83506001)(86362001)(66066001)(5001960100002)(62966003)(36756003)(122556002)(4001350100001)(5002640100001)(110136002)(2501003)(54356999)(87936001)(2656002)(92566002)(19580405001)(19580395003)(46102003)(50986999)(2900100001)(76176999)(2351001)(2950100001)(106116001)(93886004)(102836002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <33A4A16C264DEF45842894CED3A509D2@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 20:40:14.2126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454 X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB296; 2:8T1UqEuCDq+6eOY7ZXu3bZUniZPtIKegiC8aYjrAmsOzVPvGXjeYaL0Vey3Dd1mW; 3:1znC6r1B+hDtZCqt/exXgPxmot1FTyHwaS2R3UolyVfBrfOtZBI3ryCUTPXUEnTEDe3UPFVHrSy6ZiaGiTrA+EoP8KGCiBKPhsP6ZMVRvmdKtM1StgtaUtGBph0sLG3ERmwYs9oZpyiTcCdpUKkwcA==; 23:drWXzvwZNOTlKjONXOo/7szUHAEZstpVkddBiBPrTZ9tMjIN+7oaCSQJYTnx5WiWwuVeYQRTpyT5lsrhUTsJn9YhFPoEAPWFt0459Y3QOzXnEHtso2Lf0NGK+3Y9TPzgDvojS6f0QMaew0e3Gtug4PrGg9WhnWpBICOldckpZlHwX74TDVnmgrhVMXnzgLsV43mGp9tbdldQDeWIDJMqBBXsr3t51bsbdXOJRlvftwl/utoGdFk/1rx3kFe9cNI0 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 20:40:32 -0000 In my effort to submit an update for this draft before the cutoff on Monday, I'm going to assume that silence equals consent on the solution below, if no objects are raised before this end of day Friday. Thanks, Kent On 6/25/15, 7:25 PM, "Kent Watsen" wrote: > >Regarding moving "idle-timeout" node to the "listen" tree, I'm still a fan >of that, but what I think would be even better is to also have an >idle-timeout in the call-home/periodic and the call-home/persistent >sub-trees. =20 > >An idle-timeout is always useful, but its value needs to be different for >the various cases. How about this: > > Default > ------- > listen/idle-timeout 1 hour > call-home/periodic/idle-timeout 5 min > call-home/persistent/idle-timeout 1 day > > >What do you think? - makes sense? > > >Kent > > > From nobody Wed Jul 1 13:51:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7051ACD25 for ; Wed, 1 Jul 2015 13:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag8ElbVCfsYV for ; Wed, 1 Jul 2015 13:51:26 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e: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 78B8B1ACD24 for ; Wed, 1 Jul 2015 13:51:26 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so28442533pab.1 for ; Wed, 01 Jul 2015 13:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Tv6Xj6RzuEGlcfS/vAJT/4ddccoYHegZ+OKoNxh1kMM=; b=j6WfOVD/YI1623I8+PPl/cYiLbycjwvQd6RcCM17dlc85w1QPVQ+XIBCZ2GDtwf3Ei P4JSHYXg31GI/xGvUIWkHkSET3ef4uyLvLI83sHt2YqcGuT4pTnwEmJ+g6XRKMFwqhqs SipCLQ6OLekDQgsBM1VFFBPxZkXNI+is92dkcepAYP8eJ3+Vmrp6iU1+skx/UFIEGpqW ISbnfgr2XTaaV8iv37qgjZo0uEwQqw2jpJ+270i16wn/AWw4aRHPeF693srCpMgK2r/P lMF9Lfsj3RVsKNwfHUQRLoBQXq/eSebc9mXmSfJSWwsE56dwxQU+0zd/PMz15J94Lush Y2Kg== X-Received: by 10.70.94.167 with SMTP id dd7mr59780957pdb.115.1435783886206; Wed, 01 Jul 2015 13:51:26 -0700 (PDT) Received: from ?IPv6:2001:420:290:1266:8188:3b9c:b5d1:be1b? ([2001:420:290:1266:8188:3b9c:b5d1:be1b]) by mx.google.com with ESMTPSA id kp2sm3250702pab.12.2015.07.01.13.51.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jul 2015 13:51:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_09F29F02-6A9B-41DF-ACDE-FD9E115F3672" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 1 Jul 2015 13:53:23 -0700 Message-Id: <4189B6F3-CE70-4AAF-BC42-4D2852BB2BA3@gmail.com> References: To: Kent Watsen X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 20:51:28 -0000 --Apple-Mail=_09F29F02-6A9B-41DF-ACDE-FD9E115F3672 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Chair hat off] Kent, > On Jun 1, 2015, at 5:38 PM, Kent Watsen wrote: >=20 > For periodic connections, the idle-timeout is way too course (default = 1 hour). We use to have a "linger-timeout" for this purpose (default 30 = secs), but a side meeting in Dallas concluded that it was unneeded, as = the client would close the connection as and when it was ready. Still, = the intent is that the connection wouldn't stay open anywhere close to = the periodic interval (default 5 mins). An idle-timeout here is nearly = useless. I am assuming, that moving the idle-timeout to the listen tree allows = you to time connections out that connect, but do not progress. I am = thinking DOS scenario, where somebody opens connections but decides not = to make progress. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_09F29F02-6A9B-41DF-ACDE-FD9E115F3672 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [Chair hat off]

Kent,

On Jun 1, 2015, at 5:38 PM, = Kent Watsen <kwatsen@juniper.net> wrote:

For periodic connections, the = idle-timeout is way too course (default 1 hour). We use to have a = "linger-timeout" for this purpose (default 30 secs), but a side meeting = in Dallas concluded that it was unneeded, as the client would close the = connection as and when it was ready. Still, the intent is that the = connection wouldn't stay open anywhere close to the periodic interval = (default 5 mins). An idle-timeout here is nearly = useless.

I am assuming, that moving the idle-timeout to the = listen tree allows you to time connections out that connect, but do not = progress. I am thinking DOS scenario, where somebody opens connections = but decides not to make progress.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_09F29F02-6A9B-41DF-ACDE-FD9E115F3672-- From nobody Wed Jul 1 14:04:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740E81A9112 for ; Wed, 1 Jul 2015 14:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Z-fwBxsCpncZ for ; Wed, 1 Jul 2015 14:04:25 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 4CCCA1A9107 for ; Wed, 1 Jul 2015 14:04:25 -0700 (PDT) Received: by lbbpo10 with SMTP id po10so20379127lbb.3 for ; Wed, 01 Jul 2015 14:04:23 -0700 (PDT) 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=Mv+RK6OieO1fOLpQYtrVvXm6GGJ1rbOdYf1sFhmP8Uo=; b=gTXLLZ4C3XSsz4XjW1dMPP+7dRRAFxycC2ITXgZrBmt2w/n4mUH+ijDgbekzIJxJpg 7vr9kHRoOjkIopL6kCtrHrcqI9RLNeFzP46UI6+ss0KgwWEeXMO+6mv6X1HglWWUigBY 4OXxvtMSfXB0TvDC3XKzb9GVKBcC5c6ij0PxFv1iYwdVSpDt7GC9SkseInS5rYvwQPEL YDDS2sm7qJV96QuIvW9sOgxdzaCsqN7zW0dC4N4BFzSk7PHyrVtQWtws1tYvHCMIECSj 5vLKP7ZCfoy+/9IicJDF/KPx78Ko5Uiz6a+PhswvKVqB39M85G4JeBgyFARySmb7prna eWBg== X-Gm-Message-State: ALoCoQnPIrvKGk5q8TROgcqXgQV2p0s8etdmQKgK4/4KpxOqSN15d+gQCQe1uijfxYcTSN42441l MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr27214883lbp.88.1435784663805; Wed, 01 Jul 2015 14:04:23 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 1 Jul 2015 14:04:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jul 2015 14:04:23 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a113403d8dc4b470519d6aab0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 21:04:27 -0000 --001a113403d8dc4b470519d6aab0 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 1, 2015 at 1:40 PM, Kent Watsen wrote: > > In my effort to submit an update for this draft before the cutoff on > Monday, I'm going to assume that silence equals consent on the solution > below, if no objects are raised before this end of day Friday. > > Thanks, > Kent > > > On 6/25/15, 7:25 PM, "Kent Watsen" wrote: > > > > >Regarding moving "idle-timeout" node to the "listen" tree, I'm still a fan > >of that, but what I think would be even better is to also have an > >idle-timeout in the call-home/periodic and the call-home/persistent > >sub-trees. > > > >An idle-timeout is always useful, but its value needs to be different for > >the various cases. How about this: > > > > Default > > ------- > > listen/idle-timeout 1 hour > > call-home/periodic/idle-timeout 5 min > > call-home/persistent/idle-timeout 1 day > > > > > >What do you think? - makes sense? > > > I guess I missed a meeting. I remember deciding to remove idle-timeout for persistent connections. Why do we need persistent connection timeouts? I know a session that has a notification subscription active never times out. What kind of persistent session times out after 1 day? Seems like call-home sessions should be the same timeout as the idle-timeout (and persistent connections never time out). > > > >Kent > > > > > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a113403d8dc4b470519d6aab0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 1, 2015 at 1:40 PM, Kent Watsen <kwatsen@juniper.net= > wrote:

In my effort to submit an update for this draft before the cutoff on
Monday, I'm going to assume that silence equals consent on the solution=
below, if no objects are raised before this end of day Friday.

Thanks,
Kent


On 6/25/15, 7:25 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:

>
>Regarding moving "idle-timeout" node to the "listen"= ; tree, I'm still a fan
>of that, but what I think would be even better is to also have an
>idle-timeout in the call-home/periodic and the call-home/persistent
>sub-trees.
>
>An idle-timeout is always useful, but its value needs to be different f= or
>the various cases.=C2=A0 How about this:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Default
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 -------
>=C2=A0 =C2=A0listen/idle-timeout=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 hour
>=C2=A0 =C2=A0call-home/periodic/idle-timeout=C2=A0 =C2=A0 =C2=A0 =C2=A0= 5 min
>=C2=A0 =C2=A0call-home/persistent/idle-timeout=C2=A0 =C2=A0 =C2=A0 1 da= y
>
>
>What do you think?=C2=A0 - makes sense?
>

I guess I missed a meeting.
<= div>I remember deciding to remove idle-timeout for persistent connections.<= /div>
Why do we need persistent connection timeouts?=C2=A0 I know a ses= sion
that has a notification subscription active never times out.=

What kind of persistent session times out after 1= day?
Seems like call-home sessions should be the same timeout
as the idle-timeout (and persistent connections never time out).

=C2=A0
>
>Kent
>
>
>



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

--001a113403d8dc4b470519d6aab0-- From nobody Wed Jul 1 14:21:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12F1ACF5E for ; Wed, 1 Jul 2015 14:21:00 -0700 (PDT) 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, 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 uwmGzxD3OdyQ for ; Wed, 1 Jul 2015 14:20:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005981ACF58 for ; Wed, 1 Jul 2015 14:20:43 -0700 (PDT) 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.195.15; Wed, 1 Jul 2015 21:20:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.216]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) with mapi id 15.01.0207.004; Wed, 1 Jul 2015 21:20:39 +0000 From: Kent Watsen To: Mahesh Jethanandani Thread-Topic: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? Thread-Index: AQHQnMxuePjQIPVzcEq31qKXMQWLXJ3HRleA///EkIA= Date: Wed, 1 Jul 2015 21:20:38 +0000 Message-ID: References: <4189B6F3-CE70-4AAF-BC42-4D2852BB2BA3@gmail.com> In-Reply-To: <4189B6F3-CE70-4AAF-BC42-4D2852BB2BA3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:n/Zdju1YAHhiNQZ6YofBYlIiI25k3veciMZ+urFNm70CnEiHm4uNmuem6eNkV9xzNSoKfJsCTHK/3emzxddouJ4TCcuojvfB/uZ1ywd+xBOweKaVv7931amKGVa2ReBLCYYY+Sw1g4WBRH8XoULUdA==; 24:13rTfBpk9EtTdm3X/XqZP+DpDoN61FR/IrkFiLOXpCr9Y/SLsLR1TU7wk9Tf6yHn9EavNK0tAm+cEralakTGgVt6HOGHIFwg0wOSuNEDGIc=; 20:zsUl8TPHl1QWeEDnmTiT/nOZClaXl56lImwUte/24Uru/vMcUUlHNDxI9Q7+fX1lLu42wgksj4GyxZyNUjcp4A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(46102003)(2950100001)(2900100001)(66066001)(5001960100002)(36756003)(110136002)(40100003)(83506001)(558084003)(77156002)(122556002)(62966003)(102836002)(189998001)(5002640100001)(106116001)(99286002)(1411001)(86362001)(76176999)(2656002)(50986999)(16236675004)(87936001)(54356999)(4001350100001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1B9D19BB6345kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 21:20:38.7982 (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: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 21:21:00 -0000 --_000_D1B9D19BB6345kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I am assuming, that moving the idle-timeout to the listen tree allows > you to time connections out that connect, but do not progress. I am > thinking DOS scenario, where somebody opens connections but > decides not to make progress. Yes, exactly the purpose here! Cheers, Kent --_000_D1B9D19BB6345kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <3313EAC8A2219F4F9AEA7E82BABA0968@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

> I am assuming, that moving the idle-timeout to the lis= ten tree allows
> you to time connections out that connect, but do not progress. I = am
> thinking DOS scenario, where somebody opens connections but
> decides not to make progress.

Yes, exactly the purpose here!  

Cheers,
Kent

--_000_D1B9D19BB6345kwatsenjunipernet_-- From nobody Wed Jul 1 14:31:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3521AD378 for ; Wed, 1 Jul 2015 14:31:36 -0700 (PDT) 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, 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 3Zcmvo-K1Z0F for ; Wed, 1 Jul 2015 14:31:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475661AD368 for ; Wed, 1 Jul 2015 14:31:34 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 21:31:29 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.216]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) with mapi id 15.01.0207.004; Wed, 1 Jul 2015 21:31:29 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? Thread-Index: AQHQnylRVSAYbzmnCkGtm2Dh3wuOiJ2dKNsAgADRUoCAH8DLAIAJP+oAgABJzoD//8SEgA== Date: Wed, 1 Jul 2015 21:31:29 +0000 Message-ID: References: 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 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:Owhu/08vTl2MTcpa/Ev0XtOKtYzGjMNl+5IPXeirudhCwum4/VHM2BK8+EB/pGb1p5k2vdjj8J8CIDuqVG0ior9HiHfnN3E4RlIal/y9UQ4a+xWe8q5qU/9pQG/o0wkaJG36yIWecu8m0ZRVQpo5+Q==; 24:nP0sKAgc+aPK6miALZT6IaeO9b4vUpcI51kbLep4hIzulVJhcBSe1ISqY3BqNkVP67rgyjxd26bPx7cycwQlvaCwUN21PO0nhPv5bRukaWQ=; 20:Me2J0azWU2unQVMwE7gDLbUVmqyyasid5eiqz/kmE4yzNaBYTROO8xR6TEGaniSb/HR/IPAQf1xAEUJICOaaNg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(57704003)(99286002)(16236675004)(76176999)(189998001)(83506001)(86362001)(50986999)(54356999)(66066001)(106116001)(93886004)(46102003)(36756003)(87936001)(2656002)(4001350100001)(5002640100001)(77156002)(62966003)(110136002)(2900100001)(5001920100001)(2950100001)(5001960100002)(102836002)(92566002)(40100003)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1B9D1EAB6349kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 21:31:29.2865 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 21:31:36 -0000 --_000_D1B9D1EAB6349kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I guess I missed a meeting. There was none, just the email I sent before... > I remember deciding to remove idle-timeout for persistent connections. > Why do we need persistent connection timeouts? Even a persistent connection should have some kind of timeout. A day, a we= ek, a month, whatever. It just seems that, after some crazy long duration = with no NC/RC-level message being sent by the client, something has gone wr= ong and the session should be reaped. > Seems like call-home sessions should be the same timeout > as the idle-timeout (and persistent connections never time out). Very different timeouts are desired. Persistent connection timeouts are ad= dressed above. On the other end of the spectrum, we have periodic connect= ions that, by design, should not be held open for an extended amount of tim= e. Again, be it 5 minutes, 30 minutes, or an hour, at some point it become= s clear that something has gone wrong and the session should be reaped. The net-net is that I'm thinking that there should always be some kind of i= dle-timeout, but its default value varies greatly by use-case. Makes sen= se? Kent --_000_D1B9D1EAB6349kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable


> I guess I missed a meeting.

There was none, just the email I sent before...


> I remember deciding to remove idle-timeout for persistent connect= ions.
> Why do we need persistent connection timeouts? 

Even a persistent connection should have some kind of timeout.  A= day, a week, a month, whatever.  It just seems that, after some crazy= long duration with no NC/RC-level message being sent by the client, someth= ing has gone wrong and the session should be reaped.   


> Seems like call-home sessions should be the same timeout
> as the idle-timeout (and persistent connections never time out).<= /div>

Very different timeouts are desired.  Persistent connection timeo= uts are addressed above.   On the other end of the spectrum, we have p= eriodic connections that, by design, should not be held open for an extende= d amount of time.  Again, be it 5 minutes, 30 minutes, or an hour, at some point it becomes clear that something has = gone wrong and the session should be reaped.


The net-net is that I'm thinking that there should always be some kind= of idle-timeout, but its default value varies greatly by use-case.   =  Makes sense?

Kent

--_000_D1B9D1EAB6349kwatsenjunipernet_-- From nobody Wed Jul 1 14:37:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5D11B29DF for ; Wed, 1 Jul 2015 14:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 K6ur41_Pc8C7 for ; Wed, 1 Jul 2015 14:37:01 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 12E2B1AD378 for ; Wed, 1 Jul 2015 14:37:01 -0700 (PDT) Received: by lagh6 with SMTP id h6so49035050lag.2 for ; Wed, 01 Jul 2015 14:36:59 -0700 (PDT) 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=iUJGL4BwAcFgaIrV2alRpplnCzO8IimZpeq2v9Lsnwk=; b=Bihtba3XOYBvT3h5XLv4fnM/HjSOh+EhQd1PCn157Pi2N3yyIlp8y5JzMnOFhZVwpa 06rfSwCixtDuG9yWsktQe9ULz0pwds4SkFPonXBI3XAWjODJaCoX6WoLxmxWO2rGLEez 4Clbuym1En/6nA34llN/Q45Ym4yIRYO2OGCY4D/ela3ZXropySRVoRAilPJWaw/mJANI OMvsuP8FXguUuogcCPr5/pEXqJVDPeoLvgkycJ/NLtwqcjt81hRM972YQ4ORffFo2nss WpoyKJ9ZrbMEiXGgezqRRuLZWpXnvvfKXphL8VGMHwiFBYOKLcAv0y3d8cthlJdk0o0Q LlxA== X-Gm-Message-State: ALoCoQmijwHBe093ChTPW3oQNYga5UeIOlrv5aAZMWxPtH6XEc1yipvKmFv17wnHiEdkZY979o9w MIME-Version: 1.0 X-Received: by 10.152.121.99 with SMTP id lj3mr26673952lab.37.1435786619519; Wed, 01 Jul 2015 14:36:59 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 1 Jul 2015 14:36:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jul 2015 14:36:59 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=089e0115e8826e20c00519d71f3f Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 21:37:02 -0000 --089e0115e8826e20c00519d71f3f Content-Type: text/plain; charset=UTF-8 On Wed, Jul 1, 2015 at 2:31 PM, Kent Watsen wrote: > > > > I guess I missed a meeting. > > There was none, just the email I sent before... > > > > I remember deciding to remove idle-timeout for persistent > connections. > > Why do we need persistent connection timeouts? > > Even a persistent connection should have some kind of timeout. A day, a > week, a month, whatever. It just seems that, after some crazy long > duration with no NC/RC-level message being sent by the client, something > has gone wrong and the session should be reaped. > > A client that starts a session for NETCONF notifications or even RESTCONF SSE may only send 1 request and never send anything again. It will only listen for notifications. Our server never times out these sessions. > > > Seems like call-home sessions should be the same timeout > > as the idle-timeout (and persistent connections never time out). > > Very different timeouts are desired. Persistent connection timeouts > are addressed above. On the other end of the spectrum, we have periodic > connections that, by design, should not be held open for an extended amount > of time. Again, be it 5 minutes, 30 minutes, or an hour, at some point it > becomes clear that something has gone wrong and the session should be > reaped. > > > The net-net is that I'm thinking that there should always be some kind > of idle-timeout, but its default value varies greatly by use-case. Makes > sense? > > Kent > > Andy --089e0115e8826e20c00519d71f3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 1, 2015 at 2:31 PM, Kent Watsen <kwatsen@juniper.net= > wrote:


> I guess I missed a meeting.

There was none, just the email I sent before...


> I remember deciding to remove idle-timeout for persistent connect= ions.
> Why do we need persistent connection timeouts?=C2=A0

Even a persistent connection should have some kind of timeout.=C2=A0 A= day, a week, a month, whatever.=C2=A0 It just seems that, after some crazy= long duration with no NC/RC-level message being sent by the client, someth= ing has gone wrong and the session should be reaped. =C2=A0=C2=A0



A clie= nt that starts a session for NETCONF notifications
or even RESTCO= NF SSE may only send 1 request and never send anything again.
It = will only listen for notifications.=C2=A0 Our server never times out these = sessions.

=C2=A0

> Seems like call-home sessions should be the same timeout
> as the idle-timeout (and persistent connections never time out).<= /div>

Very different timeouts are desired.=C2=A0 Persistent connection timeo= uts are addressed above. =C2=A0 On the other end of the spectrum, we have p= eriodic connections that, by design, should not be held open for an extende= d amount of time.=C2=A0 Again, be it 5 minutes, 30 minutes, or an hour, at some point it becomes clear that something has = gone wrong and the session should be reaped.


The net-net is that I'm thinking that there should always be some = kind of idle-timeout, but its default value varies greatly by use-case. =C2= =A0 =C2=A0Makes sense?

Kent



Andy

--089e0115e8826e20c00519d71f3f-- From nobody Wed Jul 1 15:04:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DBE1ACD53 for ; Wed, 1 Jul 2015 15:04:58 -0700 (PDT) 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, 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 4o7Jg9fT4w_F for ; Wed, 1 Jul 2015 15:04:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24DD1AD272 for ; Wed, 1 Jul 2015 15:04:55 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.207.19; Wed, 1 Jul 2015 22:04:35 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.216]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) with mapi id 15.01.0207.004; Wed, 1 Jul 2015 22:04:35 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? Thread-Index: AQHQnylRVSAYbzmnCkGtm2Dh3wuOiJ2dKNsAgADRUoCAH8DLAIAJP+oAgABJzoD//8SEgIAARJeA///EqIA= Date: Wed, 1 Jul 2015 22:04:35 +0000 Message-ID: References: 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 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 24:80NGIbWrUZN68xWcoD2fp7AXj5xBzqIv+H8fObIislREckmbeH4H35jpvyk4b63uXskEJn902jrY8yFWwbMNX8u1entQjwAGqxTv8jTBTvE=; 20:EOFsZUsyGVPg5vjeA4p5JbZKeMx8jgoaowVSV92KheeOApW7Khq7YN4rWXJEP5IsgppMQCiqpoNW0TAA4TvGiA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189998001)(110136002)(76176999)(66066001)(36756003)(2950100001)(16236675004)(5002640100001)(54356999)(102836002)(2900100001)(2656002)(50986999)(83506001)(86362001)(5001960100002)(4001350100001)(87936001)(122556002)(92566002)(99286002)(62966003)(40100003)(77156002)(93886004)(106116001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1B9DB33B638Dkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 22:04:35.4658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:04:58 -0000 --_000_D1B9DB33B638Dkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > A client that starts a session for NETCONF notifications > or even RESTCONF SSE may only send 1 request and never send anything agai= n. > It will only listen for notifications. Our server never times out these = sessions. Yes indeed, the current idle-timeout description says "Sessions that have a= notification subscription active are never dropped." - we'd keep this lang= uage. This said, do you agree that having a different idle-timeout value= for the various use-cases makes sense? Kent --_000_D1B9DB33B638Dkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <839C66892B7AC14D8E2EBB2D1AD4F58A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


> A client that starts a session for NETCONF notifications
> or even RESTCONF SSE may only send 1 request and never send anyth= ing again.
> It will only listen for notifications.  Our server never tim= es out these sessions.


Yes indeed, the current idle-timeout description says "Sessions t= hat have a notification subscription active are never dropped." - we'd= keep this language.    This said, do you agree that having a dif= ferent idle-timeout value for the various use-cases makes sense?

Kent

 --_000_D1B9DB33B638Dkwatsenjunipernet_-- From nobody Wed Jul 1 15:09:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482411AD272 for ; Wed, 1 Jul 2015 15:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 5Uv12TTheNay for ; Wed, 1 Jul 2015 15:08:59 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 6DC411ACD53 for ; Wed, 1 Jul 2015 15:08:59 -0700 (PDT) Received: by lbbpo10 with SMTP id po10so21177292lbb.3 for ; Wed, 01 Jul 2015 15:08:57 -0700 (PDT) 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=nZBtxtNylonUPOQlaNoazUKLyDFFkoFAyMw9j5C6ILY=; b=I9r+UeHAbtzWrjJ8BDwAGHlYi3NcWsBj5idHdwZW4WQ66aSWdnlh9O+tI4VkW5LjEL iTVQxR6Mn4p9Ffg2h1WW8oe22VBsKqOK5cPg61bks+Rs9plTFz6Otu3a6oxib9J+XEvd 1hz49EH9AnyVSa/UuQ4/XrtIu9kEbno/TIf/8jFfKwIyMr1KWCB3hr/POWT6RK8vynOc uLL4IR1x/6w3JNptABTH2J8o2WzbHPDmzYJbWLgG4fuZzfdHgFE2Ivfpc9hathSxNoY1 gSBKyoknY09XSXeP5hyhDfYpZmJJc4qPeXiIh1C0ykHQrk2qWuSS0qhaaLJ97E/fLhw4 qgZw== X-Gm-Message-State: ALoCoQltm/p5l5kgawOFKS0p0Pgrl/6x9ExvtxyzL7SFDH31fS5I13jD9usDyyU8CGrZn44eo5U1 MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr27522856laj.123.1435788537819; Wed, 01 Jul 2015 15:08:57 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 1 Jul 2015 15:08:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jul 2015 15:08:57 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=089e0158ba0ac50a960519d79181 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:09:03 -0000 --089e0158ba0ac50a960519d79181 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 1, 2015 at 3:04 PM, Kent Watsen wrote: > > > > A client that starts a session for NETCONF notifications > > or even RESTCONF SSE may only send 1 request and never send anything > again. > > It will only listen for notifications. Our server never times out these > sessions. > > > Yes indeed, the current idle-timeout description says "Sessions that > have a notification subscription active are never dropped." - we'd keep > this language. This said, do you agree that having a different > idle-timeout value for the various use-cases makes sense? > > OK -- sorry I forgot that notification text was already in there. I agree with your proposal to have 3 different defaults > Kent > > Andy --089e0158ba0ac50a960519d79181 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 1, 2015 at 3:04 PM, Kent Watsen <kwatsen@juniper.net= > wrote:


> A client that starts a session for NETCONF notifications
> or even RESTCONF SSE may only send 1 request and never send anyth= ing again.
> It will only listen for notifications.=C2=A0 Our server never tim= es out these sessions.


Yes indeed, the current idle-timeout description says "Sessions t= hat have a notification subscription active are never dropped." - we&#= 39;d keep this language. =C2=A0 =C2=A0This said, do you agree that having a= different idle-timeout value for the various use-cases makes sense?



OK -- sorry I forgot that notification text was already in there.

I agree with your proposal to have 3 different defa= ults

=C2=A0
Kent

Andy

--089e0158ba0ac50a960519d79181-- From nobody Wed Jul 1 17:40:31 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140C41B2C95 for ; Wed, 1 Jul 2015 17:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBpJF2hKDehZ for ; Wed, 1 Jul 2015 17:40:27 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4731B2CB0 for ; Wed, 1 Jul 2015 17:40:14 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-e4-5594886bfabb Received: from ESGSCHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 98.3D.32595.C6884955; Thu, 2 Jul 2015 02:40:13 +0200 (CEST) Received: from ESGSCMB103.ericsson.se ([169.254.3.71]) by ESGSCHC008.ericsson.se ([146.11.116.89]) with mapi id 14.03.0210.002; Thu, 2 Jul 2015 08:40:11 +0800 From: Mandy Liu To: Per Hedeland , Phil Shafer Thread-Topic: [Netconf] About grouping changed-by-parms definition in RFC6470 Thread-Index: AdCz3ik/l2y7snXqTLuNFTFR8vTddf//3MEAgAAEKID//uBhwA== Date: Thu, 2 Jul 2015 00:40:10 +0000 Message-ID: References: <201507011507.t61F764t019786@idle.juniper.net> <55940597.3020905@tail-f.com> In-Reply-To: <55940597.3020905@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW5ux5RQg1d7pC2mbrrNarGtdQ27 xZIz69kdmD2WLPnJ5HG96Sq7x8Zfi1kCmKO4bFJSczLLUov07RK4MlYeXc1csJurYt40/wbG dRxdjJwcEgImEj0/LrJD2GISF+6tZ+ti5OIQEjjKKDGz4S8ThLOIUWLPzZUsIFVsAhoSj19N AusQEXCUmNd7gxGkiFngJKPE/Om/mEESwgI+Evu6dzFBFPlKtJz/zgZhO0mcbZ4FZrMIqEh0 dWwDG8QLVHPvaS9Yr5BAlMT2+deAejk4OAW0JK6dswIJMwJd9/3UGrCRzALiEreezGeCuFpA Ysme88wQtqjEy8f/WCFsJYnGV9ug6nUkFuz+xAZha0ssW/iaGWKtoMTJmU9YJjCKzUIydhaS lllIWmYhaVnAyLKKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCmDm75rbqD8fIbx0OMAhyM Sjy8CzwnhwqxJpYVV+YeYpTmYFES552xOS9USCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6MS c7behhkaDPudfz4XrhZI4v9TnbLuwN7JN4Js5+/Z+0e99Ojf4zVG6snZVd6uiQvXsxlIx2aE ls64EnPMXOdnzC/tN1drN5cKFjDMZHGqel+flzlFvtTxvHfwxt/ppQK9+lyp+gvk1uks83Xf clTCozN3pvamS3d2RZ2ZYdmzdNHkU9bbHZRYijMSDbWYi4oTAf+EZQSKAgAA Archived-At: Cc: Adrian Pan , Harry Huang , Qifeng Zhang , "netconf@ietf.org" , Wei Luo S Subject: Re: [Netconf] About grouping changed-by-parms definition in RFC6470 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 00:40:29 -0000 Ok, got it. Thanks for your replies, Per! Regards, Mandy -----Original Message----- From: Per Hedeland [mailto:per@tail-f.com]=20 Sent: Wednesday, July 01, 2015 11:22 PM To: Phil Shafer Cc: Mandy Liu; Adrian Pan; Harry Huang; Qifeng Zhang; netconf@ietf.org; Wei= Luo S Subject: Re: [Netconf] About grouping changed-by-parms definition in RFC647= 0 On 2015-07-01 17:07, Phil Shafer wrote: > Mandy Liu writes: >> The grouping "changed-by-parms" is defined in RFC 6470 below. Per my=20 >> unders=3D tanding there should be a case "by-server" in the choice=20 >> "server-or-user". =3D The 'server' leaf implies a case called 'server' per the shorthand rule in = RFC 6020 sect 7.9.2. Wrapping it in a redundant 'case by-server { }' would perhaps be a bit more symmetric, but it is irrelevant for the actual = interface. (I.e. the 'changed-by' container will have either the 'server' l= eaf or the 'username', 'session-id', and 'source-host' leafs.) > Also "parms" seems like an odd terminology to use. "nodes" or "data" > might be less odd. The grouping description says "Common parameters to identify the source of a change event, such as a configuration or capability change."; - and that's what it is. The actually changed nodes are not part of this gr= ouping. --Per Hedeland From nobody Wed Jul 1 17:45:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E011B2C67 for ; Wed, 1 Jul 2015 17:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 CTgIfKcGZJUI for ; Wed, 1 Jul 2015 17:44:58 -0700 (PDT) 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 7EF3F1B2BFE for ; Wed, 1 Jul 2015 17:44:57 -0700 (PDT) Received: by lagx9 with SMTP id x9so51035915lag.1 for ; Wed, 01 Jul 2015 17:44:56 -0700 (PDT) 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=WxiCcsjkFmn25SbrY5XpPWvwLrliWrIKhHKa6yDo9Vk=; b=MOvQIYANxhwzTuku6ruvMFhNpceu3/8lQBgf+KOO5qXXe/gLCi5AJ1TAUa8Y+TFv/D LvNdDWlPqXM9yPFsaw6m9bnAZ6yR7M3TCm/yRcoWAmyrmAgR7X7iL6+DgsY3Ql1q+3Cb Zs8DyZ8mVRIJ+gIa8gEkj9ki6Vj3FG//fA4K1W7AAasLN6RIs9d9cwEvb+9xz6Bf1w2f GnDsx5WMoCtc/nOj5GSPMjEZmnK3f8DyC9RKOMQJs9gl6s9LoyebGNIKFk1ODTichduD oWCKPOxW0gNYvDR6r0rSCz2q1zwhSPrnhf+nVRqgwQFDcCJMmyEbRdqwGFcrqoSKDOhP tMUQ== X-Gm-Message-State: ALoCoQnenMfxl2ExaCFFX6ztG+N/WAN+sLTrpD77ZmZAApC0PCz+0U7lMTJBDj7Viscb0kpEQBiz MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr27796246lab.82.1435797895889; Wed, 01 Jul 2015 17:44:55 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 1 Jul 2015 17:44:55 -0700 (PDT) In-Reply-To: References: <20150627.101927.980507351929498326.mbj@tail-f.com> <20150628.101115.524154870753102418.mbj@tail-f.com> <20150630.104449.916352783153186338.mbj@tail-f.com> <20150630124503.GA5406@elstar.local> Date: Wed, 1 Jul 2015 17:44:55 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3677e8de18c0519d9bfbe Archived-At: Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 00:45:01 -0000 --001a11c3677e8de18c0519d9bfbe Content-Type: text/plain; charset=UTF-8 Hi, I am going to update the draft so the conformance leaf is an enumeration with 'implement' and 'import' enums. The 'none' enum is not needed because the deviations are listed inside the module entry. A module server would return the conformance for the proxied server, not itself. No new objects will be added. Only item # is being addressed. Every module the server implements with be listed once with conformance=implement. Every module and revision that those modules import (rippled through all imports) will be listed in the library, with conformance=import, except of course if the imported module is also an implemented module. No other modules will be listed. Andy On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman wrote: > > > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> Writing as technical contributor... >> >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: >> > Hi, >> > >> > Here's a short summary, and then some questions for the WG. >> > >> > The ietf-yang-library module is designed to serve two purposes: >> > >> > 1. A protocol-independent advertisement mechanism for YANG 1.1 >> > modules. >> > >> > 2. A list of the YANG modules stored in a server. >> > >> > >> > Q1. Do you agree with these goals? >> >> I primarily care about goal 1. >> >> > Q2. Should this module be designed to work with both YANG 1.0 and >> > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? >> > >> > If it should not be defined using YANG 1.1, why is this module >> > special? >> >> I assume this module will sooner or later be YANG 1.1 anyway. >> >> > Q3. Should the /modules/module list be designed to store both YANG >> > 1.0 and YANG 1.1 modules? >> >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not have >> revised all published YANG data models that were written using YANG >> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG >> 1.1 modules. >> > > > Yes -- We also agreed that we would not be republishing modules > just to change the yang-version to 1.1. > > There are lots of YANG modules in progress at this time. > Perhaps 3 out of 100 are relying on YANG 1.1 statements. > It seems rather disruptive to declare all module must be YANG 1.1 > since it has not even made it through WGLC yat, let alone > be published as an RFC, let alone be implemented > in real tool-chains. > > I suspect if people find out the only think YANG 1.1 in their module > (preventing their existing tools from working) is a yang-version-stmt, > they might not be too happy. > > > Andy > > >> >> > Q4. Consider these modules, which both import foo without revision: >> > >> > module a { ... import foo; ... } >> > module b { ... import foo; ... } >> > >> > Do we require a server that implements both a and b to use the >> > same revision of foo? >> > >> > If the answer is yes, we need to indicate the default revision >> > that the server uses in the model: >> > >> > container modules { >> > ... >> > list module { >> > ... >> > leaf default-revision { >> > type boolean; >> > default false; >> > description >> > "Indicates that this revision is used by the server if >> > this module is imported without a specific revision >> > date."; >> > } >> > } >> > } >> > >> > If the answer is no, note that this puts an implementation burden >> > on the client. A client cannot simply download all listed >> > modules, and load/compile/process them as one set. >> > >> > If the anwser is no, I propose that we extend the module as such: >> > >> > container modules { >> > ... >> > list module { >> > ... >> > list imported-without-revision { >> > key "name revision"; >> > ... >> > } >> > } >> > } >> > >> > A server could then list: >> > >> > >> > a >> > 2015-01-01 >> > >> > foo >> > 2002-02-02 >> > >> > >> > >> > b >> > 2015-01-01 >> > >> > foo >> > 2001-01-01 >> > >> > >> >> I believe truth is advertisement is a good thing. In the SNMP world, >> not all pieces of the instrumentation were moving at the same pace and >> I would be somewhat surprised if this would be the case for all >> implementations in the NETCONF world. Hence, I rather accept that an >> import of foo without revision may resolve to different versions of >> foo for different imports. >> >> /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 >> > > --001a11c3677e8de18c0519d9bfbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am going to update the draft so t= he conformance leaf
is an enumeration with 'implement' an= d 'import' enums.
The 'none' enum is not needed b= ecause the deviations are
listed inside the module entry.=C2=A0 A= module server would return
the conformance for the proxied serve= r, not itself.

No new objects will be added.
=
Only item # is being addressed.

Every module = the server implements with be listed once
with conformance=3Dimpl= ement.=C2=A0 Every module and revision
that those modules import = (rippled through all imports) will be listed
in the library, with= conformance=3Dimport, except of
course if the imported module is= also an implemented module.
No other modules will be listed.


Andy


On Tue, Jun 30, 2015 at = 11:10 AM, Andy Bierman <andy@yumaworks.com> wrote:

<= br>
On Tue, Jun 30, 2015 at 5:45 AM, Juergen Scho= enwaelder <j.schoenwaelder@jacobs-university.de>= wrote:
Writing as technical contr= ibutor...

On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote:
> Hi,
>
> Here's a short summary, and then some questions for the WG.
>
> The ietf-yang-library module is designed to serve two purposes:
>
>=C2=A0 =C2=A01.=C2=A0 A protocol-independent advertisement mechanism fo= r YANG 1.1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0modules.
>
>=C2=A0 =C2=A02.=C2=A0 A list of the YANG modules stored in a server. >
>
> Q1.=C2=A0 Do you agree with these goals?

I primarily care about goal 1.

> Q2.=C2=A0 Should this module be designed to work with both YANG 1.0 an= d
>=C2=A0 =C2=A0 =C2=A0 YANG 1.1 servers - i.e., should it have yang-versi= on 1.1 or not?
>
>=C2=A0 =C2=A0 =C2=A0 If it should not be defined using YANG 1.1, why is= this module
>=C2=A0 =C2=A0 =C2=A0 special?

I assume this module will sooner or later be YANG 1.1 anyway.

> Q3.=C2=A0 Should the /modules/module list be designed to store both YA= NG
>=C2=A0 =C2=A0 =C2=A0 1.0 and YANG 1.1 modules?

Yes. Even if YANG 1.1 hits the street tomorrow, we will not have
revised all published YANG data models that were written using YANG
1.0. So a server needs to be able to announce both YANG 1.0 and YANG
1.1 modules.


Yes -- We a= lso agreed that we would not be republishing modules
just to chan= ge the yang-version to 1.1.

There are lots of YANG= modules in progress at this time.
Perhaps 3 out of 100 are relyi= ng on YANG 1.1 statements.
It seems rather disruptive to declare = all module must be YANG 1.1
since it has not even made it through= WGLC yat, let alone
be published as an RFC, let alone be impleme= nted
in real tool-chains.

I suspect if p= eople find out the only think YANG 1.1 in their module
(preventin= g their existing tools from working) is a yang-version-stmt,
they= might not be too happy.


Andy
=
=C2=A0

> Q4.=C2=A0 Consider these modules, which both import foo without revisi= on:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 module a { ... import foo; ... }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 module b { ... import foo; ... }
>
>=C2=A0 =C2=A0 =C2=A0 Do we require a server that implements both a and = b to use the
>=C2=A0 =C2=A0 =C2=A0 same revision of foo?
>
>=C2=A0 =C2=A0 =C2=A0 If the answer is yes, we need to indicate the defa= ult revision
>=C2=A0 =C2=A0 =C2=A0 that the server uses in the model:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf default-revision {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boolean;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Indicates= that this revision is used by the server if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this modu= le is imported without a specific revision
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0date.&quo= t;;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 If the answer is no, note that this puts an implem= entation burden
>=C2=A0 =C2=A0 =C2=A0 on the client.=C2=A0 A client cannot simply downlo= ad all listed
>=C2=A0 =C2=A0 =C2=A0 modules, and load/compile/process them as one set.=
>
>=C2=A0 =C2=A0 =C2=A0 If the anwser is no, I propose that we extend the = module as such:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list imported-without-revisio= n {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key "name revisio= n";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 A server could then list:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>a</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01-01</revisi= on>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo</name> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2002-02-02<= /revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-revision> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>b</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01-01</revisi= on>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo</name> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2001-01-01<= /revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-revision> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>

I believe truth is advertisement is a good thing. In the SNMP world,
not all pieces of the instrumentation were moving at the same pace and
I would be somewhat surprised if this would be the case for all
implementations in the NETCONF world. Hence, I rather accept that an
import of foo without revision may resolve to different versions of
foo for different imports.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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


--001a11c3677e8de18c0519d9bfbe-- From nobody Thu Jul 2 07:39:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCCF1A890E for ; Thu, 2 Jul 2015 07:39:58 -0700 (PDT) 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_20=-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 dGE1puYH3yOK for ; Thu, 2 Jul 2015 07:39:57 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 17F2A1A891D for ; Thu, 2 Jul 2015 07:39:54 -0700 (PDT) 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 KAA03038 for ; Thu, 2 Jul 2015 10:39:45 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t62Edjmu064586 for ; Thu, 2 Jul 2015 10:39:45 -0400 (EDT) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t62Edi2J064585; Thu, 2 Jul 2015 10:39:44 -0400 (EDT) (envelope-from luchuk) Date: Thu, 2 Jul 2015 10:39:44 -0400 (EDT) From: Alan Luchuk Message-Id: <201507021439.t62Edi2J064585@mainfs.snmp.com> To: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: Re: [Netconf] WGLC for draft-ietf-netconf-call-home-08 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 14:39:58 -0000 Hello, I have reviewed I-D draft-ietf-netconf-call-home-08 and have found no issues. Regards, --Alan From nobody Thu Jul 2 14:04:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1801A0266; Thu, 2 Jul 2015 14:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to04q0UljmoK; Thu, 2 Jul 2015 14:04:00 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD161A038D; Thu, 2 Jul 2015 14:04:00 -0700 (PDT) Received: by pactm7 with SMTP id tm7so45867066pac.2; Thu, 02 Jul 2015 14:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=B2aatS6Q2+3086S98M3ZVrpdLWDlq3Q3nEuxtuWo2a8=; b=MhlecoPhng17aOir3fnn3BYHI2TH/Jibmyn+rd1ygg0/Zpo+kgU1/Zm/BJu+duK/60 fpwabbHI9GQ3Kx4Iet6kzyOXocAbRvF9W8qSf7BYujgcb89gcBfnMg61CjQDPZ78aLdS fsogZnswq8MbjSH9GNQJuAE1CFznUFfRqmLDKl65R8Wt+R91EdP9iv52SWWA574ScD7f EDHxY3gCj3Ixt4z3wJ2XWemxiKMSDJ+h+NSe6Rk5tnBRldpqfnKuzAkfX2AUU7if7msC gGNepSmrSt2S6K+qeECyoq0Y93Js7iHcVTMYmcRCYySFM2nNzB6VVuaSPBaOLgvtE4BK eTeA== X-Received: by 10.66.121.230 with SMTP id ln6mr13230571pab.17.1435871039973; Thu, 02 Jul 2015 14:03:59 -0700 (PDT) Received: from ?IPv6:2001:420:302:1330:7197:4184:582e:ba8f? ([2001:420:302:1330:7197:4184:582e:ba8f]) by mx.google.com with ESMTPSA id mk6sm6691816pab.9.2015.07.02.14.03.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 14:03:59 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 2 Jul 2015 14:06:00 -0700 Message-Id: <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> To: "Eric Voit (evoit)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , NETMOD Working Group , "BRUNGARD, DEBORAH A" , Netconf Subject: Re: [Netconf] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:04:01 -0000 --Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) = wrote: >=20 > What might be interesting for a NETCONF speaking slot is an analysis = of what requirements from =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2= =80=9D are met by =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 Susan or somebody from i2rs WG can decide whether the suggested = presentation would help clarify i2rs requirements to NETCONF. =46rom a = personal perspective it would certainly help to have examples of how the = requirements could be met. Cheers. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

What might be = interesting for a NETCONF speaking slot is an analysis of what = requirements from =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D = are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. 

Susan or somebody from i2rs WG can = decide whether the suggested presentation would help clarify i2rs = requirements to NETCONF. =46rom a personal perspective it would = certainly help to have examples of how the requirements could be = met.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59-- From nobody Thu Jul 2 14:06:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA01A1A59; Thu, 2 Jul 2015 14:06:44 -0700 (PDT) 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 Skv4ZI2vbl91; Thu, 2 Jul 2015 14:06:43 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 253CC1A1A78; Thu, 2 Jul 2015 14:06:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Mahesh Jethanandani'" , "'Eric Voit \(evoit\)'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> In-Reply-To: <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> Date: Thu, 2 Jul 2015 17:06:41 -0400 Message-ID: <01d801d0b50a$feeed5f0$fccc81d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01D0B4E9.77DEBC90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLAkJXomwCCiG/twIuXbN7nP05VtA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, 'NETMOD Working Group' , "'BRUNGARD, DEBORAH A'" , 'Netconf' Subject: Re: [Netconf] [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:06:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D9_01D0B4E9.77DEBC90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mahesh:=20 =20 I think this would really help show how the requirements can be met. = Let=E2=80=99s plan on Eric doing an analysis of what requirements are = met by =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 =20 Sue=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani Sent: Thursday, July 02, 2015 5:06 PM To: Eric Voit (evoit) Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; = BRUNGARD, DEBORAH A; Alexander Clemm (alex); Netconf; Susan Hares Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS = protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 =20 On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) wrote: =20 What might be interesting for a NETCONF speaking slot is an analysis of = what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 =20 Susan or somebody from i2rs WG can decide whether the suggested = presentation would help clarify i2rs requirements to NETCONF. From a = personal perspective it would certainly help to have examples of how the = requirements could be met. =20 Cheers. =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 ------=_NextPart_000_01D9_01D0B4E9.77DEBC90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

I think this would really help show how the requirements can be met. = Let=E2=80=99s plan on Eric doing an analysis of what requirements are = met by =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. =

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani
Sent: Thursday, July 02, 2015 5:06 = PM
To: Eric Voit (evoit)
Cc: = Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; BRUNGARD, = DEBORAH A; Alexander Clemm (alex); Netconf; Susan = Hares
Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] = Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - = 11:30am ET)

 

 

On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

 

What might be interesting for a NETCONF speaking slot is an analysis = of what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. <= /p>

 

Susan or somebody from i2rs WG can decide whether the = suggested presentation would help clarify i2rs requirements to NETCONF. = >From a personal perspective it would certainly help to have examples of = how the requirements could be met.

 

Cheers.

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_01D9_01D0B4E9.77DEBC90-- From nobody Fri Jul 3 12:39:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143291A7005; Fri, 3 Jul 2015 12:39:28 -0700 (PDT) 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 qd_brI25Worl; Fri, 3 Jul 2015 12:39:26 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 DAC061A7000; Fri, 3 Jul 2015 12:39:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'BELOTTI, SERGIO \(SERGIO\)'" , "'Mahesh Jethanandani'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> In-Reply-To: Date: Fri, 3 Jul 2015 15:39:23 -0400 Message-ID: <01c801d0b5c7$f7058d80$e510a880$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C9_01D0B5A6.6FF65E80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLAkJXomwCOt7Bop0On+6Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , 'Netconf' , 'NETMOD Working Group' Subject: Re: [Netconf] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 19:39:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C9_01D0B5A6.6FF65E80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sergio:=20 =20 Just in case you missed in the rest of the email threads:=20 =20 Yes =E2=80=93 I2RS plans to coordinate the topology model with the TEAS = Topology model. The work began with the authors last week, and will = continue in a discussion of the TEAS And Topology authors next week = (7/8) in a conference call, and at IETF on Sunday (7/19 from 6-7pm).=20 =20 The I2RS WG will provide an update on the merging of these two models. = If you are a TEAS author, please let me know. If you wish to help on = an I2RS Topology model, the I2RS working group would appreciate your = review of any model.=20 =20 I am personally working on the service layer model.=20 =20 Sue Hares=20 From: BELOTTI, SERGIO (SERGIO) = [mailto:sergio.belotti@alcatel-lucent.com]=20 Sent: Wednesday, July 01, 2015 5:28 AM To: Susan Hares; 'Mahesh Jethanandani' Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; 'NETMOD Working Group'; = 'Netconf'; 'BRUNGARD, DEBORAH A' Subject: RE: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol = and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 Hello Susan, - Topology model which is a composite of: o Generic topology model: = = draft-ietf-i2rs-yang-network-topo-01=20 o L3 topology model: = = draft-ietf-i2rs-yang-l3-topology-00=20 o L2 topology model: = draft-ietf-i2rs-yang-l2-network-topology-00=20 o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 = released later this week).=20 o Service topology model: draft-hares-i2rs-service-topo-yang-model-00 = (released on Wednesday) =20 At this time, none of the Topology models utilize Traffic engineering. = It is anticipated that these models will support traffic engineering. =20 =20 Reading this , my question is whether there is intention for Traffic = Engineering part of topology model to exploit/coordinate with Teas , and = particularly with=20 draft-liu-teas-yang-te-topo or to proceed with distinct contributions = internal to I2RS. =20 Thanks Sergio =20 ------=_NextPart_000_01C9_01D0B5A6.6FF65E80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sergio:

 

Just in case you missed in the rest of the email threads: =

 

Yes =E2=80=93 I2RS plans to coordinate the topology model with the = TEAS Topology model.=C2=A0 The work began with the authors last week, = and will continue in a discussion of the TEAS And Topology authors next = week (7/8) =C2=A0in a conference call, and at IETF on Sunday (7/19 from = 6-7pm).

 

The I2RS WG will provide an update on the merging of these two = models.=C2=A0 If you are a TEAS author, please let me know. = =C2=A0=C2=A0If you wish to help on an I2RS Topology model, the I2RS = working group would appreciate your review of any model. =

 

I am personally working on the service layer model. =

 

Sue Hares

From:= = BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] =
Sent: Wednesday, July 01, 2015 5:28 AM
To: Susan = Hares; 'Mahesh Jethanandani'
Cc: Rtg-yang-coord@ietf.org; = i2rs@ietf.org; 'NETMOD Working Group'; 'Netconf'; 'BRUNGARD, DEBORAH = A'
Subject: RE: [Rtg-yang-coord] [netmod] Requirements for = I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am = ET)

 

Hello Susan,

-        = ;  Topology model which is a composite = of:=

o   Generic topology model: draft-ietf-i2rs-yang-network-topo-01 =

o   L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 =

o   L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 =

o   L1 Topology model: draft-zhang= -i2rs-l1-topo-yang-model-01 (-02 released later this week). 

o   Service topology model: draft-hares= -i2rs-service-topo-yang-model-00 (released on = Wednesday)

 =

At this = time, none of the Topology models utilize Traffic engineering.  It = is anticipated that these models will support traffic engineering. =  

 

Reading this , my question is whether there is = intention for Traffic Engineering part of topology model to = exploit/coordinate with Teas , and particularly with =

 draft-liu-teas-yang-te-topo or to proceed = with distinct contributions internal to I2RS.

 

Thanks

Sergio

 

------=_NextPart_000_01C9_01D0B5A6.6FF65E80-- From nobody Fri Jul 3 13:45:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F95E1A87B0; Fri, 3 Jul 2015 13:45:35 -0700 (PDT) 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 kv5q678g2fsY; Fri, 3 Jul 2015 13:45:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 969C21A87AF; Fri, 3 Jul 2015 13:45:30 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 57E841AE047F; Fri, 3 Jul 2015 22:45:28 +0200 (CEST) Date: Fri, 03 Jul 2015 22:45:27 +0200 (CEST) Message-Id: <20150703.224527.1947263992217736555.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150630124503.GA5406@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: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 20:45:35 -0000 Andy Bierman wrote: > Hi, > > I am going to update the draft so the conformance leaf > is an enumeration with 'implement' and 'import' enums. > The 'none' enum is not needed because the deviations are > listed inside the module entry. Don't we have to list the deviation module's revision as well? As you noted, the revision is needed in . If we don't list the deviation module in the main list, it won't be possible to download such modules over RESTCONF. > A module server would return > the conformance for the proxied server, not itself. > > No new objects will be added. This is up to the WG to decide. So far, three people (myself included) have said that they want to solve the advertisement problem, "indicate the import tree" as you put it, and the two proposed solutions require new nodes in the module. It would be good to hear from more people. I think your objection to addressing this problem is that if import w/o revision is used, the client by design cannot/should not know which revision the server used. Did I get that right? /martin > Only item # is being addressed. > > Every module the server implements with be listed once > with conformance=implement. Every module and revision > that those modules import (rippled through all imports) will be listed > in the library, with conformance=import, except of > course if the imported module is also an implemented module. > No other modules will be listed. > > > Andy > > > On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman wrote: > > > > > > > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > >> Writing as technical contributor... > >> > >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: > >> > Hi, > >> > > >> > Here's a short summary, and then some questions for the WG. > >> > > >> > The ietf-yang-library module is designed to serve two purposes: > >> > > >> > 1. A protocol-independent advertisement mechanism for YANG 1.1 > >> > modules. > >> > > >> > 2. A list of the YANG modules stored in a server. > >> > > >> > > >> > Q1. Do you agree with these goals? > >> > >> I primarily care about goal 1. > >> > >> > Q2. Should this module be designed to work with both YANG 1.0 and > >> > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? > >> > > >> > If it should not be defined using YANG 1.1, why is this module > >> > special? > >> > >> I assume this module will sooner or later be YANG 1.1 anyway. > >> > >> > Q3. Should the /modules/module list be designed to store both YANG > >> > 1.0 and YANG 1.1 modules? > >> > >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not have > >> revised all published YANG data models that were written using YANG > >> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG > >> 1.1 modules. > >> > > > > > > Yes -- We also agreed that we would not be republishing modules > > just to change the yang-version to 1.1. > > > > There are lots of YANG modules in progress at this time. > > Perhaps 3 out of 100 are relying on YANG 1.1 statements. > > It seems rather disruptive to declare all module must be YANG 1.1 > > since it has not even made it through WGLC yat, let alone > > be published as an RFC, let alone be implemented > > in real tool-chains. > > > > I suspect if people find out the only think YANG 1.1 in their module > > (preventing their existing tools from working) is a yang-version-stmt, > > they might not be too happy. > > > > > > Andy > > > > > >> > >> > Q4. Consider these modules, which both import foo without revision: > >> > > >> > module a { ... import foo; ... } > >> > module b { ... import foo; ... } > >> > > >> > Do we require a server that implements both a and b to use the > >> > same revision of foo? > >> > > >> > If the answer is yes, we need to indicate the default revision > >> > that the server uses in the model: > >> > > >> > container modules { > >> > ... > >> > list module { > >> > ... > >> > leaf default-revision { > >> > type boolean; > >> > default false; > >> > description > >> > "Indicates that this revision is used by the server if > >> > this module is imported without a specific revision > >> > date."; > >> > } > >> > } > >> > } > >> > > >> > If the answer is no, note that this puts an implementation burden > >> > on the client. A client cannot simply download all listed > >> > modules, and load/compile/process them as one set. > >> > > >> > If the anwser is no, I propose that we extend the module as such: > >> > > >> > container modules { > >> > ... > >> > list module { > >> > ... > >> > list imported-without-revision { > >> > key "name revision"; > >> > ... > >> > } > >> > } > >> > } > >> > > >> > A server could then list: > >> > > >> > > >> > a > >> > 2015-01-01 > >> > > >> > foo > >> > 2002-02-02 > >> > > >> > > >> > > >> > b > >> > 2015-01-01 > >> > > >> > foo > >> > 2001-01-01 > >> > > >> > > >> > >> I believe truth is advertisement is a good thing. In the SNMP world, > >> not all pieces of the instrumentation were moving at the same pace and > >> I would be somewhat surprised if this would be the case for all > >> implementations in the NETCONF world. Hence, I rather accept that an > >> import of foo without revision may resolve to different versions of > >> foo for different imports. > >> > >> /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 Fri Jul 3 14:12:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80ED1A882E for ; Fri, 3 Jul 2015 14:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 amA_-Ov7Dxjy for ; Fri, 3 Jul 2015 14:12:33 -0700 (PDT) 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 C13661A8828 for ; Fri, 3 Jul 2015 14:12:31 -0700 (PDT) Received: by laar3 with SMTP id r3so96831643laa.0 for ; Fri, 03 Jul 2015 14:12:30 -0700 (PDT) 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=au5mkzqpOJ2ywsotbopAqIiB5ix+ouKeSgeVswCLs1w=; b=Sa7uSmfmys4qMEOJ5NKVhsqr9/WVH5A43GoBOJszz1vxaSlCYOxvYiLlxgCJyw1wJz /nMCCrUQV1Y23Vz2uagZMF27X0kvu/ZuvWs/NL9X2CPT2aJ9si3clJGF6LnzB5ftvCtG 7Ex+lYPHJ11e6JBA1DkKWjA3lscaDXWgat63nW55GziNG88W91cEZgyhiGLeLiuVmq6Q SWFV5l6rFoerQf+5bXWCSin+wB5hnnyuvw4slyqVurLOVyj3f2pA4bKETtxPbn4zjepx fMZjVEbNYo7ES+EWfjpekVCqIhwZDW08VDbPUH6pSR264AwwaCBtCoZHDmwHD9nd1Usy 9Qag== X-Gm-Message-State: ALoCoQm1ko5T1G8BdnsDKi/CqusnCHuFQ9VJ98PXWUHlNm7ISs1bn3gdeTWGvnYiFwu3CBL4RwEW MIME-Version: 1.0 X-Received: by 10.152.43.69 with SMTP id u5mr37340642lal.119.1435957950144; Fri, 03 Jul 2015 14:12:30 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Jul 2015 14:12:30 -0700 (PDT) In-Reply-To: <20150703.224527.1947263992217736555.mbj@tail-f.com> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> Date: Fri, 3 Jul 2015 14:12:30 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c3666087f8860519ff03f1 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 21:12:36 -0000 --001a11c3666087f8860519ff03f1 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 3, 2015 at 1:45 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I am going to update the draft so the conformance leaf > > is an enumeration with 'implement' and 'import' enums. > > The 'none' enum is not needed because the deviations are > > listed inside the module entry. > > Don't we have to list the deviation module's revision as well? As you > noted, the revision is needed in . > > If we don't list the deviation module in the main list, it won't be > possible to download such modules over RESTCONF. > > That means that the deviation leaf-list has to be a list to include name and revision. Then there can be a schema leaf in each of those entries. If the deviations module also has other definitions (a bad practice) then it can be present in the 'module' list for 'implements' or 'imports'. This should be rare. > > A module server would return > > the conformance for the proxied server, not itself. > > > > No new objects will be added. > > This is up to the WG to decide. So far, three people (myself > included) have said that they want to solve the advertisement problem, > "indicate the import tree" as you put it, and the two proposed > solutions require new nodes in the module. > > I should say no new objects to this release. The WG can always decide another revision is needed. It would be good to hear from more people. > > I think your objection to addressing this problem is that if import > w/o revision is used, the client by design cannot/should not know > which revision the server used. Did I get that right? > > I propose this text in the conformance leaf: For import statements that do not specify a revision date, the most recent revision in the library SHOULD be used by the server."; It seems like a lot of data will be needed to model the dependency tree for every import-stmt in every module. Don't forget every include-stmt as well, since submodules can import with or without revision. IMO "SHOULD use latest" is good enough. Perhaps modules should use import-by-revision when they are published as RFCs (as Lada suggested). As Jeff pointed out, the only time it is safe to use import/include without revision is if you are sure the imported module (or included submodule) is the one and only revision that has, or ever will exist. Even within a single naming organization this might be a bad assumption to make. > /martin > Andy > > > > > Only item # is being addressed. > > > > Every module the server implements with be listed once > > with conformance=implement. Every module and revision > > that those modules import (rippled through all imports) will be listed > > in the library, with conformance=import, except of > > course if the imported module is also an implemented module. > > No other modules will be listed. > > > > > > Andy > > > > > > On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman > wrote: > > > > > > > > > > > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > >> Writing as technical contributor... > > >> > > >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: > > >> > Hi, > > >> > > > >> > Here's a short summary, and then some questions for the WG. > > >> > > > >> > The ietf-yang-library module is designed to serve two purposes: > > >> > > > >> > 1. A protocol-independent advertisement mechanism for YANG 1.1 > > >> > modules. > > >> > > > >> > 2. A list of the YANG modules stored in a server. > > >> > > > >> > > > >> > Q1. Do you agree with these goals? > > >> > > >> I primarily care about goal 1. > > >> > > >> > Q2. Should this module be designed to work with both YANG 1.0 and > > >> > YANG 1.1 servers - i.e., should it have yang-version 1.1 or > not? > > >> > > > >> > If it should not be defined using YANG 1.1, why is this module > > >> > special? > > >> > > >> I assume this module will sooner or later be YANG 1.1 anyway. > > >> > > >> > Q3. Should the /modules/module list be designed to store both YANG > > >> > 1.0 and YANG 1.1 modules? > > >> > > >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not have > > >> revised all published YANG data models that were written using YANG > > >> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG > > >> 1.1 modules. > > >> > > > > > > > > > Yes -- We also agreed that we would not be republishing modules > > > just to change the yang-version to 1.1. > > > > > > There are lots of YANG modules in progress at this time. > > > Perhaps 3 out of 100 are relying on YANG 1.1 statements. > > > It seems rather disruptive to declare all module must be YANG 1.1 > > > since it has not even made it through WGLC yat, let alone > > > be published as an RFC, let alone be implemented > > > in real tool-chains. > > > > > > I suspect if people find out the only think YANG 1.1 in their module > > > (preventing their existing tools from working) is a yang-version-stmt, > > > they might not be too happy. > > > > > > > > > Andy > > > > > > > > >> > > >> > Q4. Consider these modules, which both import foo without revision: > > >> > > > >> > module a { ... import foo; ... } > > >> > module b { ... import foo; ... } > > >> > > > >> > Do we require a server that implements both a and b to use the > > >> > same revision of foo? > > >> > > > >> > If the answer is yes, we need to indicate the default revision > > >> > that the server uses in the model: > > >> > > > >> > container modules { > > >> > ... > > >> > list module { > > >> > ... > > >> > leaf default-revision { > > >> > type boolean; > > >> > default false; > > >> > description > > >> > "Indicates that this revision is used by the server > if > > >> > this module is imported without a specific revision > > >> > date."; > > >> > } > > >> > } > > >> > } > > >> > > > >> > If the answer is no, note that this puts an implementation > burden > > >> > on the client. A client cannot simply download all listed > > >> > modules, and load/compile/process them as one set. > > >> > > > >> > If the anwser is no, I propose that we extend the module as > such: > > >> > > > >> > container modules { > > >> > ... > > >> > list module { > > >> > ... > > >> > list imported-without-revision { > > >> > key "name revision"; > > >> > ... > > >> > } > > >> > } > > >> > } > > >> > > > >> > A server could then list: > > >> > > > >> > > > >> > a > > >> > 2015-01-01 > > >> > > > >> > foo > > >> > 2002-02-02 > > >> > > > >> > > > >> > > > >> > b > > >> > 2015-01-01 > > >> > > > >> > foo > > >> > 2001-01-01 > > >> > > > >> > > > >> > > >> I believe truth is advertisement is a good thing. In the SNMP world, > > >> not all pieces of the instrumentation were moving at the same pace and > > >> I would be somewhat surprised if this would be the case for all > > >> implementations in the NETCONF world. Hence, I rather accept that an > > >> import of foo without revision may resolve to different versions of > > >> foo for different imports. > > >> > > >> /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 > > >> > > > > > > > --001a11c3666087f8860519ff03f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 3, 2015 at 1:45 PM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> I am going to update the draft so the conformance leaf
> is an enumeration with 'implement' and 'import' enums.=
> The 'none' enum is not needed because the deviations are
> listed inside the module entry.

Don't we have to list the deviation module's revision as well?=C2= =A0 As you
noted, the revision is needed in <get-schema>.

If we don't list the deviation module in the main list, it won't be=
possible to download such modules over RESTCONF.


That means that the deviation leaf-lis= t has to be a list
to include name and revision.=C2=A0 Then there= can be a schema leaf
in each of those entries.

If the deviations module also has other definitions
(a ba= d practice) then it can be present in the 'module' list
f= or 'implements' or 'imports'.=C2=A0 This should be rare.

=C2=A0
> A module server would return
> the conformance for the proxied server, not itself.
>
> No new objects will be added.

This is up to the WG to decide.=C2=A0 So far, three people (myself
included) have said that they want to solve the advertisement problem,
"indicate the import tree" as you put it, and the two proposed solutions require new nodes in the module.


I should say no new objects to this re= lease.
The WG can always decide another revision is needed.
=


It would be good to hear from more people.

I think your objection to addressing this problem is that if import
w/o revision is used, the client by design cannot/should not know
which revision the server used.=C2=A0 Did I get that right?


I propose this text in the conformance= leaf:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0For import statements that do not specify a revision
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0date, the most = recent revision in the library SHOULD
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0be used by the server.";
<= br>
It seems like a lot of data will be needed to model the depen= dency tree
for every import-stmt in every module.=C2=A0 Don't= forget every include-stmt
as well, since submodules can import w= ith or without revision.

IMO "SHOULD use late= st" is good enough.
Perhaps modules should use import-by-rev= ision when they
are published as RFCs (as Lada suggested).
<= div>
As Jeff pointed out, the only time it is safe to use
import/include without revision is if you are sure the imported
module (or included submodule) is the one and only
revision= that has, or ever will exist.

Even within a singl= e naming organization this might be
a bad assumption to make.




/martin

Andy
=C2=A0



> Only item # is being addressed.
>
> Every module the server implements with be listed once
> with conformance=3Dimplement.=C2=A0 Every module and revision
> that those modules import (rippled through all imports) will be listed=
> in the library, with conformance=3Dimport, except of
> course if the imported module is also an implemented module.
> No other modules will be listed.
>
>
> Andy
>
>
> On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder <
> > j.schoenw= aelder@jacobs-university.de> wrote:
> >
> >> Writing as technical contributor...
> >>
> >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wr= ote:
> >> > Hi,
> >> >
> >> > Here's a short summary, and then some questions for = the WG.
> >> >
> >> > The ietf-yang-library module is designed to serve two pu= rposes:
> >> >
> >> >=C2=A0 =C2=A01.=C2=A0 A protocol-independent advertisemen= t mechanism for YANG 1.1
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0modules.
> >> >
> >> >=C2=A0 =C2=A02.=C2=A0 A list of the YANG modules stored i= n a server.
> >> >
> >> >
> >> > Q1.=C2=A0 Do you agree with these goals?
> >>
> >> I primarily care about goal 1.
> >>
> >> > Q2.=C2=A0 Should this module be designed to work with bo= th YANG 1.0 and
> >> >=C2=A0 =C2=A0 =C2=A0 YANG 1.1 servers - i.e., should it h= ave yang-version 1.1 or not?
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If it should not be defined using YA= NG 1.1, why is this module
> >> >=C2=A0 =C2=A0 =C2=A0 special?
> >>
> >> I assume this module will sooner or later be YANG 1.1 anyway.=
> >>
> >> > Q3.=C2=A0 Should the /modules/module list be designed to= store both YANG
> >> >=C2=A0 =C2=A0 =C2=A0 1.0 and YANG 1.1 modules?
> >>
> >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not h= ave
> >> revised all published YANG data models that were written usin= g YANG
> >> 1.0. So a server needs to be able to announce both YANG 1.0 a= nd YANG
> >> 1.1 modules.
> >>
> >
> >
> > Yes -- We also agreed that we would not be republishing modules > > just to change the yang-version to 1.1.
> >
> > There are lots of YANG modules in progress at this time.
> > Perhaps 3 out of 100 are relying on YANG 1.1 statements.
> > It seems rather disruptive to declare all module must be YANG 1.1=
> > since it has not even made it through WGLC yat, let alone
> > be published as an RFC, let alone be implemented
> > in real tool-chains.
> >
> > I suspect if people find out the only think YANG 1.1 in their mod= ule
> > (preventing their existing tools from working) is a yang-version-= stmt,
> > they might not be too happy.
> >
> >
> > Andy
> >
> >
> >>
> >> > Q4.=C2=A0 Consider these modules, which both import foo = without revision:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module a { ... import foo; ..= . }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module b { ... import foo; ..= . }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 Do we require a server that implemen= ts both a and b to use the
> >> >=C2=A0 =C2=A0 =C2=A0 same revision of foo?
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the answer is yes, we need to ind= icate the default revision
> >> >=C2=A0 =C2=A0 =C2=A0 that the server uses in the model: > >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf default-re= vision {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boo= lean;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default = false;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descript= ion
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &= quot;Indicates that this revision is used by the server if
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0this module is imported without a specific revision
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0date.";
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the answer is no, note that this = puts an implementation burden
> >> >=C2=A0 =C2=A0 =C2=A0 on the client.=C2=A0 A client cannot= simply download all listed
> >> >=C2=A0 =C2=A0 =C2=A0 modules, and load/compile/process th= em as one set.
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the anwser is no, I propose that = we extend the module as such:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list imported-w= ithout-revision {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key &quo= t;name revision";
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 A server could then list:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>a</name&= gt;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01= -01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-re= vision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo&= lt;/name>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>= 2002-02-02</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-r= evision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>b</name&= gt;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01= -01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-re= vision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo&= lt;/name>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>= 2001-01-01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-r= evision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >>
> >> I believe truth is advertisement is a good thing. In the SNMP= world,
> >> not all pieces of the instrumentation were moving at the same= pace and
> >> I would be somewhat surprised if this would be the case for a= ll
> >> implementations in the NETCONF world. Hence, I rather accept = that an
> >> import of foo without revision may resolve to different versi= ons of
> >> foo for different imports.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp= us Ring 1 | 28759 Bremen | Germany
> >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.jacobs-university.de/>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/net= mod
> >>
> >
> >

--001a11c3666087f8860519ff03f1-- From nobody Fri Jul 3 14:16:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E0D1A8846 for ; Fri, 3 Jul 2015 14:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 BiQfe_FQYFkF for ; Fri, 3 Jul 2015 14:16:46 -0700 (PDT) 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 953071A8840 for ; Fri, 3 Jul 2015 14:16:45 -0700 (PDT) Received: by lagx9 with SMTP id x9so96780618lag.1 for ; Fri, 03 Jul 2015 14:16:44 -0700 (PDT) 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=koGJ4TlZ312Xa1O4H7ez/eZXA06WN3gZYPOHpEzxYHI=; b=i5arj2wNdkU7TeQ1DxDZBUJ5fuk3hJ97yviPp6FrGXiWeiZ1PHJUj8sWcZgP/l8Aqe u/Gue3djSah3lRid0yamsmq+x3wYAHjcMbhimpFY20XUraPjOaAfID6aPUV1UqSqZUIm 9q7eeIzrD0P6TZasinCTQf/aV61GQCyF/8vI3KGJViFUMKDvZQJsaUanfAlRUJThgKVk BKbf4VA0sdaPrpeXuuj4EjFzMFP2CSoM6hyNaH1X/SJAntbbyUdDjoQxBq6fLT8C8fW1 CBm6kj3Z1ruBVMTog2qjxFWBKy8yI7rUwzBRi680pOCOGxpSaQCXNLT6U/DEzsTMK7dg S5Mg== X-Gm-Message-State: ALoCoQlKF6e36z5m9fDYmeiwwJJ4mY3KYp3GsoEJCTydLuWbwQnBvoRQVFt9Gj1fbrrMSlj4v17h MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr37367683lab.82.1435958203933; Fri, 03 Jul 2015 14:16:43 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Jul 2015 14:16:43 -0700 (PDT) In-Reply-To: <20150703.224527.1947263992217736555.mbj@tail-f.com> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> Date: Fri, 3 Jul 2015 14:16:43 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c3677ea87cb10519ff124e Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 21:16:49 -0000 --001a11c3677ea87cb10519ff124e Content-Type: text/plain; charset=UTF-8 On Fri, Jul 3, 2015 at 1:45 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I am going to update the draft so the conformance leaf > > is an enumeration with 'implement' and 'import' enums. > > The 'none' enum is not needed because the deviations are > > listed inside the module entry. > > Don't we have to list the deviation module's revision as well? As you > noted, the revision is needed in . > > If we don't list the deviation module in the main list, it won't be > possible to download such modules over RESTCONF. > > I will add 'none' to the enumeration for deviations It would be bad if any file was listed for download more than once Andy > > A module server would return > > the conformance for the proxied server, not itself. > > > > No new objects will be added. > > This is up to the WG to decide. So far, three people (myself > included) have said that they want to solve the advertisement problem, > "indicate the import tree" as you put it, and the two proposed > solutions require new nodes in the module. > > It would be good to hear from more people. > > I think your objection to addressing this problem is that if import > w/o revision is used, the client by design cannot/should not know > which revision the server used. Did I get that right? > > > /martin > > > > > Only item # is being addressed. > > > > Every module the server implements with be listed once > > with conformance=implement. Every module and revision > > that those modules import (rippled through all imports) will be listed > > in the library, with conformance=import, except of > > course if the imported module is also an implemented module. > > No other modules will be listed. > > > > > > Andy > > > > > > On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman > wrote: > > > > > > > > > > > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > >> Writing as technical contributor... > > >> > > >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: > > >> > Hi, > > >> > > > >> > Here's a short summary, and then some questions for the WG. > > >> > > > >> > The ietf-yang-library module is designed to serve two purposes: > > >> > > > >> > 1. A protocol-independent advertisement mechanism for YANG 1.1 > > >> > modules. > > >> > > > >> > 2. A list of the YANG modules stored in a server. > > >> > > > >> > > > >> > Q1. Do you agree with these goals? > > >> > > >> I primarily care about goal 1. > > >> > > >> > Q2. Should this module be designed to work with both YANG 1.0 and > > >> > YANG 1.1 servers - i.e., should it have yang-version 1.1 or > not? > > >> > > > >> > If it should not be defined using YANG 1.1, why is this module > > >> > special? > > >> > > >> I assume this module will sooner or later be YANG 1.1 anyway. > > >> > > >> > Q3. Should the /modules/module list be designed to store both YANG > > >> > 1.0 and YANG 1.1 modules? > > >> > > >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not have > > >> revised all published YANG data models that were written using YANG > > >> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG > > >> 1.1 modules. > > >> > > > > > > > > > Yes -- We also agreed that we would not be republishing modules > > > just to change the yang-version to 1.1. > > > > > > There are lots of YANG modules in progress at this time. > > > Perhaps 3 out of 100 are relying on YANG 1.1 statements. > > > It seems rather disruptive to declare all module must be YANG 1.1 > > > since it has not even made it through WGLC yat, let alone > > > be published as an RFC, let alone be implemented > > > in real tool-chains. > > > > > > I suspect if people find out the only think YANG 1.1 in their module > > > (preventing their existing tools from working) is a yang-version-stmt, > > > they might not be too happy. > > > > > > > > > Andy > > > > > > > > >> > > >> > Q4. Consider these modules, which both import foo without revision: > > >> > > > >> > module a { ... import foo; ... } > > >> > module b { ... import foo; ... } > > >> > > > >> > Do we require a server that implements both a and b to use the > > >> > same revision of foo? > > >> > > > >> > If the answer is yes, we need to indicate the default revision > > >> > that the server uses in the model: > > >> > > > >> > container modules { > > >> > ... > > >> > list module { > > >> > ... > > >> > leaf default-revision { > > >> > type boolean; > > >> > default false; > > >> > description > > >> > "Indicates that this revision is used by the server > if > > >> > this module is imported without a specific revision > > >> > date."; > > >> > } > > >> > } > > >> > } > > >> > > > >> > If the answer is no, note that this puts an implementation > burden > > >> > on the client. A client cannot simply download all listed > > >> > modules, and load/compile/process them as one set. > > >> > > > >> > If the anwser is no, I propose that we extend the module as > such: > > >> > > > >> > container modules { > > >> > ... > > >> > list module { > > >> > ... > > >> > list imported-without-revision { > > >> > key "name revision"; > > >> > ... > > >> > } > > >> > } > > >> > } > > >> > > > >> > A server could then list: > > >> > > > >> > > > >> > a > > >> > 2015-01-01 > > >> > > > >> > foo > > >> > 2002-02-02 > > >> > > > >> > > > >> > > > >> > b > > >> > 2015-01-01 > > >> > > > >> > foo > > >> > 2001-01-01 > > >> > > > >> > > > >> > > >> I believe truth is advertisement is a good thing. In the SNMP world, > > >> not all pieces of the instrumentation were moving at the same pace and > > >> I would be somewhat surprised if this would be the case for all > > >> implementations in the NETCONF world. Hence, I rather accept that an > > >> import of foo without revision may resolve to different versions of > > >> foo for different imports. > > >> > > >> /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 > > >> > > > > > > > --001a11c3677ea87cb10519ff124e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 3, 2015 at 1:45 PM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> I am going to update the draft so the conformance leaf
> is an enumeration with 'implement' and 'import' enums.=
> The 'none' enum is not needed because the deviations are
> listed inside the module entry.

Don't we have to list the deviation module's revision as well?=C2= =A0 As you
noted, the revision is needed in <get-schema>.

If we don't list the deviation module in the main list, it won't be=
possible to download such modules over RESTCONF.



I will add 'none= 9; to the enumeration for deviations
It would be bad if any file = was listed for download more than once


<= div>Andy
=C2=A0
> A module server would return
> the conformance for the proxied server, not itself.
>
> No new objects will be added.

This is up to the WG to decide.=C2=A0 So far, three people (myself
included) have said that they want to solve the advertisement problem,
"indicate the import tree" as you put it, and the two proposed solutions require new nodes in the module.

It would be good to hear from more people.

I think your objection to addressing this problem is that if import
w/o revision is used, the client by design cannot/should not know
which revision the server used.=C2=A0 Did I get that right?


/martin



> Only item # is being addressed.
>
> Every module the server implements with be listed once
> with conformance=3Dimplement.=C2=A0 Every module and revision
> that those modules import (rippled through all imports) will be listed=
> in the library, with conformance=3Dimport, except of
> course if the imported module is also an implemented module.
> No other modules will be listed.
>
>
> Andy
>
>
> On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder <
> > j.schoenw= aelder@jacobs-university.de> wrote:
> >
> >> Writing as technical contributor...
> >>
> >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wr= ote:
> >> > Hi,
> >> >
> >> > Here's a short summary, and then some questions for = the WG.
> >> >
> >> > The ietf-yang-library module is designed to serve two pu= rposes:
> >> >
> >> >=C2=A0 =C2=A01.=C2=A0 A protocol-independent advertisemen= t mechanism for YANG 1.1
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0modules.
> >> >
> >> >=C2=A0 =C2=A02.=C2=A0 A list of the YANG modules stored i= n a server.
> >> >
> >> >
> >> > Q1.=C2=A0 Do you agree with these goals?
> >>
> >> I primarily care about goal 1.
> >>
> >> > Q2.=C2=A0 Should this module be designed to work with bo= th YANG 1.0 and
> >> >=C2=A0 =C2=A0 =C2=A0 YANG 1.1 servers - i.e., should it h= ave yang-version 1.1 or not?
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If it should not be defined using YA= NG 1.1, why is this module
> >> >=C2=A0 =C2=A0 =C2=A0 special?
> >>
> >> I assume this module will sooner or later be YANG 1.1 anyway.=
> >>
> >> > Q3.=C2=A0 Should the /modules/module list be designed to= store both YANG
> >> >=C2=A0 =C2=A0 =C2=A0 1.0 and YANG 1.1 modules?
> >>
> >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not h= ave
> >> revised all published YANG data models that were written usin= g YANG
> >> 1.0. So a server needs to be able to announce both YANG 1.0 a= nd YANG
> >> 1.1 modules.
> >>
> >
> >
> > Yes -- We also agreed that we would not be republishing modules > > just to change the yang-version to 1.1.
> >
> > There are lots of YANG modules in progress at this time.
> > Perhaps 3 out of 100 are relying on YANG 1.1 statements.
> > It seems rather disruptive to declare all module must be YANG 1.1=
> > since it has not even made it through WGLC yat, let alone
> > be published as an RFC, let alone be implemented
> > in real tool-chains.
> >
> > I suspect if people find out the only think YANG 1.1 in their mod= ule
> > (preventing their existing tools from working) is a yang-version-= stmt,
> > they might not be too happy.
> >
> >
> > Andy
> >
> >
> >>
> >> > Q4.=C2=A0 Consider these modules, which both import foo = without revision:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module a { ... import foo; ..= . }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module b { ... import foo; ..= . }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 Do we require a server that implemen= ts both a and b to use the
> >> >=C2=A0 =C2=A0 =C2=A0 same revision of foo?
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the answer is yes, we need to ind= icate the default revision
> >> >=C2=A0 =C2=A0 =C2=A0 that the server uses in the model: > >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf default-re= vision {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boo= lean;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default = false;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descript= ion
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &= quot;Indicates that this revision is used by the server if
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0this module is imported without a specific revision
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0date.";
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the answer is no, note that this = puts an implementation burden
> >> >=C2=A0 =C2=A0 =C2=A0 on the client.=C2=A0 A client cannot= simply download all listed
> >> >=C2=A0 =C2=A0 =C2=A0 modules, and load/compile/process th= em as one set.
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the anwser is no, I propose that = we extend the module as such:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list imported-w= ithout-revision {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key &quo= t;name revision";
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 A server could then list:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>a</name&= gt;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01= -01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-re= vision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo&= lt;/name>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>= 2002-02-02</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-r= evision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>b</name&= gt;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01= -01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-re= vision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo&= lt;/name>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>= 2001-01-01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-r= evision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >>
> >> I believe truth is advertisement is a good thing. In the SNMP= world,
> >> not all pieces of the instrumentation were moving at the same= pace and
> >> I would be somewhat surprised if this would be the case for a= ll
> >> implementations in the NETCONF world. Hence, I rather accept = that an
> >> import of foo without revision may resolve to different versi= ons of
> >> foo for different imports.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp= us Ring 1 | 28759 Bremen | Germany
> >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.jacobs-university.de/>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/net= mod
> >>
> >
> >

--001a11c3677ea87cb10519ff124e-- From nobody Sat Jul 4 03:29:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248BF1A8824; Thu, 2 Jul 2015 14:35:08 -0700 (PDT) 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 zLx1XA06lFnp; Thu, 2 Jul 2015 14:35:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 5323F1A87A8; Thu, 2 Jul 2015 14:35:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Mahesh Jethanandani'" , "'Eric Voit \(evoit\)'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> In-Reply-To: <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> Date: Thu, 2 Jul 2015 17:35:04 -0400 Message-ID: <021301d0b50e$f62a20b0$e27e6210$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0214_01D0B4ED.6F1A0750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLAkJXomwCCiG/twIuXbN7nP08VQA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Sat, 04 Jul 2015 03:29:54 -0700 Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , "'BRUNGARD, DEBORAH A'" , 'Alia Atlas' , 'Netconf' , "'Alvaro Retana \(aretana\)'" Subject: Re: [Netconf] [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:35:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0214_01D0B4ED.6F1A0750 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mahesh:=20 =20 I=E2=80=99m trying to schedule a set of meeting before I2RS presents at = NETCONF so it would be helpful to know when the I2RS session would be = schedule in NETCONF.=20 =20 Is I2RS requirements presentation at the Tuesday meeting with Netconf = [15:20 =E2=80=93 17:20] which is just before the I2RS meeting [17:40- = 18:40]. This back-to-back session would allow us to encourage people to = hear the presentations in NETCONF and then come to I2RS to discuss any = open issues for I2RS. =20 =20 Do you think we should present the NETMOD requirements before the = NETCONF requirements? I can request a brief presentation in NETMOD. I = am working on a draft to express I2RS requirements for netmod. The = requirements for NETMO will not be an I2RS WG document =E2=80=93 only a = chair=E2=80=99s observations on the differences between the yang = modules.=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani Sent: Thursday, July 02, 2015 5:06 PM To: Eric Voit (evoit) Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; = BRUNGARD, DEBORAH A; Alexander Clemm (alex); Netconf; Susan Hares Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS = protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 =20 On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) wrote: =20 What might be interesting for a NETCONF speaking slot is an analysis of = what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 =20 Susan or somebody from i2rs WG can decide whether the suggested = presentation would help clarify i2rs requirements to NETCONF. From a = personal perspective it would certainly help to have examples of how the = requirements could be met. =20 Cheers. =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 ------=_NextPart_000_0214_01D0B4ED.6F1A0750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

I=E2=80=99m trying to schedule a set of meeting before I2RS presents = at NETCONF so it would be helpful to know when the I2RS session would be = schedule in NETCONF.

 

Is I2RS requirements presentation at the Tuesday meeting with Netconf = [15:20 =E2=80=93 17:20] which is just before the I2RS meeting [17:40- = 18:40]. =C2=A0This back-to-back session would allow us to encourage = people to hear the presentations in NETCONF and then come to I2RS to = discuss any open issues for I2RS.=C2=A0

 

Do you think we should present the NETMOD requirements before the = NETCONF requirements? =C2=A0I can request a brief presentation in = NETMOD.=C2=A0 I am working on a draft to express I2RS requirements for = netmod.=C2=A0 The requirements for NETMO will not be an I2RS WG document = =E2=80=93 only a chair=E2=80=99s observations on the differences between = the yang modules.

 

Sue Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani
Sent: Thursday, July 02, 2015 5:06 = PM
To: Eric Voit (evoit)
Cc: = Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; BRUNGARD, = DEBORAH A; Alexander Clemm (alex); Netconf; Susan = Hares
Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] = Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - = 11:30am ET)

 

 

On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

 

What might be interesting for a NETCONF speaking slot is an analysis = of what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. <= /p>

 

Susan or somebody from i2rs WG can decide whether the = suggested presentation would help clarify i2rs requirements to NETCONF. = >From a personal perspective it would certainly help to have examples of = how the requirements could be met.

 

Cheers.

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_0214_01D0B4ED.6F1A0750-- From nobody Sun Jul 5 01:59:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2571B2CF0 for ; Sun, 5 Jul 2015 01:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 VgWX1L5w1FAZ for ; Sun, 5 Jul 2015 01:59:25 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 8775B1B2CEE for ; Sun, 5 Jul 2015 01:59:23 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t658xKVl018143 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Jul 2015 08:59:20 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t658xJDN032178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 5 Jul 2015 10:59:19 +0200 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 5 Jul 2015 10:59:19 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.53]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0235.001; Sun, 5 Jul 2015 10:59:18 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: I2RS Requirements on Netconf WAS:FW: [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) Thread-Index: AdCt3DMPLBEZlsLhQ3mxKrWQI0Jk+wJI49mA Date: Sun, 5 Jul 2015 08:59:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.108] Content-Type: multipart/mixed; boundary="_004_E4DE949E6CE3E34993A2FF8AE79131F81971CB13DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 55481 X-purgate-ID: 151667::1436086760-000058F0-49BB2739/0/0 Archived-At: Subject: [Netconf] I2RS Requirements on Netconf WAS:FW: [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 08:59:29 -0000 --_004_E4DE949E6CE3E34993A2FF8AE79131F81971CB13DEMUMBX005nsnin_ Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81971CB13DEMUMBX005nsnin_" --_000_E4DE949E6CE3E34993A2FF8AE79131F81971CB13DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I2RS requirements on Netconf will be discussed during IETF 93. Please review the I2RS requirement documents below as a preparation for thi= s discussion. Please comment by July 16, 2015 on whether you think one or the other requi= rement is technically not possible to fulfill or can be addressed with an e= xtension to Netconf. Mehmet From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of ext Susan Hares Sent: Tuesday, June 23, 2015 8:19 PM To: netconf@ietf.org; i2rs@ietf.org Cc: Rtg-yang-coord@ietf.org; netmod@ietf.org; 'BRUNGARD, DEBORAH A' Subject: [netmod] Requirements for I2RS protocol and I2RS interim (6/24/201= 5 at 10:00 - 11:30am ET) Netconf Working Group: The I2RS WG would like to pass you a set of requirements for the I2RS proto= col, and asks that you provide an analysis by IETF 93 on whether NETCONF or= RESTCONF can meet these requirements. We expect that these requirements = may require changes to the either NETCONF or RESTCONF. The I2RS architecture document (draft-ietf-i2rs-architecture-09) provides a high-level= overview of the I2RS protocol. The I2RS has compiled the following docum= ents to provide the additional details on the requirements for the protocol= s. 1) draft-ietf-i2rs-ephemeral-state-00 2) draft-ietf-i2rs-pub-sub-requirements-02 3) draft-ietf-i2rs-traceability-03 The draft-ietf-i2rs-ephemeral-state-00 contains the results of the discussi= on from the 6/10 interim and the top 10 requirements for I2RS. In addition= , the draft-ietf-i2rs-ephemeral-state-00 contains an set of detailed requir= ements on how the I2RS WG sees the I2RS protocol operating. These detailed= requirements are to be seen as suggestions on what type of solution the I2= RS WG would like to see, but I2RS WG is asking the NETCONF WG to provide it= s best designed protocol. Please note as part of these detailed requiremen= t the draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metada= ta to record secondary identity. The I2RS protocol is driven by data-models. The approved data models for p= rotocol independent services are: - draft-ietf-i2rs-rib-data-model-00 - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 (releas= ed later this week) - Topology model which is a composite of: o Generic topology model: draft-ietf-i2rs-yang-network-topo-01 o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 released= later this week). o Service topology model: draft-hares-i2rs-service-topo-yang-model-00 (re= leased on Wednesday) At this time, none of the Topology models utilize Traffic engineering. It = is anticipated that these models will support traffic engineering. Estimat= ed rates of transfer and timing requirements for these modules are at: http= ://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the protocol requirements = table. We hope that NETCONF WG can provide some initial feedback on these requirem= ents by IETF 93 at the Tuesday I2RS session. I2RS will use the 6/24 inter= im at 10:00-11:30am ET to provide a time for any participate in the I2RS, = netconf, or netmod group to ask additional questions on these requirements. Sue Hares Interim time: 10:00-11:30am ET Date 6/24/2015 Webex: https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61cb17b0008a3c52069d0f agenda: 10:00 - 10:05 - Bash Agenda 10:05 - 10:20- - review of requirements from draft-ietf-i2rs-ephemeral-state-00 draft-ietf-i2rs-pub-sub-requirements-02 draft-ietf-i2rs-traceability-03 Timing requirements 10:20 - 10:30 Review of requirements for mutual authentication, and transaction in draft-hares-auth-trans-01 requirements 10:30- 11:30 Open discussion for I2RS Requirements Proceedings and slides can be found at: http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.html Sue Hares --_000_E4DE949E6CE3E34993A2FF8AE79131F81971CB13DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= All,

=  

= I2RS requirements on Netconf will be discussed during = IETF 93.

=  

= Please review the I2RS requirement documents below as = a preparation for this discussion.

= Please comment by July 16, 2015 on whether you think o= ne or the other requirement is technically not possible to fulfill or can be addressed with an extension to Netconf.

=  

= Mehmet

=  

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of ext Susan Hares
Sent: Tuesday, June 23, 2015= 8:19 PM
To: netconf@ietf.org; i2rs@i= etf.org
Cc: Rtg-yang-coord@ietf.org;= netmod@ietf.org; 'BRUNGARD, DEBORAH A'
Subject: [netmod] Requiremen= ts for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET)

 

Netconf Working Group:

 

The I2RS WG would like to pass you a set of requirements for= the I2RS protocol, and asks that you provide an analysis by IETF 93 on whe= ther NETCONF or RESTCONF can meet these requirements.   We expect that these requirements may require ch= anges to the either NETCONF or RESTCONF. 

 

The I2RS architecture document (draft-ietf-i2rs-architecture-09= ) provides a high-level overview of the I2RS  proto= col.  The I2RS has compiled the following documents to provide the add= itional details on the requirements for the protocols.

 

1)      draft-ietf-i2rs-ephemeral-st= ate-00 

2)      draft-ietf-i2rs-pub-sub= -requirements-02 

3)      draft-ietf-i2rs-traceability-03<= /span> 

 

The draft-ietf-i2rs-ephemeral-state-00 contains the results = of the discussion from the 6/10 interim and the top 10 requirements for I2R= S.  In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of detailed requirements on how the I2RS WG sees the I2RS = protocol operating.  These detailed requirements are to be seen as sug= gestions on what type of solution the I2RS WG would like to see, but I2RS W= G is asking the NETCONF WG to provide its best designed protocol.  Please note as part of these detailed re= quirement the draft-ietf-i2rs-ephemeral-states-00 contains the idea of usin= g metadata to record secondary identity.   

 

The I2RS protocol is driven by data-models.  The approv= ed data models for protocol independent services are:

-  =         draft-ietf-i2rs-rib-data-model-00

-        &= nbsp; Filter-Based RIBS: = ; draft-kini-i2rs-fb-rib-data-model.00 (released late= r this week)

-        &= nbsp; Topology model which is a composite = of:

o   Generic topology model: draft-ietf-i2rs-yang-network-topo-01 

o   L3 topology model: draf= t-ietf-i2rs-yang-l3-topology-00 

o   L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00&nbs= p;

o   L1 Topology model: dra= ft-zhang-i2rs-l1-topo-yang-model-01 (-02 released later this week).

o   Service topology model: draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday)

 

At this time, none of the Topology models utilize Traffic en= gineering.  It is anticipated that these models will support traffic e= ngineering.  Estimated rates of transfer and timing requirements for these modules are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the protocol requi= rements table.

 

We hope that NETCONF WG can provide some initial feedback on= these requirements by IETF 93 at the Tuesday I2RS session.   I2R= S will use the 6/24 interim at 10:00-11:30am ET  to provide a time for any participate in the I2RS, netconf, or netmod group t= o ask additional questions on these requirements.

 

Sue Hares

 

Interim time: 10:00-11:30am ET

Date 6/24/2015

Webex:

https://ietf.webex.com/ietf/j.php?MTID=3Dm4260be= e7be61cb17b0008a3c52069d0f

 

agenda:

 

10:00 – 10:05 – Bash Agenda

10:05 – 10:20- -  review of requirements from

draft-ietf-i= 2rs-ephemeral-state-00

draft-ietf-i= 2rs-pub-sub-requirements-02

draft-ietf-i= 2rs-traceability-03

Timing requi= rements

 <= /o:p>

10:20 – 10:30    Review of requirements= for mutual authentication,

and transact= ion in  draft-hares-auth-trans-01 requirements

 

10:30- 11:30     Open discussion for I2R= S Requirements

 

Proceedings and slides can be found at:

http://www.ietf.org/proceedings/interim/2015/06/24= /i2rs/proceedings.html

 

Sue Hares

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F81971CB13DEMUMBX005nsnin_-- --_004_E4DE949E6CE3E34993A2FF8AE79131F81971CB13DEMUMBX005nsnin_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Tue, 23 Jun 2015 18:19:22 GMT"; modification-date="Tue, 23 Jun 2015 18:19:22 GMT" Content-ID: <789C7C68CAADD64FBEB704563CAD45CA@internal.nsn.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBt YWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg== --_004_E4DE949E6CE3E34993A2FF8AE79131F81971CB13DEMUMBX005nsnin_-- From nobody Sun Jul 5 02:42:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE87A1AC3D2 for ; Sun, 5 Jul 2015 02:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 ERAMrlZp8wUg for ; Sun, 5 Jul 2015 02:42:24 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 688801A90F4 for ; Sun, 5 Jul 2015 02:42:23 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t659gLrG024884 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Jul 2015 09:42:21 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t659gKV0028571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 5 Jul 2015 11:42:21 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 5 Jul 2015 11:42:19 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.53]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0235.001; Sun, 5 Jul 2015 11:42:19 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Extended deadline July 10 WAS:FW: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 Thread-Index: AQHQr8/wAUVLwWdcaUCcPkxPS//vep3MrGLA Date: Sun, 5 Jul 2015 09:42:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.108] Content-Type: multipart/mixed; boundary="_004_E4DE949E6CE3E34993A2FF8AE79131F81971CB79DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 43526 X-purgate-ID: 151667::1436089341-000076F8-FAD14290/0/0 Archived-At: Subject: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 09:42:27 -0000 --_004_E4DE949E6CE3E34993A2FF8AE79131F81971CB79DEMUMBX005nsnin_ Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81971CB79DEMUMBX005nsnin_" --_000_E4DE949E6CE3E34993A2FF8AE79131F81971CB79DEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBOZXRjb25mIFdHLA0KDQp3ZSBoYWQgc28gZmFyIG9ubHkgb25lIHJldmlldyBhbmQgb25l IHN1cHBvcnQgc3RhdGVtZW50IG9uIHRoZSBDYWxsIEhvbWUgZHJhZnQuDQpBIHRob3JvdWdoIHJl dmlldyBpcyBuZWNlc3NhcnkgYmVmb3JlIHdlIGNhbiBkZWNpZGUgb24gdGhlIG5leHQgc3RlcHMu DQoNCldpdGggdGhpcyBtYWlsIEkgd291bGQgbGlrZSB0byBleHRlbmQgdGhlIFdHTEMgZGVhZGxp bmUgdW50aWwgSnVseSAxMCwgMjAxNSBFT0IgUFQuDQoNClBsZWFzZSByZXZpZXcgdGhlIENhbGwg SG9tZSBkcmFmdCBhbmQgcHJvdmlkZSB5b3VyIGNvbW1lbnRzIHRvIE5ldGNvbmYgbWFpbGxpc3Qu DQpQbGVhc2Ugc3RhdGUgYXMgYSBtaW5pbXVtIHdoZXRoZXIgeW91IHN1cHBvcnQgdG8gcHVibGlz aCB0aGUgZG9jdW1lbnQuDQoNCk1laG1ldA0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE1haGVzaCBKZXRoYW5hbmRhbmkN ClNlbnQ6IEZyaWRheSwgSnVuZSAyNiwgMjAxNSA3OjIxIEFNDQpUbzogTmV0Y29uZg0KU3ViamVj dDogW05ldGNvbmZdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9t ZS0wNw0KDQpEZWFyIE5FVENPTkYgcGFydGljaXBhbnRzLA0KDQpUaGlzIGUtbWFpbCBpcyBhIG5v dGlmaWNhdGlvbiB0byBzdGFydCBhIE5FVENPTkYgV0cgTGFzdCBDYWxsIGZvciB0aGUgZG9jdW1l bnQgIk5FVENPTkYgQ2FsbCBIb21lIGFuZCBSRVNUQ09ORiBDYWxsIEhvbWXigJ0uDQoNClRoZSBk b2N1bWVudCBjYW4gYmUgZm91bmQgYXQ6IGRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMDc8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUt MDc+Lg0KDQpQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCwgcHJvdmlkZSBjb21tZW50cywgYW5k IGluZGljYXRlIHlvdXIgc3VwcG9ydCBmb3IgdGhlIGRyYWZ0IGJ5IEZyaWRheSBKdWx5IDMgKHlv dXIgdGltZXpvbmUpLiBUaGUgY29tbWVudHMgY2FuIGJlIGluIHRoZSBmb3JtIG9mOg0KDQoNCiAg KiAgIOKAnEkgaGF2ZSByZXZpZXdlZCB0aGUgSS1EIEJsYWggYW5kIEkgaGF2ZSBmb3VuZCBpc3N1 ZXMgd2l0aCBpdOKAnQ0KICAqICAg4oCcSSBoYXZlIHJldmlld2VkIEktRCBCbGFoIGFuZCBJIGZv dW5kIG5vIGlzc3Vlc+KAnQ0KDQpTaW11bHRhbmVvdXNseSwgdGhlIGF1dGhvciBvbiB0aGlzIGRy YWZ0IHNob3VsZCBzdGF0ZSB0byB0aGUgbWFpbGluZyBsaXN0IHdoZXRoZXIgdGhlcmUgaXMgYW55 IElQUiBhc3NvY2lhdGVkIHdpdGggdGhpcyBkcmFmdCBvciBub3QuDQoNClRoYW5rcw0KDQpNYWhl c2ggYW5kIE1laG1ldA0KKENvLWNoYWlycywgTkVUQ09ORiBXRykNCg0KDQoNCg== --_000_E4DE949E6CE3E34993A2FF8AE79131F81971CB79DEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDBCNzE3LkE1Q0M2MEYwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8bzpUYXJnZXRTY3JlZW5TaXplPjEwMjR4NzY4PC9vOlRhcmdldFNjcmVlblNpemU+DQo8L286 T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpT cGVsbGluZ1N0YXRlPg0KPHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6 RW52ZWxvcGVWaXMvPg0KPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJ bnZhbGlkPmZhbHNlPC93OlNhdmVJZlhNTEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYv Pg0KPHc6TGlkVGhlbWVPdGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVB c2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5Y LU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRv Tm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0 UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRvbnRWZXJ0QWxpZ25DZWxsV2l0aFNwLz4NCjx3OkRv bnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFibGVzLz4NCjx3OkRvbnRWZXJ0QWxpZ25JblR4Yngv Pg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4NCjx3OkNhY2hlZENvbEJhbGFuY2UvPg0KPC93OkNv bXBhdGliaWxpdHk+DQo8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8 L3c6QnJvd3NlckxldmVsPg0KPG06bWF0aFByPg0KPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEg TWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCjxtOmJya0JpblN1YiBtOnZhbD0i JiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+DQo8bTps TWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpkZWZKYyBtOnZh bD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxtOmludExp bSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwvbTptYXRo UHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVmVW5oaWRl V2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3JtYXQ9ImZhbHNlIiBE ZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjI2NyI+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFtZT0iRGVm YXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8g U3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hh ZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJr IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNv bG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBM aXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGlu ZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg TGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0 IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAx IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3Qg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdy aWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hh ZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUg RW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29r IFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBO YW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6TGF0ZW50 U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlv bnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUg MCAwIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtY2hhcnNldDoyOw0KCW1zby1nZW5lcmljLWZv bnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2ln bmF0dXJlOjAgMjY4NDM1NDU2IDAgMCAtMjE0NzQ4MzY0OCAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsN Cgltc28tZm9udC1hbHQ6IkNhbGlzdG8gTVQiOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28t Z2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCglt c28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3MzA1NzI3IDAgMCA0MTUgMDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJBcmlhbCBSb3VuZGVkIE1UIEJvbGQiOw0KCW1zby1mb250 LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1w aXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMDczNzg2MTEx IDEgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCgltc28tZm9udC1hbHQ6VmVyZGFuYTsNCgltc28tZm9u dC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQt cGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwODE2NjUgLTEwNzM3MTcx NTcgNDEgMCA2NjA0NyAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNv LXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVy bGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tYW5zaS1m b250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjojMDAwMENDO30NCnNwYW4uU3BlbGxFDQoJe21z by1zdHlsZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5ZXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0Ow0KCW1zby1oZWFkZXItbWFy Z2luOjM2LjBwdDsNCgltc28tZm9vdGVyLW1hcmdpbjozNi4wcHQ7DQoJbXNvLXBhcGVyLXNvdXJj ZTowO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTE2OTA1ODc0NTsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTEyMDg4NTI4MjA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyAxMF0+PHN0eWxlPi8qIFN0 eWxlIERlZmluaXRpb25zICovDQp0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFt ZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5 bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIi Ow0KCW1zby1wYWRkaW5nLWFsdDowY20gNS40cHQgMGNtIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdp bjowY207DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9u OndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0YWItaW50ZXJ2YWw6MzYuMHB0 Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90Oztjb2xvcjojMDAwMENDIj5EZWFyIE5ldGNvbmYgV0csPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAw MGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGkt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90Oztjb2xvcjojMDAwMENDIj53ZSBoYWQgc28gZmFyIG9ubHkgb25lIHJldmlldyBhbmQg b25lIHN1cHBvcnQgc3RhdGVtZW50IG9uIHRoZSBDYWxsIEhvbWUNCiBkcmFmdC48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6 IzAwMDBDQyI+QSB0aG9yb3VnaCByZXZpZXcgaXMgbmVjZXNzYXJ5IGJlZm9yZSB3ZSBjYW4gZGVj aWRlIG9uIHRoZSBuZXh0IHN0ZXBzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMDAwMENDIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6 IzAwMDBDQyI+V2l0aCB0aGlzIG1haWwgSSB3b3VsZCBsaWtlIHRvIGV4dGVuZCB0aGUgV0dMQyBk ZWFkbGluZSB1bnRpbCBKdWx5IDEwLA0KIDIwMTUgRU9CIFBULjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAw MDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRp LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMDAwMENDIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDs7Y29sb3I6IzAwMDBDQyI+UGxlYXNlIHJldmlldyB0aGUgQ2FsbCBIb21lIGRyYWZ0 IGFuZCBwcm92aWRlIHlvdXIgY29tbWVudHMgdG8gTmV0Y29uZg0KIG1haWxsaXN0LjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xv cjojMDAwMENDIj5QbGVhc2Ugc3RhdGUgYXMgYSBtaW5pbXVtIHdoZXRoZXIgeW91IHN1cHBvcnQg dG8gcHVibGlzaCB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkRFIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90Oztjb2xvcjojMDAwMENDO21zby1hbnNpLWxhbmd1YWdlOkRFO21zby1uby1wcm9vZjp5 ZXMiPk1laG1ldA0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzAwMDBDQyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oztmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxm b250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4NCiBOZXRj b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSA8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mDQo8L3NwYW4+PC9iPmV4dCBNYWhlc2ggSmV0aGFu YW5kYW5pPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFu PjwvYj4gRnJpZGF5LCBKdW5lIDI2LCAyMDE1IDc6MjEgQU08YnI+DQo8Yj48c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gTmV0Y29uZjxicj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtOZXRjb25mXSBXRyBM YXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMDc8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+RGVhciBORVRDT05GIHBhcnRpY2lwYW50cyw8YnI+DQo8YnI+DQpU aGlzIGUtbWFpbCBpcyBhIG5vdGlmaWNhdGlvbiB0byBzdGFydCBhIE5FVENPTkYgV0cgTGFzdCBD YWxsIGZvciB0aGUgZG9jdW1lbnQgJnF1b3Q7TkVUQ09ORiBDYWxsIEhvbWUgYW5kIFJFU1RDT05G IENhbGwgSG9tZeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48YnI+DQpUaGUgZG9jdW1lbnQgY2FuIGJlIGZvdW5kIGF0 OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5l dGNvbmYtY2FsbC1ob21lLTA3Ij5kcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lLTA3PC9hPi48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+UGxlYXNlIHJldmlldyB0aGUg ZG9jdW1lbnQsIHByb3ZpZGUgY29tbWVudHMsIGFuZCBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgZm9y IHRoZSBkcmFmdCBieSBGcmlkYXkgSnVseSAzICh5b3VyIHRpbWV6b25lKS4gVGhlIGNvbW1lbnRz DQogY2FuIGJlIGluIHRoZSBmb3JtIG9mOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7dGFiLXN0b3BzOmxp c3QgMzYuMHB0Ij4NCjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij7igJxJIGhhdmUgcmV2aWV3ZWQgdGhlIEktRCBCbGFoIGFuZCBJ IGhhdmUgZm91bmQgaXNzdWVzIHdpdGggaXTigJ08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO3RhYi1zdG9w czpsaXN0IDM2LjBwdCI+DQo8Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+4oCcSSBoYXZlIHJldmlld2VkIEktRCBCbGFoIGFuZCBJ IGZvdW5kIG5vIGlzc3Vlc+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2xpPjwvdWw+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ U2ltdWx0YW5lb3VzbHksIHRoZSBhdXRob3Igb24gdGhpcyBkcmFmdCBzaG91bGQgc3RhdGUgdG8g dGhlIG1haWxpbmcgbGlzdCB3aGV0aGVyIHRoZXJlIGlzIGFueSBJUFIgYXNzb2NpYXRlZCB3aXRo IHRoaXMgZHJhZnQNCiBvciBub3QuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij48YnI+DQpNYWhlc2ggYW5kIE1laG1ldDxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+KENvLWNoYWlycywgTkVUQ09ORiBXRyk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0i YmxhY2siIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNp emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E4DE949E6CE3E34993A2FF8AE79131F81971CB79DEMUMBX005nsnin_-- --_004_E4DE949E6CE3E34993A2FF8AE79131F81971CB79DEMUMBX005nsnin_ Content-Type: text/plain; name="ATT00002.txt" Content-Description: ATT00002.txt Content-Disposition: attachment; filename="ATT00002.txt"; size=136; creation-date="Fri, 26 Jun 2015 05:21:22 GMT"; modification-date="Fri, 26 Jun 2015 05:21:22 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_004_E4DE949E6CE3E34993A2FF8AE79131F81971CB79DEMUMBX005nsnin_-- From nobody Sun Jul 5 23:58:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A331A011E; Sun, 5 Jul 2015 23:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 VDn9YeSI4HOp; Sun, 5 Jul 2015 23:58:03 -0700 (PDT) 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 B45181A0113; Sun, 5 Jul 2015 23:58:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D85B0727; Mon, 6 Jul 2015 08:58:01 +0200 (CEST) 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 4fObVwtZgnum; Mon, 6 Jul 2015 08:57:56 +0200 (CEST) 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, 6 Jul 2015 08:58:01 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C23B2002B; Mon, 6 Jul 2015 08:58:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z_R7M233y5W4; Mon, 6 Jul 2015 08:58:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A5E520013; Mon, 6 Jul 2015 08:58:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2AFA334EE212; Mon, 6 Jul 2015 08:57:55 +0200 (CEST) Date: Mon, 6 Jul 2015 08:57:55 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150706065755.GA6056@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 06:58:06 -0000 On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > I propose this text in the conformance leaf: > > For import statements that do not specify a revision > date, the most recent revision in the library SHOULD > be used by the server."; > > It seems like a lot of data will be needed to model the dependency tree > for every import-stmt in every module. Don't forget every include-stmt > as well, since submodules can import with or without revision. > > IMO "SHOULD use latest" is good enough. > Perhaps modules should use import-by-revision when they > are published as RFCs (as Lada suggested). This sounds like "lets pretend the world is simple so we have less work to do". /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 Jul 6 00:39:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C771A8F3F for ; Mon, 6 Jul 2015 00:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gr8xQxp1-9hv for ; Mon, 6 Jul 2015 00:39:23 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 070B51A8BC5 for ; Mon, 6 Jul 2015 00:39:23 -0700 (PDT) Received: by lagh6 with SMTP id h6so143797973lag.2 for ; Mon, 06 Jul 2015 00:39:21 -0700 (PDT) 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=5Jwodf+4y+Yhwvpv5gdr7fjKazycXICkHith4S5E26o=; b=FAP6NEYrfsmHbSPHTR7mI1VyecyN9YeVs1a0t15mQhKo9A0g7MyNaBVYrXFYmi3xRL QTzN7c2bD8hTMs3LDEAnyP5xJ9BvT94JlKuPnqebvBgCvl1t5mkAD/0sxkHPlvxOXeH6 oHnWXyq4cXRxeJp8Q+sYoPxkFZZYGmNhwk/7KKk2ngO40LwRUnZgYVYEwESx3ttmF+xw GzacaMyyRpLpYYzQA2yipWylSwEEzgluz1vf7wr3kSqIepVyx/g/rlbvpADkCHltt7Bf SR78qZWYBbpuBXlN/tdNnTv3JPUSwT+Z45ihWiAc4T0tvOX6UyPqJHntGr6BK4tl/Muv 9ifA== X-Gm-Message-State: ALoCoQnvrCYDB/QWLDZ98ju/tKkMT+3Cl+n4E2smrViK09Wc7jQoViRISlQjqczZHdcjMjmRIhlW MIME-Version: 1.0 X-Received: by 10.152.121.99 with SMTP id lj3mr46489323lab.37.1436168361418; Mon, 06 Jul 2015 00:39:21 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 6 Jul 2015 00:39:21 -0700 (PDT) In-Reply-To: <20150706065755.GA6056@elstar.local> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> Date: Mon, 6 Jul 2015 00:39:21 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=089e0115e882053d22051a30011d Archived-At: Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 07:39:25 -0000 --089e0115e882053d22051a30011d Content-Type: text/plain; charset=UTF-8 On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > I propose this text in the conformance leaf: > > > > For import statements that do not specify a revision > > date, the most recent revision in the library SHOULD > > be used by the server."; > > > > It seems like a lot of data will be needed to model the dependency tree > > for every import-stmt in every module. Don't forget every include-stmt > > as well, since submodules can import with or without revision. > > > > IMO "SHOULD use latest" is good enough. > > Perhaps modules should use import-by-revision when they > > are published as RFCs (as Lada suggested). > > This sounds like "lets pretend the world is simple so we have less > work to do". > > No -- YANG currently says if there is no revision date then the implementation can use any revision, This is also good enough. Prove that this is causing interoperability problems. I don't think it is -- especially not such that the server has to model all its imports so the client can retrieve the data. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --089e0115e882053d22051a30011d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierm= an wrote:

> I propose this text in the conformance leaf:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For import stat= ements that do not specify a revision
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 date, the most = recent revision in the library SHOULD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be used by the = server.";
>
> It seems like a lot of data will be needed to model the dependency tre= e
> for every import-stmt in every module.=C2=A0 Don't forget every in= clude-stmt
> as well, since submodules can import with or without revision.
>
> IMO "SHOULD use latest" is good enough.
> Perhaps modules should use import-by-revision when they
> are published as RFCs (as Lada suggested).

This sounds like "lets pretend the world is simple so we have less
work to do".


No -- YANG currently says if there is no revision da= te
then the implementation can use any revision,
This i= s also good enough.=C2=A0 Prove that this is causing interoperability
=
problems.=C2=A0 I don't think it is -- especially not such that th= e server
has to model all its imports so the client can retrieve = the data.

=C2=A0
/js

Andy
=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--089e0115e882053d22051a30011d-- From nobody Mon Jul 6 00:46:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D807F1A8F3F; Mon, 6 Jul 2015 00:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 Skt97PXS6eik; Mon, 6 Jul 2015 00:46:06 -0700 (PDT) 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 4A67C1A8F38; Mon, 6 Jul 2015 00:46:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B69EC747; Mon, 6 Jul 2015 09:46:04 +0200 (CEST) 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 Za_SBOriMuOK; Mon, 6 Jul 2015 09:46:04 +0200 (CEST) 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, 6 Jul 2015 09:46:03 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D31320035; Mon, 6 Jul 2015 09:46:04 +0200 (CEST) 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 jsHcv769d4YI; Mon, 6 Jul 2015 09:46:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18F312002B; Mon, 6 Jul 2015 09:46:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 47FB534EE349; Mon, 6 Jul 2015 09:45:59 +0200 (CEST) Date: Mon, 6 Jul 2015 09:45:58 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150706074558.GA6272@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@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: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 07:46:08 -0000 On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > > > I propose this text in the conformance leaf: > > > > > > For import statements that do not specify a revision > > > date, the most recent revision in the library SHOULD > > > be used by the server."; > > > > > > It seems like a lot of data will be needed to model the dependency tree > > > for every import-stmt in every module. Don't forget every include-stmt > > > as well, since submodules can import with or without revision. > > > > > > IMO "SHOULD use latest" is good enough. > > > Perhaps modules should use import-by-revision when they > > > are published as RFCs (as Lada suggested). > > > > This sounds like "lets pretend the world is simple so we have less > > work to do". > > > > > No -- YANG currently says if there is no revision date > then the implementation can use any revision, Exactly - any revision. > This is also good enough. Prove that this is causing interoperability > problems. I don't think it is -- especially not such that the server > has to model all its imports so the client can retrieve the data. Did I say all imports? No. I think a server should announce which revision was picked to resolve imports without a revision. /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 Jul 6 07:57:05 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEFB1A8953; Mon, 6 Jul 2015 07:57:03 -0700 (PDT) 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 ajJLBmTqODuN; Mon, 6 Jul 2015 07:57:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFFB1A8907; Mon, 6 Jul 2015 07:56:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706145657.10996.84916.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 07:56:57 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-server-model-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:57:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Server and RESTCONF Server Configuration Models Authors : Kent Watsen Juergen Schoenwaelder Filename : draft-ietf-netconf-server-model-07.txt Pages : 87 Date : 2015-07-06 Abstract: This draft defines a NETCONF server configuration data model and a RESTCONF server configuration data model. These data models enable configuration of the NETCONF and RESTCONF services themselves, including which transports are supported, what ports the servers listen on, call-home parameters, client authentication, and other related configuration parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-server-model-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-server-model-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 07:59:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B421A894B for ; Mon, 6 Jul 2015 07:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 a_I0L66viIks for ; Mon, 6 Jul 2015 07:59:34 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 39B141A8969 for ; Mon, 6 Jul 2015 07:59:31 -0700 (PDT) Received: by labgy5 with SMTP id gy5so6144637lab.2 for ; Mon, 06 Jul 2015 07:59:29 -0700 (PDT) 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=AZKpYakO4kPeHO7Ed0jHhEPj9voO2HhcqvKF5Lso0HM=; b=WGU7Vwcrg+16h3k7xGfqRWf08foye5RMYxQ5IKkpTF/AUMzFwYRGn7sHkLdMuMStjW uKtnqwbDaDRNj38jsvRM00cl9gPF/pxjehvGH+spMgAhiYk/Lqz1lTA/OVqcbpdlx6IY mcaFmjiVHVbWMKldZKXANclaoXvVNmGWF0RkPF7eUqEFed7ipK7TKdhvwFQ5rl1J1WwS 48DhDeEzYSNTZmM2Gne9/TC8S+Q9GARlk+fu3dljyzqgYWWt4UXZu1/NYPHhepUPFQeh RrU5PeLOQDlfSivexsNgmnbOHsv+5cgAWzvOI4tCR0vOb3GkD8DsiwPdDLQdXG7Omi+f u7KA== X-Gm-Message-State: ALoCoQnA+s08k1fxEISu6dagWEEaDcrPGKB3LeTu+lOTwYqXAqdCZMfChDPAvDaor8sxsvdjG4ox MIME-Version: 1.0 X-Received: by 10.112.41.171 with SMTP id g11mr33882668lbl.123.1436194769688; Mon, 06 Jul 2015 07:59:29 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 6 Jul 2015 07:59:29 -0700 (PDT) In-Reply-To: <20150706074558.GA6272@elstar.local> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> <20150706074558.GA6272@elstar.local> Date: Mon, 6 Jul 2015 07:59:29 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11346d9c1370a4051a362754 Archived-At: Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:59:37 -0000 --001a11346d9c1370a4051a362754 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: > > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > > > > > I propose this text in the conformance leaf: > > > > > > > > For import statements that do not specify a revision > > > > date, the most recent revision in the library SHOULD > > > > be used by the server."; > > > > > > > > It seems like a lot of data will be needed to model the dependency > tree > > > > for every import-stmt in every module. Don't forget every > include-stmt > > > > as well, since submodules can import with or without revision. > > > > > > > > IMO "SHOULD use latest" is good enough. > > > > Perhaps modules should use import-by-revision when they > > > > are published as RFCs (as Lada suggested). > > > > > > This sounds like "lets pretend the world is simple so we have less > > > work to do". > > > > > > > > No -- YANG currently says if there is no revision date > > then the implementation can use any revision, > > Exactly - any revision. > > > This is also good enough. Prove that this is causing interoperability > > problems. I don't think it is -- especially not such that the server > > has to model all its imports so the client can retrieve the data. > > Did I say all imports? No. I think a server should announce which > revision was picked to resolve imports without a revision. > > But it could be any revision. A imports B.1 imports C D imports B.4 imports C E imports F imports G imports C C can be imported many times without revision. Any import in the chain can be with out without a revision date. IMO "SHOULD use latest revision of C advertised" is best because the latest revision is generally the most correct and supports the most product features. If the import of C really depends on specific revisions of some typedefs, groupings, etc. then import by revision MUST be used everywhere in the dependency chain (C and all its imports). If no revision-stmt is present the server can pick whatever revision it wants. If this is a problem, then fix this problem, don't add some complex monitoring requirements for servers to implement and clients to process. Let's make import-by-revision mandatory if import-without-revision is a such a problem. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11346d9c1370a4051a362754 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierm= an wrote:
> On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
> > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote:
> >
> > > I propose this text in the conformance leaf:
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For i= mport statements that do not specify a revision
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 date,= the most recent revision in the library SHOULD
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be us= ed by the server.";
> > >
> > > It seems like a lot of data will be needed to model the depe= ndency tree
> > > for every import-stmt in every module.=C2=A0 Don't forge= t every include-stmt
> > > as well, since submodules can import with or without revisio= n.
> > >
> > > IMO "SHOULD use latest" is good enough.
> > > Perhaps modules should use import-by-revision when they
> > > are published as RFCs (as Lada suggested).
> >
> > This sounds like "lets pretend the world is simple so we hav= e less
> > work to do".
> >
> >
> No -- YANG currently says if there is no revision date
> then the implementation can use any revision,

Exactly - any revision.

> This is also good enough.=C2=A0 Prove that this is causing interoperab= ility
> problems.=C2=A0 I don't think it is -- especially not such that th= e server
> has to model all its imports so the client can retrieve the data.

Did I say all imports? No. I think a server should announce which
revision was picked to resolve imports without a revision.


But it could be any revision.

=C2=A0 =C2=A0A= imports B.1 imports C
=C2=A0 =C2=A0D imports B.4 imports C
=
=C2=A0 =C2=A0E imports F imports G imports C

= C can be imported many times without revision.
Any import in the = chain can be with out without a revision date.

IMO= "SHOULD use latest revision of C advertised" is best because
the latest revision is generally the most correct and supports the
most product features.

If the import of C= really depends on specific revisions of
some typedefs, groupings= , etc. then import by revision MUST
be used everywhere in the dep= endency chain (C and all its imports).

If no revis= ion-stmt is present the server can pick whatever revision
it want= s.=C2=A0 If this is a problem, then fix this problem, don't add
some complex monitoring requirements for servers to implement
= and clients to process.=C2=A0 Let's make import-by-revision mandatory
if import-without-revision is a such a problem.




=C2=A0
/js

Andy
=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a11346d9c1370a4051a362754-- From nobody Mon Jul 6 08:04:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5261A893C; Mon, 6 Jul 2015 08:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 iM-N3CSR_lKT; Mon, 6 Jul 2015 08:04:42 -0700 (PDT) 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 72FD91A8A29; Mon, 6 Jul 2015 08:04:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9827B111B; Mon, 6 Jul 2015 17:04:36 +0200 (CEST) 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 ukwvMAUA6W21; Mon, 6 Jul 2015 17:04:36 +0200 (CEST) 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, 6 Jul 2015 17:04:35 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AAC72002B; Mon, 6 Jul 2015 17:04:36 +0200 (CEST) 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 S_8B8IM9Bl-q; Mon, 6 Jul 2015 17:04:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E6ED20013; Mon, 6 Jul 2015 17:04:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EA03734EF19E; Mon, 6 Jul 2015 17:04:30 +0200 (CEST) Date: Mon, 6 Jul 2015 17:04:30 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150706150430.GA342@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> <20150706074558.GA6272@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: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 15:04:44 -0000 On Mon, Jul 06, 2015 at 07:59:29AM -0700, Andy Bierman wrote: > On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: > > > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > > > > > > > I propose this text in the conformance leaf: > > > > > > > > > > For import statements that do not specify a revision > > > > > date, the most recent revision in the library SHOULD > > > > > be used by the server."; > > > > > > > > > > It seems like a lot of data will be needed to model the dependency > > tree > > > > > for every import-stmt in every module. Don't forget every > > include-stmt > > > > > as well, since submodules can import with or without revision. > > > > > > > > > > IMO "SHOULD use latest" is good enough. > > > > > Perhaps modules should use import-by-revision when they > > > > > are published as RFCs (as Lada suggested). > > > > > > > > This sounds like "lets pretend the world is simple so we have less > > > > work to do". > > > > > > > > > > > No -- YANG currently says if there is no revision date > > > then the implementation can use any revision, > > > > Exactly - any revision. > > > > > This is also good enough. Prove that this is causing interoperability > > > problems. I don't think it is -- especially not such that the server > > > has to model all its imports so the client can retrieve the data. > > > > Did I say all imports? No. I think a server should announce which > > revision was picked to resolve imports without a revision. > > > > > But it could be any revision. > > A imports B.1 imports C > D imports B.4 imports C > E imports F imports G imports C Can we agree on "all imports without a revision fixed in the data model"? > C can be imported many times without revision. Yes. > Any import in the chain can be with out without a revision date. Yes. > IMO "SHOULD use latest revision of C advertised" is best because > the latest revision is generally the most correct and supports the > most product features. But I thought the goal was to know precisely what a device implements, not what it _could_ implement. > If the import of C really depends on specific revisions of > some typedefs, groupings, etc. then import by revision MUST > be used everywhere in the dependency chain (C and all its imports). > > If no revision-stmt is present the server can pick whatever revision > it wants. If this is a problem, then fix this problem, don't add > some complex monitoring requirements for servers to implement > and clients to process. Let's make import-by-revision mandatory > if import-without-revision is a such a problem. If the data model leaves it open, then indeed the implementor can choose. What is wrong with reporting what was chosen? /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 Jul 6 08:13:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570481AD255 for ; Mon, 6 Jul 2015 08:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoDWzsnwRwkZ for ; Mon, 6 Jul 2015 08:13:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F851ACEE8 for ; Mon, 6 Jul 2015 08:13:32 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 6 Jul 2015 15:13:16 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) with mapi id 15.01.0207.004; Mon, 6 Jul 2015 15:13:15 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-server-model-07.txt Thread-Index: AQHQt/wHTnKX9T/G+ke0AbdS3ORUEp3OSYYA Date: Mon, 6 Jul 2015 15:13:15 +0000 Message-ID: References: <20150706145657.10996.84916.idtracker@ietfa.amsl.com> In-Reply-To: <20150706145657.10996.84916.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:NMYKGBtWD608DYPGDfDTYBHJVa0B/d9JznVPJY0soeilTHekyAAhU88oDb1MnSobEK+SJfThUIWNkrdYnnjhrW56EBBpY0L6s1L7H8pIzbZQJZb8LL/1tQZgpKI6Dpzuc7mMhSUeLEVeOTh04ZCFfA==; 24:vdsH7l8ARRQ2R9Pb9NXvFJlGhGFd2WFG/Um8N5SVKefIALe5mt5bH0B3eQZ2IL3pKyh2mXBZVrSOHn0UGVyTRSImmduBNfiZ0XWBJ38XI7s=; 20:ZAvqCTYypRT3pLvkUF2Le/bcVcwhrfEtb8Zcdojs1Db8sfNJvLQbG1/fxQ9FqV3En83ZjTdZW4cL4eBwk+Mmag== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(377454003)(51704005)(24454002)(164054003)(479174004)(54534003)(189998001)(99286002)(92566002)(102836002)(83506001)(40100003)(76176999)(122556002)(54356999)(5002640100001)(4001350100001)(106116001)(230783001)(50986999)(2501003)(2351001)(110136002)(2950100001)(86362001)(19580395003)(2900100001)(36756003)(5001960100002)(66066001)(62966003)(46102003)(2656002)(19580405001)(450100001)(77156002)(15975445007)(87936001)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <9BE0F1B1C1D019488FA107D0B3745FAA@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 15:13:15.8118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-server-model-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 15:13:35 -0000 Hi, This update addresses all the issues raised on the issue tracker. For a detailed list, please see the change log here: https://tools.ietf.org/html/draft-ietf-netconf-server-model-07#appendix-B.7 . Special note about Issue #49, this draft includes Appendix A as an alternative solution using keychain, ssh server, and tls server objects. The resulting relationship between the various YANG models is depicted below: +-------------+ |ietf-keychain| +-------------+ ^ ^ | | | | +------------+ +------------+ | | +---------------+ +------------------+ |ietf-ssh-server| | ietf-tls-server | +---------------+ +------------------+ ^ ^ ^ | | | | | | | +--------------------+ | | | | +-------------------+ +--------------------+ |ietf-netconf-server| |ietf-restconf-server| +-------------------+ +--------------------+ I want to discuss with the group if we should adopt this solution instead, perhaps breaking it up into separate drafts submitted to different working groups. Thanks, Kent On 7/6/15, 10:56 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 Network Configuration Working Group of >the IETF. > > Title : NETCONF Server and RESTCONF Server >Configuration Models > Authors : Kent Watsen > Juergen Schoenwaelder > Filename : draft-ietf-netconf-server-model-07.txt > Pages : 87 > Date : 2015-07-06 > >Abstract: > This draft defines a NETCONF server configuration data model and a > RESTCONF server configuration data model. These data models enable > configuration of the NETCONF and RESTCONF services themselves, > including which transports are supported, what ports the servers > listen on, call-home parameters, client authentication, and other > related configuration parameters. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-netconf-server-model-07 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-server-model-07 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jul 6 08:16:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0781A89A7 for ; Mon, 6 Jul 2015 08:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 C2050KkMslaE for ; Mon, 6 Jul 2015 08:16:35 -0700 (PDT) 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 DA9D21A8A20 for ; Mon, 6 Jul 2015 08:16:34 -0700 (PDT) Received: by labgy5 with SMTP id gy5so6879259lab.2 for ; Mon, 06 Jul 2015 08:16:33 -0700 (PDT) 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=DBs7/mUIZXGDfwC87RaikRCPDnRojmcQZmbUKKGUDzM=; b=E1kQdBluoM2BmQ/hVZJ06+U1mLnT3Mr1wlBJjxVuz/qsMqG3kGkyp6MW6jOXxgkOC9 S/tdrh7oPBtk7rhN0reN0rZVFEBKNwHbsDZxzRC4sNFSPVf4DZdHhDZLlg2Hmr40/ye3 PCPPmqMa3KZeJ560mnmiEDPElVzAM0vLKEgN+DsVLiPXPgX/DBhDeQ9C64a+CWKgGei0 pA/1ibf3EY0tq6EsY2hyglsVVeoCrGLW+dSwewj1K9x9ADAJE+kzHGmc0LyROf+OuRDO MUROqbRW70a4Zl6TxvB4/ssZYuDj8iMVxUk4uxmlqb5yqxF1dpa7Jru8oF1YJR9yP4Lr HnNg== X-Gm-Message-State: ALoCoQkKFgfqWdkWjoUgIthL6oFH4gwgX+heJkI7JmVtq5mRUqgWepgZ+88o+/nMLWeunAEf+LF+ MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr49453461lbp.88.1436195793243; Mon, 06 Jul 2015 08:16:33 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 6 Jul 2015 08:16:32 -0700 (PDT) In-Reply-To: <20150706150430.GA342@elstar.local> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> <20150706074558.GA6272@elstar.local> <20150706150430.GA342@elstar.local> Date: Mon, 6 Jul 2015 08:16:32 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113403d815a9ce051a366431 Archived-At: Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 15:16:37 -0000 --001a113403d815a9ce051a366431 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 6, 2015 at 8:04 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jul 06, 2015 at 07:59:29AM -0700, Andy Bierman wrote: > > On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: > > > > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > > > > > > > > > I propose this text in the conformance leaf: > > > > > > > > > > > > For import statements that do not specify a > revision > > > > > > date, the most recent revision in the library > SHOULD > > > > > > be used by the server."; > > > > > > > > > > > > It seems like a lot of data will be needed to model the > dependency > > > tree > > > > > > for every import-stmt in every module. Don't forget every > > > include-stmt > > > > > > as well, since submodules can import with or without revision. > > > > > > > > > > > > IMO "SHOULD use latest" is good enough. > > > > > > Perhaps modules should use import-by-revision when they > > > > > > are published as RFCs (as Lada suggested). > > > > > > > > > > This sounds like "lets pretend the world is simple so we have less > > > > > work to do". > > > > > > > > > > > > > > No -- YANG currently says if there is no revision date > > > > then the implementation can use any revision, > > > > > > Exactly - any revision. > > > > > > > This is also good enough. Prove that this is causing > interoperability > > > > problems. I don't think it is -- especially not such that the server > > > > has to model all its imports so the client can retrieve the data. > > > > > > Did I say all imports? No. I think a server should announce which > > > revision was picked to resolve imports without a revision. > > > > > > > > But it could be any revision. > > > > A imports B.1 imports C > > D imports B.4 imports C > > E imports F imports G imports C > > Can we agree on "all imports without a revision fixed in the data > model"? > That's not what the RFC 6020 says (not sure about bis) > > > C can be imported many times without revision. > > Yes. > > > Any import in the chain can be with out without a revision date. > > Yes. > > > IMO "SHOULD use latest revision of C advertised" is best because > > the latest revision is generally the most correct and supports the > > most product features. > > But I thought the goal was to know precisely what a device implements, > not what it _could_ implement. > > > If the import of C really depends on specific revisions of > > some typedefs, groupings, etc. then import by revision MUST > > be used everywhere in the dependency chain (C and all its imports). > > > > If no revision-stmt is present the server can pick whatever revision > > it wants. If this is a problem, then fix this problem, don't add > > some complex monitoring requirements for servers to implement > > and clients to process. Let's make import-by-revision mandatory > > if import-without-revision is a such a problem. > > If the data model leaves it open, then indeed the implementor can > choose. What is wrong with reporting what was chosen? > If there is just a leaf that says 'default-revision=true' like I proposed, then no problem. If I have to reproduce the entire imports/include->imports tree with filled in revision dates, then this is overkill, too much memory/data, and it is a problem. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a113403d815a9ce051a366431 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 6, 2015 at 8:04 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jul 06, 2015 at 07:59:29AM -0700, Andy Bierma= n wrote:
> On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote:
> > > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder <<= br> > > > j.sc= hoenwaelder@jacobs-university.de> wrote:
> > >
> > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman = wrote:
> > > >
> > > > > I propose this text in the conformance leaf:
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 For import statements that do not specify a revision
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 date, the most recent revision in the library SHOULD
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 be used by the server.";
> > > > >
> > > > > It seems like a lot of data will be needed to mode= l the dependency
> > tree
> > > > > for every import-stmt in every module.=C2=A0 Don&#= 39;t forget every
> > include-stmt
> > > > > as well, since submodules can import with or witho= ut revision.
> > > > >
> > > > > IMO "SHOULD use latest" is good enough.<= br> > > > > > Perhaps modules should use import-by-revision when= they
> > > > > are published as RFCs (as Lada suggested).
> > > >
> > > > This sounds like "lets pretend the world is simple= so we have less
> > > > work to do".
> > > >
> > > >
> > > No -- YANG currently says if there is no revision date
> > > then the implementation can use any revision,
> >
> > Exactly - any revision.
> >
> > > This is also good enough.=C2=A0 Prove that this is causing i= nteroperability
> > > problems.=C2=A0 I don't think it is -- especially not su= ch that the server
> > > has to model all its imports so the client can retrieve the = data.
> >
> > Did I say all imports? No. I think a server should announce which=
> > revision was picked to resolve imports without a revision.
> >
> >
> But it could be any revision.
>
>=C2=A0 =C2=A0 A imports B.1 imports C
>=C2=A0 =C2=A0 D imports B.4 imports C
>=C2=A0 =C2=A0 E imports F imports G imports C

Can we agree on "all imports without a revision fixed in the data
model"?
=C2=A0

That'= s not what the RFC 6020 says (not sure about bis)
=C2=A0

> C can be imported many times without revision.

Yes.

> Any import in the chain can be with out without a revision date.

Yes.

> IMO "SHOULD use latest revision of C advertised" is best bec= ause
> the latest revision is generally the most correct and supports the
> most product features.

But I thought the goal was to know precisely what a device implements,
not what it _could_ implement.

> If the import of C really depends on specific revisions of
> some typedefs, groupings, etc. then import by revision MUST
> be used everywhere in the dependency chain (C and all its imports). >
> If no revision-stmt is present the server can pick whatever revision > it wants.=C2=A0 If this is a problem, then fix this problem, don't= add
> some complex monitoring requirements for servers to implement
> and clients to process.=C2=A0 Let's make import-by-revision mandat= ory
> if import-without-revision is a such a problem.

If the data model leaves it open, then indeed the implementor can
choose.=C2=A0 What is wrong with reporting what was chosen?

If there is just a leaf that says 'default-revisio= n=3Dtrue'
like I proposed, then no problem.=C2=A0 If I have t= o reproduce the
entire imports/include->imports tree with fill= ed in revision dates,
then this is overkill, too much memory/data= , and it is a problem.



/js



Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a113403d815a9ce051a366431-- From nobody Mon Jul 6 09:33:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325AD1B2F96; Mon, 6 Jul 2015 09:33:09 -0700 (PDT) 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 VGhe2Yg0fCJG; Mon, 6 Jul 2015 09:33:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC6B1B2FD4; Mon, 6 Jul 2015 09:33:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706163302.28516.16680.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 09:33:02 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 16:33:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-07.txt Pages : 103 Date : 2015-07-06 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 09:35:42 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A4F1B2F90; Mon, 6 Jul 2015 09:35:41 -0700 (PDT) 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 54S9Hfo-0TRI; Mon, 6 Jul 2015 09:35:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4061B2FDB; Mon, 6 Jul 2015 09:35:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706163524.5684.59160.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 09:35:24 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 16:35:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-patch-05.txt Pages : 29 Date : 2015-07-06 Abstract: This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 09:36:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CB01B2FED; Mon, 6 Jul 2015 09:36:00 -0700 (PDT) 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 E1xl8M9Ki7Y5; Mon, 6 Jul 2015 09:35:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE01E1B2FDB; Mon, 6 Jul 2015 09:35:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706163544.29695.79263.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 09:35:44 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-library-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 16:36:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Module Library Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-library-01.txt Pages : 12 Date : 2015-07-06 Abstract: This document describes a YANG library, which provides information about all the YANG modules used by a device to represent management and protocol information. A YANG library can be shared by multiple protocols within the same device. Simple caching mechanisms are needed to allow clients to minimize retrieval of this information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-library-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-library-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 16:12:05 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7411A0233; Mon, 6 Jul 2015 16:12:03 -0700 (PDT) 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 UMqsm2QZmZNb; Mon, 6 Jul 2015 16:12:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D311D1A1A4E; Mon, 6 Jul 2015 16:11:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706231159.19439.33157.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 16:11:59 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 23:12:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) Authors : Kent Watsen Joe Clarke Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-03.txt Pages : 34 Date : 2015-07-06 Abstract: This draft presents a technique for establishing a secure NETCONF connection between a newly deployed IP-based device, configured with just its factory default settings, and its rightful owner's network management system (NMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-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 Jul 6 16:14:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF6F1A1A4E for ; Mon, 6 Jul 2015 16:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qplDyDmFSp7x for ; Mon, 6 Jul 2015 16:14:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2921A1A42 for ; Mon, 6 Jul 2015 16:14:51 -0700 (PDT) Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB426.namprd05.prod.outlook.com (10.141.74.24) with Microsoft SMTP Server (TLS) id 15.1.195.15; Mon, 6 Jul 2015 23:14:51 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 6 Jul 2015 23:14:50 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) with mapi id 15.01.0207.004; Mon, 6 Jul 2015 23:14:50 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-03.txt Thread-Index: AQHQuEEu0SmT//SyeUGPh9ipnr1K7J3Oz4UA Date: Mon, 6 Jul 2015 23:14:49 +0000 Message-ID: References: <20150706231159.19439.33157.idtracker@ietfa.amsl.com> In-Reply-To: <20150706231159.19439.33157.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:xi7niOnTqd22b1Od5Sy1WknqdEZneggMVmGqRrfY3o+2YwBFKev01H5frvoK3zYq00QoimP7r8SZGd4+II93ScaFFHLqGA0Hcf3oSwIdPrN83bRmGrlt1LMEHnTTf7Uc3yy0zjADG7aL+L0OpaEKeg==; 24:Ec8yfaxVxcF6DLJN7mBiwU/QUoMe4PHmjmfp/L4F/4GtHQsR141Bh8BoADeko1j5ARxOAtmXkyZ6a8VUhAnPO4ve84n6bUrITs7bclSilkk=; 20:yHAjmXugMqZBf4IEJErU7NqWxOAiJS7EX9C71p5oI42NjX0oDrQ5pE6nHXypAbZJYUzDzA3QtWNf4D1URo9/lw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB426; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377424004)(377454003)(51704005)(164054003)(24454002)(46102003)(76176999)(19580395003)(66066001)(19580405001)(87936001)(83506001)(50986999)(4001350100001)(2900100001)(2656002)(54356999)(92566002)(2950100001)(15975445007)(102836002)(99286002)(40100003)(122556002)(110136002)(36756003)(106116001)(5002640100001)(450100001)(189998001)(2501003)(107886002)(2351001)(5001960100002)(77156002)(230783001)(62966003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 23:14:49.9342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB426; 2:s2DqszRBCXc9zH2gn6G59GX2aYu+gZIDVeekBN6xe2i2KjL8KixH+YigXthoYNlU; 3:O1O3fylCjgBYJTyIwbJt6rlwHf/d/EWvFVs7LMmC4KlV3T96dYZVvQP5AgEJUgLMXBZqrWHS9YQoIoN+FwY2X1iMQUAAAlsGJcVOtY0CcuMkPLGtuKWJ1fUBAhICUw/VEmsI9w7B2wioDtDv03O+xA==; 23:raOYKAfZHRQYe93xsksTzFG23gMtJwJrEI8fpbGEJooH3gM78aTBokbsPpHy5GHhHt+nXLR9JDiyf6+lgwHMIM6jnY381y2u+M6noUD/+UJM7bn0Kk3DfMfBsE6izkHcwbeUGCfUyhLzJRB7iNWFVzXUidsjRF1OKRqL+abHcX5Zw71a4iGNNFwAL08ws52ZInfEN59s75l0GZDL86KiqT69pryVSBFnfA48MS1vOKAHmxogMIiR5GgjqkVbXQlx X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 23:14:53 -0000 Hi, This is minor update. It primarily adds an Editor's Note to show how this draft might integrate with the draft-pritikin-anima-bootstrapping-keyinfra. Thanks, Kent On 7/6/15, 7:11 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : Zero Touch Provisioning for NETCONF Call Home >(ZeroTouch) > Authors : Kent Watsen > Joe Clarke > Mikael Abrahamsson > Filename : draft-ietf-netconf-zerotouch-03.txt > Pages : 34 > Date : 2015-07-06 > >Abstract: > This draft presents a technique for establishing a secure NETCONF > connection between a newly deployed IP-based device, configured with > just its factory default settings, and its rightful owner's network > management system (NMS). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-03 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-zerotouch-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/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jul 6 18:50:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00361A00DD for ; Mon, 6 Jul 2015 18:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ERzac7tcg9np for ; Mon, 6 Jul 2015 18:50:16 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 995C01A00CA for ; Mon, 6 Jul 2015 18:50:15 -0700 (PDT) Received: by labgy5 with SMTP id gy5so24488866lab.2 for ; Mon, 06 Jul 2015 18:50:14 -0700 (PDT) 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=LnyGQFPFGYzmy+sBsZT3VCt5SC5FN2/ezYRrC0EZYtY=; b=B2SkG9fe89eQmmrPVMqxC9lFnW7aZYHCFZn2n2JdEvdWcaoiUiY7uka3WmYz+pZJce hEsH/xCqcu6LjEgEAp65/vfJzuo88eHS1lLDcf1CGyX85N69PK6y4m5PupNlTaAFnSG/ dFQVHqt0sgG45R/K7brlieOAVaYjcMb3zgUUxkAavZeB10Tlw+DcjesmILuOOvJsDP8o 9sQ8XJmWI9UyOFrwjraY5d3JEXT9YThCjl0lXo+RHcsqPGlM6UZxEBQ0NbfwklkwbPhL k0HsvDV6lP/URsxHJNToRZrxg57QV0SlAQSOlvHacmhOqsN0F5ygKsaVv+HKncdEZnre m+HQ== X-Gm-Message-State: ALoCoQm/9ngY740TcyoJpcaTVgdLNVIWpQpJL5T5rxLGcaDVAp8NQYxem8ymSxivbvGR2F5uVLHP MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr1606439laj.123.1436233813915; Mon, 06 Jul 2015 18:50:13 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 6 Jul 2015 18:50:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Jul 2015 18:50:13 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=089e0158ba0a4b1555051a3f3e53 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 01:50:18 -0000 --089e0158ba0a4b1555051a3f3e53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have reviewed the call home draft and I think it is done. It should be forwarded to the IESG for publication. Andy On Sun, Jul 5, 2015 at 2:42 AM, Ersue, Mehmet (Nokia - DE/Munich) < mehmet.ersue@nokia.com> wrote: > Dear Netconf WG, > > > > we had so far only one review and one support statement on the Call Home > draft. > > A thorough review is necessary before we can decide on the next steps. > > > > With this mail I would like to extend the WGLC deadline until July 10, > 2015 EOB PT. > > > > Please review the Call Home draft and provide your comments to Netconf > maillist. > > Please state as a minimum whether you support to publish the document. > > > > Mehmet > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *ext > Mahesh Jethanandani > *Sent:* Friday, June 26, 2015 7:21 AM > *To:* Netconf > *Subject:* [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 > > > > Dear NETCONF participants, > > This e-mail is a notification to start a NETCONF WG Last Call for the > document "NETCONF Call Home and RESTCONF Call Home=E2=80=9D. > > > The document can be found at: draft-ietf-netconf-call-home-07 > . > > > > Please review the document, provide comments, and indicate your support > for the draft by Friday July 3 (your timezone). The comments can be in th= e > form of: > > > > - =E2=80=9CI have reviewed the I-D Blah and I have found issues with i= t=E2=80=9D > - =E2=80=9CI have reviewed I-D Blah and I found no issues=E2=80=9D > > > > Simultaneously, the author on this draft should state to the mailing list > whether there is any IPR associated with this draft or not. > > > > Thanks > > > Mahesh and Mehmet > > (Co-chairs, NETCONF WG) > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --089e0158ba0a4b1555051a3f3e53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have reviewed the call home draft= and I think it is done.
It should be forwarded to the IESG for p= ublication.


Andy


On Sun, J= ul 5, 2015 at 2:42 AM, Ersue, Mehmet (Nokia - DE/Munich) = <mehmet.ersu= e@nokia.com> wrote:

= Dear Netconf WG,

= =C2=A0

= we had so far only one review and one support st= atement on the Call Home draft.

= A thorough review is necessary before we can dec= ide on the next steps.

= =C2=A0

= With this mail I would like to extend the WGLC d= eadline until July 10, 2015 EOB PT.

= =C2=A0

= Please review the Call Home draft and provide yo= ur comments to Netconf maillist.

= Please state as a minimum whether you support to= publish the document.

= =C2=A0

= Mehmet

= =C2=A0

From: Netconf [mailto:netconf-bounces@ietf.org] On Be= half Of ext Mahesh Jethanandani
Sent: Friday, June 26, 2015 = 7:21 AM
To: Netconf
Subject: [Netconf] WG Last C= all for draft-ietf-netconf-call-home-07

=C2=A0

Dear NETCONF participants,

This e-mail is a notification to start a NETCONF WG Last Call for the docum= ent "NETCONF Call Home and RESTCONF Call Home=E2=80=9D.<= /span>


The document can be found at:=C2=A0draft-ietf-netconf-call-h= ome-07.

=C2=A0

Please review the document, provide comments, and in= dicate your support for the draft by Friday July 3 (your timezone). The com= ments can be in the form of:

=C2=A0

  • = =E2=80=9CI have reviewed the I-D Blah and I have found issues with it=E2=80= =9D
  • = =E2=80=9CI have reviewed I-D Blah and I found no issues=E2=80=9D<= /u>

=C2=A0

Simultaneously, the author on this draft should stat= e to the mailing list whether there is any IPR associated with this draft or not.

=C2=A0

Thanks


Mahesh and Mehmet

(Co-chairs, NETCONF WG)<= /p>

=C2=A0

=C2=A0<= /span>

=C2=A0


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


--089e0158ba0a4b1555051a3f3e53-- From nobody Mon Jul 6 22:39:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0847C1A8AD2 for ; Mon, 6 Jul 2015 22:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ7lXgGMK8Ov for ; Mon, 6 Jul 2015 22:39:38 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C6C1A8ACD for ; Mon, 6 Jul 2015 22:39:37 -0700 (PDT) Received: by pactm7 with SMTP id tm7so107237811pac.2 for ; Mon, 06 Jul 2015 22:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=8R+aukyG4XUzkKGgnkBYxmWUEX3fuOIPF88qBGTWlbg=; b=Z1tquBVv3DqAfgWvw8Cjvh7UsUqLOAcOMW6mKuzhzyLJnmrhqbecZHu1JAXrFSgZTE Xz1YFngDEmtI8Y0fJDoA/HTHJJwEEGnsPtlADSccYX8/fxWaDbGlEjfz/IfatZ1L4LBk NdvG96izZckIiikSAZgq5PnZeEwn4bPwlZcexl+rxu2eHNNLKJpktRpMDWy3b7soj0bL 2Opt0AgAkwxb2K5sTQGCcqVhmQoSKkB8vkaFz5ikd7wfmfVQSAvZHvxobU0Vhwr+5H/E Kzb+C+h1C9AIloLCf7fZ4wgASQpx34fa1ozAxr4aytoA/LVNxilke8bl3gBYHV362IuF k4PA== X-Received: by 10.68.57.168 with SMTP id j8mr5019048pbq.99.1436247577680; Mon, 06 Jul 2015 22:39:37 -0700 (PDT) Received: from sjc-mahesh-nitro3.cisco.com ([128.107.241.168]) by mx.google.com with ESMTPSA id md10sm11450088pdb.33.2015.07.06.22.39.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 22:39:36 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_A59C1B5D-9D92-44F7-A7B6-805ACF66BA55" Date: Mon, 6 Jul 2015 22:39:34 -0700 Message-Id: <12774D67-A97C-487E-BFB0-F3580EC3020F@gmail.com> To: Netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Netconf] Call for agenda items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 05:39:39 -0000 --Apple-Mail=_A59C1B5D-9D92-44F7-A7B6-805ACF66BA55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a call for agenda items for IETF 93 in Prague. Please provide = topics that you would like to see discussed in the meeting. We will = publish a draft agenda shortly. Cheers. Mahesh & Mehmet --Apple-Mail=_A59C1B5D-9D92-44F7-A7B6-805ACF66BA55 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii This is a call for agenda items for IETF 93 in Prague. Please provide topics that you would like to see discussed in the meeting. We will publish a draft agenda shortly.

Cheers.

Mahesh & Mehmet





--Apple-Mail=_A59C1B5D-9D92-44F7-A7B6-805ACF66BA55-- From nobody Tue Jul 7 00:53:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA41A1A99; Tue, 7 Jul 2015 00:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 8FihF3MqwaQS; Tue, 7 Jul 2015 00:53:42 -0700 (PDT) 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 E01481A1A39; Tue, 7 Jul 2015 00:53:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 366AA11D9; Tue, 7 Jul 2015 09:53:39 +0200 (CEST) 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 X72HxByleUe7; Tue, 7 Jul 2015 09:53:38 +0200 (CEST) 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, 7 Jul 2015 09:53:38 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46C7020013; Tue, 7 Jul 2015 09:53:39 +0200 (CEST) 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 UgwxNbTJMLzi; Tue, 7 Jul 2015 09:53:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 669E92002C; Tue, 7 Jul 2015 09:53:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3A25734EFCA8; Tue, 7 Jul 2015 09:53:33 +0200 (CEST) Date: Tue, 7 Jul 2015 09:53:32 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150707075330.GA1656@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> <20150706074558.GA6272@elstar.local> <20150706150430.GA342@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: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 07:53:48 -0000 On Mon, Jul 06, 2015 at 08:16:32AM -0700, Andy Bierman wrote: > > > If the import of C really depends on specific revisions of > > > some typedefs, groupings, etc. then import by revision MUST > > > be used everywhere in the dependency chain (C and all its imports). > > > > > > If no revision-stmt is present the server can pick whatever revision > > > it wants. If this is a problem, then fix this problem, don't add > > > some complex monitoring requirements for servers to implement > > > and clients to process. Let's make import-by-revision mandatory > > > if import-without-revision is a such a problem. > > > > If the data model leaves it open, then indeed the implementor can > > choose. What is wrong with reporting what was chosen? > > > > If there is just a leaf that says 'default-revision=true' > like I proposed, then no problem. But this assumes that there is a single revision that has been used by all imports. Are we sure this will be true for all implementations? Benoit just posted some numbers - OpenDaylight Lithim shipped with 473 YANG modules, about 155 YANG modules that can be extracted in I-Ds for the upcoming IETF, and other SDOs are on their way as well to produce YANG modules. If I assume that products will in a couple of years implement hundreds of YANG modules, do we believe that imports without revision can all be kept at a specific revision throughout the whole system? > If I have to reproduce the entire imports/include->imports tree with > filled in revision dates, then this is overkill, too much > memory/data, and it is a problem. It seems to be a trade-off. If a vendor manages to manage his software very well, then 'default-revision=true' may do its job. If not, then we have no standard way to find out what was actually implemented. So we have the following scenarios: a) Import by revision de-factor disappears. Problem disappears. b) Import by revision does not disappear. 1) Vendor manages to keeps all modules aligned to a single revision, then 'default-revision=true' works. 2) Vendor does not manage to keep all modules aligned to a single revision (btw, this can also be forced on the vendor by modules from differnet SDOs), then we apparently need additional complexity to report what precisely was implemented. One option out could be to strongly recommend a), to provide the 'default-revision=true' possibility, to provide b.2) as a feature for systems where 'default-revision=true' is not workable. /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 Jul 7 09:28:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7FD1ACE26 for ; Tue, 7 Jul 2015 09:27:58 -0700 (PDT) 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 20qhy-yf7L2j for ; Tue, 7 Jul 2015 09:27:56 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40AED1ACE28 for ; Tue, 7 Jul 2015 09:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41487; q=dns/txt; s=iport; t=1436286474; x=1437496074; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=WaifFOsvrJgVojaLEMriRMLez7t2jBFlNaNDIoABuZU=; b=mrS8psK+s57+QDgaeoyrkyTjGu9lmhUyRPg4Q7er8FthanvMC3xtf7jp lOQVEL8/VMsjX+SKifyB80cWtkm6Uq5/AvrTG+NzZeJ27yYhMxKjbfXAZ K4MCGOiN/CDGtNFWhMKbhlFR3TsDAEBFDOY0n+oqZbYOVV5TghPwuUEAN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CkBAA8/ZtV/xbLJq1bgkWBIWC1PYoEGQEJhS1KAoIhAQEBAQEBgQuEIwEBAQQBAQEaBgpBCgEQCQIRBAEBChYBAQYDAgIJAwIBAgEUAR8IAQgGAQwFAQIBAQWIJQ2YS50ZlmQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0uBPYJ3AQEFRwQGAYJogUMBBIcFjROEYocHgTpFg1KCbYgVhCqDXSZjgTYkgUA8MQGBDIE+AQEB X-IronPort-AV: E=Sophos;i="5.15,424,1432598400"; d="scan'208,217";a="551648530" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 07 Jul 2015 16:27:52 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t67GRpbH026594; Tue, 7 Jul 2015 16:27:51 GMT To: "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" References: From: Benoit Claise Message-ID: <559BFE07.8010009@cisco.com> Date: Tue, 7 Jul 2015 18:27:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020306000305030809030100" Archived-At: Cc: 'Barry Leiba' Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 16:27:59 -0000 This is a multi-part message in MIME format. --------------020306000305030809030100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear authors, - 1.4 . Update to RFC 4253 This document updates the SSH Transport Layer Protocol [RFC4253 ] only in removing the statement "The client initiates the connection" made inSection 4 (Connection Setup). Assuming the reference to client means "SSH client" and the reference to connection means "TCP connection", this statement doesn't hold true in call home, where the network element is the SSH server and yet still initiates the TCP connection. Security implications related to this change are discussed in Security Considerations (Section 4 ). From idnits: Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC4253, updated by this document, for RFC5378 checks: 2005-03-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) All of the above is around the RFC 4253 update ... but actually, do you update RFC 4253? If you update it (remove "The client initiates the connection"), then this is for all SSH users, and we should check with everybody. I guess that what you want to say is something such as: This document uses the SSH Transport Layer Protocol [RFC4253 ] with the exception that the statement "The client initiates the connection" made inSection 4 (Connection Setup) does not apply. Assuming the reference to client means "SSH client" and the reference to connection means "TCP connection", this statement doesn't hold true in call home, where the network element is the SSH server and yet still initiates the TCP connection. Security implications related to this change are discussed in Security Considerations (Section 4 ). And then you don't update RFC 4253. - draft-ietf-netconf-rfc5539bis is now RFC 7589 Regards, Benoit > > Dear Netconf WG, > > we had so far only one review and one support statement on the Call > Home draft. > > A thorough review is necessary before we can decide on the next steps. > > With this mail I would like to extend the WGLC deadline until July 10, > 2015 EOB PT. > > Please review the Call Home draft and provide your comments to Netconf > maillist. > > Please state as a minimum whether you support to publish the document. > > Mehmet > > *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *ext > Mahesh Jethanandani > *Sent:* Friday, June 26, 2015 7:21 AM > *To:* Netconf > *Subject:* [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 > > Dear NETCONF participants, > > This e-mail is a notification to start a NETCONF WG Last Call for the > document "NETCONF Call Home and RESTCONF Call Homeâ€. > > > The document can be found at: draft-ietf-netconf-call-home-07 > . > > Please review the document, provide comments, and indicate your > support for the draft by Friday July 3 (your timezone). The comments > can be in the form of: > > * “I have reviewed the I-D Blah and I have found issues with it†> * “I have reviewed I-D Blah and I found no issues†> > Simultaneously, the author on this draft should state to the mailing > list whether there is any IPR associated with this draft or not. > > Thanks > > > Mahesh and Mehmet > > (Co-chairs, NETCONF WG) > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------020306000305030809030100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dear authors,

- 

1.4.  Update to RFC 4253

   This document updates the SSH Transport Layer Protocol [RFC4253] only
   in removing the statement "The client initiates the connection" made
   in Section 4 (Connection Setup).  Assuming the reference to client
   means "SSH client" and the reference to connection means "TCP
   connection", this statement doesn't hold true in call home, where the
   network element is the SSH server and yet still initiates the TCP
   connection.  Security implications related to this change are
   discussed in Security Considerations (Section 4).

>From idnits:


  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC4253, but the
     abstract doesn't seem to mention this, which it should.
  Miscellaneous warnings:
  ----------------------------------------------------------------------------

     (Using the creation date from RFC4253, updated by this document, for
     RFC5378 checks: 2005-03-16)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.)
All of the above is around the RFC 4253 update ... but actually, do you update RFC 4253?
If you update it (remove "The client initiates the connection"), then this is for all SSH users, and we should check with everybody.
I guess that what you want to say is something such as: 
   This document uses the SSH Transport Layer Protocol [RFC4253] with the 
   exception that the statement "The client initiates the connection" made
   in Section 4 (Connection Setup) does not apply.  Assuming the reference 
   to client means "SSH client" and the reference to connection means "TCP
   connection", this statement doesn't hold true in call home, where the
   network element is the SSH server and yet still initiates the TCP
   connection.  Security implications related to this change are
   discussed in Security Considerations (Section 4).
And then you don't update RFC 4253.
 
- draft-ietf-netconf-rfc5539bis is now RFC 7589

Regards, Benoit

Dear Netconf WG,

 

we had so far only one review and one support statement on the Call Home draft.

A thorough review is necessary before we can decide on the next steps.

 

With this mail I would like to extend the WGLC deadline until July 10, 2015 EOB PT.

 

Please review the Call Home draft and provide your comments to Netconf maillist.

Please state as a minimum whether you support to publish the document.

 

Mehmet

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mahesh Jethanandani
Sent: Friday, June 26, 2015 7:21 AM
To: Netconf
Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07

 

Dear NETCONF participants,

This e-mail is a notification to start a NETCONF WG Last Call for the document "NETCONF Call Home and RESTCONF Call Homeâ€.


The document can be found at: draft-ietf-netconf-call-home-07.

 

Please review the document, provide comments, and indicate your support for the draft by Friday July 3 (your timezone). The comments can be in the form of:

 

  • “I have reviewed the I-D Blah and I have found issues with itâ€
  • “I have reviewed I-D Blah and I found no issuesâ€

 

Simultaneously, the author on this draft should state to the mailing list whether there is any IPR associated with this draft or not.

 

Thanks


Mahesh and Mehmet

(Co-chairs, NETCONF WG)

 

 

 



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

--------------020306000305030809030100-- From nobody Tue Jul 7 15:05:10 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB6F1AD49D for ; Tue, 7 Jul 2015 15:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 ELGI5TN8-Rms for ; Tue, 7 Jul 2015 15:05:06 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 6F4CF1AD36E for ; Tue, 7 Jul 2015 15:05:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t67M54M2031830 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Jul 2015 22:05:04 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t67M530T031003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jul 2015 00:05:04 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 8 Jul 2015 00:05:03 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.53]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0235.001; Wed, 8 Jul 2015 00:05:03 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Opinion poll for the support of draft-mm-netconf-time-capability Thread-Index: AdC5APj6F5AalfP1QqqtQQDMYH6XWQ== Date: Tue, 7 Jul 2015 22:05:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819721C63DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4072 X-purgate-ID: 151667::1436306704-000058F0-EB55BE17/0/0 Archived-At: Subject: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 22:05:08 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819721C63DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, draft-mm-netconf-time-capability has been discussed in Netconf WG in differ= ent IETF meetings. There was only cautious support. As recently the authors asked for support on the maillist no single person = spoke for this draft. However, after the draft has been brought to IETF LC as AD supported draft,= there were diverse people supporting strongly and proposed to publish the = document in NETCONF WG. Just to be sure we develop the right documents in Netconf WG, we would like= to ask the same question again. Based on the support on Netconf maillist draft-mm-netconf-time-capability m= ay be adopted as a new WG item. - If anybody thinks draft-mm-netconf-time-capability does fit the focus of = Netconf WG and should be developed as Netconf WG item please state your opi= nion on the maillist within one week (July 15, 2015 EOB PT). - If anybody thinks that this is not the right approach to develop in Netco= nf WG please state it as well. - We also would like to know whether anybody did or is planning to implemen= t draft-mm-netconf-time-capability. Best Regards, Mehmet Ersue Netconf WG Co-chair --_000_E4DE949E6CE3E34993A2FF8AE79131F819721C63DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
draft-mm-netconf-time-capability has been disc= ussed in Netconf WG in different IETF meetings. There was only cautious sup= port.
As recently the authors asked for support on t= he maillist no single person spoke for this draft.
 
However, after the draft has been brought to I= ETF LC as AD supported draft, there were diverse people supporting strongly= and proposed to publish the document in NETCONF WG.
 
Just to be sure we develop the right documents= in Netconf WG, we would like to ask the same question again.
Based on the support on Netconf maillist draft= -mm-netconf-time-capability may be adopted as a new WG item.
 
 
- If anybody thinks draft-mm-netconf-time-capa= bility does fit the focus of Netconf WG and should be developed as Netconf = WG item please state your opinion on the maillist within one week (July 15,= 2015 EOB PT).
 
- If anybody thinks that this is not the right= approach to develop in Netconf WG please state it as well.
 
- We also would like to know whether anybody d= id or is planning to implement draft-mm-netconf-time-capability.
 
Best Regards,
Mehmet Ersue
Netconf WG Co-chair
 
 
 --_000_E4DE949E6CE3E34993A2FF8AE79131F819721C63DEMUMBX005nsnin_-- From nobody Tue Jul 7 17:46:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAEE1B2C3A for ; Tue, 7 Jul 2015 17:46:15 -0700 (PDT) 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 uznbKkkqDBOL for ; Tue, 7 Jul 2015 17:46:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAB41B2C38 for ; Tue, 7 Jul 2015 17:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4160; q=dns/txt; s=iport; t=1436316373; x=1437525973; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=4/+Xly4fAt7I1YdlevfB5EUp2D7Ohz31cMcEosas++0=; b=c7R0M/+NUJm1ZS95yfL4b47HhmSPjneOiQ0967y51j4GU1FVrelgmqZv /nONvb2MhwD6lYrRWKKyfnifg1wnT0IDnsX1x8fLnVHqOk+gjT8oIBa0e k8Ix4K/NmPxln2wkIYRBh8vV39moc1owjj57tIYPUMJTzUzvpXoNR9SFW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CMBQBzcZxV/5JdJa1bgxJUYAaDGrpWgXGFdQIcgTw5EwEBAQEBAQGBCoQjAQEBBCMRRQwGARkEAQEDAgYDGgMCBDAUAQgJAQQOBQiIJg22K5ZCAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiiqELQENGjENgmIvgRQFjByHfAGEYYhBRYNSiwKIByaDe28BgQMBHyOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,427,1432598400"; d="scan'208";a="13483615" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jul 2015 00:46:12 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t680kCGd013136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jul 2015 00:46:12 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.132]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 19:46:12 -0500 From: "Alexander Clemm (alex)" To: "netconf@ietf.org" Thread-Topic: New version for draft-clemm-netconf-yang-push-01.txt Thread-Index: AdC5FyP9Rm6uBgErR8+WZ2t4USQNKA== Date: Wed, 8 Jul 2015 00:46:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 00:46:15 -0000 SGksDQoNCndlIGp1c3Qgd2FudGVkIHRvIGxldCB5b3Uga25vdyB0aGF0IHdlIHBvc3RlZCBhIG5l dyB2ZXJzaW9uIG9mIHRoZSBZQU5HIGRhdGFzdG9yZSBwdXNoIGRyYWZ0IHllc3RlcmRheSwgd2hp Y2ggd2UgYXJlIHBsYW5uaW5nIHRvIHByZXNlbnQgaW4gUHJhZ3VlLiAgDQoNClBsZWFzZSBzZWUg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNsZW1tLW5ldGNvbmYt eWFuZy1wdXNoLTAxLnR4dCANCg0KVGhlcmUgYXJlIGEgYSBmZXcgdGVjaG5pY2FsIHVwZGF0ZXMs IGFzIHdlbGwgYXMgcXVpdGUgYSBmZXcgZWRpdG9yaWFsIHVwZGF0ZXMuICANCg0KVGhlIHRlY2hu aWNhbCB1cGRhdGVzIGluY2x1ZGU6DQotIEEgcGFyYW1ldGVyIHRoYXQgYWxsb3dzIGEgc3Vic2Ny aWJlciB0byBzcGVjaWZ5IHdoaWNoIGVuY29kaW5nIHRvIHVzZSBmb3IgZGF0YXN0b3JlIHVwZGF0 ZXMNCi0gQSBwYXJhbWV0ZXIgdGhhdCBhbGxvd3MgYSBzdWJzY3JpYmVyIHRvIGxpbWl0IG9uLWNo YW5nZSBzdWJzY3JpcHRpb25zIHRvIGNlcnRhaW4gdHlwZXMgb2YgY2hhbmdlcw0KDQpUaGVyZSBh cmUgYSBmZXcgaXRlbXMgdGhhdCBtYXkgd2FycmFudCBkaXNjdXNzaW9uLCBtb3N0IG9mIHdoaWNo IGNhbiBiZSBmb3VuZCBpbiBzZWN0aW9uIDMuMTAsIGluY2x1ZGluZzoNCi0gSW50cm9kdWN0aW9u IG9mIGFkZGl0aW9uYWwgYnVpbHQtaW4gZGF0YXN0cmVhbXMgbGltaXRlZCB0byBvcGVyYXRpb25h bCBkYXRhIChzZWN0aW9uIDMuMTAuNSksIHdoaWNoIHdlIHRoaW5rIHdvdWxkIGJlIGEgZ29vZCBp ZGVhIHRvIGZvcm1hbGx5IGluY2x1ZGUgaW4gdGhlIG5leHQgcmV2aXNpb24NCi0gV2hldGhlciB0 byBzdXBwb3J0IHN1YnNjcmlwdGlvbiBwZXJzaXN0ZW5jeSAoY3VycmVudGx5IHRoZSBzdWJzY3Jp cHRpb24gbGlmZWN5Y2xlIGlzIHRpZWQgdG8gdGhlIGxpZmVjeWNsZSBvZiBhIE5ldGNvbmYgc2Vz c2lvbikNCi0gV2hldGhlciB0byBwcm92aWRlIGd1aWRhbmNlIG9uICJjaHVua2luZyIgb2YgdXBk YXRlcyAoY3VycmVudGx5IGxlZnQgdG8gdGhlIGltcGxlbWVudGF0aW9uIHdoZXRoZXIgdG8gc2Vu ZCBhIHNpbmdsZSB1cGRhdGUgbWVzc2FnZSB3aXRoIHRoZSBlbnRpcmUgZGF0YSwgb3IgbXVsdGlw bGUgdXBkYXRlIG1lc3NhZ2VzIGVhY2ggd2l0aCBhIHN1YnNldCBvZiB0aGUgZGF0YSkNCi0gV2hl dGhlciB0byB0cmFjayB0aGUgIm93bmVycyIgb2YgYSBzdWJzY3JpcHRpb24gYXMgcGFydCBvZiB0 aGUgc3Vic2NyaXB0aW9uIGRhdGEgbW9kZWwgKGFnYWluLCB3ZSBiZWxpZXZlIHRoaXMgaXMgYSBn b29kIGlkZWEgd2hpY2ggd2UgcGxhbiB0byBhZGQgaW4gdGhlIG5leHQgcmV2aXNpb24pIA0KDQpS ZWdhcmRzDQotLS0gQWxleCAoYWxzbyBvbiBiZWhhbGYgb2YgRXJpYyBhbmQgQWxiZXJ0bykNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bHkg MDYsIDIwMTUgMzo1NyBQTQ0KVG86IEFsZXhhbmRlciBDbGVtbSAoYWxleCk7IEFsYmVydG8gR29u emFsZXogUHJpZXRvIChhbGJlcnRnbyk7IEFsYmVydG8gR29uemFsZXogUHJpZXRvIChhbGJlcnRn byk7IEVyaWMgVm9pdCAoZXZvaXQpOyBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBFcmljIFZvaXQg KGV2b2l0KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1jbGVt bS1uZXRjb25mLXlhbmctcHVzaC0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtY2xlbW0tbmV0Y29uZi15YW5nLXB1c2gtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEFsZXhhbmRlciBDbGVtbSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z aXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1jbGVtbS1uZXRjb25mLXlhbmctcHVzaA0KUmV2aXNpb246 CTAxDQpUaXRsZToJCVN1YnNjcmliaW5nIHRvIFlBTkcgZGF0YXN0b3JlIHB1c2ggdXBkYXRlcw0K RG9jdW1lbnQgZGF0ZToJMjAxNS0wNy0wNg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24N ClBhZ2VzOgkJMzINClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5nLXB1c2gtMDEudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2xlbW0tbmV0Y29u Zi15YW5nLXB1c2gvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNoLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNo LTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc3Vic2NyaXB0aW9u IGFuZCBwdXNoIG1lY2hhbmlzbSBmb3IgWUFORw0KICAgZGF0YXN0b3Jlcy4gIFRoaXMgbWVjaGFu aXNtIGFsbG93cyBjbGllbnQgYXBwbGljYXRpb25zIHRvIHJlcXVlc3QNCiAgIHVwZGF0ZXMgZnJv bSBhIFlBTkcgZGF0YXN0b3JlLCB3aGljaCBhcmUgdGhlbiBwdXNoZWQgYnkgdGhlIHNlcnZlciB0 bw0KICAgdGhlIGNsaWVudCBwZXIgYSBzdWJzY3JpcHRpb24gcG9saWN5LCB3aXRob3V0IHJlcXVp cmluZyBhZGRpdGlvbmFsDQogICBjbGllbnQgcmVxdWVzdHMuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg== From nobody Wed Jul 8 01:53:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EB61B3302 for ; Wed, 8 Jul 2015 01:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ElPeT95RELJH for ; Wed, 8 Jul 2015 01:53:48 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4324B1B32E9 for ; Wed, 8 Jul 2015 01:53:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAFAHvmdlWHCzIm/2dsb2JhbABcgkUhKlReBqxfAQEBAQEBBplnAoFITAEBAQEBAYELhCIBAQEBAxIbXAIBCA0EBAEBCx0HMhQJCAEBBAESCBMHiAwBoUiufgEBAQEBAQEDAQEBAQEBAQEBARiGGYUqhFU3AYMXgRYFkz6MYIN7gnWLcINbJIIKHIFSb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,581,1427774400"; d="scan'208,217";a="128212938" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Jul 2015 04:53:42 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 08 Jul 2015 04:53:42 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Wed, 8 Jul 2015 10:53:40 +0200 From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" Thread-Topic: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability Thread-Index: AdC5APj6F5AalfP1QqqtQQDMYH6XWQAWhVPw Date: Wed, 8 Jul 2015 08:53:39 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 08:53:50 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was one of the individuals who commented at the IETF LC that this work se= ems to be useful and seems to be within the scope of the Netconf WG. There = were discussions whether the solution proposed in draft-mm-netconf-time-cap= ability is 'the right approach', and also questions about extending this so= lution to Restconf. Regards, Dan From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (Nokia - DE/Munich) Sent: Wednesday, July 08, 2015 1:05 AM To: netconf@ietf.org Subject: [Netconf] Opinion poll for the support of draft-mm-netconf-time-ca= pability Dear NETCONF WG, draft-mm-netconf-time-capability has been discussed in Netconf WG in differ= ent IETF meetings. There was only cautious support. As recently the authors asked for support on the maillist no single person = spoke for this draft. However, after the draft has been brought to IETF LC as AD supported draft,= there were diverse people supporting strongly and proposed to publish the = document in NETCONF WG. Just to be sure we develop the right documents in Netconf WG, we would like= to ask the same question again. Based on the support on Netconf maillist draft-mm-netconf-time-capability m= ay be adopted as a new WG item. - If anybody thinks draft-mm-netconf-time-capability does fit the focus of = Netconf WG and should be developed as Netconf WG item please state your opi= nion on the maillist within one week (July 15, 2015 EOB PT). - If anybody thinks that this is not the right approach to develop in Netco= nf WG please state it as well. - We also would like to know whether anybody did or is planning to implemen= t draft-mm-netconf-time-capability. Best Regards, Mehmet Ersue Netconf WG Co-chair --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I was one of the individu= als who commented at the IETF LC that this work seems to be useful and seem= s to be within the scope of the Netconf WG. There were discussions whether the solution proposed in draft-mm-netconf-time-capability is ̵= 6;the right approach’, and also questions about extending this soluti= on to Restconf.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (Nokia - DE/Munich)
Sent: Wednesday, July 08, 2015 1:05 AM
To: netconf@ietf.org
Subject: [Netconf] Opinion poll for the support of draft-mm-netconf-= time-capability

 

Dear NETCONF WG,

 

draft-mm-netconf-time-cap= ability has been discussed in Netconf WG in different IETF meetings. There = was only cautious support.

As recently the authors a= sked for support on the maillist no single person spoke for this draft.

 

However, after the draft = has been brought to IETF LC as AD supported draft, there were diverse peopl= e supporting strongly and proposed to publish the document in NETCONF WG.

 

Just to be sure we develo= p the right documents in Netconf WG, we would like to ask the same question= again.

Based on the support on N= etconf maillist draft-mm-netconf-time-capability may be adopted as a new WG= item.

 

 

- If anybody thinks draft= -mm-netconf-time-capability does fit the focus of Netconf WG and should be = developed as Netconf WG item please state your opinion on the maillist within one week (July 15, 2015 EOB PT).

 

- If anybody thinks that = this is not the right approach to develop in Netconf WG please state it as = well.

 

- We also would like to k= now whether anybody did or is planning to implement draft-mm-netconf-time-c= apability.

 

Best Regards,
Mehmet Ersue

Netconf WG Co-chair

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30AZFFEXMB04globa_-- From nobody Wed Jul 8 09:55:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBDF1A1A8B for ; Wed, 8 Jul 2015 09:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 mB5BKhOVKcH3 for ; Wed, 8 Jul 2015 09:55:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 51E381A0404 for ; Wed, 8 Jul 2015 09:55:30 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t68GtLE0021589 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jul 2015 16:55:22 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t68GtKKh014823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jul 2015 18:55:21 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 8 Jul 2015 18:55:20 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.53]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0235.001; Wed, 8 Jul 2015 18:55:20 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , "netconf@ietf.org" Thread-Topic: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability Thread-Index: AQHQuZ7f9zwJMD6xSESVDL1NkTZXng== Date: Wed, 8 Jul 2015 16:55:19 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.121] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819723E2BDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 41149 X-purgate-ID: 151667::1436374522-000076F8-E2ACA9F2/0/0 Archived-At: Subject: Re: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 16:55:33 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819723E2BDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Dan! Others please comment no later than July 15th indicating your support or no= n-support. Cheers, Mehmet From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Wednesday, July 08, 2015 10:54 AM To: Ersue, Mehmet (Nokia - DE/Munich); netconf@ietf.org Subject: RE: [Netconf] Opinion poll for the support of draft-mm-netconf-tim= e-capability Hi, I was one of the individuals who commented at the IETF LC that this work se= ems to be useful and seems to be within the scope of the Netconf WG. There = were discussions whether the solution proposed in draft-mm-netconf-time-cap= ability is 'the right approach', and also questions about extending this so= lution to Restconf. Regards, Dan From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (Nokia - DE/Munich) Sent: Wednesday, July 08, 2015 1:05 AM To: netconf@ietf.org Subject: [Netconf] Opinion poll for the support of draft-mm-netconf-time-ca= pability Dear NETCONF WG, draft-mm-netconf-time-capability has been discussed in Netconf WG in differ= ent IETF meetings. There was only cautious support. As recently the authors asked for support on the maillist no single person = spoke for this draft. However, after the draft has been brought to IETF LC as AD supported draft,= there were diverse people supporting strongly and proposed to publish the = document in NETCONF WG. Just to be sure we develop the right documents in Netconf WG, we would like= to ask the same question again. Based on the support on Netconf maillist draft-mm-netconf-time-capability m= ay be adopted as a new WG item. - If anybody thinks draft-mm-netconf-time-capability does fit the focus of = Netconf WG and should be developed as Netconf WG item please state your opi= nion on the maillist within one week (July 15, 2015 EOB PT). - If anybody thinks that this is not the right approach to develop in Netco= nf WG please state it as well. - We also would like to know whether anybody did or is planning to implemen= t draft-mm-netconf-time-capability. Best Regards, Mehmet Ersue Netconf WG Co-chair --_000_E4DE949E6CE3E34993A2FF8AE79131F819723E2BDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Thanks Dan!

=  

= Others please comment no later than July 15th indicating your support or non-support.

=  

= Cheers,
Mehmet

=  

From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Wednesday, July 08, 20= 15 10:54 AM
To: Ersue, Mehmet (Nokia - D= E/Munich); netconf@ietf.org
Subject: RE: [Netconf] Opini= on poll for the support of draft-mm-netconf-time-capability

 

= Hi,

=  

= I was one of the individuals who commented at th= e IETF LC that this work seems to be useful and seems to be within the scope of the Netconf WG. There were discussions whether the solution p= roposed in draft-mm-netconf-time-capability is ‘the right approach= 217;, and also questions about extending this solution to Restconf.

=  

= Regards,

=  

= Dan

=  

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of Ersue, Mehmet (= Nokia - DE/Munich)
Sent: Wednesday, July 08, 20= 15 1:05 AM
To: netconf@ietf.org
Subject: [Netconf] Opinion p= oll for the support of draft-mm-netconf-time-capability

 

= Dear NETCONF WG,

 <= /p>

= draft-mm-netconf-time-capability has been discus= sed in Netconf WG in different IETF meetings. There was only cautious support.

= As recently the authors asked for support on the= maillist no single person spoke for this draft.

=  

= However, after the draft has been brought to IET= F LC as AD supported draft, there were diverse people supporting strongly and proposed to publish the document in NETCONF WG.

=  

= Just to be sure we develop the right documents i= n Netconf WG, we would like to ask the same question again.

= Based on the support on Netconf maillist draft-m= m-netconf-time-capability may be adopted as a new WG item.

=  

=  

= - If anybody thinks draft-mm-netconf-time-capabi= lity does fit the focus of Netconf WG and should be developed as Netconf WG item please state your opinion on the maillist within one we= ek (July 15, 2015 EOB PT).<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">

=  

= - If anybody thinks that this is not the right a= pproach to develop in Netconf WG please state it as well.

=  

= - We also would like to know whether anybody did= or is planning to implement draft-mm-netconf-time-capability.

=  

= Best Regards,
Mehmet Ersue

= Netconf WG Co-chair

 = ;

 = ;

--_000_E4DE949E6CE3E34993A2FF8AE79131F819723E2BDEMUMBX005nsnin_-- From nobody Wed Jul 8 11:43:16 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78B31A7020 for ; Wed, 8 Jul 2015 11:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 LQKteAna0Xzb for ; Wed, 8 Jul 2015 11:43:12 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 196A71A700D for ; Wed, 8 Jul 2015 11:43:12 -0700 (PDT) Received: by laar3 with SMTP id r3so231865815laa.0 for ; Wed, 08 Jul 2015 11:43:10 -0700 (PDT) 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=lJ1Wr8w0zhLxVSPn8eyeVtNjnyKLlX4/aBtyj7svuTA=; b=GdxFUlZkbyPf4fun1NUja1AhpOfKmF87CGNNQG45wLZlC5TXoQwvL967WXfjAzJ4/2 sM8y1fW6cr19pTdl7aF7CxvmiZYKcZGstprnX3MtyCIjFb0/iaI7V4EDR98VAisAbTCO 9Hfx6gT0lBYXwVWT8J7Xe8ixE1vBneRLRBDdKDtU1kDAvPoLaXJkmK6dNKAxn/Gudksx BGnUgxtYxO1CxkaN7J239PPh7nhBWd0biPZ+frBrQaOCF06RPxWRM6QEz7d9uIpzOjHQ R+7JaIMFrU7RuNM2NtkRO27cQO3zGloCIgnj4y3QRC5Xr9bLRhbm0rSe8OzwjSFNUpp2 CPkQ== X-Gm-Message-State: ALoCoQl6g8BIfQ5r4O6dRxps/rXGkocAaGZDvQerO9tmAtmc9gfRYtRHc8yJjqyi/ieoGPA/8VCM MIME-Version: 1.0 X-Received: by 10.112.41.171 with SMTP id g11mr10922172lbl.123.1436380990268; Wed, 08 Jul 2015 11:43:10 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 8 Jul 2015 11:43:10 -0700 (PDT) In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30@AZ-FFEXMB04.global.avaya.com> Date: Wed, 8 Jul 2015 11:43:10 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=001a11346d9cb00354051a61820d Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 18:43:14 -0000 --001a11346d9cb00354051a61820d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I don't support this draft because it is a general computing platform feature, and NETCONF is a configuration management protocol. The draft does not provide any way to examine or edit pending RPC calls. Andy On Wed, Jul 8, 2015 at 9:55 AM, Ersue, Mehmet (Nokia - DE/Munich) < mehmet.ersue@nokia.com> wrote: > Thanks Dan! > > > > Others please comment no later than July 15th indicating your support or > non-support. > > > > Cheers, > Mehmet > > > > *From:* ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > *Sent:* Wednesday, July 08, 2015 10:54 AM > *To:* Ersue, Mehmet (Nokia - DE/Munich); netconf@ietf.org > *Subject:* RE: [Netconf] Opinion poll for the support of > draft-mm-netconf-time-capability > > > > Hi, > > > > I was one of the individuals who commented at the IETF LC that this work > seems to be useful and seems to be within the scope of the Netconf WG. > There were discussions whether the solution proposed in > draft-mm-netconf-time-capability is =E2=80=98the right approach=E2=80=99,= and also > questions about extending this solution to Restconf. > > > > Regards, > > > > Dan > > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org > ] *On Behalf Of *Ersue, Mehmet (Nokia - > DE/Munich) > *Sent:* Wednesday, July 08, 2015 1:05 AM > *To:* netconf@ietf.org > *Subject:* [Netconf] Opinion poll for the support of > draft-mm-netconf-time-capability > > > > Dear NETCONF WG, > > > > draft-mm-netconf-time-capability has been discussed in Netconf WG in > different IETF meetings. There was only cautious support. > > As recently the authors asked for support on the maillist no single perso= n > spoke for this draft. > > > > However, after the draft has been brought to IETF LC as AD supported > draft, there were diverse people supporting strongly and proposed to > publish the document in NETCONF WG. > > > > Just to be sure we develop the right documents in Netconf WG, we would > like to ask the same question again. > > Based on the support on Netconf maillist draft-mm-netconf-time-capability > may be adopted as a new WG item. > > > > > > - If anybody thinks draft-mm-netconf-time-capability does fit the focus o= f > Netconf WG and should be developed as Netconf WG item please state your > opinion on the maillist within one week (July 15, 2015 EOB PT). > > > > - If anybody thinks that this is not the right approach to develop in > Netconf WG please state it as well. > > > > - We also would like to know whether anybody did or is planning to > implement draft-mm-netconf-time-capability. > > > > Best Regards, > Mehmet Ersue > > Netconf WG Co-chair > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11346d9cb00354051a61820d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I don't support this draft beca= use it is a general computing platform feature,
and NETCONF is a = configuration management protocol.
The draft does not provide any= way to examine or edit pending RPC calls.

Andy




On Wed, Jul 8, 2= 015 at 9:55 AM, Ersue, Mehmet (Nokia - DE/Munich) <mehmet.ersue@nokia= .com> wrote:

= Thanks Dan!

= =C2=A0

= Others please comment no later than July 15= th indicating your support or non-support.

= =C2=A0

= Cheers,
Mehmet

= =C2=A0

From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Wednesday, July 08, 20= 15 10:54 AM
To: Ersue, Mehmet (Nokia - D= E/Munich); netconf@ie= tf.org
Subject: RE: [Netconf] Opini= on poll for the support of draft-mm-netconf-time-capability

=C2=A0

= Hi,

= =C2=A0

= I was one of the individuals who commented at th= e IETF LC that this work seems to be useful and seems to be within the scope of the Netconf WG. There were discussions whether the solution p= roposed in draft-mm-netconf-time-capability is =E2=80=98the right approach= =E2=80=99, and also questions about extending this solution to Restconf.

= =C2=A0

= Regards,

= =C2=A0

= Dan

= =C2=A0

= =C2=A0

From: Netconf [mai= lto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (= Nokia - DE/Munich)
Sent: Wednesday, July 08, 20= 15 1:05 AM
To: netconf@ietf.org
Subject: [Netconf] Opinion p= oll for the support of draft-mm-netconf-time-capability

=C2=A0

= Dear NETCONF WG,

=C2=A0

= draft-mm-netconf-time-capability has been discus= sed in Netconf WG in different IETF meetings. There was only cautious support. <= /u>

= As recently the authors asked for support on the= maillist no single person spoke for this draft.

= =C2=A0

= However, after the draft has been brought to IET= F LC as AD supported draft, there were diverse people supporting strongly and proposed to publish the document in NETCONF WG.

= =C2=A0

= Just to be sure we develop the right documents i= n Netconf WG, we would like to ask the same question again.

= Based on the support on Netconf maillist draft-m= m-netconf-time-capability may be adopted as a new WG item.

= =C2=A0

= =C2=A0

= - If anybody thinks draft-mm-netconf-time-capabi= lity does fit the focus of Netconf WG and should be developed as Netconf WG item please state your opinion on the maillist within one we= ek (July 15, 2015 EOB PT).<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">

= =C2=A0

= - If anybody thinks that this is not the right a= pproach to develop in Netconf WG please state it as well.

= =C2=A0

= - We also would like to know whether anybody did= or is planning to implement draft-mm-netconf-time-capability.

= =C2=A0

= Best Regards,
Mehmet Ersue

= Netconf WG Co-chair

=C2= =A0

=C2= =A0


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


--001a11346d9cb00354051a61820d-- From nobody Wed Jul 8 12:00:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3AC1A854D for ; Wed, 8 Jul 2015 12:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JmDaGpFmu0zI for ; Wed, 8 Jul 2015 12:00:04 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 86F721A1A4C for ; Wed, 8 Jul 2015 12:00:02 -0700 (PDT) Received: by lbnk3 with SMTP id k3so61947151lbn.1 for ; Wed, 08 Jul 2015 12:00:01 -0700 (PDT) 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=eUksnl3O0LMlihCXoUcQvxCxmgZHOFdSSpHiaqVxci4=; b=OWK8ocEGNKRBqsiDZReQ5mZ6GZyD//JcHB5GXth1gxh7PZSE/jO9f4rWSVpn2+C2HX KWxeWTEarljPtWoaRFuKSC/dhqDL1EeuKEYLYpW3Mr0VA4HTe+7Jazudb7Xnw6szZVyI pYhnj93kc8VH10oOeMDmok/FZF9COd2VwGde4dc7OVEPJToRIc9i+fMiLIIvZGaAJwjC a+P9VCVMxxcK8zjEO1kTAJrxzG2JGidRCfeqm31VTzy6f+eFuW2+gUcFVGnTtzoaLtm2 HvhfqwIBqIfAI1Aat4YO5ew6HJUp1gYq8FhoXS/Tcgznikt6ZY2Fk6xR3hxZMesWTB0q YVkQ== X-Gm-Message-State: ALoCoQmWrYqg/Jac/OyB+YP1WxCT0co1/vmIVXi2G6D2kdcHgdEuywO8nchXQh+SUpoOChrZLVLr MIME-Version: 1.0 X-Received: by 10.112.186.35 with SMTP id fh3mr10913906lbc.82.1436382001249; Wed, 08 Jul 2015 12:00:01 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 8 Jul 2015 12:00:01 -0700 (PDT) In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30@AZ-FFEXMB04.global.avaya.com> Date: Wed, 8 Jul 2015 12:00:01 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=001a1134dcc8f25fa0051a61be7d Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:00:06 -0000 --001a1134dcc8f25fa0051a61be7d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The draft does not say what happens if the session that requests the scheduled RFC is dropped. Are the scheduled tasks dropped? If not, how does the server send the "real" reply? Clients are designed so that a request is completed when the response with the proper message-id is received. >>> sent immediately .... >>> sent 5 days from now This breaks the NETCONF design which expects that only one is sent for each request. Andy On Wed, Jul 8, 2015 at 9:55 AM, Ersue, Mehmet (Nokia - DE/Munich) < mehmet.ersue@nokia.com> wrote: > Thanks Dan! > > > > Others please comment no later than July 15th indicating your support or > non-support. > > > > Cheers, > Mehmet > > > > *From:* ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > *Sent:* Wednesday, July 08, 2015 10:54 AM > *To:* Ersue, Mehmet (Nokia - DE/Munich); netconf@ietf.org > *Subject:* RE: [Netconf] Opinion poll for the support of > draft-mm-netconf-time-capability > > > > Hi, > > > > I was one of the individuals who commented at the IETF LC that this work > seems to be useful and seems to be within the scope of the Netconf WG. > There were discussions whether the solution proposed in > draft-mm-netconf-time-capability is =E2=80=98the right approach=E2=80=99,= and also > questions about extending this solution to Restconf. > > > > Regards, > > > > Dan > > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org > ] *On Behalf Of *Ersue, Mehmet (Nokia - > DE/Munich) > *Sent:* Wednesday, July 08, 2015 1:05 AM > *To:* netconf@ietf.org > *Subject:* [Netconf] Opinion poll for the support of > draft-mm-netconf-time-capability > > > > Dear NETCONF WG, > > > > draft-mm-netconf-time-capability has been discussed in Netconf WG in > different IETF meetings. There was only cautious support. > > As recently the authors asked for support on the maillist no single perso= n > spoke for this draft. > > > > However, after the draft has been brought to IETF LC as AD supported > draft, there were diverse people supporting strongly and proposed to > publish the document in NETCONF WG. > > > > Just to be sure we develop the right documents in Netconf WG, we would > like to ask the same question again. > > Based on the support on Netconf maillist draft-mm-netconf-time-capability > may be adopted as a new WG item. > > > > > > - If anybody thinks draft-mm-netconf-time-capability does fit the focus o= f > Netconf WG and should be developed as Netconf WG item please state your > opinion on the maillist within one week (July 15, 2015 EOB PT). > > > > - If anybody thinks that this is not the right approach to develop in > Netconf WG please state it as well. > > > > - We also would like to know whether anybody did or is planning to > implement draft-mm-netconf-time-capability. > > > > Best Regards, > Mehmet Ersue > > Netconf WG Co-chair > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a1134dcc8f25fa0051a61be7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The draft does not say what happens= if the session that requests the
scheduled RFC is dropped.=C2=A0= Are the scheduled tasks dropped?
If not, how does the server sen= d the "real" reply?

Clients are designed= so that a request is completed when the
response with the proper= message-id is received.

=C2=A0 =C2=A0<rpc mess= age-id=3D"1">
=C2=A0 =C2=A0 =C2=A0 <get =C2=A0sch= edule=3D5-days-from-now />
=C2=A0 =C2=A0</rpc>

=C2=A0 =C2=A0<rpc-reply message-id=3D"1">&l= t;ok/><rpc-reply> =C2=A0 >>> sent immediately
<= br>
=C2=A0 <rpc-reply message-id=3D"1">
=C2=A0 =C2=A0 <data> .... </data>
=C2=A0 <rpc-rep= ly> =C2=A0 >>> sent 5 days from now

This breaks the NETCONF design which expects that only
one <= rpc-reply> is sent for each <rpc> request.


Andy


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


On Wed, Jul 8, 2015 at 9:55 AM, Ersue, Mehmet (Nokia - DE/= Munich) <mehmet.ersue@nokia.com> wrote:

= Thanks Dan!

= =C2=A0

= Others please comment no later than July 15= th indicating your support or non-support.

= =C2=A0

= Cheers,
Mehmet

= =C2=A0

From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Wednesday, July 08, 20= 15 10:54 AM
To: Ersue, Mehmet (Nokia - D= E/Munich); netconf@ie= tf.org
Subject: RE: [Netconf] Opini= on poll for the support of draft-mm-netconf-time-capability

=C2=A0

= Hi,

= =C2=A0

= I was one of the individuals who commented at th= e IETF LC that this work seems to be useful and seems to be within the scope of the Netconf WG. There were discussions whether the solution p= roposed in draft-mm-netconf-time-capability is =E2=80=98the right approach= =E2=80=99, and also questions about extending this solution to Restconf.

= =C2=A0

= Regards,

= =C2=A0

= Dan

= =C2=A0

= =C2=A0

From: Netconf [mai= lto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (= Nokia - DE/Munich)
Sent: Wednesday, July 08, 20= 15 1:05 AM
To: netconf@ietf.org
Subject: [Netconf] Opinion p= oll for the support of draft-mm-netconf-time-capability

=C2=A0

= Dear NETCONF WG,

=C2=A0

= draft-mm-netconf-time-capability has been discus= sed in Netconf WG in different IETF meetings. There was only cautious support. <= /u>

= As recently the authors asked for support on the= maillist no single person spoke for this draft.

= =C2=A0

= However, after the draft has been brought to IET= F LC as AD supported draft, there were diverse people supporting strongly and proposed to publish the document in NETCONF WG.

= =C2=A0

= Just to be sure we develop the right documents i= n Netconf WG, we would like to ask the same question again.

= Based on the support on Netconf maillist draft-m= m-netconf-time-capability may be adopted as a new WG item.

= =C2=A0

= =C2=A0

= - If anybody thinks draft-mm-netconf-time-capabi= lity does fit the focus of Netconf WG and should be developed as Netconf WG item please state your opinion on the maillist within one we= ek (July 15, 2015 EOB PT).<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">

= =C2=A0

= - If anybody thinks that this is not the right a= pproach to develop in Netconf WG please state it as well.

= =C2=A0

= - We also would like to know whether anybody did= or is planning to implement draft-mm-netconf-time-capability.

= =C2=A0

= Best Regards,
Mehmet Ersue

= Netconf WG Co-chair

=C2= =A0

=C2= =A0


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


--001a1134dcc8f25fa0051a61be7d-- From nobody Wed Jul 8 12:45:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6491A3BA2 for ; Wed, 8 Jul 2015 12:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 gNwDCj0bNtcw for ; Wed, 8 Jul 2015 12:45:43 -0700 (PDT) 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 DB7E81A21B2 for ; Wed, 8 Jul 2015 12:45:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D783913C5; Wed, 8 Jul 2015 21:45:38 +0200 (CEST) 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 xFO4z-lPCr_T; Wed, 8 Jul 2015 21:45:38 +0200 (CEST) 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, 8 Jul 2015 21:45:37 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7247E20035; Wed, 8 Jul 2015 21:45:40 +0200 (CEST) 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 88cNdGMvLRTO; Wed, 8 Jul 2015 21:46:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C072B20031; Wed, 8 Jul 2015 21:45:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A751A353C7C4; Wed, 8 Jul 2015 21:45:37 +0200 (CEST) Date: Wed, 8 Jul 2015 21:45:37 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (Nokia - DE/Munich)" Message-ID: <20150708194537.GA1826@elstar.local> Mail-Followup-To: "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@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: "netconf@ietf.org" Subject: Re: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:45:44 -0000 On Tue, Jul 07, 2015 at 10:05:02PM +0000, Ersue, Mehmet (Nokia - DE/Munich) wrote: > > Just to be sure we develop the right documents in Netconf WG, we would like to ask the same question again. > Based on the support on Netconf maillist draft-mm-netconf-time-capability may be adopted as a new WG item. > > > - If anybody thinks draft-mm-netconf-time-capability does fit the focus of Netconf WG and should be developed as Netconf WG item please state your opinion on the maillist within one week (July 15, 2015 EOB PT). > > - If anybody thinks that this is not the right approach to develop in Netconf WG please state it as well. > > - We also would like to know whether anybody did or is planning to implement draft-mm-netconf-time-capability. I think the key questions are: a) Is the problem a real-world problem operators using NETCONF are facing? Is there any operational evidence that the current features NETCONF has to run network wide transactions are not sufficient? b) If a) is confirmed, does the solution proposed in the I-D provide a good starting point for a standardized solution? c) If a) and b), do we have a sufficient number of people to work on this? If perhaps not, what is the priority of addressing this given all the other things the active contributors have on their plate? I personally can't answer a). Concerning b), I do have some technical concerns (but then such an I-D is a starting point). My main concern is actually c). Our resources are finite and taking on work that than takes >3 years to finish is not helpful. /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 Jul 8 13:33:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DD61A879A for ; Wed, 8 Jul 2015 13:33:21 -0700 (PDT) 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 kjjY5T3paPYf for ; Wed, 8 Jul 2015 13:33:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 274091A8798 for ; Wed, 8 Jul 2015 13:33:20 -0700 (PDT) Received: from localhost (unknown [173.38.220.50]) by mail.tail-f.com (Postfix) with ESMTPSA id 0C02F1AE019A; Wed, 8 Jul 2015 22:33:17 +0200 (CEST) Date: Wed, 08 Jul 2015 22:33:17 +0200 (CEST) Message-Id: <20150708.223317.589678321380709464.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150708194537.GA1826@elstar.local> References: <20150708194537.GA1826@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: netconf@ietf.org Subject: Re: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 20:33:21 -0000 Hi, Juergen Schoenwaelder wrote: > On Tue, Jul 07, 2015 at 10:05:02PM +0000, Ersue, Mehmet (Nokia - DE/Munich) wrote: > > > > Just to be sure we develop the right documents in Netconf WG, we would like to ask the same question again. > > Based on the support on Netconf maillist draft-mm-netconf-time-capability may be adopted as a new WG item. > > > > > > - If anybody thinks draft-mm-netconf-time-capability does fit the focus of Netconf WG and should be developed as Netconf WG item please state your opinion on the maillist within one week (July 15, 2015 EOB PT). > > > > - If anybody thinks that this is not the right approach to develop in Netconf WG please state it as well. > > > > - We also would like to know whether anybody did or is planning to implement draft-mm-netconf-time-capability. > > I think the key questions are: This is a good summary of the issues. > a) Is the problem a real-world problem operators using NETCONF are > facing? Is there any operational evidence that the current features > NETCONF has to run network wide transactions are not sufficient? I don't know the answer to this one. I do know that the current NETCONF mechanisms are sufficient for the deployments we have done. > b) If a) is confirmed, does the solution proposed in the I-D provide a > good starting point for a standardized solution? I have some concerns. The proposed solution is fragile b/c it relies on augmenting every rpc with additional parameters, instead of trying to find a generic mechanism. > c) If a) and b), do we have a sufficient number of people to work on > this? If perhaps not, what is the priority of addressing this given > all the other things the active contributors have on their plate? > > I personally can't answer a). Concerning b), I do have some technical > concerns (but then such an I-D is a starting point). My main concern > is actually c). Our resources are finite and taking on work that than > takes >3 years to finish is not helpful. /martin From nobody Wed Jul 8 16:13:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D121A1A75 for ; Wed, 8 Jul 2015 16:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 5bDj1M6udw4N for ; Wed, 8 Jul 2015 16:13:08 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 0D4F31A1A5A for ; Wed, 8 Jul 2015 16:13:07 -0700 (PDT) Received: by laar3 with SMTP id r3so235722958laa.0 for ; Wed, 08 Jul 2015 16:13:06 -0700 (PDT) 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=CyuAydM0BtzJnkB9lHggWmAET6N0ekgzQx6tYcbeBGQ=; b=lDWRjUHRQ38ECCMzUu7GF4paroR4TSk1JFOAucMR3/rx+nQbo7ZM2eF1F0ANxOE+Pn /3U4zD1KPGymKPdcLHdFz5VkzYPLMRUjAuvAHf5EW4gatKlzkOTl+esf/zWVKYrccuYs HOKnLN61rgB9thBInh46xwxslEUgheKuA2yK2tCazg52qLVn8cizK+Q1KVToaUHig8bx eYovX/vi6CoY5xkec3/yQAAnW9WwhWsuiNE1+oW980XgL8wpjtXxKU83gc0mqH4fj5pK xMJ1Ib7Wso/a8+CesgZhLggHCBWCwlybqrrZQi4DBm/kdWwex6h8+OoBonU2KuQuUbHl Rkhg== X-Gm-Message-State: ALoCoQlerkktmwC7GXUYwcMrtgvY1uDbsI3/kbU7JNeGEOUUtJk2wCAmqf4Y2hZ7rdZLh3wfZ3Aq MIME-Version: 1.0 X-Received: by 10.112.124.71 with SMTP id mg7mr11807645lbb.38.1436397186268; Wed, 08 Jul 2015 16:13:06 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 8 Jul 2015 16:13:05 -0700 (PDT) In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30@AZ-FFEXMB04.global.avaya.com> Date: Wed, 8 Jul 2015 16:13:05 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=047d7bfd0d860b594e051a654891 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:13:10 -0000 --047d7bfd0d860b594e051a654891 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 8, 2015 at 12:00 PM, Andy Bierman wrote: > Hi, > > The draft does not say what happens if the session that requests the > scheduled RFC is dropped. Are the scheduled tasks dropped? > If not, how does the server send the "real" reply? > > Clients are designed so that a request is completed when the > response with the proper message-id is received. > > > > > > >>> sent immediately > > > .... > >>> sent 5 days from now > > This breaks the NETCONF design which expects that only > one is sent for each request. > > I misread the latest version. The original will not have an immediate response. Instead a notification is sent indicating the RPC was scheduled. Only 1 rpc-reply is sent at the end. > > Andy > > Andy > > > > > On Wed, Jul 8, 2015 at 9:55 AM, Ersue, Mehmet (Nokia - DE/Munich) < > mehmet.ersue@nokia.com> wrote: > >> Thanks Dan! >> >> >> >> Others please comment no later than July 15th indicating your support or >> non-support. >> >> >> >> Cheers, >> Mehmet >> >> >> >> *From:* ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >> *Sent:* Wednesday, July 08, 2015 10:54 AM >> *To:* Ersue, Mehmet (Nokia - DE/Munich); netconf@ietf.org >> *Subject:* RE: [Netconf] Opinion poll for the support of >> draft-mm-netconf-time-capability >> >> >> >> Hi, >> >> >> >> I was one of the individuals who commented at the IETF LC that this work >> seems to be useful and seems to be within the scope of the Netconf WG. >> There were discussions whether the solution proposed in >> draft-mm-netconf-time-capability is =E2=80=98the right approach=E2=80=99= , and also >> questions about extending this solution to Restconf. >> >> >> >> Regards, >> >> >> >> Dan >> >> >> >> >> >> *From:* Netconf [mailto:netconf-bounces@ietf.org >> ] *On Behalf Of *Ersue, Mehmet (Nokia - >> DE/Munich) >> *Sent:* Wednesday, July 08, 2015 1:05 AM >> *To:* netconf@ietf.org >> *Subject:* [Netconf] Opinion poll for the support of >> draft-mm-netconf-time-capability >> >> >> >> Dear NETCONF WG, >> >> >> >> draft-mm-netconf-time-capability has been discussed in Netconf WG in >> different IETF meetings. There was only cautious support. >> >> As recently the authors asked for support on the maillist no single >> person spoke for this draft. >> >> >> >> However, after the draft has been brought to IETF LC as AD supported >> draft, there were diverse people supporting strongly and proposed to >> publish the document in NETCONF WG. >> >> >> >> Just to be sure we develop the right documents in Netconf WG, we would >> like to ask the same question again. >> >> Based on the support on Netconf maillist draft-mm-netconf-time-capabilit= y >> may be adopted as a new WG item. >> >> >> >> >> >> - If anybody thinks draft-mm-netconf-time-capability does fit the focus >> of Netconf WG and should be developed as Netconf WG item please state yo= ur >> opinion on the maillist within one week (July 15, 2015 EOB PT). >> >> >> >> - If anybody thinks that this is not the right approach to develop in >> Netconf WG please state it as well. >> >> >> >> - We also would like to know whether anybody did or is planning to >> implement draft-mm-netconf-time-capability. >> >> >> >> Best Regards, >> Mehmet Ersue >> >> Netconf WG Co-chair >> >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > --047d7bfd0d860b594e051a654891 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 8, 2015 at 12:00 PM, Andy Bierman <andy@yumaworks.com= > wrote:
Hi,
The draft does not say what happens if the session that r= equests the
scheduled RFC is dropped.=C2=A0 Are the scheduled tas= ks dropped?
If not, how does the server send the "real"= reply?

Clients are designed so that a request is = completed when the
response with the proper message-id is receive= d.

=C2=A0 =C2=A0<rpc message-id=3D"1"= >
=C2=A0 =C2=A0 =C2=A0 <get =C2=A0schedule=3D5-days-from-no= w />
=C2=A0 =C2=A0</rpc>

=C2=A0= =C2=A0<rpc-reply message-id=3D"1"><ok/><rpc-reply= > =C2=A0 >>> sent immediately

=C2=A0 &= lt;rpc-reply message-id=3D"1">
=C2=A0 =C2=A0 <dat= a> .... </data>
=C2=A0 <rpc-reply> =C2=A0 >>= > sent 5 days from now

This breaks the NETC= ONF design which expects that only
one <rpc-reply> is sent = for each <rpc> request.

<= br>
I misread the latest version.
The original <get&= gt; will not have an immediate response.
Instead a notification i= s sent indicating the RPC was scheduled.
Only 1 rpc-reply is sent= at the end.

=C2=A0

Andy


Andy
=C2=A0

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

On Wed, Jul 8, 2015 at 9:55 AM, Ersue, Mehmet = (Nokia - DE/Munich) <mehmet.ersue@nokia.com> wrote:
=

= Thanks Dan!

= =C2=A0

= Others please comment no later than July 15= th indicating your support or non-support.

= =C2=A0

= Cheers,
Mehmet

= =C2=A0

From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Wednesday, July 08, 20= 15 10:54 AM
To: Ersue, Mehmet (Nokia - D= E/Munich); netconf@ie= tf.org
Subject: RE: [Netconf] Opini= on poll for the support of draft-mm-netconf-time-capability

=C2=A0

= Hi,

= =C2=A0

= I was one of the individuals who commented at th= e IETF LC that this work seems to be useful and seems to be within the scope of the Netconf WG. There were discussions whether the solution p= roposed in draft-mm-netconf-time-capability is =E2=80=98the right approach= =E2=80=99, and also questions about extending this solution to Restconf.

= =C2=A0

= Regards,

= =C2=A0

= Dan

= =C2=A0

= =C2=A0

From: Netconf [mai= lto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (= Nokia - DE/Munich)
Sent: Wednesday, July 08, 20= 15 1:05 AM
To: netconf@ietf.org
Subject: [Netconf] Opinion p= oll for the support of draft-mm-netconf-time-capability

=C2=A0

= Dear NETCONF WG,

=C2=A0

= draft-mm-netconf-time-capability has been discus= sed in Netconf WG in different IETF meetings. There was only cautious support. <= /u>

= As recently the authors asked for support on the= maillist no single person spoke for this draft.

= =C2=A0

= However, after the draft has been brought to IET= F LC as AD supported draft, there were diverse people supporting strongly and proposed to publish the document in NETCONF WG.

= =C2=A0

= Just to be sure we develop the right documents i= n Netconf WG, we would like to ask the same question again.

= Based on the support on Netconf maillist draft-m= m-netconf-time-capability may be adopted as a new WG item.

= =C2=A0

= =C2=A0

= - If anybody thinks draft-mm-netconf-time-capabi= lity does fit the focus of Netconf WG and should be developed as Netconf WG item please state your opinion on the maillist within one we= ek (July 15, 2015 EOB PT).<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">

= =C2=A0

= - If anybody thinks that this is not the right a= pproach to develop in Netconf WG please state it as well.

= =C2=A0

= - We also would like to know whether anybody did= or is planning to implement draft-mm-netconf-time-capability.

= =C2=A0

= Best Regards,
Mehmet Ersue

= Netconf WG Co-chair

=C2= =A0

=C2= =A0


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



--047d7bfd0d860b594e051a654891-- From nobody Thu Jul 9 13:59:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7B11A0203 for ; Thu, 9 Jul 2015 13:59:56 -0700 (PDT) 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 FDNSLQOuW9oO for ; Thu, 9 Jul 2015 13:59:54 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCC61A01F2 for ; Thu, 9 Jul 2015 13:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5310; q=dns/txt; s=iport; t=1436475594; x=1437685194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ad5I4CjCrRQwmryFQf9vUDOcb+WuCVvt4naTe5yh4/Y=; b=S1kXuqUEoK5que5tjPLhZ34CV931AXTiEvL4BO/GFi3nRBCadZuO1w3e +IiEyZjd/nY5GpT0jLYHcm3s/AJyIcW4Sa+eMAdyQUPm8BSC+2ERhV8bM 0b1HLQy/P56Ln8b6CxHaikha703bVaKpkBt54XTMc+pPy5UNycvcDp38A k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DRAwD5355V/4QNJK1bgxJUYAaDGrgHCYFzhXUCHIFFOBQBAQEBAQEBgQqEIwEBAQQjEUUMBAIBCBEEAQEDAgYDGgMCAgIwFAEICAEBBA4FCIgmDbkhljYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKKoQtAQ0aMQcGgmIvgRQFjCqIAwGEZocagTxFg1OLBogMJoIMHIFTbwGBAwEfAyCBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,442,1432598400"; d="scan'208";a="8466094" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 09 Jul 2015 20:59:53 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t69KxrDh020531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 Jul 2015 20:59:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.208]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 15:59:53 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: New version for draft-clemm-netconf-yang-push-01.txt Thread-Index: AdC5FyP9Rm6uBgErR8+WZ2t4USQNKABbyl6Q Date: Thu, 9 Jul 2015 20:59:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.118.56.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 20:59:56 -0000 QWRkaW5nIHRvIHdoYXQgQWxleCBzYWlkLCBoZXJlIGFyZSBhIGZldyBxdWVzdGlvbnMgbGVmdCB1 bmRlZmluZWQgaW4gdGhlIGxhdGVzdCBkcmFmdCB3aGljaCBhcmUgd29ydGggZXhwbG9yaW5nIGVp dGhlciBvbiB0aGUgTkVUQ09ORiBtYWlsZXIgb3IgaW4gUHJhZ3VlLi4uDQoNCigxKSBTaG91bGQg dGhpcyBkcmFmdCBzdXBwb3J0IHRoZSBhYmlsaXR5IHRvIHN1c3BlbmQgLyByZXN1bWUgYSBTdWJz Y3JpcHRpb24gYXQgdGhlIHJlcXVlc3Qgb2YgdGhlIFN1YnNjcmliZXI/DQoNCigyKSBTaG91bGQg dGhlIGxvc3Mgb2YgYXV0aGVudGljYXRlZCBhY2Nlc3MgdG8gWUFORyBzdWJ0cmVlIGJlIGNvbW11 bmljYXRlZCB0byB0aGUgU3Vic2NyaWJlcj8NCg0KKDMpIEFyZSB0aGVyZSBmaWx0ZXJzIHdoaWNo IHNob3VsZCBiZSBwcm92aWRlZCBiZXlvbmQgUkZDIDUyNzcgU3VidHJlZSBhbmQgUHJvcGVydHkg RmlsdGVycz8NCg0KVGhvdWdodHMgb24gdGhlc2UsIG9yIG90aGVyIHN1Z2dlc3Rpb25zL3F1ZXN0 aW9ucyBvbiB0aGUgZHJhZnQgYXJlIGFwcHJlY2lhdGVkLg0KDQotIEVyaWMgKGFsc28gb24gYmVo YWxmIG9mIEFsZXggYW5kIEFsYmVydG8pDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIA0KU2VudDogVHVlc2RheSwgSnVseSAwNywgMjAx NSA4OjQ2IFBNDQpUbzogbmV0Y29uZkBpZXRmLm9yZw0KQ2M6IEVyaWMgVm9pdCAoZXZvaXQpOyBB bGJlcnRvIEdvbnphbGV6IFByaWV0byAoYWxiZXJ0Z28pDQpTdWJqZWN0OiBOZXcgdmVyc2lvbiBm b3IgZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5nLXB1c2gtMDEudHh0DQoNCkhpLA0KDQp3ZSBqdXN0 IHdhbnRlZCB0byBsZXQgeW91IGtub3cgdGhhdCB3ZSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0 aGUgWUFORyBkYXRhc3RvcmUgcHVzaCBkcmFmdCB5ZXN0ZXJkYXksIHdoaWNoIHdlIGFyZSBwbGFu bmluZyB0byBwcmVzZW50IGluIFByYWd1ZS4gIA0KDQpQbGVhc2Ugc2VlIGh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jbGVtbS1uZXRjb25mLXlhbmctcHVzaC0wMS50 eHQgDQoNClRoZXJlIGFyZSBhIGEgZmV3IHRlY2huaWNhbCB1cGRhdGVzLCBhcyB3ZWxsIGFzIHF1 aXRlIGEgZmV3IGVkaXRvcmlhbCB1cGRhdGVzLiAgDQoNClRoZSB0ZWNobmljYWwgdXBkYXRlcyBp bmNsdWRlOg0KLSBBIHBhcmFtZXRlciB0aGF0IGFsbG93cyBhIHN1YnNjcmliZXIgdG8gc3BlY2lm eSB3aGljaCBlbmNvZGluZyB0byB1c2UgZm9yIGRhdGFzdG9yZSB1cGRhdGVzDQotIEEgcGFyYW1l dGVyIHRoYXQgYWxsb3dzIGEgc3Vic2NyaWJlciB0byBsaW1pdCBvbi1jaGFuZ2Ugc3Vic2NyaXB0 aW9ucyB0byBjZXJ0YWluIHR5cGVzIG9mIGNoYW5nZXMNCg0KVGhlcmUgYXJlIGEgZmV3IGl0ZW1z IHRoYXQgbWF5IHdhcnJhbnQgZGlzY3Vzc2lvbiwgbW9zdCBvZiB3aGljaCBjYW4gYmUgZm91bmQg aW4gc2VjdGlvbiAzLjEwLCBpbmNsdWRpbmc6DQotIEludHJvZHVjdGlvbiBvZiBhZGRpdGlvbmFs IGJ1aWx0LWluIGRhdGFzdHJlYW1zIGxpbWl0ZWQgdG8gb3BlcmF0aW9uYWwgZGF0YSAoc2VjdGlv biAzLjEwLjUpLCB3aGljaCB3ZSB0aGluayB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBmb3JtYWxs eSBpbmNsdWRlIGluIHRoZSBuZXh0IHJldmlzaW9uDQotIFdoZXRoZXIgdG8gc3VwcG9ydCBzdWJz Y3JpcHRpb24gcGVyc2lzdGVuY3kgKGN1cnJlbnRseSB0aGUgc3Vic2NyaXB0aW9uIGxpZmVjeWNs ZSBpcyB0aWVkIHRvIHRoZSBsaWZlY3ljbGUgb2YgYSBOZXRjb25mIHNlc3Npb24pDQotIFdoZXRo ZXIgdG8gcHJvdmlkZSBndWlkYW5jZSBvbiAiY2h1bmtpbmciIG9mIHVwZGF0ZXMgKGN1cnJlbnRs eSBsZWZ0IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiB3aGV0aGVyIHRvIHNlbmQgYSBzaW5nbGUgdXBk YXRlIG1lc3NhZ2Ugd2l0aCB0aGUgZW50aXJlIGRhdGEsIG9yIG11bHRpcGxlIHVwZGF0ZSBtZXNz YWdlcyBlYWNoIHdpdGggYSBzdWJzZXQgb2YgdGhlIGRhdGEpDQotIFdoZXRoZXIgdG8gdHJhY2sg dGhlICJvd25lcnMiIG9mIGEgc3Vic2NyaXB0aW9uIGFzIHBhcnQgb2YgdGhlIHN1YnNjcmlwdGlv biBkYXRhIG1vZGVsIChhZ2Fpbiwgd2UgYmVsaWV2ZSB0aGlzIGlzIGEgZ29vZCBpZGVhIHdoaWNo IHdlIHBsYW4gdG8gYWRkIGluIHRoZSBuZXh0IHJldmlzaW9uKSANCg0KUmVnYXJkcw0KLS0tIEFs ZXggKGFsc28gb24gYmVoYWxmIG9mIEVyaWMgYW5kIEFsYmVydG8pDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdWx5IDA2LCAyMDE1IDM6NTcg UE0NClRvOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBBbGJlcnRvIEdvbnphbGV6IFByaWV0byAo YWxiZXJ0Z28pOyBBbGJlcnRvIEdvbnphbGV6IFByaWV0byAoYWxiZXJ0Z28pOyBFcmljIFZvaXQg KGV2b2l0KTsgQWxleGFuZGVyIENsZW1tIChhbGV4KTsgRXJpYyBWb2l0IChldm9pdCkNClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5n LXB1c2gtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNsZW1tLW5ldGNv bmYteWFuZy1wdXNoLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBB bGV4YW5kZXIgQ2xlbW0gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OgkJZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5nLXB1c2gNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlT dWJzY3JpYmluZyB0byBZQU5HIGRhdGFzdG9yZSBwdXNoIHVwZGF0ZXMNCkRvY3VtZW50IGRhdGU6 CTIwMTUtMDctMDYNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTMyDQpV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNoLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNoLw0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jbGVtbS1u ZXRjb25mLXlhbmctcHVzaC0wMQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1jbGVtbS1uZXRjb25mLXlhbmctcHVzaC0wMQ0KDQpBYnN0cmFj dDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHN1YnNjcmlwdGlvbiBhbmQgcHVzaCBtZWNo YW5pc20gZm9yIFlBTkcNCiAgIGRhdGFzdG9yZXMuICBUaGlzIG1lY2hhbmlzbSBhbGxvd3MgY2xp ZW50IGFwcGxpY2F0aW9ucyB0byByZXF1ZXN0DQogICB1cGRhdGVzIGZyb20gYSBZQU5HIGRhdGFz dG9yZSwgd2hpY2ggYXJlIHRoZW4gcHVzaGVkIGJ5IHRoZSBzZXJ2ZXIgdG8NCiAgIHRoZSBjbGll bnQgcGVyIGEgc3Vic2NyaXB0aW9uIHBvbGljeSwgd2l0aG91dCByZXF1aXJpbmcgYWRkaXRpb25h bA0KICAgY2xpZW50IHJlcXVlc3RzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From nobody Thu Jul 9 14:09:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF311A0273 for ; Thu, 9 Jul 2015 14:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTIlE4id41a1 for ; Thu, 9 Jul 2015 14:09:03 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id CA5301A0218 for ; Thu, 9 Jul 2015 14:09:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VoRNQaTVkyB27X9DFJk7KPFP6fOxSxy3eubF7TQeLzAfnQN5ui6TNGF6MD0skWoS; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZDJ42-00052k-Jw for netconf@ietf.org; Thu, 09 Jul 2015 17:09:02 -0400 Received: from 76.254.53.21 by webmail.earthlink.net with HTTP; Thu, 9 Jul 2015 17:09:02 -0400 Message-ID: <16955559.1436476142511.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Thu, 9 Jul 2015 14:09:02 -0700 (GMT-07:00) From: Randy Presuhn To: "netconf@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba0cce87b1e0ad9556e5c063261c8c2359b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 Archived-At: Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 21:09:05 -0000 Hi - >From: "Eric Voit (evoit)" >Sent: Jul 9, 2015 1:59 PM >To: "netconf@ietf.org" >Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt ... >(2) Should the loss of authenticated access to YANG subtree be > communicated to the Subscriber? No. Randy From nobody Fri Jul 10 00:28:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FD01A8915 for ; Fri, 10 Jul 2015 00:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tMXYahVSyUC for ; Fri, 10 Jul 2015 00:28:35 -0700 (PDT) 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 A9EF41A8906 for ; Fri, 10 Jul 2015 00:28:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYP25602; Fri, 10 Jul 2015 07:28:32 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jul 2015 08:28:00 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.135]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 10 Jul 2015 15:27:56 +0800 From: "Liubing (Leo)" To: netconf Thread-Topic: Need Multi-Replies extention in Netconf?-//FW: New Version Notification for draft-liu-netconf-multiple-replies-01.txt Thread-Index: AQHQuuHwMIR1YssWZkyzc//CtRLhdw== Date: Fri, 10 Jul 2015 07:27:56 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C21E6F76@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Netconf] Need Multi-Replies extention in Netconf?-//FW: New Version Notification for draft-liu-netconf-multiple-replies-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 07:28:38 -0000 SGkgRGVhciBhbGwsDQoNCldlJ3ZlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgZHJhZnQtbGl1 LW5ldGNvbmYtbXVsdGlwbGUtcmVwbGllcy0wMS4gVGhpcyBkcmFmdCB3YXMgYnJpZWZseSBwcmVz ZW50ZWQgaW4gRGFsbGFzLg0KDQpFeGN1c2UgbXkgaXRlcmF0aW9uLCB0aGUgbWFpbiBpZGVhIG9m IHRoZSBkcmFmdCBpcyB0aGF0IGluIHNvbWUgc2NlbmFyaW9zLCBtdWx0aXBsZSByZXBsaWVzIGZv ciBhIHNpbmdsZSByZXF1ZXN0IG1pZ2h0IGJlIG5lZWRlZC4gVGhlc2Ugc2NlbmFyaW9zIGxpc3Rl ZCBpbiB0aGUgZHJhZnQgYXJlOg0KLSBCdWxrIHJlcGx5DQogIFRoZSByZXBseSBtZXNzYWdlIGlz IGh1Z2UsIG5lZWRzIG11bHRpcGxlIGZyYWdtZW50cw0KLSBQZXJzaXN0ZW50IHJlcGx5DQogIFNv bWUgb3BlcmF0aW9ucyBzdWNoIGFzIFBpbmdpbmcsIFRyYWNlcnQgbmVlZCBjb250aW51b3VzIHJl cGxpZXMgZm9yIHRoZSByZXF1ZXN0Lg0KLSBMb25nIHRpbWUgcmVwbHkNCiAgU29tZSBvcGVyYXRp b25zIG1pZ2h0IHRha2UgYSBsb25nIHRpbWUgdG8gcGVyZm9ybSwgbWlnaHQgbmVlZCByZXNwb25z ZXMgcmV0dXJucyBtb25pdG9yaW5nIHByb2dyZXNzIHRpbGwgdGhlIGZpbmFsIHJlc3VsdA0KLSBE YXRhc3RvcmUgcHVzaCB1cGRhdGVzIChuZXdseSBhZGRlZCBpbiB0aGUgMDEgdmVyc2lvbikNCiAg VGhpcyBpcyByZWdhcmRpbmcgdG8gdGhlIHRoZSBpMnJzIHJlcXVpcmVtZW50cyB1c2luZyBTdWJz Y3JpYmluZyB0byBkYXRhc3RvcmUgcHVzaCB1cGRhdGVzLCB3aGljaCB3aWxsIGJlIGRpc2N1c3Nl ZCBpbiB0aGUgdXBjb21pbmcgbWVldGluZy4NCiAgVGhlIGRhdGFzdG9yZSBwdXNoIHByb2JsZW0g aXMgYSBjb21wcmVoZW5zaXZlIGlzc3VlIHRoYXQgbmVlZHMgY29uc2lkZXJhdGlvbnMgaW4gQ29u dGVudCwgT3BlcmF0aW9ucyBhbmQgTWVzc2FnZXMgbGF5ZXIgaW4gTmV0Y29uZi4gDQogIEluIG91 ciBkcmFmdCwgd2Ugb25seSBjYXJlcyBhYm91dCB0aGUgTWVzc2FnZXMgbGF5ZXIuIGRyYWZ0LWNs ZW1tLW5ldGNvbmYteWFuZy1wdXNoLTAwIHByb3Bvc2VkIHRvIGV4dGVuZCB0aGUgTm90aWZpY2F0 aW9uIG1lc3NhZ2luZyB0byBmdWxmaWxsIHRoZSByZXF1aXJlbWVudHMuIFRoaXMgZHJhZnQgcHJv cG9zZXMgbXVsdGktcmVwbGllcyBtZXNzYWdpbmcgbWlnaHQgYWxzbyBjb3ZlciB0aGUgcmVxdWly ZW1lbnRzIChpdCBuZWVkcyBtb3JlIGRpc2N1c3Npb24gdGhvdWdoKS4gDQoNClNvLCB3aXRoIHRo ZXNlIHNjZW5hcmlvcywgZG8geW91IHRoaW5rIHRoZSBOZXRjb25mIG5lZWQgdG8gYmUgZXh0ZW5k ZWQgYXQgdGhlIE1lc3NhZ2VzIGxheWVyIHRvIHN1cHBvcnQgbXVsdGktcmVwbGllcz8NCihCdHcs IHRoaXMgZHJhZnQgYWxzbyBicmllZmx5IGRpc2N1c3NlcyB0d28gc29sdXRpb24gYWx0ZXJuYXRp dmVzLikNCg0KTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgY29tbWVudHMuIFRoYW5rIHlvdS4NCg0K QmVzdCByZWdhcmRzLA0KQmluZw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIA0KU2VudDogTW9uZGF5LCBKdWx5IDA2LCAyMDE1IDk6MzIgUE0NClRvOiBaaGVuZ2d1YW5n eWluZzsgTWFoZXNoIEpldGhhbmFuZGFuaTsgTGl1YmluZyAoTGVvKTsgS2VudCBXYXRzZW47IEtl bnQgV2F0c2VuOyBaaGVuZ2d1YW5neWluZzsgTWFoZXNoIEpldGhhbmFuZGFuaTsgTGl1YmluZyAo TGVvKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtbmV0 Y29uZi1tdWx0aXBsZS1yZXBsaWVzLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1saXUtbmV0Y29uZi1tdWx0aXBsZS1yZXBsaWVzLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5nIExpdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z aXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1saXUtbmV0Y29uZi1tdWx0aXBsZS1yZXBsaWVzDQpSZXZp c2lvbjoJMDENClRpdGxlOgkJUHJvY2Vzc2luZyBNdWx0aXBsZSBSZXBsaWVzIGZvciBPbmUgUmVx dWVzdCBpbiBORVRDT05GDQpEb2N1bWVudCBkYXRlOgkyMDE1LTA3LTA2DQpHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtbmV0Y29uZi1tdWx0aXBsZS1yZXBs aWVzLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWxpdS1uZXRjb25mLW11bHRpcGxlLXJlcGxpZXMvDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1uZXRjb25mLW11bHRpcGxlLXJl cGxpZXMtMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtbGl1LW5ldGNvbmYtbXVsdGlwbGUtcmVwbGllcy0wMQ0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHNldmVyYWwgc2NlbmFyaW9zIHRoYXQgbXVsdGlwbGUg cmVwbGllcyBmb3IgYQ0KICAgc2luZ2xlIHJlcXVlc3QgYXJlIG5lZWRlZCwgd2l0aCB0aGUgYWJp bGl0eSB0byB0ZXJtaW5hdGUgdGhlIHJlcGxpZXMNCiAgIGF0IGFueSB0aW1lLiAgU3VjaCBzY2Vu YXJpb3MgYXJlIG5vdCB3ZWxsIHN1cHBvcnRlZCBieSBjdXJyZW50DQogICBORVRDT05GIChOZXR3 b3JrIENvbmZpZ3VyYXRpb24pIHByb3RvY29sLiAgQW4gZXh0ZW50aW9uIGF0IHRoZQ0KICAgTkVU Q09ORiBtZXNzYWdpbmcgbGF5ZXIgaXMgbmVlZGVkIHRvIGZ1bGZpbGwgdGhlIHJlcXVpcmVtZW50 Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Jul 10 00:30:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81FC1A891B for ; Fri, 10 Jul 2015 00:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 WhZmc_jgazfp for ; Fri, 10 Jul 2015 00:30:25 -0700 (PDT) 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 B9B531A8915 for ; Fri, 10 Jul 2015 00:30:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 009F91084; Fri, 10 Jul 2015 09:30:20 +0200 (CEST) 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 pfGz0_2AY9UG; Fri, 10 Jul 2015 09:30:20 +0200 (CEST) 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, 10 Jul 2015 09:30:19 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D553120035; Fri, 10 Jul 2015 09:30:23 +0200 (CEST) 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 6d4Ok9PqUV89; Fri, 10 Jul 2015 09:30:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0754E20031; Fri, 10 Jul 2015 09:30:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 030DC353D06F; Fri, 10 Jul 2015 09:30:20 +0200 (CEST) Date: Fri, 10 Jul 2015 09:30:20 +0200 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Message-ID: <20150710073019.GA3709@elstar.local> Mail-Followup-To: "Eric Voit (evoit)" , "netconf@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: "netconf@ietf.org" Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 07:30:27 -0000 On Thu, Jul 09, 2015 at 08:59:52PM +0000, Eric Voit (evoit) wrote: > > (3) Are there filters which should be provided beyond RFC 5277 Subtree and Property Filters? > What is a 'Property Filter'? /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 Jul 10 07:06:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E971AD190 for ; Fri, 10 Jul 2015 07:06:04 -0700 (PDT) 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 09PrxRG-ZWeW for ; Fri, 10 Jul 2015 07:06:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9832E1AD186 for ; Fri, 10 Jul 2015 07:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=645; q=dns/txt; s=iport; t=1436537161; x=1437746761; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YHWjTOshcOhoe9dArce2pd2ppsoVX6LhWw1x4kEf8uQ=; b=eBNNrhTWN45ATISNt5hiegzK+VnATbaotW0tHgDD1c5eb9oUn3xwAG5+ ZHcumMaa/JxQqG6aXaWu4LKkVUfIGoffeW3epaS93Zxqqs+f+UGPmH1be xXcGxkpKfO+4KE5JRZucbkPL8elBZoEZmDPM3XFtbeULUAAaz/hn+dw+l E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BdAwD5z59V/5FdJa1bgxKBOrstCYdoAoFHOBQBAQEBAQEBgQqEIwEBAQMBOj8FCwIBCA4HAwoUEDIlAQEEDg0TiAsIz3oBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0uEVTEHgxeBFAEElDEBjASYaiaDe4I2gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,446,1432598400"; d="scan'208";a="14327042" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 10 Jul 2015 14:06:00 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6AE5xKd031823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jul 2015 14:05:59 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.208]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 10 Jul 2015 09:05:59 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Thread-Index: AdC5FyP9Rm6uBgErR8+WZ2t4USQNKABbyl6QACF4cAAAAkA7cA== Date: Fri, 10 Jul 2015 14:05:59 +0000 Message-ID: References: <20150710073019.GA3709@elstar.local> In-Reply-To: <20150710073019.GA3709@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.118.56.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 14:06:04 -0000 > From: Juergen Schoenwaelder, July 10, 2015 3:30 AM > >> On Thu, Jul 09, 2015 at 08:59:52PM +0000, Eric Voit (evoit) wrote: >>=20 >> (3) Are there filters which should be provided beyond RFC 5277 Subtree = and Property Filters? >> > > What is a 'Property Filter'? RFC 5277 XPATH Filters for attribute match expressions is what I believe is= achievable right now upon YANG objects. But other PubSub technologies li= ke DDS (OMG) and MQTT (OASIS) can pass PubSub topic filters which are more = flexible. With this question I was hoping to leave space open for someone = willing to argue for a solution here. Eric > /js From nobody Fri Jul 10 14:35:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D041A03AA for ; Fri, 10 Jul 2015 14:35:50 -0700 (PDT) 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, 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 sAEPyv2_bqJG for ; Fri, 10 Jul 2015 14:35:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1051A0398 for ; Fri, 10 Jul 2015 14:35:45 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB378.namprd05.prod.outlook.com (10.141.51.23) with Microsoft SMTP Server (TLS) id 15.1.201.16; Fri, 10 Jul 2015 21:35:25 +0000 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.207.19; Fri, 10 Jul 2015 21:35:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) with mapi id 15.01.0207.004; Fri, 10 Jul 2015 21:35:23 +0000 From: Kent Watsen To: Benoit Claise , "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" Thread-Topic: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07 Thread-Index: AQHQr8/wAUVLwWdcaUCcPkxPS//vep3MrGLAgAOXuoCABMnZAA== Date: Fri, 10 Jul 2015 21:35:23 +0000 Message-ID: References: <559BFE07.8010009@cisco.com> In-Reply-To: <559BFE07.8010009@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:qIZ6/IN7s4h2voAV36iFobGullhWC83XYBDPbI11QHJqTY/ufBzniJ1iw86mnJk7TNWbewFqPQoZonc5t3Ecankib62uo9/hXZcLlgeRrIDfdQ1oZqGBsQwdRkdqSL+xLpgVtjWlGkV2OvjeBGXKHQ==; 24:AnSNvEnjiMitv+BDtiWNYqI+54pbx1bzXoxHJ92p+PEmjgEdQPimJ+2XfSL1dNkPnbA9MSHkA3IGZ2H7oTsOgIcQ9DcM1EjvczTUvjmw6uw=; 20:7gWqQ24pY3I+HCUiWWl7/Y5bCJzks6FNVY702qRkpKSl/4mJ9sqA6AkGei/EO6+ZXS3RIUWGF9QbVTqawDYx0g== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB378; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(377454003)(43784003)(83506001)(2900100001)(5002640100001)(2950100001)(122556002)(54356999)(230783001)(76176999)(5001770100001)(4001350100001)(16236675004)(36756003)(19625215002)(5001960100002)(2501003)(189998001)(2656002)(99286002)(19580405001)(87936001)(19617315012)(106116001)(19580395003)(15975445007)(102836002)(77156002)(66066001)(62966003)(40100003)(92566002)(46102003)(86362001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1C5B11ABB61Akwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2015 21:35:23.7194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB378; 2:qh3O4WiV9NMqKC/e4UZCtohJHTa77DdWAOkT3hLmP6EX6E1cK2uDFdXVgbcINPyv; 3:33oniLyDq3m2+NcvIdhFjQbt6qANXwpLiBfMi/gXCO9Trky6dGJRq9zK4n7QgiHUWDKb7B5mvC4bQCiFLRo5LNTV+tNEZt2/VXJ2Q4Pce9cVMLmt97Q7I7/Yk3SqzqLl+G6fjgtUsJrfZOtPhvNoHg==; 25:Ne8hsM9h3z/lQCIMld+4BfiCD2Ue9pl12VrnjkDooQQNiX1YTTUN1e6QwcAdgwnhK5Xmvs9veQ8huNhs3JScYTYRDYjSRA/m9zXKSyjs9cDCa88mxc0Z+oF6WPOZAXXzlO+dzApype3oDFk/pKJ1ihA9WuT/D/NwOtOiJP/Oy7sQq4+MnY7kHK4Mhk8PvFEvqlUp/ayiXJ5kXvjHhwFMNyGB7ViafkjHbtzYYr/5z4RBPRKF3c2cbxGWy22dxpMV8hn+i73Ag34GzXdvFSryjQ==; 23:8O/KwcxCgXVnpBf8MRDresvzrF6ym37pyhFm0wxlFBDbNjRrpp+K9BwYRWOFk+bREIDj+a+fEVinPXL0TBVCWwfNeTt00VEeu81VWoA3Sdh+RahyK0X+Dfw6X6hsCS5XyKPw6iJTmwHiH+H5IafcnLbvu72ACMJHNG1b5m4RamD1PdYRGCStwON/LrH3Dktx7OzluFhClXlCnMloVD1gnZxM5KjNgZ/xY3FCLiKceGbr4KxngEVq0SLFxfR63cZR X-OriginatorOrg: juniper.net Archived-At: Cc: 'Barry Leiba' Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 21:35:50 -0000 --_000_D1C5B11ABB61Akwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Benoit, Thank you for your review. I agree that this draft does not truly update = RFC4253, and I like your suggested text. I will put the needed changes int= o the next update to the draft. And I'll also replace-all draft-ietf-netc= onf-rfc5539bis with RFC7589. Thanks again, Kent From: Benoit Claise > Date: Tuesday, July 7, 2015 at 12:27 PM To: "Ersue, Mehmet (Nokia - DE/Munich)" >, "netconf@ietf.org" > Cc: 'Barry Leiba' > Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for d= raft-ietf-netconf-call-home-07 Dear authors, - 1.4. Update to RFC 4253 This document updates the SSH Transport Layer Protocol [RFC4253] only in removing the statement "The client initiates the connection" made in Section 4 (Connection Setup). Assuming the reference to client means "SSH client" and the reference to connection means "TCP connection", this statement doesn't hold true in call home, where the network element is the SSH server and yet still initiates the TCP connection. Security implications related to this change are discussed in Security Considerations (Section 4). >From idnits: Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- -- The draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: -------------------------------------------------------------------------= --- (Using the creation date from RFC4253, updated by this document, for RFC5378 checks: 2005-03-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If yo= u have contacted all the original authors and they are all willing to gr= ant the BCP78 rights to the IETF Trust, then this is fine, and you can ign= ore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) All of the above is around the RFC 4253 update ... but actually, do you update RFC 4253? If you update it (remove "The client initiates the connection"), then this = is for all SSH users, and we should check with everybody. I guess that what you want to say is something such as: This document uses the SSH Transport Layer Protocol [RFC4253] with the exception that the statement "The client initiates the connection" made in Section 4 (Connection Setup) does not apply. Assuming the reference to client means "SSH client" and the reference to connection means "TCP connection", this statement doesn't hold true in call home, where the network element is the SSH server and yet still initiates the TCP connection. Security implications related to this change are discussed in Security Considerations (Section 4). And then you don't update RFC 4253. - draft-ietf-netconf-rfc5539bis is now RFC 7589 Regards, Benoit Dear Netconf WG, we had so far only one review and one support statement on the Call Home dr= aft. A thorough review is necessary before we can decide on the next steps. With this mail I would like to extend the WGLC deadline until July 10, 2015= EOB PT. Please review the Call Home draft and provide your comments to Netconf mail= list. Please state as a minimum whether you support to publish the document. Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mahesh Jet= hanandani Sent: Friday, June 26, 2015 7:21 AM To: Netconf Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 Dear NETCONF participants, This e-mail is a notification to start a NETCONF WG Last Call for the docum= ent "NETCONF Call Home and RESTCONF Call Home". The document can be found at: draft-ietf-netconf-call-home-07. Please review the document, provide comments, and indicate your support for= the draft by Friday July 3 (your timezone). The comments can be in the for= m of: * "I have reviewed the I-D Blah and I have found issues with it" * "I have reviewed I-D Blah and I found no issues" Simultaneously, the author on this draft should state to the mailing list w= hether there is any IPR associated with this draft or not. Thanks Mahesh and Mehmet (Co-chairs, NETCONF WG) _______________________________________________ Netconf mailing list Netconf@ietf.orghttps://www.ietf.org/mailman/listi= nfo/netconf --_000_D1C5B11ABB61Akwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Benoit,

Thank you for your review.   I = agree that this draft does not truly update RFC4253, and I like your s= uggested text.  I will put the needed changes into the next update to = the draft.   And I'll also replace-all draft-ietf-netconf-rfc5539bis with RFC7589.

Thanks again,
Kent

From: Benoit Claise <bclaise@cisco.com>
Date: Tuesday, July 7, 2015 at 12:2= 7 PM
To: "Ersue, Mehmet (Nokia - DE= /Munich)" <mehmet.ersue@n= okia.com>, "netconf@ietf.or= g" <netconf@ietf.org>= ;
Cc: 'Barry Leiba' <barryleiba@computer.org>
Subject: Re: [Netconf] Extended dea= dline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07

Dear authors,

-=20

1.4=
.  Update to RFC 4253

   This document updates the SSH Transport Layer Protocol [RFC4253] only
   in removing the statement "The client initiates the connection"=
; made
   in Section 4 (Connection Setup).  Assuming the reference to c=
lient
   means "SSH client" and the reference to connection means "=
;TCP
   connection", this statement doesn't hold true in call home, where t=
he
   network element is the SSH server and yet still initiates the TCP
   connection.  Security implications related to this change are
   discussed in Security Considerations (Section 4).

>From idnits:


  Checking nits according to http://www.ietf.org/id-info/checklist :
  -------------------------------------------------------------------------=
---

  -- The draft header indicates that this document updates RFC4253, but the
     abstract doesn't seem to mention this, which it should.
  Miscellaneous warnings:
  -------------------------------------------------------------------------=
---

     (Using the creation date from RFC4253, updated by this document, for
     RFC5378 checks: 2005-03-16)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If yo=
u
     have contacted all the original authors and they are all willing to gr=
ant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ign=
ore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.=
=20
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.)
All of the above is around the RFC 4253 update ... but actually, do you update RFC 4253?
If you update it (remove "The client initiates the connection"), = then this is for all SSH users, and we should check with everybody.
I guess that what you want to say is something such as: 
   This document uses the SSH Transport Layer Protocol [RFC4253] with the=20
   exception that the statement "The client initiates the connection&q=
uot; made
   in Section 4 (Connection Setup) does not apply.  Assuming the=
 reference=20
   to client means "SSH client" and the reference to connection m=
eans "TCP
   connection", this statement doesn't hold true in call home, where t=
he
   network element is the SSH server and yet still initiates the TCP
   connection.  Security implications related to this change are
   discussed in Security Considerations (Section 4).
And then you don't update RFC 4253.
 
- draft-ietf-netconf-rfc5539bis is now RFC 7589

Regards, Benoit

= Dear Net= conf WG,

= &nb= sp;

= we had s= o far only one review and one support statement on the Call Home draft.

= A thorou= gh review is necessary before we can decide on the next steps.

= &nb= sp;

= With thi= s mail I would like to extend the WGLC deadline until July 10, 2015 EOB PT.=

= &nb= sp;

= Please r= eview the Call Home draft and provide your comments to Netconf maillist.

= Please s= tate as a minimum whether you support to publish the document.

= &nb= sp;

= Mehmet

= &nb= sp;

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mahesh Jeth= anandani
Sent: Friday, June 26, 2015 = 7:21 AM
To: Netconf
Subject: [Netconf] WG Last C= all for draft-ietf-netconf-call-home-07

 

Dear NETCONF participants,

This e-mail is a notification to start a NETCONF WG Last Call for the docum= ent "NETCONF Call Home and RESTCONF Call Home”.


The document can be found at: draft-ietf-netconf= -call-home-07.

 

Please review the document, provide commen= ts, and indicate your support for the draft by Friday July 3 (your timezone). The comments can be in the form of:

 

  • “I have reviewed the I-D Blah and = I have found issues with it”
  • “I have reviewed I-D Blah and I fo= und no issues”

 

Simultaneously, the author on this draft= should state to the mailing list whether there is any IPR associated with this draft or not.

 

Thanks


Mahesh and Mehmet

(Co-chairs, NETCONF WG)<= /font>

 

 

 



_______________________________________________
Netconf mailing list
Netc=
onf@ietf.orghttps://www.ietf.org/mailman/listinfo/netcon=
f

--_000_D1C5B11ABB61Akwatsenjunipernet_-- From nobody Sat Jul 11 04:03:56 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45731A8A99 for ; Sat, 11 Jul 2015 04:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 6xpzbPyIjsNi for ; Sat, 11 Jul 2015 04:03:49 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 70D211A8A92 for ; Sat, 11 Jul 2015 04:03:48 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t6BB3ha8022497 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Jul 2015 11:03:43 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t6BB3gw1027644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jul 2015 13:03:43 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 11 Jul 2015 13:03:42 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.121]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0235.001; Sat, 11 Jul 2015 13:03:42 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: ext Kent Watsen , "netconf@ietf.org" Thread-Topic: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07 Thread-Index: AQHQu8k/BIy8q7O1Jkat4Uzi92+gBQ== Date: Sat, 11 Jul 2015 11:03:42 +0000 Message-ID: References: <559BFE07.8010009@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.108] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819730706DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 66530 X-purgate-ID: 151667::1436612623-000076F8-58D3BE73/0/0 Archived-At: Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 11:03:54 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819730706DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, it looks the WGLC was successful. I think once the draft update is available we can start the IESG publicatio= n machinery. Mehmet From: ext Kent Watsen [mailto:kwatsen@juniper.net] Sent: Friday, July 10, 2015 11:35 PM To: Benoit Claise; Ersue, Mehmet (Nokia - DE/Munich); netconf@ietf.org Cc: 'Barry Leiba' Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for d= raft-ietf-netconf-call-home-07 Hi Benoit, Thank you for your review. I agree that this draft does not truly update = RFC4253, and I like your suggested text. I will put the needed changes int= o the next update to the draft. And I'll also replace-all draft-ietf-netc= onf-rfc5539bis with RFC7589. Thanks again, Kent From: Benoit Claise > Date: Tuesday, July 7, 2015 at 12:27 PM To: "Ersue, Mehmet (Nokia - DE/Munich)" >, "netconf@ietf.org" > Cc: 'Barry Leiba' > Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for d= raft-ietf-netconf-call-home-07 Dear authors, - 1.4. Update to RFC 4253 This document updates the SSH Transport Layer Protocol [RFC4253] only in removing the statement "The client initiates the connection" made in Section 4 (Connection Setup). Assuming the reference to client means "SSH client" and the reference to connection means "TCP connection", this statement doesn't hold true in call home, where the network element is the SSH server and yet still initiates the TCP connection. Security implications related to this change are discussed in Security Considerations (Section 4). >From idnits: Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- -- The draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: -------------------------------------------------------------------------= --- (Using the creation date from RFC4253, updated by this document, for RFC5378 checks: 2005-03-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If yo= u have contacted all the original authors and they are all willing to gr= ant the BCP78 rights to the IETF Trust, then this is fine, and you can ign= ore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) All of the above is around the RFC 4253 update ... but actually, do you update RFC 4253? If you update it (remove "The client initiates the connection"), then this = is for all SSH users, and we should check with everybody. I guess that what you want to say is something such as: This document uses the SSH Transport Layer Protocol [RFC4253] with the exception that the statement "The client initiates the connection" made in Section 4 (Connection Setup) does not apply. Assuming the reference to client means "SSH client" and the reference to connection means "TCP connection", this statement doesn't hold true in call home, where the network element is the SSH server and yet still initiates the TCP connection. Security implications related to this change are discussed in Security Considerations (Section 4). And then you don't update RFC 4253. - draft-ietf-netconf-rfc5539bis is now RFC 7589 Regards, Benoit Dear Netconf WG, we had so far only one review and one support statement on the Call Home dr= aft. A thorough review is necessary before we can decide on the next steps. With this mail I would like to extend the WGLC deadline until July 10, 2015= EOB PT. Please review the Call Home draft and provide your comments to Netconf mail= list. Please state as a minimum whether you support to publish the document. Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mahesh Jet= hanandani Sent: Friday, June 26, 2015 7:21 AM To: Netconf Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 Dear NETCONF participants, This e-mail is a notification to start a NETCONF WG Last Call for the docum= ent "NETCONF Call Home and RESTCONF Call Home". The document can be found at: draft-ietf-netconf-call-home-07. Please review the document, provide comments, and indicate your support for= the draft by Friday July 3 (your timezone). The comments can be in the for= m of: ? "I have reviewed the I-D Blah and I have found issues with it" ? "I have reviewed I-D Blah and I found no issues" Simultaneously, the author on this draft should state to the mailing list w= hether there is any IPR associated with this draft or not. Thanks Mahesh and Mehmet (Co-chairs, NETCONF WG) _______________________________________________ Netconf mailing list Netconf@ietf.orghttps://www.ietf.org/mailman/listi= nfo/netconf --_000_E4DE949E6CE3E34993A2FF8AE79131F819730706DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Kent,

=  

= it looks the WGLC was successful.

=  

= I think once the draft update is available we can start the IESG publicati= on machinery.

=  

= Mehmet

=  

From: ext Kent Watsen [mailto:kwatsen@juniper.net]
Sent: Friday, July 10, 2015 = 11:35 PM
To: Benoit Claise; Ersue, Me= hmet (Nokia - DE/Munich); netconf@ietf.org
Cc: 'Barry Leiba'
Subject: Re: [Netconf] Exten= ded deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-= 07

 

=  

= Hi Benoit,

=  

= Thank you for your review.   I agree that this draft does not tru= ly update RFC4253, and I like your suggested text.  I will put the needed = changes into the next update to the draft.   And I'll also replace-all=  draft-ietf-netconf-rfc5539bis with RFC7589.<= /p>

=  

Thanks again,<= span style=3D"mso-fareast-font-family:"Times New Roman"">

Kent

=  

From: Benoi= t Claise <bclaise@cisco.com>=
Date: Tuesday, July 7, 2015 = at 12:27 PM
To: "Ersue, Mehmet (Nok= ia - DE/Munich)" <mehmet.= ersue@nokia.com>, "netconf@= ietf.org" <netconf@ietf.org= >
Cc: 'Barry Leiba' <barryleiba@computer.org>
Subject: Re: [Netconf] Exten= ded deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-= 07

=  

Dear authors,

-

1.4.  Update to RFC 4253

 
   =
This document updates the SSH Transport Layer Protocol [RFC4253] only

   =
in removing the statement "The client initiates the connection&=
quot; made


   =
in Section 4 (Connection Setup).  Assuming the reference to client


   =
means "SSH client" and the reference to connection means &=
quot;TCP


   =
connection", this statement doesn't hold true in call home, whe=
re the


   =
network element is the SSH server and yet still initiates the TCP


   =
connection.  Security i=
mplications related to this change are


   =
discussed in Security Considerations (Section 4).


 


>From idnits:

 


 


  Checking nits according to http://www.ietf.org/id-info/checklist :

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


 


  -- The draft header indicates that this document updates RFC4253, but the<=
o:p>


  &=
nbsp;  abstract doesn't seem to mention this, which it should.<=
o:p>


  Miscellaneous warnings:


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


 


  &=
nbsp;  (Using the creation date from RFC4253, updated by this d=
ocument, for


  &=
nbsp;  RFC5378 checks: 2005-03-16)

 


  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may


  &=
nbsp;  have content which was first submitted before 10 Novembe=
r 2008.  If you


  &=
nbsp;  have contacted all the original authors and they are all=
 willing to grant


  &=
nbsp;  the BCP78 rights to the IETF Trust, then this is fine, a=
nd you can ignore


  &=
nbsp;  this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 


  &=
nbsp;  (See the Legal Provisions document at


  &=
nbsp;  http://=
trustee.ietf.org/license-info for more information.)<=
/font>


 


 


=
All of the above is around the
RFC 4253 update ... but=
 actually, do you update
RFC 4253?

If you update it (remove "The client initiates the connection"), =
then this is for all SSH users, and we should check with everybody.

I guess that what you want to say is something such as: <=
/font>


  &=
nbsp;This document uses the SSH Transport Layer Protocol [RFC4253] with the 


  &=
nbsp;exception that the statement "The client initiates the con=
nection" made


   =
in Section 4 (Connection Setup) does not apply.  Assuming the reference 


  &=
nbsp;to client means "SSH client" and the reference to con=
nection means "TCP


   =
connection", this statement doesn't hold true in call home, whe=
re the


   =
network element is the SSH server and yet still initiates the TCP


   =
connection.  Security i=
mplications related to this change are


   =
discussed in Security Considerations (Section 4).


=
And then you don't update RFC 4253.

 

- draft-ietf-netconf-rfc5539bis is now RFC 7589 



Regards, Benoit

= Dear Netconf WG,

=  

= we had so far only one review and one support st= atement on the Call Home draft.

= A thorough review is necessary before we can dec= ide on the next steps.

=  

= With this mail I would like to extend the WGLC d= eadline until July 10, 2015 EOB PT.

=  

= Please review the Call Home draft and provide yo= ur comments to Netconf maillist.

= Please state as a minimum whether you support to= publish the document.

=  

= Mehmet =

=  

From= : Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Mahesh Jeth= anandani
Sent: Friday, June 26, 2015 = 7:21 AM
To: Netconf
Subject: [Netconf] WG Last C= all for draft-ietf-netconf-call-home-07=

 =

Dear NETCONF participants,

This e-mail is a notification to start a NETCONF WG Last Call for the docum= ent "NETCONF Call Home and RESTCONF Call Home”.


The document can be found at: draft-ietf-netconf-call-home-07.=

 

Please review the document, provide comments, a= nd indicate your support for the draft by Friday July 3 (your timezone). The comments can be in the form of:

 

?    &n= bsp;    = 220;I have reviewed the I-D Blah and I have found issues with it”

?    &n= bsp;    = 220;I have reviewed I-D Blah and I found no issues”=

 

Simultaneously, the author on this draft should= state to the mailing list whether there is any IPR associated with this draft or not.

 

Thanks


Mahesh and Mehmet

(Co-chairs, NETCONF WG)

 <= /p>

 

 

= 


______________________________________________=
_
Netconf mailing list<=
/pre>

Netconf@ie=
tf.orghttps:/=
/www.ietf.org/mailman/listinfo/netconf

=  

--_000_E4DE949E6CE3E34993A2FF8AE79131F819730706DEMUMBX005nsnin_-- From nobody Sat Jul 11 22:16:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC001A1B34 for ; Sat, 11 Jul 2015 22:16:10 -0700 (PDT) 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 8mxXYlFaOOsX for ; Sat, 11 Jul 2015 22:16:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1A11A1B2C for ; Sat, 11 Jul 2015 22:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1371; q=dns/txt; s=iport; t=1436678169; x=1437887769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j4dD1IYCtxSVVu5qfQyUuLPytW07VT6Umre3GXCTStc=; b=LCg1JuQUHJISq1CTembHQxMuGU6crwGNphwDMLKMd71Z6sDr2YedBvuU KAz2FKeO6kzM8piKX+Yelri00surD75s2FTz6KCN0QWpoh/5txTokBLSS ulJLiVKdml/5JdBdrJiJw6I7k00f3L0itYjg/4ayhu9jmJc4P8tdrV5Rc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BhAwDz9qFV/4QNJK1bgxRUaQa7MgmBaQqFLUoCgSI4FAEBAQEBAQGBCoQjAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoCAREJBycLFAkIAQEEAQ0FCBOICwgNxkQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItMhFUxBwaDEYEUBZQxAaRuJoN7b4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,456,1432598400"; d="scan'208";a="9029772" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jul 2015 05:16:08 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6C5G81E029513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Jul 2015 05:16:08 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sun, 12 Jul 2015 00:16:08 -0500 From: "Ambika Prasad Tripathy (ambtripa)" To: "Eric Voit (evoit)" , Juergen Schoenwaelder , "Alexander Clemm (alex)" Thread-Topic: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Thread-Index: AdC5FyP9Rm6uBgErR8+WZ2t4USQNKABbyl6QACF4cAAAAkA7cABS5r3Q Date: Sun, 12 Jul 2015 05:16:07 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF110926B0@xmb-aln-x08.cisco.com> References: <20150710073019.GA3709@elstar.local> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.40.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 05:16:11 -0000 Hi Alex/Eric, Few doubts =20 1) who will define streams? What is the practical use of it? Doesn't the fi= lter will address the requirement? 2) If user is defining the streams, how to subscribe to the stream? Is stre= am is a mandatory parameter for subscription?=20 Br, Ambika Prasad Tripathy -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Friday, July 10, 2015 7:06 AM To: Juergen Schoenwaelder Cc: netconf@ietf.org Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt > From: Juergen Schoenwaelder, July 10, 2015 3:30 AM > >> On Thu, Jul 09, 2015 at 08:59:52PM +0000, Eric Voit (evoit) wrote: >>=20 >> (3) Are there filters which should be provided beyond RFC 5277 Subtree = and Property Filters? >> > > What is a 'Property Filter'? RFC 5277 XPATH Filters for attribute match expressions is what I believe is= achievable right now upon YANG objects. But other PubSub technologies li= ke DDS (OMG) and MQTT (OASIS) can pass PubSub topic filters which are more = flexible. With this question I was hoping to leave space open for someone = willing to argue for a solution here. Eric > /js _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jul 13 02:18:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7F21A1A19 for ; Mon, 13 Jul 2015 02:18:40 -0700 (PDT) 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 vujJpTU-s2Ox for ; Mon, 13 Jul 2015 02:18:39 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DE51A1A1B for ; Mon, 13 Jul 2015 02:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3035; q=dns/txt; s=iport; t=1436779119; x=1437988719; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TAoBz12SNhNir49R4n1VT0CpZJet0qYXG4tMaPFYECU=; b=e9dL7dJgHBio4psBXBt/ZNGtg/BuVKxL8Y+44CMVNfR4jl29iUfw73kZ WFh58focal6esv1P90eEzSlCy0zto+o4vndY1jxo/Etfs6uPxQ+fNq9t7 UnMHQAgRlLLQDlCqJk8Nx1JvkI1R9HQmtrNjm29qbyEIRaNfNda8w7Q3m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGBQDqgKNV/5xdJa1bgxRUaQa9JgqFLUoCgTE7EQEBAQEBAQGBCoQjAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoCAREJBycLFAkIAgQBDQUIE4gLCA3IYgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0yEVTEHBoMRgRQFlDEBpG4mggeBdG+BR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,461,1432598400"; d="scan'208";a="167998379" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 13 Jul 2015 09:18:38 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6D9IcDv001371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jul 2015 09:18:38 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.132]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 13 Jul 2015 04:18:38 -0500 From: "Alexander Clemm (alex)" To: "Ambika Prasad Tripathy (ambtripa)" , "Eric Voit (evoit)" , Juergen Schoenwaelder Thread-Topic: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Thread-Index: AQHQuooz6Uik0pcfPUyNY2GdZIVzUZ3Uo0oAgABui4CAApCegIABf5xA Date: Mon, 13 Jul 2015 09:18:37 +0000 Message-ID: References: <20150710073019.GA3709@elstar.local> <3B675C3A8DF102408C754E30986E43CF110926B0@xmb-aln-x08.cisco.com> In-Reply-To: <3B675C3A8DF102408C754E30986E43CF110926B0@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.167.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 09:18:40 -0000 Hi Ambika, there is one conceptual stream that is predefined, datastore-push. =20 One item for discussion concerns whether there should be other conceptual s= treams that are predefined: specifically, one stream with all operational = data (in effect, datastore-push with all config data removed) - e.g. "opera= tional-push", and (potentiallly) one stream with all operational data minus= counters (specifically for on-change subscriptions, which make little sens= e for ocunters). While strictly speaking you could define filters on datas= tore-push instead, having a dedicated stream is more convenient as the arti= culation of a separate filter is more tedious and makes the mechanism harde= r to use. =20 To let users define streams is strictly speaking not required, but makes fo= r a "convenience function". Among other things, again it saves subscribers= from having to articulate filters, in particular if an administrator preco= nfigures corresponding streams. =20 In any event, yes, the stream is a mandatory parameter. You always subscri= be to a stream (well, with datastore-push as a default, we can argue if it = should therefore whether as a parameter it should be optional after all). = This is also one of the parameters that have already introduced in RFC 527= 7 (create-subscription for notifications). =20 Thanks --- Alex -----Original Message----- From: Ambika Prasad Tripathy (ambtripa)=20 Sent: Sunday, July 12, 2015 7:16 AM To: Eric Voit (evoit); Juergen Schoenwaelder; Alexander Clemm (alex) Cc: netconf@ietf.org Subject: RE: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Hi Alex/Eric, Few doubts =20 1) who will define streams? What is the practical use of it? Doesn't the fi= lter will address the requirement? 2) If user is defining the streams, how to subscribe to the stream? Is stre= am is a mandatory parameter for subscription?=20 Br, Ambika Prasad Tripathy -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Friday, July 10, 2015 7:06 AM To: Juergen Schoenwaelder Cc: netconf@ietf.org Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt > From: Juergen Schoenwaelder, July 10, 2015 3:30 AM > >> On Thu, Jul 09, 2015 at 08:59:52PM +0000, Eric Voit (evoit) wrote: >>=20 >> (3) Are there filters which should be provided beyond RFC 5277 Subtree = and Property Filters? >> > > What is a 'Property Filter'? RFC 5277 XPATH Filters for attribute match expressions is what I believe is= achievable right now upon YANG objects. But other PubSub technologies li= ke DDS (OMG) and MQTT (OASIS) can pass PubSub topic filters which are more = flexible. With this question I was hoping to leave space open for someone = willing to argue for a solution here. Eric > /js _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jul 13 08:52:56 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE79D1B2BFB for ; Mon, 13 Jul 2015 08:52:54 -0700 (PDT) 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 xM83isVVmpB8 for ; Mon, 13 Jul 2015 08:52:53 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126F31B2BED for ; Mon, 13 Jul 2015 08:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3714; q=dns/txt; s=iport; t=1436802773; x=1438012373; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=x5SVTqtYZQceqqpyH1q0r7wB5dti6so6mDeo98him4A=; b=F54TM0L7rCC+O8aCI0omYg1e52xLJHRgZVRGBcWMYkLCSERawMAaTSEZ aZgGe7+x2LrGwSSFQPbtIdZ/iUpO0MJg9SHjivGMi3ueRuYoJ1jBVRqkH 7yN0yMOFZl6j2ynRb0BJGLxPSKA0NjrKoT/UH157/pAgj9kK1JkCb/Bsw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BkAwD33aNV/51dJa1bgxNUaQa7PAmBaQqFLUoCgTY4FAEBAQEBAQGBCoQjAQEBAwEBAQE3NAQHBQcEAgEIEQQBAQEKAgERCQcnCxQJCAIEAQ0FCBOICwgNyncBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItMhFUxBwaDEYEUBZQxAY1ChBiTFCaCB4F0b4EGJRyBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,463,1432598400"; d="scan'208";a="168062189" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 13 Jul 2015 15:52:52 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6DFqqoh028096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jul 2015 15:52:52 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 13 Jul 2015 10:52:51 -0500 From: "Ambika Prasad Tripathy (ambtripa)" To: "Alexander Clemm (alex)" , "Eric Voit (evoit)" , Juergen Schoenwaelder Thread-Topic: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Thread-Index: AdC5FyP9Rm6uBgErR8+WZ2t4USQNKABbyl6QACF4cAAAAkA7cABS5r3QAEWA+YAAAvssAA== Date: Mon, 13 Jul 2015 15:52:51 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF11092DBB@xmb-aln-x08.cisco.com> References: <20150710073019.GA3709@elstar.local> <3B675C3A8DF102408C754E30986E43CF110926B0@xmb-aln-x08.cisco.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.136.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 15:52:55 -0000 Hi Alex, Thanks. It is clear about stream. But we can do the same stuff with filter.=20 What is the difference between filter and stream is not clear? When I am su= bscribing to a stream, can I apply filters? If yes, then is the filter shou= ld be validated based on stream definition? Cloud you please explain on filters of subscription and streams and relatio= n? Br, Ambika -----Original Message----- From: Alexander Clemm (alex)=20 Sent: Monday, July 13, 2015 2:19 AM To: Ambika Prasad Tripathy (ambtripa); Eric Voit (evoit); Juergen Schoenwae= lder Cc: netconf@ietf.org Subject: RE: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Hi Ambika, there is one conceptual stream that is predefined, datastore-push. =20 One item for discussion concerns whether there should be other conceptual s= treams that are predefined: specifically, one stream with all operational = data (in effect, datastore-push with all config data removed) - e.g. "opera= tional-push", and (potentiallly) one stream with all operational data minus= counters (specifically for on-change subscriptions, which make little sens= e for ocunters). While strictly speaking you could define filters on datas= tore-push instead, having a dedicated stream is more convenient as the arti= culation of a separate filter is more tedious and makes the mechanism harde= r to use. =20 To let users define streams is strictly speaking not required, but makes fo= r a "convenience function". Among other things, again it saves subscribers= from having to articulate filters, in particular if an administrator preco= nfigures corresponding streams. =20 In any event, yes, the stream is a mandatory parameter. You always subscri= be to a stream (well, with datastore-push as a default, we can argue if it = should therefore whether as a parameter it should be optional after all). = This is also one of the parameters that have already introduced in RFC 527= 7 (create-subscription for notifications). =20 Thanks --- Alex -----Original Message----- From: Ambika Prasad Tripathy (ambtripa)=20 Sent: Sunday, July 12, 2015 7:16 AM To: Eric Voit (evoit); Juergen Schoenwaelder; Alexander Clemm (alex) Cc: netconf@ietf.org Subject: RE: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Hi Alex/Eric, Few doubts =20 1) who will define streams? What is the practical use of it? Doesn't the fi= lter will address the requirement? 2) If user is defining the streams, how to subscribe to the stream? Is stre= am is a mandatory parameter for subscription?=20 Br, Ambika Prasad Tripathy -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Friday, July 10, 2015 7:06 AM To: Juergen Schoenwaelder Cc: netconf@ietf.org Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt > From: Juergen Schoenwaelder, July 10, 2015 3:30 AM > >> On Thu, Jul 09, 2015 at 08:59:52PM +0000, Eric Voit (evoit) wrote: >>=20 >> (3) Are there filters which should be provided beyond RFC 5277 Subtree = and Property Filters? >> > > What is a 'Property Filter'? RFC 5277 XPATH Filters for attribute match expressions is what I believe is= achievable right now upon YANG objects. But other PubSub technologies li= ke DDS (OMG) and MQTT (OASIS) can pass PubSub topic filters which are more = flexible. With this question I was hoping to leave space open for someone = willing to argue for a solution here. Eric > /js _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jul 13 11:46:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E41D1A8770 for ; Mon, 13 Jul 2015 11:46:20 -0700 (PDT) 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 n3ZikjJJ7s3K for ; Mon, 13 Jul 2015 11:46:18 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82BE71A8746 for ; Mon, 13 Jul 2015 11:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5444; q=dns/txt; s=iport; t=1436813178; x=1438022778; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VlxuU6DAtUn56oFOB8NnTcJb4vG/M6I4QY6JNS1as84=; b=NjXU+uEsijl8SGmps1mpeVbR768UclKSF7E7SbVFrpypL02TViNENJV1 mZhVidhwG4MKG3FGUSdbOwuOYok3o+41PrYNXgGLZ7ir+yaBLzbgBOQai WWbsn9UIXmxJOCc0K6ThdD3JIg/pRETeFoptIJMtVvJ7C7lb0K/onWzxV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ACBQCZBqRV/5xdJa1bgxNUaQa7RoFqCoUtSgKBPTkTAQEBAQEBAYEKhCMBAQEDAQEBATc0BAcFBwQCAQgRBAEBAQoCAREJBycLFAkIAgQBDQUIE4gLCA3LKgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0yEVTEHBoMRgRQFlDEBh0aFfIQYiweELoNfJoIHgXRvgQYlHIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,464,1432598400"; d="scan'208";a="168287307" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2015 18:46:17 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6DIkHaH010617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jul 2015 18:46:17 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.132]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 13 Jul 2015 13:46:17 -0500 From: "Alexander Clemm (alex)" To: "Ambika Prasad Tripathy (ambtripa)" , "Eric Voit (evoit)" , Juergen Schoenwaelder Thread-Topic: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Thread-Index: AQHQuooz6Uik0pcfPUyNY2GdZIVzUZ3Uo0oAgABui4CAApCegIABf5xAgADEoID//9ZhYA== Date: Mon, 13 Jul 2015 18:46:15 +0000 Message-ID: References: <20150710073019.GA3709@elstar.local> <3B675C3A8DF102408C754E30986E43CF110926B0@xmb-aln-x08.cisco.com> <3B675C3A8DF102408C754E30986E43CF11092DBB@xmb-aln-x08.cisco.com> In-Reply-To: <3B675C3A8DF102408C754E30986E43CF11092DBB@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.167.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 18:46:20 -0000 Hi Ambika, maybe going at your questions in reverse order, from bottom to top: =20 Filters and stream are different. You subscribe to a stream. You can appl= y a filter to that stream, which you specify as part of your subscription. = =20 You apply the filter to the update records that are part of the stream. Wh= en a data item/update matches the filter condition, you let it pass, otherw= ise you discard it. (I am not sure what you mean with validation. If you = specify a filter condition that doesn't match anything in the stream, you w= ill simply not get many updates.) "We can do the same stuff with filter." I think here you are referring to = custom datastreams. Yes, indeed, custom datastreams are configured using t= he same parameters as filter conditions. It is a convenience function. Th= ere are a number of reasons why you may want to configure a custom datastre= am, instead of simply entering a subscription with corresponding filter con= dition to datastream push: For one, if you have multiple subscribers that = require the same informaiton, providing a custom datastream that evaluates = a filter once and then pushes the same data to everyone may be more effecti= ve than having to evaluate the same filter condition multiple times. Secon= d, it makes subscriptions easier to provide - as a user, you don't need to = articulate potentially complex filter conditions. =20 --- Alex -----Original Message----- From: Ambika Prasad Tripathy (ambtripa)=20 Sent: Monday, July 13, 2015 5:53 PM To: Alexander Clemm (alex); Eric Voit (evoit); Juergen Schoenwaelder Cc: netconf@ietf.org Subject: RE: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Hi Alex, Thanks. It is clear about stream. But we can do the same stuff with filter.=20 What is the difference between filter and stream is not clear? When I am su= bscribing to a stream, can I apply filters? If yes, then is the filter shou= ld be validated based on stream definition? Cloud you please explain on filters of subscription and streams and relatio= n? Br, Ambika -----Original Message----- From: Alexander Clemm (alex)=20 Sent: Monday, July 13, 2015 2:19 AM To: Ambika Prasad Tripathy (ambtripa); Eric Voit (evoit); Juergen Schoenwae= lder Cc: netconf@ietf.org Subject: RE: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Hi Ambika, there is one conceptual stream that is predefined, datastore-push. =20 One item for discussion concerns whether there should be other conceptual s= treams that are predefined: specifically, one stream with all operational = data (in effect, datastore-push with all config data removed) - e.g. "opera= tional-push", and (potentiallly) one stream with all operational data minus= counters (specifically for on-change subscriptions, which make little sens= e for ocunters). While strictly speaking you could define filters on datas= tore-push instead, having a dedicated stream is more convenient as the arti= culation of a separate filter is more tedious and makes the mechanism harde= r to use. =20 To let users define streams is strictly speaking not required, but makes fo= r a "convenience function". Among other things, again it saves subscribers= from having to articulate filters, in particular if an administrator preco= nfigures corresponding streams. =20 In any event, yes, the stream is a mandatory parameter. You always subscri= be to a stream (well, with datastore-push as a default, we can argue if it = should therefore whether as a parameter it should be optional after all). = This is also one of the parameters that have already introduced in RFC 527= 7 (create-subscription for notifications). =20 Thanks --- Alex -----Original Message----- From: Ambika Prasad Tripathy (ambtripa)=20 Sent: Sunday, July 12, 2015 7:16 AM To: Eric Voit (evoit); Juergen Schoenwaelder; Alexander Clemm (alex) Cc: netconf@ietf.org Subject: RE: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt Hi Alex/Eric, Few doubts =20 1) who will define streams? What is the practical use of it? Doesn't the fi= lter will address the requirement? 2) If user is defining the streams, how to subscribe to the stream? Is stre= am is a mandatory parameter for subscription?=20 Br, Ambika Prasad Tripathy -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Friday, July 10, 2015 7:06 AM To: Juergen Schoenwaelder Cc: netconf@ietf.org Subject: Re: [Netconf] New version for draft-clemm-netconf-yang-push-01.txt > From: Juergen Schoenwaelder, July 10, 2015 3:30 AM > >> On Thu, Jul 09, 2015 at 08:59:52PM +0000, Eric Voit (evoit) wrote: >>=20 >> (3) Are there filters which should be provided beyond RFC 5277 Subtree = and Property Filters? >> > > What is a 'Property Filter'? RFC 5277 XPATH Filters for attribute match expressions is what I believe is= achievable right now upon YANG objects. But other PubSub technologies li= ke DDS (OMG) and MQTT (OASIS) can pass PubSub topic filters which are more = flexible. With this question I was hoping to leave space open for someone = willing to argue for a solution here. Eric > /js _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jul 13 13:03:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ED21B2DFD for ; Mon, 13 Jul 2015 13:03:19 -0700 (PDT) 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 oEFDZW52Se1e for ; Mon, 13 Jul 2015 13:03:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0136.outbound.protection.outlook.com [207.46.100.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FFA1B2DE2 for ; Mon, 13 Jul 2015 13:03:09 -0700 (PDT) Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB347.namprd05.prod.outlook.com (10.141.52.11) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 13 Jul 2015 20:03:08 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 13 Jul 2015 20:03:07 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.189]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.189]) with mapi id 15.01.0213.000; Mon, 13 Jul 2015 20:03:06 +0000 From: Kent Watsen To: "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" Thread-Topic: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07 Thread-Index: AQHQr8/wAUVLwWdcaUCcPkxPS//vep3MrGLAgAOXuoCABMnZAIABJOkAgAN4TAA= Date: Mon, 13 Jul 2015 20:03:06 +0000 Message-ID: References: <559BFE07.8010009@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: nokia.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:4DVSd1v1yP7ZRK6Cbk27D1TPFmkr1cl0j3HJDGWN5ITWVnlE2ZZlx3CnDNtYWAbdSfy/og2phGUweG+1sJDZxrEF8fD4tiRKuxJROTVNxpiGFEYQTt48lBoLg1/J/N1uwcSkIeij56dSWxVdxsczxQ==; 24:iKmT1EybFinZmBSpk9FvETI/1M1SsvveSr0B1HUWgC/Hr9whHeMBkjxARCeLHZa0IwwE+PGMaBx6ZWGNjULEMKVBJighBakAGbq/salY5zI=; 20:CtqW8DRKuF/2zZ/mPz/fDRVrRqsvJwnSaDVXZ4nX23ER+jFfjnR/CbWEtoeNSEGaZGCwuw4GOdHaP105gxL2PA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB347; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0636271852 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(43784003)(377424004)(377454003)(2656002)(5001960100002)(106116001)(2950100001)(19580395003)(122556002)(19300405004)(2501003)(83506001)(16236675004)(19580405001)(40100003)(230783001)(2900100001)(87936001)(77156002)(93886004)(189998001)(15187005004)(5002640100001)(36756003)(46102003)(54356999)(66066001)(5001770100001)(76176999)(92566002)(102836002)(4001350100001)(62966003)(86362001)(50986999)(15975445007)(19617315012)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1C99104BC9B6kwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2015 20:03:06.7519 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB347; 2:ON+TXtiFYvBFm7qONFSy3ZASGR0DdomECici2+eqggZmavktECteC3bBtSQgoApb; 3:dBAqAJ6Khz6SIcTGrwhPZMUsAOlUHw2hIGkaAd0YHmCJ6/Kq4u01WISdyIoAGbze5f2VElsWPtpg9ItXcvdYJ6mdXeusSrShEx2Jd0qaTzdp1mKcSt8/cmrxpUp5hafTxsVGWpVlt4rDe2+EaBqwGQ==; 25:4NJXmegf3VZLHloqJQGAsKyYkWleRTB5xolV21YfI2qaWdJvj7HcQu1OWqD6Tn2/4S/9YlMlKlHvqIVHHZ9EPSbl2MoCF8jJVLM0vQw1yY6Fp+vO5vVa2xliP5MLauGq3tETVJMPZcbUTJwoKqgnVDPq8RrWwkFLIil+Ej2FQ3JbOYJU66Ojy1AXyZQBkgDNIWDFwQ1I1CCZNA7nppVZe85e5tKSShN/8zFVWal847/6CQ5U1hMEis/EOqZLuis6bFSsvESG/rnsJq125hXV5w==; 23:kESs+VYMYrERYL4Jm3US/kJ/AwS4mRvOR7+wNoHAPXJAJBWrv+5hmDvjcPWQ+xhJSr2mnd/8MhsDjtGd5GCTbJaR1EU0PHTJ+DVqD2p1VSfoqXPRy9/R5hGPBIIPVOr56hLVyR9hVydH1zMuP27xAC/mPVrGiMeOHIpeTjuD/oOymM0TNJB4Ra2277R9hIec2hH+W5MWoz9LDO18cZfQuuBmhnh+1JJlJmJ8wsRN5StEQ6E2ZOEhKEDVK4IYBTe+ X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 20:03:19 -0000 --_000_D1C99104BC9B6kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mehmet, Indeed, and I can post the update on or about Sunday, when the submissions = are allowed again. Cheers, Kent From: , "Mehmet (Nokia - DE/Munich)" > Date: Saturday, July 11, 2015 at 7:03 AM To: Kent Watsen >, "netconf= @ietf.org" > Cc: Benoit Claise > Subject: RE: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for d= raft-ietf-netconf-call-home-07 Hi Kent, it looks the WGLC was successful. I think once the draft update is available we can start the IESG publicatio= n machinery. Mehmet From: ext Kent Watsen [mailto:kwatsen@juniper.net] Sent: Friday, July 10, 2015 11:35 PM To: Benoit Claise; Ersue, Mehmet (Nokia - DE/Munich); netconf@ietf.org Cc: 'Barry Leiba' Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for d= raft-ietf-netconf-call-home-07 Hi Benoit, Thank you for your review. I agree that this draft does not truly update = RFC4253, and I like your suggested text. I will put the needed changes int= o the next update to the draft. And I'll also replace-all draft-ietf-netc= onf-rfc5539bis with RFC7589. Thanks again, Kent From: Benoit Claise > Date: Tuesday, July 7, 2015 at 12:27 PM To: "Ersue, Mehmet (Nokia - DE/Munich)" >, "netconf@ietf.org" > Cc: 'Barry Leiba' > Subject: Re: [Netconf] Extended deadline July 10 WAS:FW: WG Last Call for d= raft-ietf-netconf-call-home-07 Dear authors, - 1.4. Update to RFC 4253 This document updates the SSH Transport Layer Protocol [RFC4253] only in removing the statement "The client initiates the connection" made in Section 4 (Connection Setup). Assuming the reference to client means "SSH client" and the reference to connection means "TCP connection", this statement doesn't hold true in call home, where the network element is the SSH server and yet still initiates the TCP connection. Security implications related to this change are discussed in Security Considerations (Section 4). >From idnits: Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- -- The draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: -------------------------------------------------------------------------= --- (Using the creation date from RFC4253, updated by this document, for RFC5378 checks: 2005-03-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If yo= u have contacted all the original authors and they are all willing to gr= ant the BCP78 rights to the IETF Trust, then this is fine, and you can ign= ore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) All of the above is around the RFC 4253 update ... but actually, do you update RFC 4253? If you update it (remove "The client initiates the connection"), then this = is for all SSH users, and we should check with everybody. I guess that what you want to say is something such as: This document uses the SSH Transport Layer Protocol [RFC4253] with the exception that the statement "The client initiates the connection" made in Section 4 (Connection Setup) does not apply. Assuming the reference to client means "SSH client" and the reference to connection means "TCP connection", this statement doesn't hold true in call home, where the network element is the SSH server and yet still initiates the TCP connection. Security implications related to this change are discussed in Security Considerations (Section 4). And then you don't update RFC 4253. - draft-ietf-netconf-rfc5539bis is now RFC 7589 Regards, Benoit Dear Netconf WG, we had so far only one review and one support statement on the Call Home dr= aft. A thorough review is necessary before we can decide on the next steps. With this mail I would like to extend the WGLC deadline until July 10, 2015= EOB PT. Please review the Call Home draft and provide your comments to Netconf mail= list. Please state as a minimum whether you support to publish the document. Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mahesh Jet= hanandani Sent: Friday, June 26, 2015 7:21 AM To: Netconf Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 Dear NETCONF participants, This e-mail is a notification to start a NETCONF WG Last Call for the docum= ent "NETCONF Call Home and RESTCONF Call Home". The document can be found at: draft-ietf-netconf-call-home-07. Please review the document, provide comments, and indicate your support for= the draft by Friday July 3 (your timezone). The comments can be in the for= m of: ? "I have reviewed the I-D Blah and I have found issues with it" ? "I have reviewed I-D Blah and I found no issues" Simultaneously, the author on this draft should state to the mailing list w= hether there is any IPR associated with this draft or not. Thanks Mahesh and Mehmet (Co-chairs, NETCONF WG) _______________________________________________ Netconf mailing list Netconf@ietf.orghttps://www.ietf.org/mailman/listi= nfo/netconf --_000_D1C99104BC9B6kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Mehmet,

Indeed, and I can post the update on or about Sunday, when the submiss= ions are allowed again.

Cheers,
Kent

From: <Ersue>, "Mehmet (= Nokia - DE/Munich)" <mehm= et.ersue@nokia.com>
Date: Saturday, July 11, 2015 at 7:= 03 AM
To: Kent Watsen <kwatsen@juniper.net>, "netconf@ietf.org" <netconf@ietf.org>
Cc: Benoit Claise <bclaise@cisco.com>
Subject: RE: [Netconf] Extended dea= dline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-07

= Hi Kent,

=  

= it looks the WGLC was successful.

=  

= I think once the draft update is available we can start the = IESG publication machinery.

=  

= Mehmet

=  

From:<= /span> ext Kent Watsen [mailto:kwatsen@juniper= .net]
Sent: Friday, July 10, 2015 = 11:35 PM
To: Benoit Claise; Ersue, Me= hmet (Nokia - DE/Munich); netconf@ietf.org
Cc: 'Barry Leiba'
Subject: Re: [Netconf] Exten= ded deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-= 07

 

 

Hi Benoit,

 

Thank you for your review.   I agree that this draft does n= ot truly update RFC4253, and I like your suggested text.  I will put the needed changes into the next update to the draft. &nb= sp; And I'll also replace-all draft-ietf-netconf-rfc5539bis with RFC75= 89.

=  

Thanks again,<= /o:p>

Kent

 

From: B= enoit Claise <bclaise@cisco.com= >
Date: Tuesday, July 7, 2015 = at 12:27 PM
To: "Ersue, Mehmet (Nok= ia - DE/Munich)" <mehmet.= ersue@nokia.com>, "netconf@= ietf.org" <netconf@ietf.org= >
Cc: 'Barry Leiba' <barryleiba@computer.org>
Subject: Re: [Netconf] Exten= ded deadline July 10 WAS:FW: WG Last Call for draft-ietf-netconf-call-home-= 07

 

Dear authors,= 

-

1.4.&nb= sp; Update to RFC 4253

 
   =
This document updates the SSH Transport Layer Protocol [RFC4253] only

   =
in removing the statement "The client initiates the connection&=
quot; made


   =
in Section 4 (Connection Setup).  Assuming the reference to client


   =
means "SSH client" and the reference to connection means &=
quot;TCP


   =
connection", this statement doesn't hold true in call home, whe=
re the


   =
network element is the SSH server and yet still initiates the TCP


   =
connection.  Security i=
mplications related to this change are


   =
discussed in Security Considerations (Section 4).


 


>From idnits:

 


 


  Checking nits according to http://www.ietf.org/id-info/checklist :

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


 


  -- The draft header indicates that this document updates RFC4253, but the<=
o:p>


  &=
nbsp;  abstract doesn't seem to mention this, which it should.<=
o:p>


  Miscellaneous warnings:


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


 


  &=
nbsp;  (Using the creation date from RFC4253, updated by this d=
ocument, for


  &=
nbsp;  RFC5378 checks: 2005-03-16)

 


  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may


  &=
nbsp;  have content which was first submitted before 10 Novembe=
r 2008.  If you


  &=
nbsp;  have contacted all the original authors and they are all=
 willing to grant


  &=
nbsp;  the BCP78 rights to the IETF Trust, then this is fine, a=
nd you can ignore


  &=
nbsp;  this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 


  &=
nbsp;  (See the Legal Provisions document at


  &=
nbsp;  http://=
trustee.ietf.org/license-info for more information.)<=
/font>


 


 


All of the above is around the
RFC 4253 update ... but=
 actually, do you update
RFC 4253?

If you update it (remove "The client initiates the connection"), =
then this is for all SSH users, and we should check with everybody.

I guess that what you want to say is something such as: <=
/font>


  &=
nbsp;This document uses the SSH Transport Layer Protocol [RFC4253] with the 


  &=
nbsp;exception that the statement "The client initiates the con=
nection" made


   =
in Section 4 (Connection Setup) does not apply.  Assuming the reference 


  &=
nbsp;to client means "SSH client" and the reference to con=
nection means "TCP


   =
connection", this statement doesn't hold true in call home, whe=
re the


   =
network element is the SSH server and yet still initiates the TCP


   =
connection.  Security i=
mplications related to this change are


   =
discussed in Security Considerations (Section 4).


And then you don't update RFC 4253.

 

- draft-ietf-netconf-rfc5539bis is now RFC 7589 



Regards, Benoit

= Dear Netconf WG,

=  

= we had so far only one review and one support statement on t= he Call Home draft.

= A thorough review is necessary before we can decide on the n= ext steps.<= o:p>

=  

= With this mail I would like to extend the WGLC deadline unti= l July 10, 2015 EOB PT.

=  

= Please review the Call Home draft and provide your comments = to Netconf maillist.

= Please state as a minimum whether you support to publish the= document.<= o:p>

=  

= Mehmet =

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Mahesh Jeth= anandani
Sent: Friday, June 26, 2015 = 7:21 AM
To: Netconf
Subject: [Netconf] WG Last C= all for draft-ietf-netconf-call-home-07=

 =

Dear NETCONF participants,

This e-mail is a notification to start a NETCONF WG Last Call for the docum= ent "NETCONF Call Home and RESTCONF Call Home”.


The document can be found at: draft-ietf-netconf-call-home-07.=

 

Please review the document, provide comments, a= nd indicate your support for the draft by Friday July 3 (your timezone). The comments can be in the form of:

 

<= span style=3D"font-size: 10pt; color: black;">?     &= nbsp;   “I have reviewed the I-D Blah and I have found issues with it”=

<= span style=3D"font-size: 10pt; color: black;">?     &= nbsp;   “I have reviewed I-D Blah and I found no issues”

 

Simultaneously, the author on this draft should= state to the mailing list whether there is any IPR associated with this draft or not.

 

Thanks


Mahesh and Mehmet

(Co-chairs, NETCONF WG)

 <= /p>

 

 




______________________________________________=
_
Netconf mailing list<=
/pre>

Netconf@ie=
tf.orghttps:/=
/www.ietf.org/mailman/listinfo/netconf

 

 --_000_D1C99104BC9B6kwatsenjunipernet_-- From nobody Fri Jul 17 14:31:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF741A882E for ; Fri, 17 Jul 2015 14:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 L-EHolBNCS6T for ; Fri, 17 Jul 2015 14:31:08 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 8D7BB1A6FF6 for ; Fri, 17 Jul 2015 14:31:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t6HLV55M024472 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Jul 2015 21:31:05 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t6HLV4vM012076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 Jul 2015 23:31:05 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 17 Jul 2015 23:31:04 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.121]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0248.002; Fri, 17 Jul 2015 23:31:04 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability Thread-Index: AQHQudOm8aTyeFJzmk2n4E2UNNVX8p3gOd/g Date: Fri, 17 Jul 2015 21:31:03 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5CA8CC30@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81973F032DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 70702 X-purgate-ID: 151667::1437168665-000076F8-38FD2EDB/0/0 Archived-At: Subject: Re: [Netconf] Opinion poll for the support of draft-mm-netconf-time-capability X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 21:31:11 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81973F032DEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBOZXRjb25mIFdHLA0KDQphcyBmYXIgYXMgdGhlIGNvLWNoYWlycyBjYW4gc2VlLCB0aGVy ZSB3YXMgbm8gc3VmZmljaWVudCBzdXBwb3J0IHRvIGVuYWJsZSB0aGUNCmFkb3B0aW9uIG9mIGRy YWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5IGFzIFdHIGl0ZW0uDQoNCldlIGhhdmUgc2Vl biBzdXBwb3J0IGZyb20gb25lIHBlcnNvbiBvbiB0aGUgbWFpbGluZyBsaXN0LCBidXQgYXQgdGhl IHNhbWUNCnRpbWUgdGhlcmUgd2VyZSBwbGVudHkgb2YgY2hhbGxlbmdpbmcgcXVlc3Rpb25zIGZy b20gZGlmZmVyZW50IFdHIG1lbWJlci4NCg0KTWVobWV0DQoNCkZyb206IGV4dCBBbmR5IEJpZXJt YW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAwOSwg MjAxNSAxOjEzIEFNDQpUbzogRXJzdWUsIE1laG1ldCAoTm9raWEgLSBERS9NdW5pY2gpDQpDYzog ZXh0IFJvbWFzY2FudSwgRGFuIChEYW4pOyBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W05ldGNvbmZdIE9waW5pb24gcG9sbCBmb3IgdGhlIHN1cHBvcnQgb2YgZHJhZnQtbW0tbmV0Y29u Zi10aW1lLWNhcGFiaWxpdHkNCg0KDQoNCk9uIFdlZCwgSnVsIDgsIDIwMTUgYXQgMTI6MDAgUE0s IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5j b20+PiB3cm90ZToNCkhpLA0KDQpUaGUgZHJhZnQgZG9lcyBub3Qgc2F5IHdoYXQgaGFwcGVucyBp ZiB0aGUgc2Vzc2lvbiB0aGF0IHJlcXVlc3RzIHRoZQ0Kc2NoZWR1bGVkIFJGQyBpcyBkcm9wcGVk LiAgQXJlIHRoZSBzY2hlZHVsZWQgdGFza3MgZHJvcHBlZD8NCklmIG5vdCwgaG93IGRvZXMgdGhl IHNlcnZlciBzZW5kIHRoZSAicmVhbCIgcmVwbHk/DQoNCkNsaWVudHMgYXJlIGRlc2lnbmVkIHNv IHRoYXQgYSByZXF1ZXN0IGlzIGNvbXBsZXRlZCB3aGVuIHRoZQ0KcmVzcG9uc2Ugd2l0aCB0aGUg cHJvcGVyIG1lc3NhZ2UtaWQgaXMgcmVjZWl2ZWQuDQoNCiAgIDxycGMgbWVzc2FnZS1pZD0iMSI+ DQogICAgICA8Z2V0ICBzY2hlZHVsZT01LWRheXMtZnJvbS1ub3cgLz4NCiAgIDwvcnBjPg0KDQog ICA8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEiPjxvay8+PHJwYy1yZXBseT4gICA+Pj4gc2VudCBp bW1lZGlhdGVseQ0KDQogIDxycGMtcmVwbHkgbWVzc2FnZS1pZD0iMSI+DQogICAgPGRhdGE+IC4u Li4gPC9kYXRhPg0KICA8cnBjLXJlcGx5PiAgID4+PiBzZW50IDUgZGF5cyBmcm9tIG5vdw0KDQpU aGlzIGJyZWFrcyB0aGUgTkVUQ09ORiBkZXNpZ24gd2hpY2ggZXhwZWN0cyB0aGF0IG9ubHkNCm9u ZSA8cnBjLXJlcGx5PiBpcyBzZW50IGZvciBlYWNoIDxycGM+IHJlcXVlc3QuDQoNCg0KSSBtaXNy ZWFkIHRoZSBsYXRlc3QgdmVyc2lvbi4NClRoZSBvcmlnaW5hbCA8Z2V0PiB3aWxsIG5vdCBoYXZl IGFuIGltbWVkaWF0ZSByZXNwb25zZS4NCkluc3RlYWQgYSBub3RpZmljYXRpb24gaXMgc2VudCBp bmRpY2F0aW5nIHRoZSBSUEMgd2FzIHNjaGVkdWxlZC4NCk9ubHkgMSBycGMtcmVwbHkgaXMgc2Vu dCBhdCB0aGUgZW5kLg0KDQoNCg0KQW5keQ0KDQoNCkFuZHkNCg0KDQoNCg0KDQpPbiBXZWQsIEp1 bCA4LCAyMDE1IGF0IDk6NTUgQU0sIEVyc3VlLCBNZWhtZXQgKE5va2lhIC0gREUvTXVuaWNoKSA8 bWVobWV0LmVyc3VlQG5va2lhLmNvbTxtYWlsdG86bWVobWV0LmVyc3VlQG5va2lhLmNvbT4+IHdy b3RlOg0KVGhhbmtzIERhbiENCg0KT3RoZXJzIHBsZWFzZSBjb21tZW50IG5vIGxhdGVyIHRoYW4g SnVseSAxNXRoIGluZGljYXRpbmcgeW91ciBzdXBwb3J0IG9yIG5vbi1zdXBwb3J0Lg0KDQpDaGVl cnMsDQpNZWhtZXQNCg0KRnJvbTogZXh0IFJvbWFzY2FudSwgRGFuIChEYW4pIFttYWlsdG86ZHJv bWFzY2FAYXZheWEuY29tPG1haWx0bzpkcm9tYXNjYUBhdmF5YS5jb20+XQ0KU2VudDogV2VkbmVz ZGF5LCBKdWx5IDA4LCAyMDE1IDEwOjU0IEFNDQpUbzogRXJzdWUsIE1laG1ldCAoTm9raWEgLSBE RS9NdW5pY2gpOyBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3Vi amVjdDogUkU6IFtOZXRjb25mXSBPcGluaW9uIHBvbGwgZm9yIHRoZSBzdXBwb3J0IG9mIGRyYWZ0 LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5DQoNCkhpLA0KDQpJIHdhcyBvbmUgb2YgdGhlIGlu ZGl2aWR1YWxzIHdobyBjb21tZW50ZWQgYXQgdGhlIElFVEYgTEMgdGhhdCB0aGlzIHdvcmsgc2Vl bXMgdG8gYmUgdXNlZnVsIGFuZCBzZWVtcyB0byBiZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBO ZXRjb25mIFdHLiBUaGVyZSB3ZXJlIGRpc2N1c3Npb25zIHdoZXRoZXIgdGhlIHNvbHV0aW9uIHBy b3Bvc2VkIGluIGRyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5IGlzIOKAmHRoZSByaWdo dCBhcHByb2FjaOKAmSwgYW5kIGFsc28gcXVlc3Rpb25zIGFib3V0IGV4dGVuZGluZyB0aGlzIHNv bHV0aW9uIHRvIFJlc3Rjb25mLg0KDQpSZWdhcmRzLA0KDQpEYW4NCg0KDQpGcm9tOiBOZXRjb25m IFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJzdWUsIE1l aG1ldCAoTm9raWEgLSBERS9NdW5pY2gpDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDgsIDIwMTUg MTowNSBBTQ0KVG86IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbTmV0Y29uZl0gT3BpbmlvbiBwb2xsIGZvciB0aGUgc3VwcG9ydCBvZiBkcmFmdC1t bS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eQ0KDQpEZWFyIE5FVENPTkYgV0csDQoNCmRyYWZ0LW1t LW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5IGhhcyBiZWVuIGRpc2N1c3NlZCBpbiBOZXRjb25mIFdH IGluIGRpZmZlcmVudCBJRVRGIG1lZXRpbmdzLiBUaGVyZSB3YXMgb25seSBjYXV0aW91cyBzdXBw b3J0Lg0KQXMgcmVjZW50bHkgdGhlIGF1dGhvcnMgYXNrZWQgZm9yIHN1cHBvcnQgb24gdGhlIG1h aWxsaXN0IG5vIHNpbmdsZSBwZXJzb24gc3Bva2UgZm9yIHRoaXMgZHJhZnQuDQoNCkhvd2V2ZXIs IGFmdGVyIHRoZSBkcmFmdCBoYXMgYmVlbiBicm91Z2h0IHRvIElFVEYgTEMgYXMgQUQgc3VwcG9y dGVkIGRyYWZ0LCB0aGVyZSB3ZXJlIGRpdmVyc2UgcGVvcGxlIHN1cHBvcnRpbmcgc3Ryb25nbHkg YW5kIHByb3Bvc2VkIHRvIHB1Ymxpc2ggdGhlIGRvY3VtZW50IGluIE5FVENPTkYgV0cuDQoNCkp1 c3QgdG8gYmUgc3VyZSB3ZSBkZXZlbG9wIHRoZSByaWdodCBkb2N1bWVudHMgaW4gTmV0Y29uZiBX Rywgd2Ugd291bGQgbGlrZSB0byBhc2sgdGhlIHNhbWUgcXVlc3Rpb24gYWdhaW4uDQpCYXNlZCBv biB0aGUgc3VwcG9ydCBvbiBOZXRjb25mIG1haWxsaXN0IGRyYWZ0LW1tLW5ldGNvbmYtdGltZS1j YXBhYmlsaXR5IG1heSBiZSBhZG9wdGVkIGFzIGEgbmV3IFdHIGl0ZW0uDQoNCg0KLSBJZiBhbnli b2R5IHRoaW5rcyBkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eSBkb2VzIGZpdCB0aGUg Zm9jdXMgb2YgTmV0Y29uZiBXRyBhbmQgc2hvdWxkIGJlIGRldmVsb3BlZCBhcyBOZXRjb25mIFdH IGl0ZW0gcGxlYXNlIHN0YXRlIHlvdXIgb3BpbmlvbiBvbiB0aGUgbWFpbGxpc3Qgd2l0aGluIG9u ZSB3ZWVrIChKdWx5IDE1LCAyMDE1IEVPQiBQVCkuDQoNCi0gSWYgYW55Ym9keSB0aGlua3MgdGhh dCB0aGlzIGlzIG5vdCB0aGUgcmlnaHQgYXBwcm9hY2ggdG8gZGV2ZWxvcCBpbiBOZXRjb25mIFdH IHBsZWFzZSBzdGF0ZSBpdCBhcyB3ZWxsLg0KDQotIFdlIGFsc28gd291bGQgbGlrZSB0byBrbm93 IHdoZXRoZXIgYW55Ym9keSBkaWQgb3IgaXMgcGxhbm5pbmcgdG8gaW1wbGVtZW50IGRyYWZ0LW1t LW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5Lg0KDQpCZXN0IFJlZ2FyZHMsDQpNZWhtZXQgRXJzdWUN Ck5ldGNvbmYgV0cgQ28tY2hhaXINCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9y ZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZg0KDQoNCg== --_000_E4DE949E6CE3E34993A2FF8AE79131F81973F032DEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJQcm9nSWQiIGNvbnRlbnQ9 IldvcmQuRG9jdW1lbnQiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3Nv ZnQgV29yZCAxMiI+DQo8bWV0YSBuYW1lPSJPcmlnaW5hdG9yIiBjb250ZW50PSJNaWNyb3NvZnQg V29yZCAxMiI+DQo8bGluayByZWw9IkZpbGUtTGlzdCIgaHJlZj0iY2lkOmZpbGVsaXN0LnhtbEAw MUQwQzBFOC5BM0FDNTQzMCI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpPZmZpY2VEb2N1 bWVudFNldHRpbmdzPg0KPG86QWxsb3dQTkcvPg0KPG86RG9Ob3RSZWx5T25DU1MvPg0KPG86VGFy Z2V0U2NyZWVuU2l6ZT4xMDI0eDc2ODwvbzpUYXJnZXRTY3JlZW5TaXplPg0KPC9vOk9mZmljZURv Y3VtZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjx3OldvcmREb2N1bWVudD4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdT dGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3Bl VmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5m YWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93 Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8 L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3Okxp ZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WC1O T05FPC93OkxpZFRoZW1lQXNpYW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93 OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpEb05vdEV4cGFu ZFNoaWZ0UmV0dXJuLz4NCjx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTcGxpdFBnQnJlYWtB bmRQYXJhTWFyay8+DQo8dzpEb250VmVydEFsaWduQ2VsbFdpdGhTcC8+DQo8dzpEb250QnJlYWtD b25zdHJhaW5lZEZvcmNlZFRhYmxlcy8+DQo8dzpEb250VmVydEFsaWduSW5UeGJ4Lz4NCjx3Oldv cmQxMUtlcm5pbmdQYWlycy8+DQo8dzpDYWNoZWRDb2xCYWxhbmNlLz4NCjwvdzpDb21wYXRpYmls aXR5Pg0KPHc6QnJvd3NlckxldmVsPk1pY3Jvc29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dz ZXJMZXZlbD4NCjxtOm1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4N CjxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIv Pg0KPG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBt OnZhbD0iMCIvPg0KPG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRl ckdyb3VwIi8+DQo8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9 InN1YlN1cCIvPg0KPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpX b3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N Cjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBEZWZTZW1pSGlkZGVuPSJ0cnVlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3Jp dHk9Ijk5IiBMYXRlbnRTdHlsZUNvdW50PSIyNjciPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgTmFtZT0idG9jIDkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTAiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRpdGxlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIE5hbWU9IkRlZmF1bHQgUGFy YWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MTEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjIyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjU5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNpbmci Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkRhcmsgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i UmV2aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzQi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBT aGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFj Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlz dCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGlu ZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBB Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEg QWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBH cmlkIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkRhcmsgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJ bnRlbnNlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjMxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgTmFtZT0iQmli bGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KPC93OkxhdGVudFN0eWxlcz4N CjwveG1sPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJDYWxpc3RvIE1UIjsNCgltc28tZm9udC1j aGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtcGl0 Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTEwNzMwNTcyNyAw IDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWFsdDoiQXJpYWwgUm91bmRlZCBNVCBC b2xkIjsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dp c3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4 NzAxNDUgMTA3Mzc4NjExMSAxIDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtYWx0OkFy aWFsOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lz czsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA4 MTY2NSAtMTA3MzcxNzE1NyA0MSAwIDY2MDQ3IDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxlLXVu aGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3 aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l Ow0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5k ZXJsaW5lOnNpbmdsZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxl LXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28t YXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjojMDAw MENDO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJbXNvLWFuc2ktZm9udC1zaXplOjguMHB0Ow0KCW1z by1iaWRpLWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OlRhaG9tYTsNCgltc28taGFuc2ktZm9udC1mYW1p bHk6VGFob21hOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OlRhaG9tYTt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZGVmYXVsdC1wcm9wczp5ZXM7 DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDsN Cgltc28taGVhZGVyLW1hcmdpbjozNi4wcHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzYuMHB0Ow0K CW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJs ZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xi YW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNv LXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBjbTsN Cgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ct b3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9u dC1mYW1pbHk6Q2FsaWJyaTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRhYi1pbnRlcnZhbDozNi4wcHQi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7O2NvbG9yOiMwMDAwQ0MiPkRlYXIgTmV0Y29uZiBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAw Y2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYmlkaS1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzAwMDBDQyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPmFzIGZhciBhcyB0aGUgY28tY2hhaXJzIGNhbiBzZWUsIHRo ZXJlIHdhcyBubyBzdWZmaWNpZW50IHN1cHBvcnQgdG8gZW5hYmxlDQogdGhlIDxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjoj MDAwMENDIj5hZG9wdGlvbiBvZiBkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eSBhcyBX RyBpdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90Oztjb2xvcjojMDAwMENDIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwY2Mi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYmlkaS1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzAwMDBDQyI+V2UgaGF2 ZSBzZWVuIHN1cHBvcnQgZnJvbSBvbmUgcGVyc29uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGJ1dCBh dCB0aGUgc2FtZQ0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPnRpbWUgdGhlcmUgd2VyZSBwbGVudHkgb2Yg Y2hhbGxlbmdpbmcgcXVlc3Rpb25zIGZyb20gZGlmZmVyZW50IFdHIG1lbWJlci4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xv cjojMDAwMENDIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmki PjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMDAwMENDO21zby1hbnNpLWxhbmd1YWdl OkRFO21zby1uby1wcm9vZjp5ZXMiPk1laG1ldA0KPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90Oztmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9i Pjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4NCiBl eHQgQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXSA8YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBUaHVyc2RheSwgSnVs eSAwOSwgMjAxNSAxOjEzIEFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlRvOjwvc3Bhbj48L2I+IEVyc3VlLCBNZWhtZXQgKE5va2lhIC0gREUvTXVuaWNoKTxicj4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiBleHQgUm9tYXNj YW51LCBEYW4gKERhbik7IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW05ldGNvbmZdIE9waW5pb24g cG9sbCBmb3IgdGhlIHN1cHBvcnQgb2YgZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHk8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5PbiBXZWQsIEp1bCA4LCAyMDE1IGF0IDEyOjAwIFBNLCBBbmR5IEJp ZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2Js YW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhpLDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoZSBkcmFmdCBkb2VzIG5v dCBzYXkgd2hhdCBoYXBwZW5zIGlmIHRoZSBzZXNzaW9uIHRoYXQgcmVxdWVzdHMgdGhlPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPnNjaGVkdWxlZCBSRkMgaXMgZHJvcHBlZC4mbmJzcDsgQXJlIHRoZSBz Y2hlZHVsZWQgdGFza3MgZHJvcHBlZD88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SWYgbm90LCBob3cg ZG9lcyB0aGUgc2VydmVyIHNlbmQgdGhlICZxdW90O3JlYWwmcXVvdDsgcmVwbHk/PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5DbGllbnRzIGFyZSBkZXNp Z25lZCBzbyB0aGF0IGEgcmVxdWVzdCBpcyBjb21wbGV0ZWQgd2hlbiB0aGU8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+cmVzcG9uc2Ugd2l0aCB0aGUgcHJvcGVyIG1lc3NhZ2UtaWQgaXMgcmVjZWl2ZWQu PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsg Jm5ic3A7Jmx0O3JwYyBtZXNzYWdlLWlkPSZxdW90OzEmcXVvdDsmZ3Q7PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtnZXQgJm5ic3A7c2NoZWR1bGU9NS1kYXlz LWZyb20tbm93IC8mZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyAmbmJzcDsmbHQ7L3Jw YyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZu YnNwOyAmbmJzcDsmbHQ7cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9JnF1b3Q7MSZxdW90OyZndDsmbHQ7 b2svJmd0OyZsdDtycGMtcmVwbHkmZ3Q7ICZuYnNwOyAmZ3Q7Jmd0OyZndDsgc2VudCBpbW1lZGlh dGVseTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5i c3A7ICZsdDtycGMtcmVwbHkgbWVzc2FnZS1pZD0mcXVvdDsxJnF1b3Q7Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mbmJzcDsgJm5ic3A7ICZsdDtkYXRhJmd0OyAuLi4uICZsdDsvZGF0YSZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7ICZsdDtycGMtcmVwbHkmZ3Q7ICZuYnNwOyAmZ3Q7 Jmd0OyZndDsgc2VudCA1IGRheXMgZnJvbSBub3c8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoaXMgYnJlYWtzIHRoZSBORVRDT05GIGRlc2lnbiB3aGlj aCBleHBlY3RzIHRoYXQgb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5vbmUgJmx0O3JwYy1yZXBs eSZndDsgaXMgc2VudCBmb3IgZWFjaCAmbHQ7cnBjJmd0OyByZXF1ZXN0LjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+SSBtaXNyZWFkIHRoZSBsYXRlc3QgdmVyc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+VGhlIG9yaWdpbmFsICZsdDtnZXQmZ3Q7IHdpbGwgbm90IGhhdmUgYW4gaW1tZWRp YXRlIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JbnN0ZWFkIGEgbm90aWZpY2F0aW9u IGlzIHNlbnQgaW5kaWNhdGluZyB0aGUgUlBDIHdhcyBzY2hlZHVsZWQuPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPk9ubHkgMSBycGMtcmVwbHkgaXMgc2VudCBhdCB0aGUgZW5kLjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7bXNvLWJvcmRlci1sZWZ0LWFsdDpzb2xpZCAj Q0NDQ0NDIC43NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BbmR5PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BbmR5PG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O21zby1ib3Jk ZXItbGVmdC1hbHQ6c29saWQgI0NDQ0NDQyAuNzVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9uIFdlZCwgSnVsIDgsIDIw MTUgYXQgOTo1NSBBTSwgRXJzdWUsIE1laG1ldCAoTm9raWEgLSBERS9NdW5pY2gpICZsdDs8YSBo cmVmPSJtYWlsdG86bWVobWV0LmVyc3VlQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1laG1l dC5lcnN1ZUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwMDBDQyI+VGhhbmtzIERhbiE8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0Mi PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+T3RoZXJzIHBsZWFzZSBjb21tZW50 IG5vIGxhdGVyIHRoYW4gSnVseSAxNTxzdXA+dGg8L3N1cD4NCiBpbmRpY2F0aW5nIHlvdXIgc3Vw cG9ydCBvciBub24tc3VwcG9ydC48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPiZuYnNwOzwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFu Zz0iREUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMENDO21zby1hbnNpLWxhbmd1 YWdlOkRFIj5DaGVlcnMsDQo8YnI+DQpNZWhtZXQgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDAwQ0MiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1vdXRsaW5l LWxldmVsOjEiPg0KPGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxm b250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBl eHQgUm9tYXNjYW51LCBEYW4gKERhbikNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkcm9tYXNj YUBhdmF5YS5jb20iIHRhcmdldD0iX2JsYW5rIj5kcm9tYXNjYUBhdmF5YS5jb208L2E+XQ0KPGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gV2Vk bmVzZGF5LCBKdWx5IDA4LCAyMDE1IDEwOjU0IEFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IEVyc3VlLCBNZWhtZXQgKE5va2lhIC0gREUvTXVu aWNoKTsNCjxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSRTogW05ldGNvbmZdIE9waW5pb24gcG9sbCBmb3IgdGhl IHN1cHBvcnQgb2YgZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHk8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSB3YXMgb25lIG9mIHRoZSBpbmRpdmlkdWFscyB3aG8gY29tbWVudGVkIGF0IHRoZSBJRVRGDQog TEMgdGhhdCB0aGlzIHdvcmsgc2VlbXMgdG8gYmUgdXNlZnVsIGFuZCBzZWVtcyB0byBiZSB3aXRo aW4gdGhlIHNjb3BlIG9mIHRoZSBOZXRjb25mIFdHLiBUaGVyZSB3ZXJlIGRpc2N1c3Npb25zIHdo ZXRoZXIgdGhlIHNvbHV0aW9uIHByb3Bvc2VkIGluIGRyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBh YmlsaXR5IGlzIOKAmHRoZSByaWdodCBhcHByb2FjaOKAmSwgYW5kIGFsc28gcXVlc3Rpb25zIGFi b3V0IGV4dGVuZGluZyB0aGlzIHNvbHV0aW9uIHRvIFJlc3Rjb25mLg0KPC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkRhbjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLW91dGxpbmUtbGV2ZWw6MSI+DQo8Yj48Zm9udCBzaXpl PSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2ZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21h Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5ldGNvbmYgWzxhIGhyZWY9Im1haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86bmV0Y29uZi1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5P biBCZWhhbGYgT2YgPC9zcGFuPjwvYj5FcnN1ZSwgTWVobWV0IChOb2tpYSAtIERFL011bmljaCk8 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBX ZWRuZXNkYXksIEp1bHkgMDgsIDIwMTUgMTowNSBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiA8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBbTmV0Y29uZl0g T3BpbmlvbiBwb2xsIGZvciB0aGUgc3VwcG9ydCBvZiBkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2Fw YWJpbGl0eTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDAwMENDIj5EZWFyIE5FVENPTkYgV0csPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDoz Ni4wcHQiPg0KPGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMENDIj4mbmJzcDs8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPmRyYWZ0LW1tLW5ldGNvbmYtdGltZS1j YXBhYmlsaXR5IGhhcyBiZWVuIGRpc2N1c3NlZA0KIGluIE5ldGNvbmYgV0cgaW4gZGlmZmVyZW50 IElFVEYgbWVldGluZ3MuIFRoZXJlIHdhcyBvbmx5IGNhdXRpb3VzIHN1cHBvcnQuIDwvc3Bhbj4N CjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMENDIj5BcyByZWNlbnRseSB0aGUgYXV0 aG9ycyBhc2tlZCBmb3Igc3VwcG9ydCBvbiB0aGUgbWFpbGxpc3QNCiBubyBzaW5nbGUgcGVyc29u IHNwb2tlIGZvciB0aGlzIGRyYWZ0Ljwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwY2Mi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMEND Ij5Ib3dldmVyLCBhZnRlciB0aGUgZHJhZnQgaGFzIGJlZW4gYnJvdWdodCB0byBJRVRGIExDDQog YXMgQUQgc3VwcG9ydGVkIGRyYWZ0LCB0aGVyZSB3ZXJlIGRpdmVyc2UgcGVvcGxlIHN1cHBvcnRp bmcgc3Ryb25nbHkgYW5kIHByb3Bvc2VkIHRvIHB1Ymxpc2ggdGhlIGRvY3VtZW50IGluIE5FVENP TkYgV0cuDQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+SnVzdCB0byBiZSBz dXJlIHdlIGRldmVsb3AgdGhlIHJpZ2h0IGRvY3VtZW50cyBpbiBOZXRjb25mDQogV0csIHdlIHdv dWxkIGxpa2UgdG8gYXNrIHRoZSBzYW1lIHF1ZXN0aW9uIGFnYWluLjwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+QmFzZWQgb24gdGhlIHN1cHBvcnQgb24gTmV0Y29u ZiBtYWlsbGlzdCBkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eQ0KIG1heSBiZSBhZG9w dGVkIGFzIGEgbmV3IFdHIGl0ZW0uPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMw MDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDAwMENDIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0Mi PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+LSBJZiBh bnlib2R5IHRoaW5rcyBkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eQ0KIGRvZXMgZml0 IHRoZSBmb2N1cyBvZiBOZXRjb25mIFdHIGFuZCBzaG91bGQgYmUgZGV2ZWxvcGVkIGFzIE5ldGNv bmYgV0cgaXRlbSBwbGVhc2Ugc3RhdGUgeW91ciBvcGluaW9uIG9uIHRoZSBtYWlsbGlzdCB3aXRo aW4gb25lIHdlZWsgKEp1bHkgMTUsIDIwMTUgRU9CIFBUKS48L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwMDBDQyI+LSBJZiBhbnlib2R5IHRoaW5rcyB0aGF0IHRoaXMgaXMgbm90IHRoZSBy aWdodCBhcHByb2FjaA0KIHRvIGRldmVsb3AgaW4gTmV0Y29uZiBXRyBwbGVhc2Ugc3RhdGUgaXQg YXMgd2VsbC48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+LSBXZSBhbHNvIHdv dWxkIGxpa2UgdG8ga25vdyB3aGV0aGVyIGFueWJvZHkgZGlkIG9yDQogaXMgcGxhbm5pbmcgdG8g aW1wbGVtZW50IGRyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5Ljwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMDAwMENDIj5CZXN0IFJlZ2FyZHMsDQo8YnI+DQpNZWhtZXQgRXJzdWU8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPk5ldGNvbmYgV0cgQ28t Y2hhaXI8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E4DE949E6CE3E34993A2FF8AE79131F81973F032DEMUMBX005nsnin_-- From nobody Tue Jul 21 01:20:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FCF1B2A09; Tue, 21 Jul 2015 01:20:03 -0700 (PDT) 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 VvintKJpVInA; Tue, 21 Jul 2015 01:20:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB7C1B29FF; Tue, 21 Jul 2015 01:20:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150721082002.9901.68808.idtracker@ietfa.amsl.com> Date: Tue, 21 Jul 2015 01:20:02 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 08:20:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-09.txt Pages : 13 Date : 2015-07-21 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 21 01:25:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6041C1B2A36; Tue, 21 Jul 2015 01:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tasIoHNDRNXl; Tue, 21 Jul 2015 01:25:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C604A1B2A89; Tue, 21 Jul 2015 01:25:21 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.219.17; Tue, 21 Jul 2015 08:25:02 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.137]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.137]) with mapi id 15.01.0219.018; Tue, 21 Jul 2015 08:25:01 +0000 From: Kent Watsen To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-09.txt Thread-Index: AQHQw44TKezkyD7m2UuI0FIaDbOQuZ3lt+AA Date: Tue, 21 Jul 2015 08:25:01 +0000 Message-ID: References: <20150721082002.9901.68808.idtracker@ietfa.amsl.com> In-Reply-To: <20150721082002.9901.68808.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.16] x-microsoft-exchange-diagnostics: 1; BN1PR05MB453; 5:aiE5g4Dm4mMshbMjQAQqz6GDF9MStZmDjOVgd73VFDYPEFv1uePsG/k7iYTb38dRJrn/j0tfEvP3HlSwki6hmRlCPhLrxf1qdYfE1snN0TCgV8N4wjoeaz6PUTKx4oK1+kHMZzA3faav1HjpbrBU8A==; 24:q8mBc7GBCYY4nucuRWrjgMJ0qIiPuzotE3EhQbL99eSJDpton3W+TX67HUChrCIl4C4tznK36Q0eH6eMIu4YcYX49pC48JAjl8SvR10/etM=; 20:0szWifj/MvOJf/9/oKxF9AG8ZCdywyi7g+MdIJNBUJkENV40DMZylwYiQ5QPG3cTL5HT2yaTOQLcMCMvpXmbNg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453; bn1pr05mb453: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(24454002)(479174004)(377454003)(377424004)(19580405001)(5002640100001)(36756003)(106116001)(5001960100002)(122556002)(19580395003)(40100003)(189998001)(66066001)(99286002)(2501003)(230783001)(5001920100001)(4001350100001)(92566002)(2900100001)(76176999)(5001770100001)(54356999)(50986999)(15975445007)(2656002)(46102003)(102836002)(450100001)(2950100001)(86362001)(87936001)(62966003)(77156002)(83506001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2015 08:25:01.9146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 08:25:36 -0000 Changes in this update include: o Added dynamic DNS as an example for an IP mapping service o Replaced draft-ietf-netconf-rfc5539bis with RFC7589 o Recharacterized this draft's relationship to RFC4253 Cheers, Kent On 7/21/15, 10:20 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 Network Configuration Working Group of >the IETF. > > Title : NETCONF Call Home and RESTCONF Call Home > Author : Kent Watsen > Filename : draft-ietf-netconf-call-home-09.txt > Pages : 13 > Date : 2015-07-21 > >Abstract: > This RFC presents NETCONF Call Home and RESTCONF Call Home, which > enable a NETCONF or RESTCONF server to initiate a secure connection > to a NETCONF or RESTCONF client respectively. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-netconf-call-home-09 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-call-home-09 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 22 05:48:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540DD1B32D7 for ; Wed, 22 Jul 2015 05:48:04 -0700 (PDT) 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 euMafek7GfmR for ; Wed, 22 Jul 2015 05:48:02 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAE91B32C8 for ; Wed, 22 Jul 2015 05:48:02 -0700 (PDT) Received: from dhcp-b33f.meeting.ietf.org ([31.133.179.63]) by smtp-cloud2.xs4all.net with ESMTP id vQnx1q00N1NTpLX01Qo0Mk; Wed, 22 Jul 2015 14:48:00 +0200 Message-ID: <55AF90FD.1010305@bwijnen.net> Date: Wed, 22 Jul 2015 14:47:57 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Netconf References: <55AF8FBB.1080607@bwijnen.net> In-Reply-To: <55AF8FBB.1080607@bwijnen.net> X-Forwarded-Message-Id: <55AF8FBB.1080607@bwijnen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] bar-bof meeting on IBNEMO Thursday 20:00 in Budapest (Mezzanine level) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:48:04 -0000 A second side-bar (bar-bof) meeting of IBNEMO (Intent Based NEtwork MOdeling) meeting will occur at 8pm (20:00) in the Budapest meeting room (mezzanine level). It also has discussions about the use of YANG, NETCONF and RESTCONF, so I figure it is relevant to these WGs. If you can attend, please do. There is a mailing list at ibnemo@ietf.org Bert From nobody Wed Jul 22 15:04:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ECC1B2F36 for ; Wed, 22 Jul 2015 15:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 j6nvQfqvUmGJ for ; Wed, 22 Jul 2015 15:04:47 -0700 (PDT) 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 4EF7B1B2F39 for ; Wed, 22 Jul 2015 15:04:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 27F9E1320 for ; Thu, 23 Jul 2015 00:04:43 +0200 (CEST) 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 dXIXgVkD8ypd for ; Thu, 23 Jul 2015 00:04:42 +0200 (CEST) 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, 23 Jul 2015 00:04:42 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A32022003A for ; Thu, 23 Jul 2015 00:04:45 +0200 (CEST) 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 L5LVBg5PwxEa; Thu, 23 Jul 2015 00:04:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E36C220039; Thu, 23 Jul 2015 00:04:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1632B35DDE06; Thu, 23 Jul 2015 00:04:42 +0200 (CEST) Date: Thu, 23 Jul 2015 00:04:42 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20150722220442.GA8338@elstar.local> Mail-Followup-To: netconf@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: [Netconf] restconf header nit in example in section 3.6 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 22:04:49 -0000 Hi, I think this example POST /restconf/operations/module-A:reset HTTP/1.1 Server example.com should have been POST /restconf/operations/module-A:reset HTTP/1.1 Host: example.com /js PS: Should error-info be defined to be anydata instead of anyxml so that a json encoded request also returns a json encoded errors grouping? -- 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 Jul 22 18:18:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C49B1A1A1E for ; Wed, 22 Jul 2015 18:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 l7U0yXn48WaH for ; Wed, 22 Jul 2015 18:18:09 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 2BC1F1A023E for ; Wed, 22 Jul 2015 18:18:09 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so147704003lbb.0 for ; Wed, 22 Jul 2015 18:18:07 -0700 (PDT) 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=GEWNVdecFN3O0tviw3aMWEeDFPMsgiZzdGc1bYk9/CY=; b=QSJPxiF3ysex7SYNK8RoGX+LJZsVTJsoClBMS0JbmDiSvCchdGXhxrDkHdWAwOmkbs Ch2qCF4AJgmM3d4w2QZ4ly0hn5+wu6PeOaJWrpjj1kw1RyLKZKmbB2Jt5zzlfuiuYnvE KDD0JHr9wwY53wjcGvDVBtxbJ56JPwmciyRZbG068APCmI5Xo8N9AQPjBCVr8cTWBy4s LS4rRI43YBV5LufX96yPUHdUNpwdK8RO+sAx3LnwsTsyzKga/3FoBy7AvgROSSArOtrW L1wC8Hzg+7wbIhiNX6mggqMBO978h/gZqqZczll9LF0bXzphpx9GRhOn7QnLPGjK1xhl 4GAw== X-Gm-Message-State: ALoCoQlTSoGZd48infhUOoL1bUCHbPqMJVtXmkKqZo7+9XTkXHsA9w8oWHB0q30PwaTWIu8SWRkY MIME-Version: 1.0 X-Received: by 10.152.87.205 with SMTP id ba13mr4855471lab.37.1437614287544; Wed, 22 Jul 2015 18:18:07 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 22 Jul 2015 18:18:07 -0700 (PDT) In-Reply-To: <20150722220442.GA8338@elstar.local> References: <20150722220442.GA8338@elstar.local> Date: Wed, 22 Jul 2015 18:18:07 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Netconf Content-Type: multipart/alternative; boundary=001a11c3539aef01c9051b80a8e4 Archived-At: Subject: Re: [Netconf] restconf header nit in example in section 3.6 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 01:18:11 -0000 --001a11c3539aef01c9051b80a8e4 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 3:04 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > I think this example > > POST /restconf/operations/module-A:reset HTTP/1.1 > Server example.com > > should have been > > POST /restconf/operations/module-A:reset HTTP/1.1 > Host: example.com > > OK > /js > > PS: Should error-info be defined to be anydata instead of anyxml so > that a json encoded request also returns a json encoded errors > grouping? > > good question that applies to all RESTCONF anyxml usage. I would say yes. Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c3539aef01c9051b80a8e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 22, 2015 at 3:04 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

I think this example

=C2=A0 =C2=A0 =C2=A0 POST /restconf/operations/module-A:reset HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 Server example.com

should have been

=C2=A0 =C2=A0 =C2=A0 POST /restconf/operations/module-A:reset HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 Host: example.com



OK

=
=C2=A0
/js

PS: Should error-info be defined to be anydata instead of anyxml so
=C2=A0 =C2=A0 that a json encoded request also returns a json encoded error= s
=C2=A0 =C2=A0 grouping?



good question that applies to all RES= TCONF anyxml usage.
I would say yes.

Andy

=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a11c3539aef01c9051b80a8e4-- From nobody Thu Jul 23 02:06:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F7B1A8992; Thu, 23 Jul 2015 02:05:58 -0700 (PDT) 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 rB3eV1qC3tTS; Thu, 23 Jul 2015 02:05:57 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BF51A886D; Thu, 23 Jul 2015 02:05:57 -0700 (PDT) Received: from dhcp-b33f.meeting.ietf.org ([31.133.179.63]) by smtp-cloud6.xs4all.net with ESMTP id vl5s1q00Q1NTpLX01l5v92; Thu, 23 Jul 2015 11:05:56 +0200 Message-ID: <55B0AE71.8050203@bwijnen.net> Date: Thu, 23 Jul 2015 11:05:53 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: NETMOD Working Group , Netconf References: <55AF8FBB.1080607@bwijnen.net> <55AF90FD.1010305@bwijnen.net> In-Reply-To: <55AF90FD.1010305@bwijnen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] Correction: bar-bof meeting on IBNEMO Thursday 20:00 in Budapest (LOBBY level) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 09:05:59 -0000 My apologies, the Budapest room is NOT at the Mezzanine level, but at the LOBBY level. Bert On 22/07/15 14:47, Bert Wijnen (IETF) wrote: > A second side-bar (bar-bof) meeting of IBNEMO (Intent Based NEtwork MOdeling) meeting > will occur at 8pm (20:00) in the Budapest meeting room (mezzanine level). > > It also has discussions about the use of YANG, NETCONF and RESTCONF, > so I figure it is relevant to these WGs. > > If you can attend, please do. > > There is a mailing list at ibnemo@ietf.org > > Bert > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Jul 23 05:04:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCE31A9166 for ; Thu, 23 Jul 2015 05:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65GaVfZS5bgL for ; Thu, 23 Jul 2015 05:04:52 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CD3901A9250 for ; Thu, 23 Jul 2015 05:04:52 -0700 (PDT) Received: from [172.29.64.71] (jplon-nat11.juniper.net [193.110.55.11]) by slice.pfrc.org (Postfix) with ESMTPSA id 166101E373; Thu, 23 Jul 2015 08:06:55 -0400 (EDT) From: Jeffrey Haas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jul 2015 14:04:50 +0200 To: netconf@ietf.org Message-Id: <3A9517A1-F43E-43F6-9CDC-F51C6530145F@pfrc.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [Netconf] yang library issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:04:54 -0000 The comment I was unable to make at the mic is that work ongoing in IETF = to structure yang modules is potentially proceeding with a fallacy. = That fallacy is that the location of a module is effectively "known = ahead of time". Thus, if your device supports BGP, you will potentially = have a routing/ietf-bgp module. The presence of modules is conveyed in the protocol HELLO. The use of the library to help provide a manifest of actual = implementations seems quite important. I am endeavoring to help the = participants of the rtg-yang-architecture group and also members of = openconfig that they should not depend location of a module and = consequences if they do. -- Jeff From nobody Thu Jul 23 05:12:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0891A92F8 for ; Thu, 23 Jul 2015 05:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ama62BLgyldR for ; Thu, 23 Jul 2015 05:12:36 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 3DF8E1A0BE8 for ; Thu, 23 Jul 2015 05:12:36 -0700 (PDT) Received: by lblf12 with SMTP id f12so156115750lbl.2 for ; Thu, 23 Jul 2015 05:12:34 -0700 (PDT) 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=FRTd9gnjuvAgn9jJ4yWPQZy2QPdwx8Tm26Nm8te4T00=; b=RsDON3FEQ7REr2k252P8WvIOs/6GxSunQKI1SJV00px21OCojgdgsmne5n0S36xri5 61nFlSrpvts37Smp0wnonvsw+zswmmKy0aX3bSHEQkkCbcyDPmuSxIoagCahcgHrpJY/ duK4Jcxybokbia6FMJBwuIr45u1FQP5Oc5IlZ5zFwFEIuAx/1CZuSkQXCTB0JrsOMOLm FrE8hk2BPDmdL2MKCHwb3DcIGj0QHVsfgDogjpg9anAgrRR+PYDUN9DIP4QhH2sHvHGV m7mbtZngl167FnuJoOsg6DuemToDbXRj6VeCb3I/ej0kUP+IvSccTxuAUSa90NCTH0Bq d9XQ== X-Gm-Message-State: ALoCoQkUKZ/sza0Gy3iek4cbWfoRiOQx5+ZIBdzWGE3WVlRAqyBf/CRPDss72bpQ1ur+CxVx2vvX MIME-Version: 1.0 X-Received: by 10.112.125.166 with SMTP id mr6mr7544328lbb.83.1437653554624; Thu, 23 Jul 2015 05:12:34 -0700 (PDT) Received: by 10.112.3.73 with HTTP; Thu, 23 Jul 2015 05:12:34 -0700 (PDT) In-Reply-To: <3A9517A1-F43E-43F6-9CDC-F51C6530145F@pfrc.org> References: <3A9517A1-F43E-43F6-9CDC-F51C6530145F@pfrc.org> Date: Thu, 23 Jul 2015 05:12:34 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=089e0122aeca6f142c051b89cd9a Archived-At: Cc: Netconf Subject: Re: [Netconf] yang library issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:12:38 -0000 --089e0122aeca6f142c051b89cd9a Content-Type: text/plain; charset=UTF-8 Hi, YANG modules do not have locations. I think you mean a YANG module that has data nodes places those data nodes in a specific location relative to the document root. Any YANG compiler knows what top-level data nodes are defined in a module, so I do not understand your comments. Module names have a flat namespace. There are naming conventions like ietf-foo vs. example-foo. There is no layering like routing/ietf-routing. Andy On Thu, Jul 23, 2015 at 5:04 AM, Jeffrey Haas wrote: > The comment I was unable to make at the mic is that work ongoing in IETF > to structure yang modules is potentially proceeding with a fallacy. That > fallacy is that the location of a module is effectively "known ahead of > time". Thus, if your device supports BGP, you will potentially have a > routing/ietf-bgp module. > > The presence of modules is conveyed in the protocol HELLO. > > The use of the library to help provide a manifest of actual > implementations seems quite important. I am endeavoring to help the > participants of the rtg-yang-architecture group and also members of > openconfig that they should not depend location of a module and > consequences if they do. > > -- Jeff > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --089e0122aeca6f142c051b89cd9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

YANG modules do not have locations.=
I think you mean a YANG module that has data nodes
pla= ces those data nodes in a specific location relative
to the docum= ent root.

Any YANG compiler knows what top-level d= ata nodes are defined
in a module, so I do not understand your co= mments.

Module names have a flat namespace.
<= div>There are naming conventions like ietf-foo vs. example-foo.
T= here is no layering like routing/ietf-routing.

Andy


On Thu, Jul 23, 2015 at 5:04 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
The comment I was un= able to make at the mic is that work ongoing in IETF to structure yang modu= les is potentially proceeding with a fallacy.=C2=A0 That fallacy is that th= e location of a module is effectively "known ahead of time".=C2= =A0 Thus, if your device supports BGP, you will potentially have a routing/= ietf-bgp module.

The presence of modules is conveyed in the protocol HELLO.

The use of the library to help provide a manifest of actual implementations= seems quite important.=C2=A0 I am endeavoring to help the participants of = the rtg-yang-architecture group and also members of openconfig that they sh= ould not depend location of a module and consequences if they do.

-- Jeff

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

--089e0122aeca6f142c051b89cd9a-- From nobody Thu Jul 23 05:15:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847B81A92F8 for ; Thu, 23 Jul 2015 05:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Xvfsei1xmClj for ; Thu, 23 Jul 2015 05:15:14 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.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 04E241A92EE for ; Thu, 23 Jul 2015 05:15:14 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 51C25B323A8FC for ; Thu, 23 Jul 2015 12:15:10 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t6NCFAv2005839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jul 2015 12:15:11 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 08:15:10 -0400 From: "Carey, Timothy (Timothy)" To: "netconf@ietf.org" Thread-Topic: Mandatory statement for the use of XML in Restconf Thread-Index: AdDFQTd3S36dA69yT3quCOuUwqDrNQ== Date: Thu, 23 Jul 2015 12:15:08 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC22161A@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC22161AUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Mandatory statement for the use of XML in Restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:15:15 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC22161AUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Team, I wanted to express my concern about making XML the mandatory encoding for = the Restconf (draft-ietf-netconf-restconf-07). There are use cases where Restconf may be used in CPEs or constrained devic= es where multiple encoding are just not possible. In fact JSON will most li= kely be the more popular option. As such I would remove the wording to stat= e XML is mandatory. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC22161AUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Team,

 

I wanted to express my concern about making XML the= mandatory encoding for the Restconf (draft-ietf-netconf-restconf-07).=

 

There are use cases where Restconf may be used in C= PEs or constrained devices where multiple encoding are just not possible. I= n fact JSON will most likely be the more popular option. As such I would remove the wording to state XML is mandatory.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC22161AUS70UWXCHMBA05z_-- From nobody Thu Jul 23 05:25:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AC21A92FB for ; Thu, 23 Jul 2015 05:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CyJjHnlUZEn9 for ; Thu, 23 Jul 2015 05:25:26 -0700 (PDT) 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 5AEBE1ABD3C for ; Thu, 23 Jul 2015 05:25:25 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 9F53A42618ED6 for ; Thu, 23 Jul 2015 12:25:21 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6NCPMNA022455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jul 2015 14:25:23 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 14:25:22 +0200 From: "Scharf, Michael (Michael)" To: "Carey, Timothy (Timothy)" , "netconf@ietf.org" Thread-Topic: Mandatory statement for the use of XML in Restconf Thread-Index: AdDFQTd3S36dA69yT3quCOuUwqDrNQAAC6Vw Date: Thu, 23 Jul 2015 12:25:22 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48437DBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22161A@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC22161A@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48437DBEFR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Mandatory statement for the use of XML in Restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:25:28 -0000 --_000_655C07320163294895BBADA28372AF5D48437DBEFR712WXCHMBA15z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, ... and in other potential use cases of RESTCONF JSON will also most likely= the more popular option, e.g., on certain NBIs that will clearly be JSON-b= ased. Supporting both encodings there just creates needless overhead, AFAIK= T. Note that this use case is entirely disjoint to Tim's one. Michael From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Carey, Timothy= (Timothy) Sent: Thursday, July 23, 2015 2:15 PM To: netconf@ietf.org Subject: [Netconf] Mandatory statement for the use of XML in Restconf Team, I wanted to express my concern about making XML the mandatory encoding for = the Restconf (draft-ietf-netconf-restconf-07). There are use cases where Restconf may be used in CPEs or constrained devic= es where multiple encoding are just not possible. In fact JSON will most li= kely be the more popular option. As such I would remove the wording to stat= e XML is mandatory. BR, Tim --_000_655C07320163294895BBADA28372AF5D48437DBEFR712WXCHMBA15z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

…= and in other potential use cases of RESTCONF JSON will also most likely th= e more popular option, e.g., on certain NBIs that will clearly be JSON-base= d. Supporting both encodings there just creates needless overhead, AFAIKT. Note that this use case is entirely disjoint to= Tim’s one.

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: Thursday, July 23, 2015 2:15 PM
To: netconf@ietf.org
Subject: [Netconf] Mandatory statement for the use of XML in Restcon= f

 

Team,

 

I wanted to express my concern about= making XML the mandatory encoding for the Restconf (draft-ietf-netconf-res= tconf-07).

 

There are use cases where Restconf m= ay be used in CPEs or constrained devices where multiple encoding are just = not possible. In fact JSON will most likely be the more popular option. As such I would remove the wording to state XML is mandatory.=

 

BR,

Tim

--_000_655C07320163294895BBADA28372AF5D48437DBEFR712WXCHMBA15z_-- From nobody Thu Jul 23 05:32:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106211AC39C for ; Thu, 23 Jul 2015 05:32:13 -0700 (PDT) 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 eEitJCLaekaz for ; Thu, 23 Jul 2015 05:32:06 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan5.extendcp.co.uk [79.170.43.33]) (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 35B301ABB19 for ; Thu, 23 Jul 2015 05:31:54 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan3.hi.local) by mailscan-g68.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZIFfE-00030R-Dt; Thu, 23 Jul 2015 13:31:52 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=webmail5.hi.local) by mailscan3.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1ZIFeJ-0002EL-TM; Thu, 23 Jul 2015 13:31:51 +0100 Received: from localhost ([127.0.0.1]) by webmail5.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZIFdu-0008E0-V1; Thu, 23 Jul 2015 13:30:31 +0100 Message-Id: <8da8863fae53cc4fd3f783f8a84a803e34fe44b9@webmail.hansfords.net> From: "Jonathan Hansford" To: "Carey Timothy (Timothy)" , netconf@ietf.org X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 79.77.2.126 in-reply-to: <9966516C6EB5FC4381E05BF80AA55F77DC22161A@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Thu, 23 Jul 2015 13:30:30 +0100 Content-Type: multipart/alternative; boundary="=_f6da1d558ae923c56d810f916405e969" MIME-Version: 1.0 X-Authenticated-As: jonathan@hansfords.net Archived-At: Subject: Re: [Netconf] Mandatory statement for the use of XML in Restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:32:13 -0000 --=_f6da1d558ae923c56d810f916405e969 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =0A=0A=09Tim,=0AThis has been discussed before (see the [Netconf] Sugges= tion for=0ARESTCONF section 5.3 [1] thread).=C2=A0=0A=0AJonathan=0A=0A--= --- Original Message -----=0AFrom: "Carey Timothy (Timothy)" =0ATo:"netc= onf@ietf.org" =0ACc:=0ASent:Thu, 23 Jul 2015 12:15:08 +0000=0ASubject:[N= etconf] Mandatory statement for the use of XML in Restconf=0A=0A=09Team,= =0A=0A=09=C2=A0=0A=0A=09I wanted to express my concern about making XML= the mandatory=0Aencoding for the Restconf (draft-ietf-netconf-restconf-= 07).=0A=0A=09=C2=A0=0A=0A=09There are use cases where Restconf may be us= ed in CPEs or constrained=0Adevices where multiple encoding are just not= possible. In fact JSON=0Awill most likely be the more popular option. A= s such I would remove=0Athe wording to state XML is mandatory.=0A=0A=09= =C2=A0=0A=0A=09BR,=0A=0A=09Tim=0A=0A=09 =0A=0ALinks:=0A------=0A[1]=0Ah= ttps://mailarchive.ietf.org/arch/msg/netconf/osCW_tb7P7DvkwoXyPmAjQsJJ4g= =0A --=_f6da1d558ae923c56d810f916405e969 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Tim,


This has been= discussed before (see the [Netconf] Suggestion for RESTCO= NF section 5.3 thread).=C2=A0

Jonathan
<= br />----- Original Message -----
From:
"Care= y Timothy (Timothy)" <timothy.carey@alcatel-lucent.com>

To:
"netconf@ietf.org" <netcon= f@ietf.org>
Cc:

Sent:
Thu, 23 Jul 2015 12:15:08 +0000<= br />
Subject:
[Netconf] Mandatory= statement for the use of XML in Restconf


=0A

Team,

=0A

=C2=A0

=0A

I wanted to express my concern a= bout making XML the mandatory encoding for the Restconf (draft-ietf-netc= onf-restconf-07).

=0A

=C2= =A0

=0A

There are use cases where Restconf may be used= in CPEs or constrained devices where multiple encoding are just not pos= sible. In fact JSON will most likely be the more popular option.=0A As s= uch I would remove the wording to state XML is mandatory.

<= /p>

=0A

=C2=A0

=0A

BR,

=0A

Tim

=0A
= =0A=0A
--=_f6da1d558ae923c56d810f916405e969-- From nobody Thu Jul 23 07:04:31 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7111A1A67 for ; Thu, 23 Jul 2015 07:04:27 -0700 (PDT) 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 a_IWm5xTt0cc for ; Thu, 23 Jul 2015 07:04:22 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B351A1B43 for ; Thu, 23 Jul 2015 07:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6566; q=dns/txt; s=iport; t=1437660261; x=1438869861; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=QGlUphy9PHduBHDnMQFhoScilQCkQiN3Iap+bGP6wGE=; b=dlAkLs9WG3u4sIavq3GMxAKgpPhdYdtax74C+HSjiwVwzZZNk2gpz30J 7JdFDCS3Kf4eJDOvS9tQ6wJCXMlDyD2LX0ATj1qiSmWiDVJIYiNpQV02Z SSMqNE3jWCSgQwfoe9GEpCu19hvilj/1PQ1Uj+haQu7vuMFg7Rh2FkkHo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DqBACw87BV/xbLJq1cGYNQab1AHQELhHEBAUJKAoIUAQEBAQEBgQuEIwEBAQEDAQEBawoNBAsRBAEBAQkWDwkDAgECARUoCAYBDAYCAQGIKg3LHQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0yEO1IGhCYFlGCEdodEiE+QTCZkgxo9MYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,531,1432598400"; d="scan'208,217";a="574378188" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 23 Jul 2015 14:04:19 +0000 Received: from [10.63.114.175] ([10.63.114.175]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6NE4JQC003882; Thu, 23 Jul 2015 14:04:19 GMT To: Jonathan Hansford , "Carey Timothy (Timothy)" , netconf@ietf.org References: <8da8863fae53cc4fd3f783f8a84a803e34fe44b9@webmail.hansfords.net> From: Robert Wilton Message-ID: <55B0F463.7000009@cisco.com> Date: Thu, 23 Jul 2015 15:04:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <8da8863fae53cc4fd3f783f8a84a803e34fe44b9@webmail.hansfords.net> Content-Type: multipart/alternative; boundary="------------010601010303050000090300" Archived-At: Subject: Re: [Netconf] Mandatory statement for the use of XML in Restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 14:04:28 -0000 This is a multi-part message in MIME format. --------------010601010303050000090300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I also agree with Tim: I don't think that RESTCONF should require XML as a mandatory encoding. I would suggest that both client and server can decide whether they want to support JSON and/or XML. To make a server with maximal interoperability then it should support both protoocols. Likewise for the client. But if there isn't consensus on a mandatory default encoding then surely it is better to have no default encoding at all, and just leave it to the implementers to decide what they want to support. Cheers, Rob On 23/07/2015 13:30, Jonathan Hansford wrote: > > Tim, > > > This has been discussed before (see the [Netconf] Suggestion for > RESTCONF section 5.3 > > thread). > > Jonathan > > > ----- Original Message ----- > From: > "Carey Timothy (Timothy)" > > To: > "netconf@ietf.org" > Cc: > > Sent: > Thu, 23 Jul 2015 12:15:08 +0000 > Subject: > [Netconf] Mandatory statement for the use of XML in Restconf > > > Team, > > I wanted to express my concern about making XML the mandatory > encoding for the Restconf (draft-ietf-netconf-restconf-07). > > There are use cases where Restconf may be used in CPEs or > constrained devices where multiple encoding are just not possible. > In fact JSON will most likely be the more popular option. As such > I would remove the wording to state XML is mandatory. > > BR, > > Tim > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------010601010303050000090300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I also agree with Tim: I don't think that RESTCONF should require XML as a mandatory encoding.

I would suggest that both client and server can decide whether they want to support JSON and/or XML.

To make a server with maximal interoperability then it should support both protoocols. Likewise for the client.  But if there isn't consensus on a mandatory default encoding then surely it is better to have no default encoding at all, and just leave it to the implementers to decide what they want to support.

Cheers,
Rob


On 23/07/2015 13:30, Jonathan Hansford wrote:

Tim,


This has been discussed before (see the [Netconf] Suggestion for RESTCONF section 5.3 thread). 

Jonathan

----- Original Message -----
From:
"Carey Timothy (Timothy)" <timothy.carey@alcatel-lucent.com>

To:
"netconf@ietf.org" <netconf@ietf.org>
Cc:

Sent:
Thu, 23 Jul 2015 12:15:08 +0000
Subject:
[Netconf] Mandatory statement for the use of XML in Restconf


Team,

 

I wanted to express my concern about making XML the mandatory encoding for the Restconf (draft-ietf-netconf-restconf-07).

 

There are use cases where Restconf may be used in CPEs or constrained devices where multiple encoding are just not possible. In fact JSON will most likely be the more popular option. As such I would remove the wording to state XML is mandatory.

 

BR,

Tim



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

--------------010601010303050000090300-- From nobody Thu Jul 23 08:10:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851A01A0390 for ; Thu, 23 Jul 2015 08:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ_2eb6LQsZJ for ; Thu, 23 Jul 2015 08:10:25 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A531A0387 for ; Thu, 23 Jul 2015 08:10:24 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-ed-55b09bc6ff2b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9D.3B.07675.6CB90B55; Thu, 23 Jul 2015 09:46:14 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Thu, 23 Jul 2015 11:10:23 -0400 From: Ing-Wher Chen To: "netconf@ietf.org" Thread-Topic: key management YANG models in rtgwg Thread-Index: AdDFWbHJHo1KRWpVQWKHJHM/jRlbPg== Date: Thu, 23 Jul 2015 15:10:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyuXRPlO6x2RtCDWYu0bOYuuk2qwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mtp/XGUr2MxTMefocrYGxu1cXYycHBICJhJ7H71jhLDFJC7c W8/WxcjFISRwlFHi3My3LBDOckaJ6Q2TWUCq2AQMJDZ83MIEYosIaEo0zvrACmILC+hIHHly hBUibigxb8E2RghbT2LZuglsIDaLgKpE09dfYHFeAV+JtgP9YPWMQJu/n1oDNpNZQFzi1pP5 TBAXCUgs2XOeGcIWlXj5+B8rhK0kMWnpOVaIeh2JBbs/sUHY2hLLFr5mhpgvKHFy5hOWCYzC s5CMnYWkZRaSlllIWhYwsqxi5CgtTi3LTTcy3MQIDOVjEmyOOxgXfLI8xCjAwajEw5sgtCFU iDWxrLgy9xCjNAeLkjivtF9eqJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGETHfL4e3F3YI rnM1u6Jz7sEdxcjZFtEO87YwLV3013B9sFMNi0bt+po7f8uTH72Pfz5hxZPjbL2TlXaGzJm7 xE1Uq/SvV6PqK4tbuyYwSb0Kfbl6XXb+pZ7Z3sEXeCpPtfY7XNXlO2r18tS7p7uqRE54bDn+ gXf/Ee4cCZvK+e+ibFmE5M18lFiKMxINtZiLihMBs3GlcUYCAAA= Archived-At: Subject: [Netconf] key management YANG models in rtgwg X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 15:10:31 -0000 Hello, The discussion of modeling of key chains came up during the presentation of presentation of at the netconf working group meeting on Jul. 23, 2015. Here's a bit more b= ackground on the topic of key management YANG models. Currently, there are two key management YANG models being debated in rtgwg. There is a key-table YANG model based on RFC 7210. This key-table YANG model is based on the symmetric key table that the KARP working group defined in RFC 7210 . This table is intended to be a generic key database, capable of supporting different protocols. I believe the KARP working group concluded after publishing RFC 7210. The second model proposed in rtgwg is the key-chain YANG model. This key-chain model is a different view of, and in my opinion, a subset o= f the key-table YANG model above. Both key management YANG models above only address symmetric keys, which are not the same as the asymmetric keys described in draft-ietf-netconf-server-model-07, Appendix A.1. (This is not to say that a single key management model should manage=20 both symmetric and asymmetric keys, or that each type of key requires its own key management model.) Thanks, Helen From nobody Fri Jul 24 03:43:56 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0D61A8982 for ; Fri, 24 Jul 2015 03:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tHAqH_EyHhBj for ; Fri, 24 Jul 2015 03:43:45 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 270DB1A8AE4 for ; Fri, 24 Jul 2015 03:43:44 -0700 (PDT) Received: by lahh5 with SMTP id h5so11679611lah.2 for ; Fri, 24 Jul 2015 03:43:42 -0700 (PDT) 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=eRsez/wF+8Dj99bnn/mpMLBPr378jpzVzQh6MBON840=; b=PtANgPR5CBJ1ZMsGiyImB6lYMXLKZ/Tz9RBkuMkJ5vcOIb5fu5FyMfZZ2jjHt+EJDC 5YJiTXgss8+s73nrEZ8uz45uy9WOaeGhOOH+8B3+VeQkXFUbjXERh82XdqIkK5KoQ9N2 VwCAkIUb6rmyzSWOHKRayLBncXb83KdWEZgifRQYuY/4bX4ZR0sycRDpCKgyyPwmJC92 /LW4XmSdbhvM0xwHvdn90IfGP+TD1+MGnkRA2tL8eA6XHKFRPnwRXS3laHxHFKxFgsVu Mxl6mhKDT5GQ5WpFfnZv52kSRcGs6IPDZO7L6sqAk8Jk8KhEKFGbZe7XkumgBSVX5Z9/ PWGA== X-Gm-Message-State: ALoCoQkt2/nKnCe0jxBmReS2Go51fEbIn6SFfKZb/XS/o3MghsOqOIXaiLvAC0kz9WmulKB/EsDN MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr12971733laj.123.1437734622634; Fri, 24 Jul 2015 03:43:42 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 24 Jul 2015 03:43:42 -0700 (PDT) Date: Fri, 24 Jul 2015 03:43:42 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=089e0158ba0a76c147051b9cad21 Archived-At: Subject: [Netconf] RESTCONF #18 and #19 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:43:47 -0000 --089e0158ba0a76c147051b9cad21 Content-Type: text/plain; charset=UTF-8 Hi, There was some discussion (albeit truncated by the WG chairs) about how anyxml should be handled in retrieval operations using the "fields" or "depth" parameters. There was also much confusion wrt/ the proposed changes. The WG does not yet understand the issue. The first order problem to solve is whether these query parameters apply to the YANG schema (A) or the conceptual instance document (B) (e.g., running datastore contents). If the answer is the YANG schema, then it is quite clear that an anyxml (or anydata) is a terminal node. As such, the entire anyxml or anydata node is treated as a leaf (i.e., no further depth levels exist and no subnodes can be selected with a fields parameter.) Here is an example because the WG is totally confused how this works: container top { anyxml foo; } 42 43 GET /restconf/data/top/foo?depth=1 (A) 42 43 (B) GET /restconf/data/foo?fields=bar (A) fields ignored since no schema node (not sure if error returned or empty data) (B) 42 (A) treats foo as a leaf (B) treats foo as a subtree with child nodes In order to implement (A) the server MUST understand the YANG schema. We have previously said this is not required. We need NETMOD WG to clarify anydata wrt/ (A) or (B). The intent seems to be that (B) would be returned. Proposed Changes: For anyxml, it is implementation-specific what the server returns. For anydata, the server MUST implement (B), which does not require knowledge of the YANG schema but does require that descendants of anydata are proper YANG data nodes Andy --089e0158ba0a76c147051b9cad21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

There was some discussion (albeit t= runcated by the WG chairs)
about how anyxml should be handled in = retrieval operations
using the "fields" or "depth&= quot; parameters.

There was also much confusion wr= t/ the proposed changes.
The WG does not yet understand the issue= .

The first order problem to solve is whether thes= e query
parameters apply to the YANG schema (A) or the conceptual=
instance document (B) (e.g., running datastore contents).
<= div>
If the answer is the YANG schema, then it is quite clear=
that an anyxml (or anydata) is a terminal node.
As suc= h, the entire anyxml or anydata node is
treated as a leaf (i.e., = no further depth levels exist
and no subnodes can be selected wit= h a fields parameter.)

Here is an example because = the WG is totally confused
how this works:


=C2=A0 =C2=A0container top {
=C2=A0 =C2=A0 =C2= =A0 anyxml foo;
=C2=A0 =C2=A0}

=C2=A0 = =C2=A0<top>
=C2=A0 =C2=A0 =C2=A0 <foo>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <bar>42</bar>
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <baz>43</baz>
=C2=A0 =C2= =A0 =C2=A0 </foo>
=C2=A0 </top>

<= div>
=C2=A0 GET /restconf/data/top/foo?depth=3D1

(A)
=C2=A0 =C2=A0<foo>
=C2=A0 =C2=A0 =C2=A0 <bar>42</bar>
=C2=A0 =C2=A0 = =C2=A0 <baz>43</baz>
=C2=A0 =C2=A0</foo>
<= div>
(B)
=C2=A0 =C2=A0<foo />

<= /div>

=C2=A0 GET /restconf/data/foo?fields=3Dbar

(A)

=C2=A0 =C2=A0fields ignored = since no schema node
=C2=A0 =C2=A0(not sure if error returned or = empty data)

(B)

=C2=A0 &l= t;foo>
=C2=A0 =C2=A0 =C2=A0<bar>42</bar>
=C2=A0 </foo>


(A) treats foo= as a leaf
(B) treats foo as a subtree with child nodes

In order to implement (A) the server MUST understand
<= div>the YANG schema.=C2=A0 We have previously said this
is not re= quired.

We need NETMOD WG to clarify anydata wrt/<= /div>
(A) or (B).=C2=A0 The intent seems to be that (B)
would= be returned.

Proposed Changes:

For anyxml, it is implementation-specific what the server
= returns.=C2=A0

For anydata, the server MUST implem= ent (B), which
does not require knowledge of the YANG schema but<= /div>
does require that descendants of anydata are proper
YAN= G data nodes


Andy


--089e0158ba0a76c147051b9cad21-- From nobody Fri Jul 24 03:54:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC421A8BB2 for ; Fri, 24 Jul 2015 03:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 jkZ7PzKZrhjH for ; Fri, 24 Jul 2015 03:54:04 -0700 (PDT) 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 D7FB21A8870 for ; Fri, 24 Jul 2015 03:54:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3496D18BF; Fri, 24 Jul 2015 12:53:58 +0200 (CEST) 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 YFSyE882L2Kf; Fri, 24 Jul 2015 12:53:57 +0200 (CEST) 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, 24 Jul 2015 12:53:57 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E50C72003C; Fri, 24 Jul 2015 12:54:01 +0200 (CEST) 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 wdW_pf2ccCfH; Fri, 24 Jul 2015 12:54:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA51120039; Fri, 24 Jul 2015 12:54:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7FA5735DF66C; Fri, 24 Jul 2015 12:54:00 +0200 (CEST) Date: Fri, 24 Jul 2015 12:54:00 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150724105400.GA12867@elstar.local> Mail-Followup-To: Andy Bierman , Netconf 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: Netconf Subject: Re: [Netconf] RESTCONF #18 and #19 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:54:06 -0000 On Fri, Jul 24, 2015 at 03:43:42AM -0700, Andy Bierman wrote: > Hi, > > There was some discussion (albeit truncated by the WG chairs) > about how anyxml should be handled in retrieval operations > using the "fields" or "depth" parameters. > > There was also much confusion wrt/ the proposed changes. > The WG does not yet understand the issue. > > The first order problem to solve is whether these query > parameters apply to the YANG schema (A) or the conceptual > instance document (B) (e.g., running datastore contents). > > If the answer is the YANG schema, then it is quite clear > that an anyxml (or anydata) is a terminal node. > As such, the entire anyxml or anydata node is > treated as a leaf (i.e., no further depth levels exist > and no subnodes can be selected with a fields parameter.) > > Here is an example because the WG is totally confused > how this works: > > > container top { > anyxml foo; > } > > > > 42 > 43 > > > > > GET /restconf/data/top/foo?depth=1 > > > (A) > > 42 > 43 > > > (B) > > > > GET /restconf/data/foo?fields=bar > > (A) > > fields ignored since no schema node > (not sure if error returned or empty data) > > (B) > > > 42 > > > > (A) treats foo as a leaf > (B) treats foo as a subtree with child nodes > > In order to implement (A) the server MUST understand > the YANG schema. We have previously said this > is not required. > > We need NETMOD WG to clarify anydata wrt/ > (A) or (B). The intent seems to be that (B) > would be returned. > > Proposed Changes: > > For anyxml, it is implementation-specific what the server > returns. I think this is what the totally confused WG agreed on yesterday. > For anydata, the server MUST implement (B), which > does not require knowledge of the YANG schema but > does require that descendants of anydata are proper > YANG data nodes Yes, I expect filters to operate on the instance tree. /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 Jul 24 04:12:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFD31A8843 for ; Fri, 24 Jul 2015 04:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 C_LKqDT507e0 for ; Fri, 24 Jul 2015 04:12:26 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 6C3F91A6F22 for ; Fri, 24 Jul 2015 04:12:25 -0700 (PDT) Received: by lagw2 with SMTP id w2so12041042lag.3 for ; Fri, 24 Jul 2015 04:12:24 -0700 (PDT) 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=FTVTQEDuAY4iauKoDi11V+lnU/5eVbM1qLU/zY0NeY4=; b=gkzt5WTCJtmU9rbAsNJUMgAZNIX4KAxNX87B4oZJ6n0wxlV/wLTawPCBQj1OQPwGAv 6nJg++/pdH44Ahb+HcbnJweoDyaNY78TtsgKBieUp9k9ycf84SyArCRnptTSNE3Bh+Y6 uUFs9c4L2z0GxK5m7ekkkh4oFYgEFPfhhEGN91oKz6ND0RtaYTVcXmxkm5eXBGhGFEzH z9wf9AO2To8M45sGU1+Iz05G8JjSFUnF/Q2BsJibyNzKodBt0Na+OK23oF5rM8v2RWhk ROohLA2v5LcVgsz2NgJmQP1EmKsLYeupGZ2Nl6pCPAKPvEfIltH32H0c7DA6rH3bxyY9 16gg== X-Gm-Message-State: ALoCoQm7XRxo4b13/ZUTszDxFNPZvYx5bzp7iOY4/bTMGH6iqDjGoSWQKz3/mZpIVuVdCZZLFQqb MIME-Version: 1.0 X-Received: by 10.112.186.35 with SMTP id fh3mr12940411lbc.82.1437736343947; Fri, 24 Jul 2015 04:12:23 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 24 Jul 2015 04:12:23 -0700 (PDT) In-Reply-To: <20150724105400.GA12867@elstar.local> References: <20150724105400.GA12867@elstar.local> Date: Fri, 24 Jul 2015 04:12:23 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=001a1134dcc80ff671051b9d1467 Archived-At: Subject: Re: [Netconf] RESTCONF #18 and #19 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 11:12:28 -0000 --001a1134dcc80ff671051b9d1467 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 24, 2015 at 3:54 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Jul 24, 2015 at 03:43:42AM -0700, Andy Bierman wrote: > > Hi, > > > > There was some discussion (albeit truncated by the WG chairs) > > about how anyxml should be handled in retrieval operations > > using the "fields" or "depth" parameters. > > > > There was also much confusion wrt/ the proposed changes. > > The WG does not yet understand the issue. > > > > The first order problem to solve is whether these query > > parameters apply to the YANG schema (A) or the conceptual > > instance document (B) (e.g., running datastore contents). > > > > If the answer is the YANG schema, then it is quite clear > > that an anyxml (or anydata) is a terminal node. > > As such, the entire anyxml or anydata node is > > treated as a leaf (i.e., no further depth levels exist > > and no subnodes can be selected with a fields parameter.) > > > > Here is an example because the WG is totally confused > > how this works: > > > > > > container top { > > anyxml foo; > > } > > > > > > > > 42 > > 43 > > > > > > > > > > GET /restconf/data/top/foo?depth=1 > > > > > > (A) > > > > 42 > > 43 > > > > > > (B) > > > > > > > > GET /restconf/data/foo?fields=bar > > > > (A) > > > > fields ignored since no schema node > > (not sure if error returned or empty data) > > > > (B) > > > > > > 42 > > > > > > > > (A) treats foo as a leaf > > (B) treats foo as a subtree with child nodes > > > > In order to implement (A) the server MUST understand > > the YANG schema. We have previously said this > > is not required. > > > > We need NETMOD WG to clarify anydata wrt/ > > (A) or (B). The intent seems to be that (B) > > would be returned. > > > > Proposed Changes: > > > > For anyxml, it is implementation-specific what the server > > returns. > > I think this is what the totally confused WG agreed on yesterday. > > OK -- I should have made an example in the slides to address the confusion. Trying to do that now on the mailing list > > For anydata, the server MUST implement (B), which > > does not require knowledge of the YANG schema but > > does require that descendants of anydata are proper > > YANG data nodes > > Yes, I expect filters to operate on the instance tree. > agreed > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a1134dcc80ff671051b9d1467 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 24, 2015 at 3:54 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Jul 24, 2015 at 03:43:42AM -0700, Andy Bierm= an wrote:
> Hi,
>
> There was some discussion (albeit truncated by the WG chairs)
> about how anyxml should be handled in retrieval operations
> using the "fields" or "depth" parameters.
>
> There was also much confusion wrt/ the proposed changes.
> The WG does not yet understand the issue.
>
> The first order problem to solve is whether these query
> parameters apply to the YANG schema (A) or the conceptual
> instance document (B) (e.g., running datastore contents).
>
> If the answer is the YANG schema, then it is quite clear
> that an anyxml (or anydata) is a terminal node.
> As such, the entire anyxml or anydata node is
> treated as a leaf (i.e., no further depth levels exist
> and no subnodes can be selected with a fields parameter.)
>
> Here is an example because the WG is totally confused
> how this works:
>
>
>=C2=A0 =C2=A0 container top {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0anyxml foo;
>=C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 <top>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<foo>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<bar>42</bar>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<baz>43</baz>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0</foo>
>=C2=A0 =C2=A0</top>
>
>
>=C2=A0 =C2=A0GET /restconf/data/top/foo?depth=3D1
>
>
> (A)
>=C2=A0 =C2=A0 <foo>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<bar>42</bar>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<baz>43</baz>
>=C2=A0 =C2=A0 </foo>
>
> (B)
>=C2=A0 =C2=A0 <foo />
>
>
>=C2=A0 =C2=A0GET /restconf/data/foo?fields=3Dbar
>
> (A)
>
>=C2=A0 =C2=A0 fields ignored since no schema node
>=C2=A0 =C2=A0 (not sure if error returned or empty data)
>
> (B)
>
>=C2=A0 =C2=A0<foo>
>=C2=A0 =C2=A0 =C2=A0 <bar>42</bar>
>=C2=A0 =C2=A0</foo>
>
>
> (A) treats foo as a leaf
> (B) treats foo as a subtree with child nodes
>
> In order to implement (A) the server MUST understand
> the YANG schema.=C2=A0 We have previously said this
> is not required.
>
> We need NETMOD WG to clarify anydata wrt/
> (A) or (B).=C2=A0 The intent seems to be that (B)
> would be returned.
>
> Proposed Changes:
>
> For anyxml, it is implementation-specific what the server
> returns.

I think this is what the totally confused WG agreed on yesterday.



OK -- I should have mad= e an example in the slides to
address the confusion.=C2=A0 Trying= to do that now on the mailing list
=C2=A0
> For anydata, the server MUST implement (B), which
> does not require knowledge of the YANG schema but
> does require that descendants of anydata are proper
> YANG data nodes

Yes, I expect filters to operate on the instance tree.

agreed

=C2=A0

/js

Andy
=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a1134dcc80ff671051b9d1467-- From nobody Sat Jul 25 04:04:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3EF1A1B60 for ; Sat, 25 Jul 2015 04:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 11UmcRYUwQIF for ; Sat, 25 Jul 2015 04:04:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 36F4C1A1B53 for ; Sat, 25 Jul 2015 04:04:47 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t6PB4kME009563 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 25 Jul 2015 11:04:46 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t6PB4jYx023216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 25 Jul 2015 13:04:45 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sat, 25 Jul 2015 13:04:45 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.210]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0248.002; Sat, 25 Jul 2015 13:04:45 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Summary and AIs from the NETCONF Session in IETF #93 Thread-Index: AQHQxsm2aK2Ew2cXREeSuByjGlCGvg== Date: Sat, 25 Jul 2015 11:04:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.120] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819766314DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 37213 X-purgate-ID: 151667::1437822286-000063FD-81EC548E/0/0 Archived-At: Subject: [Netconf] Summary and AIs from the NETCONF Session in IETF #93 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 11:04:51 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819766314DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Benoit, NETCONF WG, below is a summary and action items from the NETCONF WG session on July 23,= 2015 in Prague, Czech Republic. - We had approx. 65+ participants in the 2 hour NETCONF session, - We reviewed the status of the WG, - We had a discussion on 7 chartered documents. - Many thanks to the note takers: ext Radek Krejci and Mike Leske and the j= abber scribe: Juergen Schoenwaelder. The session agenda is available at: https://www.ietf.org/proceedings/93/age= nda/agenda-93-netconf Following is a summary of the discussion and the decisions taken per show-h= ands. This mail is at the same time to verify the discussion result and decisions= from the IETF 93 NETCONF session. If there is no strong objection we will implement as discussed. - After WG LC Call Home will go to AD review. Write-up will be provided by = the shepherd (Mahesh). - Server Model: The duplication of data in server model has been discussed = with 4 optional solutions. Option 4 based on key chains has been proposed. = Many WG member are in favor. Nobody against. This option requires a delay of the work and some part needs to be done in = Security area. Kent to provide a proposal for the way forward describing how to address op= tion 4 with key chains and the work split with SEC area. - Restconf issues have been discussed. Agreed to use the current YANG 1.1 d= raft instead of YANG 1.0 and finalize issues in Restconf with this basis. T= he goal is to go to LC with this basis asap. - Different folks would like to have JSON as additional encoding. This disc= ussion has been separated in the sake of time usage and will be brought to = the maillist. - Remaining YANG Patch and YANG Library issues will be solved soon and WG L= C is the next step. - Pub/Sub Solution draft. WG supports adoption, no objections. ADs recommended to not wait. The co-ch= airs support the adoption. It'll be verified on the maillist. - I2RS requirements have been discussed. Issues have been clarified in two = steps first in NETCONF and then in I2RS session. Regards, Mehmet & Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F819766314DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Benoit, NETCONF WG,

 

below is a summary and actio= n items from the NETCONF WG session on July 23, 2015 in Prague, Czech Republic.

 

- We had approx. 65+ par= ticipants in the 2 hour NETCONF session,

- We reviewed the status of = the WG,

- We had a discussion on 7 c= hartered documents.

 

- Many thanks to the note ta= kers: ext Radek Krejci and Mike Leske and the jabber scribe: Juergen Schoen= waelder.

 

 

Following is a summary of th= e discussion and the decisions taken per show-hands.

=  

This mail is at the same tim= e to verify the discussion result and decisions from the IETF 93 NETCONF session.

If there is no strong object= ion we will implement as discussed.

 

- After WG LC Call Home will= go to AD review. Write-up will be provided by the shepherd (Mahesh).

 

- Server Model: The duplicat= ion of data in server model has been discussed with 4 optional solutions. Option 4 based on key chains has been proposed. Many WG member are in favo= r. Nobody against.

This option requires a delay= of the work and some part needs to be done in Security area.

Kent to provide a proposal f= or the way forward describing how to address option 4 with key chains and the work split with SEC area.

 

- Restconf issues have been = discussed. Agreed to use the current YANG 1.1 draft instead of YANG 1.0 and finalize issues in Restconf with this basis. The goal is to go to LC with this basis asap.

- Different folks would like= to have JSON as additional encoding. This discussion has been separated in the sake of time usage and will be brought to the maillist.

 

- Remaining YANG Patch and Y= ANG Library issues will be solved soon and WG LC is the next step.

 

- Pub/Sub Solution draft.

WG supports adoption, no obj= ections. ADs recommended to not wait. The co-chairs support the adoption. It'll be verified on the maillist.

 

- I2RS requirements have bee= n discussed. Issues have been clarified in two steps first in NETCONF and then in I2RS session.

 

 

Regards,
Mehmet & Mahesh

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819766314DEMUMBX005nsnin_-- From nobody Sat Jul 25 14:32:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A881A0364 for ; Sat, 25 Jul 2015 14:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 g86YHJhbMAv5 for ; Sat, 25 Jul 2015 14:32:50 -0700 (PDT) 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 C748C1A034F for ; Sat, 25 Jul 2015 14:32:49 -0700 (PDT) Received: by lblf12 with SMTP id f12so32912645lbl.2 for ; Sat, 25 Jul 2015 14:32:48 -0700 (PDT) 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=YAsFx9HXv6wsTL0+dP+VZYerGYfssXV2Y4p0ijzEob8=; b=V8wOnH10qsKbVbGKMQLGtsRGDfHC3L2cqvEMBtVg6nZS3V2ROrvw7Aza6wtz/EEtNf 4QuG0eI9soQet64p/ncSZ5IIqTN0jrSkjaomsramwx30lmGy5kRFrYh8j/KfIsi2kuNm gAk8NCr8DdxXpb22TQ6fIG9XVh+vcpkEjbNoK0SMnsES2M8ZUin6AoTwNqnA05Gv4b4i qm0pW789OP5kj343IaklAwYGMN7tVJEF+ixkCorVvW6KJVQH2Yi/nnUOrGz2nqr1xY6M wGz7eUV3b8cii48vjm+Kajzvgk9VQ+LVm4Bw4758Or5wmE3HUab9cWiXrxM3d+mYlhyx dXtg== X-Gm-Message-State: ALoCoQm7FsEttiqMiHfgxkFZIW1H8zue2st1BtFbDNmvzLs4CnnCXqPvvrWm5ojciiBNq/XlsZbc MIME-Version: 1.0 X-Received: by 10.112.46.130 with SMTP id v2mr19676019lbm.119.1437859968207; Sat, 25 Jul 2015 14:32:48 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 25 Jul 2015 14:32:48 -0700 (PDT) Date: Sat, 25 Jul 2015 14:32:48 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a1134aee8a46639051bb9dc70 Archived-At: Subject: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 21:32:51 -0000 --001a1134aee8a46639051bb9dc70 Content-Type: text/plain; charset=UTF-8 Hi, It would be good if we could close this issue soon. I am not in favor of changing the previous consensus call. At first I thought JSON would be good for RESTCONF, until I implemented it. It is not appropriate for streaming servers. The complexity and memory required and just as bad or worse than XML, especially once namespaces and attributes are added. JSON is fine if the entire document is in memory, but that's not how NETCONF/RESTCONF servers work. Andy --001a1134aee8a46639051bb9dc70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

It would be good if we could close = this issue soon.
I am not in favor of changing the previous conse= nsus call.

At first I thought JSON would be good f= or RESTCONF,
until I implemented it.=C2=A0 It is not appropriate = for streaming servers.
The complexity and memory required and jus= t as bad or worse
than XML, especially once namespaces and attrib= utes are
added.

JSON is fine if the enti= re document is in memory,
but that's not how NETCONF/RESTCONF= servers work.


Andy

<= /div>



--001a1134aee8a46639051bb9dc70-- From nobody Sun Jul 26 00:26:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22891ACDF9 for ; Sun, 26 Jul 2015 00:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 s0xej5zXRzon for ; Sun, 26 Jul 2015 00:26:17 -0700 (PDT) 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 85E521ACDF7 for ; Sun, 26 Jul 2015 00:26:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0C8211424; Sun, 26 Jul 2015 09:26:10 +0200 (CEST) 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 drcS9YHPOVJW; Sun, 26 Jul 2015 09:26:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 26 Jul 2015 09:26:09 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A30902003D; Sun, 26 Jul 2015 09:26:15 +0200 (CEST) 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 yRtL8GSw1dM4; Sun, 26 Jul 2015 09:26:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A90592003C; Sun, 26 Jul 2015 09:26:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6089E35E006D; Sun, 26 Jul 2015 09:26:14 +0200 (CEST) Date: Sun, 26 Jul 2015 09:26:14 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150726072614.GD16276@elstar.local> Mail-Followup-To: Andy Bierman , Netconf 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: Netconf Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 07:26:19 -0000 On Sat, Jul 25, 2015 at 02:32:48PM -0700, Andy Bierman wrote: > Hi, > > It would be good if we could close this issue soon. > I am not in favor of changing the previous consensus call. > > At first I thought JSON would be good for RESTCONF, > until I implemented it. It is not appropriate for streaming servers. > The complexity and memory required and just as bad or worse > than XML, especially once namespaces and attributes are > added. > > JSON is fine if the entire document is in memory, > but that's not how NETCONF/RESTCONF servers work. I would probably change my position from 'make XML mandatory' to leave it undefined. I do see scenarios where servers will only do JSON because this is what the clients they interact with expect. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jul 26 09:43:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C481A9174 for ; Sun, 26 Jul 2015 09:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 OfmlKVDuGBZP for ; Sun, 26 Jul 2015 09:43:38 -0700 (PDT) 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 B65E41A9173 for ; Sun, 26 Jul 2015 09:43:37 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so40219084lbb.1 for ; Sun, 26 Jul 2015 09:43:36 -0700 (PDT) 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=hDwhzT6SDwaUdB/prULyZED3yKXDtL7vunEQ55II/QA=; b=BfHLb1wTSs3kzcFsr+GbvFpOUx4xPCitBX7yRMqWIZDWs+zVtAnxLK4BvCm2e9Cba+ CWyIpvMIjDHfp/i0CZXIr3cpp0C6nUVWAEIAQe6hHVi370KlqKTMfkEMyPVUebYu4QQJ fXguGmHngGLuK8ja7M91QBsntUE8sdlIW9RheTZGBozj/MjKl4+nxZa4HH055rzw0Yji v3NJ/sbT8jU31Th3V7078ZLePF1XDuaqt9YQaKztyQ3WcbXxSVoKrzsNZlXCGmM+UjkB WCc05KI3OcXXMp4yLvBi4CJ90a+dJcFDN09KI+F2ogyNZsG7AhjkhZJE2scfJgMrkL29 TUlw== X-Gm-Message-State: ALoCoQnhd4fFjD9sndVo/CquQYonf8Me1olhwxt+jiZ44/PfmtRc7wL9OYHcdrYMZ1ScYkuuwqpJ MIME-Version: 1.0 X-Received: by 10.112.24.71 with SMTP id s7mr22367370lbf.37.1437929016148; Sun, 26 Jul 2015 09:43:36 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Jul 2015 09:43:36 -0700 (PDT) In-Reply-To: <20150726072614.GD16276@elstar.local> References: <20150726072614.GD16276@elstar.local> Date: Sun, 26 Jul 2015 09:43:36 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=001a11343832385b96051bc9f0f7 Archived-At: Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 16:43:39 -0000 --001a11343832385b96051bc9f0f7 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 26, 2015 at 12:26 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sat, Jul 25, 2015 at 02:32:48PM -0700, Andy Bierman wrote: > > Hi, > > > > It would be good if we could close this issue soon. > > I am not in favor of changing the previous consensus call. > > > > At first I thought JSON would be good for RESTCONF, > > until I implemented it. It is not appropriate for streaming servers. > > The complexity and memory required and just as bad or worse > > than XML, especially once namespaces and attributes are > > added. > > > > JSON is fine if the entire document is in memory, > > but that's not how NETCONF/RESTCONF servers work. > > I would probably change my position from 'make XML mandatory' to leave > it undefined. I do see scenarios where servers will only do JSON > because this is what the clients they interact with expect. > > Could the XRD returned for the initial GET on /.well-known be used to return the encoding formats supported by the server? That way it will not cost an extra round-trip to find out if the server supports XML, JSON, or both. If so, I would also change my position. Let the market decide if it is acceptable to be a JSON-only server. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11343832385b96051bc9f0f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 26, 2015 at 12:26 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Jul 25, 2015 at 02:32:48PM -0700, Andy Bier= man wrote:
> Hi,
>
> It would be good if we could close this issue soon.
> I am not in favor of changing the previous consensus call.
>
> At first I thought JSON would be good for RESTCONF,
> until I implemented it.=C2=A0 It is not appropriate for streaming serv= ers.
> The complexity and memory required and just as bad or worse
> than XML, especially once namespaces and attributes are
> added.
>
> JSON is fine if the entire document is in memory,
> but that's not how NETCONF/RESTCONF servers work.

I would probably change my position from 'make XML mandatory' to le= ave
it undefined. I do see scenarios where servers will only do JSON
because this is what the clients they interact with expect.



Could the XRD returned for the initia= l GET on =C2=A0/.well-known
be used to return the encoding format= s supported by the server?
That way it will not cost an extra rou= nd-trip to find out if the
server supports XML, JSON, or both.

If so, I would also change my position. Let the mark= et decide
if it is acceptable to be a JSON-only server.


/js

Andy
=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a11343832385b96051bc9f0f7-- From nobody Sun Jul 26 10:06:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCEF1AC3E8 for ; Sun, 26 Jul 2015 10:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 ArML_xpYps4f for ; Sun, 26 Jul 2015 10:06:19 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 CD5A11AC3E7 for ; Sun, 26 Jul 2015 10:06:18 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t6QH6FIF013432 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Jul 2015 17:06:16 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t6QH6FM3022745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jul 2015 19:06:15 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 26 Jul 2015 19:06:14 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.210]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0248.002; Sun, 26 Jul 2015 19:06:14 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: ext Andy Bierman , Juergen Schoenwaelder , Netconf Thread-Topic: [Netconf] RESTCONF #24:mandatory encoding revisited Thread-Index: AQHQx8I9YF8HTysoA0etBY7Xg/CGjZ3t+YXA Date: Sun, 26 Jul 2015 17:06:14 +0000 Message-ID: References: <20150726072614.GD16276@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.110] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819769AE5DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 42486 X-purgate-ID: 151667::1437930376-000058E2-CFE2EFB7/0/0 Archived-At: Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 17:06:21 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819769AE5DEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoZWFyZCBzZXZlcmFsIHRpbWVzIHRoZSBhcmd1bWVudCB0aGF0IEpTT04gd291bGQgYmUgdGhl IGJldHRlciBjaG9pY2UgZm9yIElvVC4NCklzIFJFU1RDT05GIGluZGVlZCB0aGUgcmlnaHQgcHJv dG9jb2wgZm9yIElvVD8NCg0KVGhvc2Ugd2hvIGZhdm9yIHRoZSB1c2Ugb2YgUkVTVENPTkYgKyBK U09OIGZvciBJb1Qgc2hvdWxkIGVsYWJvcmF0ZSB0aGVpciB1c2UgY2FzZS4NCg0KQ2hlZXJzLA0K TWVobWV0DQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBleHQgQW5keSBCaWVybWFuDQpTZW50OiBTdW5kYXksIEp1bHkgMjYsIDIw MTUgNjo0NCBQTQ0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgQW5keSBCaWVybWFuOyBOZXRj b25mDQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIFJFU1RDT05GICMyNDptYW5kYXRvcnkgZW5jb2Rp bmcgcmV2aXNpdGVkDQoNCg0KDQpPbiBTdW4sIEp1bCAyNiwgMjAxNSBhdCAxMjoyNiBBTSwgSnVl cmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8 bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+IHdyb3RlOg0KT24g U2F0LCBKdWwgMjUsIDIwMTUgYXQgMDI6MzI6NDhQTSAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3Rl Og0KPiBIaSwNCj4NCj4gSXQgd291bGQgYmUgZ29vZCBpZiB3ZSBjb3VsZCBjbG9zZSB0aGlzIGlz c3VlIHNvb24uDQo+IEkgYW0gbm90IGluIGZhdm9yIG9mIGNoYW5naW5nIHRoZSBwcmV2aW91cyBj b25zZW5zdXMgY2FsbC4NCj4NCj4gQXQgZmlyc3QgSSB0aG91Z2h0IEpTT04gd291bGQgYmUgZ29v ZCBmb3IgUkVTVENPTkYsDQo+IHVudGlsIEkgaW1wbGVtZW50ZWQgaXQuICBJdCBpcyBub3QgYXBw cm9wcmlhdGUgZm9yIHN0cmVhbWluZyBzZXJ2ZXJzLg0KPiBUaGUgY29tcGxleGl0eSBhbmQgbWVt b3J5IHJlcXVpcmVkIGFuZCBqdXN0IGFzIGJhZCBvciB3b3JzZQ0KPiB0aGFuIFhNTCwgZXNwZWNp YWxseSBvbmNlIG5hbWVzcGFjZXMgYW5kIGF0dHJpYnV0ZXMgYXJlDQo+IGFkZGVkLg0KPg0KPiBK U09OIGlzIGZpbmUgaWYgdGhlIGVudGlyZSBkb2N1bWVudCBpcyBpbiBtZW1vcnksDQo+IGJ1dCB0 aGF0J3Mgbm90IGhvdyBORVRDT05GL1JFU1RDT05GIHNlcnZlcnMgd29yay4NCg0KSSB3b3VsZCBw cm9iYWJseSBjaGFuZ2UgbXkgcG9zaXRpb24gZnJvbSAnbWFrZSBYTUwgbWFuZGF0b3J5JyB0byBs ZWF2ZQ0KaXQgdW5kZWZpbmVkLiBJIGRvIHNlZSBzY2VuYXJpb3Mgd2hlcmUgc2VydmVycyB3aWxs IG9ubHkgZG8gSlNPTg0KYmVjYXVzZSB0aGlzIGlzIHdoYXQgdGhlIGNsaWVudHMgdGhleSBpbnRl cmFjdCB3aXRoIGV4cGVjdC4NCg0KDQpDb3VsZCB0aGUgWFJEIHJldHVybmVkIGZvciB0aGUgaW5p dGlhbCBHRVQgb24gIC8ud2VsbC1rbm93bg0KYmUgdXNlZCB0byByZXR1cm4gdGhlIGVuY29kaW5n IGZvcm1hdHMgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXI/DQpUaGF0IHdheSBpdCB3aWxsIG5vdCBj b3N0IGFuIGV4dHJhIHJvdW5kLXRyaXAgdG8gZmluZCBvdXQgaWYgdGhlDQpzZXJ2ZXIgc3VwcG9y dHMgWE1MLCBKU09OLCBvciBib3RoLg0KDQpJZiBzbywgSSB3b3VsZCBhbHNvIGNoYW5nZSBteSBw b3NpdGlvbi4gTGV0IHRoZSBtYXJrZXQgZGVjaWRlDQppZiBpdCBpcyBhY2NlcHRhYmxlIHRvIGJl IGEgSlNPTi1vbmx5IHNlcnZlci4NCg0KDQovanMNCg0KQW5keQ0KDQoNCi0tDQpKdWVyZ2VuIFNj aG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhv bmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVu IHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5q YWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCg== --_000_E4DE949E6CE3E34993A2FF8AE79131F819769AE5DEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDBDN0Q2LjIzM0VDNzcwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8bzpUYXJnZXRTY3JlZW5TaXplPjEwMjR4NzY4PC9vOlRhcmdldFNjcmVlblNpemU+DQo8L286 T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpT cGVsbGluZ1N0YXRlPg0KPHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6 RW52ZWxvcGVWaXMvPg0KPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJ bnZhbGlkPmZhbHNlPC93OlNhdmVJZlhNTEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYv Pg0KPHc6TGlkVGhlbWVPdGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVB c2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5Y LU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRv Tm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0 UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRvbnRWZXJ0QWxpZ25DZWxsV2l0aFNwLz4NCjx3OkRv bnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFibGVzLz4NCjx3OkRvbnRWZXJ0QWxpZ25JblR4Yngv Pg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4NCjx3OkNhY2hlZENvbEJhbGFuY2UvPg0KPC93OkNv bXBhdGliaWxpdHk+DQo8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8 L3c6QnJvd3NlckxldmVsPg0KPG06bWF0aFByPg0KPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEg TWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCjxtOmJya0JpblN1YiBtOnZhbD0i JiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+DQo8bTps TWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpkZWZKYyBtOnZh bD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxtOmludExp bSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwvbTptYXRo UHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVmVW5oaWRl V2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3JtYXQ9ImZhbHNlIiBE ZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjI2NyI+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFtZT0iRGVm YXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8g U3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hh ZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJr IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNv bG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBM aXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGlu ZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg TGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0 IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAx IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3Qg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdy aWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hh ZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUg RW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29r IFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBO YW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6TGF0ZW50 U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlv bnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1hbHQ6IkNhbGlzdG8gTVQiOw0KCW1z by1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28t Zm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3 MzA1NzI3IDAgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJBcmlhbCBSb3Vu ZGVkIE1UIEJvbGQiOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZh bWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1 cmU6LTUzNjg3MDE0NSAxMDczNzg2MTExIDEgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCgltc28tZm9u dC1hbHQ6QXJpYWw7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFt aWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVy ZTotNTIwMDgxNjY1IC0xMDczNzE3MTU3IDQxIDAgNjYwNDcgMDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28t c3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFy ZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdp bmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJ dGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhv ZW56YjsNCgltc28tc3R5bGUtdW5oaWRlOm5vO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsNCgltc28tYmlkaS1m b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6 IzAwMDBDQzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tZGVmYXVsdC1wcm9wczp5ZXM7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDsNCgltc28taGVhZGVyLW1hcmdpbjozNi4wcHQ7DQoJbXNv LWZvb3Rlci1tYXJnaW46MzYuMHB0Ow0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxl DQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1z aXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1z by1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7 DQoJbXNvLXBhcmEtbWFyZ2luOjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQo8L3N0eWxlPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5 bGU9InRhYi1pbnRlcnZhbDozNi4wcHQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPkkgaGVhcmQgc2V2ZXJh bCB0aW1lcyB0aGUgYXJndW1lbnQgdGhhdCBKU09OIHdvdWxkIGJlIHRoZSBiZXR0ZXIgY2hvaWNl DQogZm9yIElvVC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzAwMDBDQyI+SXMgUkVTVENPTkYgaW5kZWVkIHRoZSByaWdo dCBwcm90b2NvbCBmb3IgSW9UPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMDAwMENDIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztt c28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzAw MDBDQyI+VGhvc2Ugd2hvIGZhdm9yIHRoZSB1c2Ugb2YgUkVTVENPTkYgJiM0MzsgSlNPTiBmb3Ig SW9UIHNob3VsZCBlbGFib3JhdGUgdGhlaXINCiB1c2UgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMw MDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYmlk aS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzAwMDBDQyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5n PSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzAwMDBDQzttc28tYW5zaS1sYW5ndWFnZTpERTttc28tbm8t cHJvb2Y6eWVzIj5DaGVlcnMsDQo8YnI+DQpNZWhtZXQgPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNj IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oztmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+ PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4N CiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSA8Yj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mDQo8L3NwYW4+PC9iPmV4dCBBbmR5IEJp ZXJtYW48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+ PC9iPiBTdW5kYXksIEp1bHkgMjYsIDIwMTUgNjo0NCBQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IEFu ZHkgQmllcm1hbjsgTmV0Y29uZjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbTmV0Y29uZl0gUkVTVENPTkYgIzI0Om1hbmRhdG9y eSBlbmNvZGluZyByZXZpc2l0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5PbiBTdW4sIEp1bCAyNiwgMjAx NSBhdCAxMjoyNiBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJtYWlsdG86 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5PbiBTYXQsIEp1bCAyNSwgMjAxNSBhdCAwMjoz Mjo0OFBNIC0wNzAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJdCB3b3VsZCBiZSBnb29kIGlmIHdlIGNvdWxkIGNsb3NlIHRoaXMgaXNzdWUg c29vbi48YnI+DQomZ3Q7IEkgYW0gbm90IGluIGZhdm9yIG9mIGNoYW5naW5nIHRoZSBwcmV2aW91 cyBjb25zZW5zdXMgY2FsbC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBdCBmaXJzdCBJIHRob3VnaHQg SlNPTiB3b3VsZCBiZSBnb29kIGZvciBSRVNUQ09ORiw8YnI+DQomZ3Q7IHVudGlsIEkgaW1wbGVt ZW50ZWQgaXQuJm5ic3A7IEl0IGlzIG5vdCBhcHByb3ByaWF0ZSBmb3Igc3RyZWFtaW5nIHNlcnZl cnMuPGJyPg0KJmd0OyBUaGUgY29tcGxleGl0eSBhbmQgbWVtb3J5IHJlcXVpcmVkIGFuZCBqdXN0 IGFzIGJhZCBvciB3b3JzZTxicj4NCiZndDsgdGhhbiBYTUwsIGVzcGVjaWFsbHkgb25jZSBuYW1l c3BhY2VzIGFuZCBhdHRyaWJ1dGVzIGFyZTxicj4NCiZndDsgYWRkZWQuPGJyPg0KJmd0Ozxicj4N CiZndDsgSlNPTiBpcyBmaW5lIGlmIHRoZSBlbnRpcmUgZG9jdW1lbnQgaXMgaW4gbWVtb3J5LDxi cj4NCiZndDsgYnV0IHRoYXQncyBub3QgaG93IE5FVENPTkYvUkVTVENPTkYgc2VydmVycyB3b3Jr Ljxicj4NCjxicj4NCkkgd291bGQgcHJvYmFibHkgY2hhbmdlIG15IHBvc2l0aW9uIGZyb20gJ21h a2UgWE1MIG1hbmRhdG9yeScgdG8gbGVhdmU8YnI+DQppdCB1bmRlZmluZWQuIEkgZG8gc2VlIHNj ZW5hcmlvcyB3aGVyZSBzZXJ2ZXJzIHdpbGwgb25seSBkbyBKU09OPGJyPg0KYmVjYXVzZSB0aGlz IGlzIHdoYXQgdGhlIGNsaWVudHMgdGhleSBpbnRlcmFjdCB3aXRoIGV4cGVjdC48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+Q291bGQgdGhlIFhSRCByZXR1cm5lZCBmb3IgdGhlIGluaXRpYWwgR0VUIG9uICZuYnNwOy8u d2VsbC1rbm93bjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5iZSB1c2VkIHRvIHJldHVybiB0aGUgZW5j b2RpbmcgZm9ybWF0cyBzdXBwb3J0ZWQgYnkgdGhlIHNlcnZlcj88bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+VGhhdCB3YXkgaXQgd2lsbCBub3QgY29zdCBhbiBleHRyYSByb3VuZC10cmlwIHRvIGZpbmQg b3V0IGlmIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5zZXJ2ZXIgc3VwcG9ydHMgWE1MLCBKU09O LCBvciBib3RoLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+SWYgc28sIEkgd291bGQgYWxzbyBjaGFuZ2UgbXkgcG9zaXRpb24uIExldCB0aGUgbWFya2V0 IGRlY2lkZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5pZiBpdCBpcyBhY2NlcHRhYmxlIHRvIGJlIGEg SlNPTi1vbmx5IHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O21zby1ib3JkZXItbGVmdC1hbHQ6c29saWQgI0NDQ0NDQyAuNzVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImhvZW56YiI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9 IiM4ODg4ODgiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6Izg4ODg4OCI+L2pzPC9zcGFuPjwvZm9udD48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7bXNvLWJv cmRlci1sZWZ0LWFsdDpzb2xpZCAjQ0NDQ0NDIC43NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzg4ODg4OCIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojODg4ODg4Ij48YnI+DQo8c3Bh biBjbGFzcz0iaG9lbnpiIj4tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5KdWVy Z2VuIFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0phY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0i aG9lbnpiIj5QaG9uZTogJiM0Mzs0OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8L3NwYW4+ PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+RmF4OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAy MDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0 cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3 LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E4DE949E6CE3E34993A2FF8AE79131F819769AE5DEMUMBX005nsnin_-- From nobody Sun Jul 26 10:16:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DE01AC41B for ; Sun, 26 Jul 2015 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 VWEsKjuft1gx for ; Sun, 26 Jul 2015 10:16:16 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 A98211AC410 for ; Sun, 26 Jul 2015 10:16:15 -0700 (PDT) Received: by lblf12 with SMTP id f12so40445838lbl.2 for ; Sun, 26 Jul 2015 10:16:14 -0700 (PDT) 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=lsFr36WZfpJyfPMK3GK13v7jjc5SRc6cia49yaKsl/w=; b=aSwwjhslBofiWo7YkYo+s5I00ZFHttpEetdI1rzowGaLGCCXYWfNYudne8Z4n3U9Ja SUPMMAxOhzEZqGu9Fsc1p9I18YQauJrDpxSbATQwRPlXekF3UC0DxZnRvsoI7cKV6DHR 4x/+C+uygKWLSjk7fwHEjcjzSW4UPXRH+kyqrZS+E3vrT56AIM54fiM4KIbFpV4whBm2 za07dZ3lguKjS9ZEJ0frJ7IEK0vhTRnj7dLdhZxzA7Uw2xa++/DrsZplf1gBOR0f69j3 jt2/AIuDKOewBIbmUNHUDV69XBZaGH9joQDAsBrV4LxrJ+EL+PGkAZCdageOT/sT5Fq/ n8uQ== X-Gm-Message-State: ALoCoQnTGEQWACVSnWVwouuN7caY4+pxRz5BzKWJKXHxaFO+FUiZyFD6L+rtMsoCdMLYpqFLNtmE MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr22996999lbp.88.1437930974153; Sun, 26 Jul 2015 10:16:14 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Jul 2015 10:16:14 -0700 (PDT) In-Reply-To: References: <20150726072614.GD16276@elstar.local> Date: Sun, 26 Jul 2015 10:16:14 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=001a113403d8ed2374051bca64cd Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 17:16:18 -0000 --001a113403d8ed2374051bca64cd Content-Type: text/plain; charset=UTF-8 On Sun, Jul 26, 2015 at 10:06 AM, Ersue, Mehmet (Nokia - DE/Munich) < mehmet.ersue@nokia.com> wrote: > I heard several times the argument that JSON would be the better choice > for IoT. > > Is RESTCONF indeed the right protocol for IoT? > > > > Those who favor the use of RESTCONF + JSON for IoT should elaborate their > use case. > > > I don't think anyone mentioned IoT in this thread. If the WEB client tools generate JSON only, then they want a server that supports JSON and do not care about XML. It is a tools choice before it is a message encoding choice. > Cheers, > Mehmet > Andy > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *ext Andy > Bierman > *Sent:* Sunday, July 26, 2015 6:44 PM > *To:* Juergen Schoenwaelder; Andy Bierman; Netconf > *Subject:* Re: [Netconf] RESTCONF #24:mandatory encoding revisited > > > > > > > > On Sun, Jul 26, 2015 at 12:26 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Sat, Jul 25, 2015 at 02:32:48PM -0700, Andy Bierman wrote: > > Hi, > > > > It would be good if we could close this issue soon. > > I am not in favor of changing the previous consensus call. > > > > At first I thought JSON would be good for RESTCONF, > > until I implemented it. It is not appropriate for streaming servers. > > The complexity and memory required and just as bad or worse > > than XML, especially once namespaces and attributes are > > added. > > > > JSON is fine if the entire document is in memory, > > but that's not how NETCONF/RESTCONF servers work. > > I would probably change my position from 'make XML mandatory' to leave > it undefined. I do see scenarios where servers will only do JSON > because this is what the clients they interact with expect. > > > > > > Could the XRD returned for the initial GET on /.well-known > > be used to return the encoding formats supported by the server? > > That way it will not cost an extra round-trip to find out if the > > server supports XML, JSON, or both. > > > > If so, I would also change my position. Let the market decide > > if it is acceptable to be a JSON-only server. > > > > > > /js > > > > Andy > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > --001a113403d8ed2374051bca64cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 26, 2015 at 10:06 AM, Ersue, Mehmet (Nokia - DE/Munich) <mehmet.ersue@nokia.com> wrote:

= I heard several times the argument that JSON wou= ld be the better choice for IoT.

= Is RESTCONF indeed the right protocol for IoT?

= =C2=A0

= Those who favor the use of RESTCONF + JSON for I= oT should elaborate their use case.

= =C2=A0



I don't think anyone mention= ed IoT in this thread.
If the WEB client tools generate JSON only= , then they
want a server that supports JSON and do not care abou= t XML.
It is a tools choice before it is a message encoding choic= e.

=C2=A0
=

= Cheers,
Mehmet



Andy

=C2=A0

= =C2=A0

From: Netconf [mailto:netconf-bounces@ietf.org] On Be= half Of ext Andy Bierman
Sent: Sunday, July 26, 2015 = 6:44 PM
To: Juergen Schoenwaelder; A= ndy Bierman; Netconf
Subject: Re: [Netconf] RESTC= ONF #24:mandatory encoding revisited

=C2=A0

=C2=A0

=C2=A0

On Sun, Jul 26, 2015 at 12:26 AM, Juergen Schoenwael= der <j.schoenwaelder@jacobs-university.de> wrote:

On Sat, Jul 25, 2015 = at 02:32:48PM -0700, Andy Bierman wrote:
> Hi,
>
> It would be good if we could close this issue soon.
> I am not in favor of changing the previous consensus call.
>
> At first I thought JSON would be good for RESTCONF,
> until I implemented it.=C2=A0 It is not appropriate for streaming serv= ers.
> The complexity and memory required and just as bad or worse
> than XML, especially once namespaces and attributes are
> added.
>
> JSON is fine if the entire document is in memory,
> but that's not how NETCONF/RESTCONF servers work.

I would probably change my position from 'make XML mandatory' to le= ave
it undefined. I do see scenarios where servers will only do JSON
because this is what the clients they interact with expect.

=C2=A0

=C2=A0

Could the XRD returned for the initial GET on =C2=A0= /.well-known

be used to return the encoding formats supported by = the server?

That way it will not cost an extra round-trip to fin= d out if the

server supports XML, JSON, or both.

=C2=A0

If so, I would also change my position. Let the mark= et decide

if it is acceptable to be a JSON-only server.=

=C2=A0

=C2=A0

/js

=C2=A0

Andy

=C2=A0


--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring = 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&l= t;http://www= .jacobs-university.de/>=

=C2=A0


--001a113403d8ed2374051bca64cd-- From nobody Sun Jul 26 12:33:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89DC1A8825 for ; Sun, 26 Jul 2015 12:33:09 -0700 (PDT) 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 0OXQ7MTuCakq for ; Sun, 26 Jul 2015 12:33:07 -0700 (PDT) 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 B84BF1A87F0 for ; Sun, 26 Jul 2015 12:33:06 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 597B7E651E74A for ; Sun, 26 Jul 2015 19:33:00 +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 t6QJX2wu023350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 26 Jul 2015 19:33:02 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sun, 26 Jul 2015 15:33:02 -0400 From: "Carey, Timothy (Timothy)" To: "netconf@ietf.org" Thread-Topic: Netconf Digest, Vol 89, Issue 33 Thread-Index: AQHQx8V+bzEAsGw09kCoR4bSH+mt2p3uI+Eg Date: Sun, 26 Jul 2015 19:33:01 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC225C0C@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Netconf Digest, Vol 89, Issue 33 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 19:33:09 -0000 I would indeed like to have the XML mandatory text relaxed leaving it undef= ined as Juergen suggested. BR, Tim -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of netconf-reques= t@ietf.org Sent: Sunday, July 26, 2015 7:06 PM To: netconf@ietf.org Subject: Netconf Digest, Vol 89, Issue 33 Send Netconf mailing list submissions to netconf@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/netconf or, via email, send a message with subject or body 'help' to netconf-request@ietf.org You can reach the person managing the list at netconf-owner@ietf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of Netconf digest..." Today's Topics: 1. RESTCONF #24:mandatory encoding revisited (Andy Bierman) 2. Re: RESTCONF #24:mandatory encoding revisited (Juergen Schoenwaelder) 3. Re: RESTCONF #24:mandatory encoding revisited (Andy Bierman) 4. Re: RESTCONF #24:mandatory encoding revisited (Ersue, Mehmet (Nokia - DE/Munich)) ---------------------------------------------------------------------- Message: 1 Date: Sat, 25 Jul 2015 14:32:48 -0700 From: Andy Bierman To: Netconf Subject: [Netconf] RESTCONF #24:mandatory encoding revisited Message-ID: Content-Type: text/plain; charset=3D"utf-8" Hi, It would be good if we could close this issue soon. I am not in favor of changing the previous consensus call. At first I thought JSON would be good for RESTCONF, until I implemented it.= It is not appropriate for streaming servers. The complexity and memory required and just as bad or worse than XML, espec= ially once namespaces and attributes are added. JSON is fine if the entire document is in memory, but that's not how NETCON= F/RESTCONF servers work. Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 26 Jul 2015 09:26:14 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Netconf Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited Message-ID: <20150726072614.GD16276@elstar.local> Content-Type: text/plain; charset=3Dus-ascii On Sat, Jul 25, 2015 at 02:32:48PM -0700, Andy Bierman wrote: > Hi, >=20 > It would be good if we could close this issue soon. > I am not in favor of changing the previous consensus call. >=20 > At first I thought JSON would be good for RESTCONF, until I=20 > implemented it. It is not appropriate for streaming servers. > The complexity and memory required and just as bad or worse than XML,=20 > especially once namespaces and attributes are added. >=20 > JSON is fine if the entire document is in memory, but that's not how=20 > NETCONF/RESTCONF servers work. I would probably change my position from 'make XML mandatory' to leave it u= ndefined. I do see scenarios where servers will only do JSON because this i= s what the clients they interact with expect. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ------------------------------ Message: 3 Date: Sun, 26 Jul 2015 09:43:36 -0700 From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited Message-ID: Content-Type: text/plain; charset=3D"utf-8" On Sun, Jul 26, 2015 at 12:26 AM, Juergen Schoenwaelder < j.schoenwaelder@j= acobs-university.de> wrote: > On Sat, Jul 25, 2015 at 02:32:48PM -0700, Andy Bierman wrote: > > Hi, > > > > It would be good if we could close this issue soon. > > I am not in favor of changing the previous consensus call. > > > > At first I thought JSON would be good for RESTCONF, until I=20 > > implemented it. It is not appropriate for streaming servers. > > The complexity and memory required and just as bad or worse than=20 > > XML, especially once namespaces and attributes are added. > > > > JSON is fine if the entire document is in memory, but that's not how=20 > > NETCONF/RESTCONF servers work. > > I would probably change my position from 'make XML mandatory' to leave=20 > it undefined. I do see scenarios where servers will only do JSON=20 > because this is what the clients they interact with expect. > > Could the XRD returned for the initial GET on /.well-known be used to retu= rn the encoding formats supported by the server? That way it will not cost an extra round-trip to find out if the server sup= ports XML, JSON, or both. If so, I would also change my position. Let the market decide if it is acce= ptable to be a JSON-only server. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Sun, 26 Jul 2015 17:06:14 +0000 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: ext Andy Bierman , Juergen Schoenwaelder , Netconf Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited Message-ID: Content-Type: text/plain; charset=3D"utf-8" I heard several times the argument that JSON would be the better choice for= IoT. Is RESTCONF indeed the right protocol for IoT? Those who favor the use of RESTCONF + JSON for IoT should elaborate their u= se case. Cheers, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierm= an Sent: Sunday, July 26, 2015 6:44 PM To: Juergen Schoenwaelder; Andy Bierman; Netconf Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited On Sun, Jul 26, 2015 at 12:26 AM, Juergen Schoenwaelder > wrote: On Sat, Jul 25, 2015 at 02:32:48PM -0700, Andy Bierman wrote: > Hi, > > It would be good if we could close this issue soon. > I am not in favor of changing the previous consensus call. > > At first I thought JSON would be good for RESTCONF, until I=20 > implemented it. It is not appropriate for streaming servers. > The complexity and memory required and just as bad or worse than XML,=20 > especially once namespaces and attributes are added. > > JSON is fine if the entire document is in memory, but that's not how=20 > NETCONF/RESTCONF servers work. I would probably change my position from 'make XML mandatory' to leave it u= ndefined. I do see scenarios where servers will only do JSON because this i= s what the clients they interact with expect. Could the XRD returned for the initial GET on /.well-known be used to retu= rn the encoding formats supported by the server? That way it will not cost an extra round-trip to find out if the server sup= ports XML, JSON, or both. If so, I would also change my position. Let the market decide if it is acce= ptable to be a JSON-only server. /js Andy -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------------------------------ End of Netconf Digest, Vol 89, Issue 33 *************************************** From nobody Mon Jul 27 00:21:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC071ACE3B for ; Mon, 27 Jul 2015 00:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 6tRRtIX4uo5x for ; Mon, 27 Jul 2015 00:21:31 -0700 (PDT) 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 2EBF91ACE5D for ; Mon, 27 Jul 2015 00:21:31 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id D61191A6BB5C9; Mon, 27 Jul 2015 07:21:26 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6R7LRm1015596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 09:21:28 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 09:21:27 +0200 From: "Scharf, Michael (Michael)" To: Andy Bierman , Netconf Thread-Topic: [Netconf] RESTCONF #24:mandatory encoding revisited Thread-Index: AQHQxyF54EgSS2QHEUWb4et7dg8mep3u51lw Date: Mon, 27 Jul 2015 07:21:27 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4843B843@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D4843B843FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 07:21:35 -0000 --_000_655C07320163294895BBADA28372AF5D4843B843FR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBtaWdodCBiZSB3cm9uZywgYnV0IHRoaXMgbWF5IGRlcGVuZCBxdWl0ZSBhIGJpdCBvbiB0aGUg aW1wbGVtZW50YXRpb24uIEZvciBpbnN0YW5jZSwgdGhlcmUgYXJlIGFsc28gY2xhaW1zIHRoYXQg SlNPTiBzZXJpYWxpemF0aW9uIGlzIG11Y2ggbW9yZSBlZmZpY2llbnQ6IGh0dHA6Ly93d3cuY29k ZXByb2plY3QuY29tL0FydGljbGVzLzYwNDcyMC9KU09OLXZzLVhNTC1Tb21lLWhhcmQtbnVtYmVy cy1hYm91dC12ZXJib3NpdHkNCihzZWUgYWxzbyB0aGUgY29tbWVudHMgdGhlcmVpbiDigJMgYnV0 IEkgaGF2ZSBub3QgdmVyaWZpZWQgdGhlc2UgbnVtYmVycykNCg0KSSB0aGluayBpbiBxdWl0ZSBh IG51bWJlciB1c2UgY2FzZXMgaXQgd2lsbCBiZSB3ZWxsLWtub3duIGEgcHJpb3JpIHdoaWNoIGVu Y29kaW5nIHRoZSBzZXJ2ZXIgc3VwcG9ydHMsIGFuZCBJIGV4cGVjdCB0aGF0IGluIHNvbWUgb2Yg dGhlbSBKU09OIHdpbGwgYmUgcHJlZmVycmVkLiBZZXQsIGlmIHRoZXJlIHdhcyBhIHNpbXBsZSBh bmQgZmFzdCB3YXkgdG8gZGV0ZXJtaW5lIHRoZSBzdXBwb3J0ZWQgZW5jb2RpbmcsIHRoYXQgY291 bGQgcGVyaGFwcyBiZSB1c2VmdWwuDQoNCk9uZSBjb3VsZCBhbHNvIHRyeSB0byBmaW5kIGEgd29y ZGluZyB0aGF0IFJFQ09NTUVORHMgdGhlIHN1cHBvcnQgb2YgWE1MIGZvciB1c2UgY2FzZXMgaW4g d2hpY2ggaXQgaXMgbm90IGEgcHJpb3JpIGtub3duIHRoYXQgdGhlIGNsaWVudCBleHBlY3RzIEpT T04gYW5kIHdpbGwgb25seSB1c2UgSlNPTi4NCg0KTWljaGFlbA0KDQoNCg0KRnJvbTogTmV0Y29u ZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgQmll cm1hbg0KU2VudDogU2F0dXJkYXksIEp1bHkgMjUsIDIwMTUgMTE6MzMgUE0NClRvOiBOZXRjb25m DQpTdWJqZWN0OiBbTmV0Y29uZl0gUkVTVENPTkYgIzI0Om1hbmRhdG9yeSBlbmNvZGluZyByZXZp c2l0ZWQNCg0KSGksDQoNCkl0IHdvdWxkIGJlIGdvb2QgaWYgd2UgY291bGQgY2xvc2UgdGhpcyBp c3N1ZSBzb29uLg0KSSBhbSBub3QgaW4gZmF2b3Igb2YgY2hhbmdpbmcgdGhlIHByZXZpb3VzIGNv bnNlbnN1cyBjYWxsLg0KDQpBdCBmaXJzdCBJIHRob3VnaHQgSlNPTiB3b3VsZCBiZSBnb29kIGZv ciBSRVNUQ09ORiwNCnVudGlsIEkgaW1wbGVtZW50ZWQgaXQuICBJdCBpcyBub3QgYXBwcm9wcmlh dGUgZm9yIHN0cmVhbWluZyBzZXJ2ZXJzLg0KVGhlIGNvbXBsZXhpdHkgYW5kIG1lbW9yeSByZXF1 aXJlZCBhbmQganVzdCBhcyBiYWQgb3Igd29yc2UNCnRoYW4gWE1MLCBlc3BlY2lhbGx5IG9uY2Ug bmFtZXNwYWNlcyBhbmQgYXR0cmlidXRlcyBhcmUNCmFkZGVkLg0KDQpKU09OIGlzIGZpbmUgaWYg dGhlIGVudGlyZSBkb2N1bWVudCBpcyBpbiBtZW1vcnksDQpidXQgdGhhdCdzIG5vdCBob3cgTkVU Q09ORi9SRVNUQ09ORiBzZXJ2ZXJzIHdvcmsuDQoNCg0KQW5keQ0KDQoNCg0KDQo= --_000_655C07320163294895BBADA28372AF5D4843B843FR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RS1NYWlsRm9ybWF0dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgbWlnaHQg YmUgd3JvbmcsIGJ1dCB0aGlzIG1heSBkZXBlbmQgcXVpdGUgYSBiaXQgb24gdGhlIGltcGxlbWVu dGF0aW9uLiBGb3IgaW5zdGFuY2UsIHRoZXJlIGFyZSBhbHNvIGNsYWltcyB0aGF0IEpTT04gc2Vy aWFsaXphdGlvbiBpcyBtdWNoIG1vcmUNCiBlZmZpY2llbnQ6IDxhIGhyZWY9Imh0dHA6Ly93d3cu Y29kZXByb2plY3QuY29tL0FydGljbGVzLzYwNDcyMC9KU09OLXZzLVhNTC1Tb21lLWhhcmQtbnVt YmVycy1hYm91dC12ZXJib3NpdHkiPg0KaHR0cDovL3d3dy5jb2RlcHJvamVjdC5jb20vQXJ0aWNs ZXMvNjA0NzIwL0pTT04tdnMtWE1MLVNvbWUtaGFyZC1udW1iZXJzLWFib3V0LXZlcmJvc2l0eTwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihzZWUgYWxzbyB0 aGUgY29tbWVudHMgdGhlcmVpbiDigJMgYnV0IEkgaGF2ZSBub3QgdmVyaWZpZWQgdGhlc2UgbnVt YmVycyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBpbiBxdWl0 ZSBhIG51bWJlciB1c2UgY2FzZXMgaXQgd2lsbCBiZSB3ZWxsLWtub3duIGEgcHJpb3JpIHdoaWNo IGVuY29kaW5nIHRoZSBzZXJ2ZXIgc3VwcG9ydHMsIGFuZCBJIGV4cGVjdCB0aGF0IGluIHNvbWUg b2YgdGhlbSBKU09OIHdpbGwNCiBiZSBwcmVmZXJyZWQuIFlldCwgaWYgdGhlcmUgd2FzIGEgc2lt cGxlIGFuZCBmYXN0IHdheSB0byBkZXRlcm1pbmUgdGhlIHN1cHBvcnRlZCBlbmNvZGluZywgdGhh dCBjb3VsZCBwZXJoYXBzIGJlIHVzZWZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+T25lIGNvdWxkIGFsc28gdHJ5IHRvIGZpbmQgYSB3b3JkaW5nIHRoYXQgUkVDT01NRU5E cyB0aGUgc3VwcG9ydCBvZiBYTUwgZm9yIHVzZSBjYXNlcyBpbiB3aGljaCBpdCBpcyBub3QgYSBw cmlvcmkga25vd24gdGhhdCB0aGUgY2xpZW50IGV4cGVjdHMNCiBKU09OIGFuZCB3aWxsIG9ubHkg dXNlIEpTT04uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBOZXRjb25mIFttYWlsdG86 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJt YW48YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1bHkgMjUsIDIwMTUgMTE6MzMgUE08YnI+ DQo8Yj5Ubzo8L2I+IE5ldGNvbmY8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW05ldGNvbmZdIFJFU1RD T05GICMyNDptYW5kYXRvcnkgZW5jb2RpbmcgcmV2aXNpdGVkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQgYmUgZ29vZCBpZiB3ZSBjb3VsZCBj bG9zZSB0aGlzIGlzc3VlIHNvb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBpbiBmYXZvciBvZiBjaGFuZ2luZyB0aGUgcHJldmlv dXMgY29uc2Vuc3VzIGNhbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkF0IGZpcnN0IEkgdGhvdWdodCBKU09OIHdvdWxkIGJlIGdvb2QgZm9y IFJFU1RDT05GLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+dW50aWwgSSBpbXBsZW1lbnRlZCBpdC4mbmJzcDsgSXQgaXMgbm90IGFwcHJvcHJpYXRl IGZvciBzdHJlYW1pbmcgc2VydmVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjb21wbGV4aXR5IGFuZCBtZW1vcnkgcmVxdWlyZWQgYW5k IGp1c3QgYXMgYmFkIG9yIHdvcnNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj50aGFuIFhNTCwgZXNwZWNpYWxseSBvbmNlIG5hbWVzcGFjZXMgYW5k IGF0dHJpYnV0ZXMgYXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5hZGRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SlNPTiBpcyBmaW5lIGlmIHRoZSBlbnRpcmUgZG9jdW1lbnQgaXMgaW4g bWVtb3J5LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+YnV0IHRoYXQncyBub3QgaG93IE5FVENPTkYvUkVTVENPTkYgc2VydmVycyB3b3JrLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_655C07320163294895BBADA28372AF5D4843B843FR712WXCHMBA15z_-- From nobody Wed Jul 29 01:55:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6CB1A0029 for ; Wed, 29 Jul 2015 01:55:15 -0700 (PDT) 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 zo-oZUoRCMs1 for ; Wed, 29 Jul 2015 01:55:14 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 368EC1A000F for ; Wed, 29 Jul 2015 01:55:14 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8C9801CC008C; Wed, 29 Jul 2015 10:55:14 +0200 (CEST) From: Ladislav Lhotka To: "Ersue\, Mehmet \(Nokia - DE\/Munich\)" , "netconf\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 29 Jul 2015 10:55:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Netconf] Summary and AIs from the NETCONF Session in IETF #93 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 08:55:16 -0000 "Ersue, Mehmet (Nokia - DE/Munich)" writes: > Dear Benoit, NETCONF WG, > > below is a summary and action items from the NETCONF WG session on July 23, 2015 in Prague, Czech Republic. > > - We had approx. 65+ participants in the 2 hour NETCONF session, > - We reviewed the status of the WG, > - We had a discussion on 7 chartered documents. > > - Many thanks to the note takers: ext Radek Krejci and Mike Leske and the jabber scribe: Juergen Schoenwaelder. > > The session agenda is available at: https://www.ietf.org/proceedings/93/agenda/agenda-93-netconf > > Following is a summary of the discussion and the decisions taken per show-hands. > > This mail is at the same time to verify the discussion result and decisions from the IETF 93 NETCONF session. > If there is no strong objection we will implement as discussed. > > - After WG LC Call Home will go to AD review. Write-up will be provided by the shepherd (Mahesh). > > - Server Model: The duplication of data in server model has been discussed with 4 optional solutions. Option 4 based on key chains has been proposed. Many WG member are in favor. Nobody against. > This option requires a delay of the work and some part needs to be done in Security area. > Kent to provide a proposal for the way forward describing how to address option 4 with key chains and the work split with SEC area. > > - Restconf issues have been discussed. Agreed to use the current YANG 1.1 draft instead of YANG 1.0 and finalize issues in Restconf with this basis. The goal is to go to LC with this basis asap. > - Different folks would like to have JSON as additional encoding. This > discussion has been separated in the sake of time usage and will be > brought to the maillist. I think the real issue here is that support for XML should not be mandatory. Lada > > - Remaining YANG Patch and YANG Library issues will be solved soon and WG LC is the next step. > > - Pub/Sub Solution draft. > WG supports adoption, no objections. ADs recommended to not wait. The co-chairs support the adoption. It'll be verified on the maillist. > > - I2RS requirements have been discussed. Issues have been clarified in two steps first in NETCONF and then in I2RS session. > > > Regards, > Mehmet & Mahesh > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 02:14:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABF01A00E6 for ; Wed, 29 Jul 2015 02:14:28 -0700 (PDT) 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 DFC2n078AkyJ for ; Wed, 29 Jul 2015 02:14:27 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 402151A00DD for ; Wed, 29 Jul 2015 02:14:27 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id D9EFB1CC008C; Wed, 29 Jul 2015 11:14:26 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Netconf In-Reply-To: References: User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 29 Jul 2015 11:14:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 09:14:29 -0000 Andy Bierman writes: > Hi, > > It would be good if we could close this issue soon. > I am not in favor of changing the previous consensus call. I am in favor of changing it. The consensus call that was done before Honolulu meeting was IMO very problematic and I had strong objections against it - the opinions were 10:7 in favor of making XML mandatory. See this thread: https://mailarchive.ietf.org/arch/search/?email_list=netconf&gbt=1&index=8EhIVndveGw2QrHTefsYsADPC6Y Recently, other people expressed their preference, and explained technical reasons, for NOT doing so. > > At first I thought JSON would be good for RESTCONF, > until I implemented it. It is not appropriate for streaming servers. > The complexity and memory required and just as bad or worse > than XML, especially once namespaces and attributes are > added. Not all servers need to stream data. > > JSON is fine if the entire document is in memory, > but that's not how NETCONF/RESTCONF servers work. You probably mean your NETCONF/RESTCONF servers. Small devices have configurations that easily fit into memory, and small devices are exactly those for which XML support is a considerable burden. Lada > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 03:42:31 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510651A1EED for ; Wed, 29 Jul 2015 03:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 YsTNf_AuXvz6 for ; Wed, 29 Jul 2015 03:42:27 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B2B1A0110 for ; Wed, 29 Jul 2015 03:42:27 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so194938558wib.0 for ; Wed, 29 Jul 2015 03:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iPi8qKSMJ05Dav0hAR34IavctwhkcPzU+oMQCzPLCdI=; b=DxuWvTpmISfDCfRtgwvbFoQlshqoiMGGbihUdhC+UdvOZGC3kXjcuDJ+uNll6I4lSO +j9E/JrRrb8GFZcOpsdra6kz78f8v2wUucopOkogmmAAEJa9uU/WJuhGGI6Vgyx59p5j rW5CXIQmRvXId9sOm5azVUzSUJ7J1CXksO933bpDD64G/WuAFBKb51FOLK01wVkNhLCh 0gFFkyHoxd4roqzL6sNnpqqfLlCyOj8NZAqASl8hxZbSBjEFsFDbWHbkHZKl9b3IIyLo Kt9S0SF8jm3yZJI0eExgKo1CpoUAjtjGURJ90HdV+LZMNFD+y4+7np/JVRgm4TQqsPv2 ZfqQ== X-Received: by 10.194.185.8 with SMTP id ey8mr75419498wjc.118.1438166546067; Wed, 29 Jul 2015 03:42:26 -0700 (PDT) Received: from [192.168.254.80] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id lm16sm22244485wic.18.2015.07.29.03.42.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jul 2015 03:42:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Dean Bogdanovic In-Reply-To: Date: Wed, 29 Jul 2015 12:42:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9A9DDE29-ABAA-4EE8-AFBE-E318B3BE8D23@gmail.com> References: To: Ladislav Lhotka X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 10:42:29 -0000 I agree it will depend on case by case. For big networking devices with = large schemas, XML might be better, as it is easier to extract deep = nested information. For devices with simple schema, like IoT case, JSON = might be the right answer. IMO, XML should be recommended, but there shouldn=E2=80=99t be anything = preventing server to offer JSON only Dean > On Jul 29, 2015, at 11:14 AM, Ladislav Lhotka wrote: >=20 > Andy Bierman writes: >=20 >> Hi, >>=20 >> It would be good if we could close this issue soon. >> I am not in favor of changing the previous consensus call. >=20 > I am in favor of changing it. The consensus call that was done before > Honolulu meeting was IMO very problematic and I had strong objections > against it - the opinions were 10:7 in favor of making XML mandatory. >=20 > See this thread: >=20 > = https://mailarchive.ietf.org/arch/search/?email_list=3Dnetconf&gbt=3D1&ind= ex=3D8EhIVndveGw2QrHTefsYsADPC6Y >=20 > Recently, other people expressed their preference, and explained > technical reasons, for NOT doing so. >=20 >>=20 >> At first I thought JSON would be good for RESTCONF, >> until I implemented it. It is not appropriate for streaming servers. >> The complexity and memory required and just as bad or worse >> than XML, especially once namespaces and attributes are >> added. >=20 > Not all servers need to stream data. >=20 >>=20 >> JSON is fine if the entire document is in memory, >> but that's not how NETCONF/RESTCONF servers work. >=20 > You probably mean your NETCONF/RESTCONF servers. Small devices have > configurations that easily fit into memory, and small devices are > exactly those for which XML support is a considerable burden. >=20 > Lada >=20 >>=20 >>=20 >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 29 14:16:02 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C264E1ACDA9 for ; Wed, 29 Jul 2015 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wDFrCOBNwmJz for ; Wed, 29 Jul 2015 14:15:59 -0700 (PDT) Received: from smtp84.iad3a.emailsrvr.com (smtp84.iad3a.emailsrvr.com [173.203.187.84]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00FF1B2BE9 for ; Wed, 29 Jul 2015 14:15:54 -0700 (PDT) Received: from smtp27.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E6794180163; Wed, 29 Jul 2015 17:15:53 -0400 (EDT) Received: by smtp27.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id EBBC718030F; Wed, 29 Jul 2015 17:15:51 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Wed, 29 Jul 2015 21:15:53 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_08155B96-9374-4C8C-B080-406CA3DF0941" Date: Wed, 29 Jul 2015 17:15:51 -0400 Message-Id: To: ietf , netconf@ietf.org, draft-mm-netconf-time-capability.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Cc: secdir@ietf.org Subject: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 21:16:00 -0000 --Apple-Mail=_08155B96-9374-4C8C-B080-406CA3DF0941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document is ready for publication The document is well written. The security considerations are clear and accurate. I would like = highlight one omission though. =20 This capability allows an attacker once it has gained access to schedule = events in the future even=20 though attackers access has been detected and revoked.=20 Olafur=20= --Apple-Mail=_08155B96-9374-4C8C-B080-406CA3DF0941 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I have reviewed = this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed = by the 
IESG.  These comments were written = primarily for the benefit of the 
security area = directors.  Document editors and WG chairs should = treat 
these comments just like any other last = call comments.

This document is = ready for publication
The document is well written.
The security considerations are clear = and accurate. I would like highlight one omission though. =  
This capability allows an attacker once it has gained = access to schedule events in the future even 
though attackers access has been detected and = revoked. 

Olafur 
= --Apple-Mail=_08155B96-9374-4C8C-B080-406CA3DF0941-- From nobody Wed Jul 29 14:39:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D491B2D9C for ; Wed, 29 Jul 2015 14:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 xnUqyEzlWAja for ; Wed, 29 Jul 2015 14:39:54 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 B6DED1B2DA4 for ; Wed, 29 Jul 2015 14:39:43 -0700 (PDT) Received: by lblf12 with SMTP id f12so15508434lbl.2 for ; Wed, 29 Jul 2015 14:39:42 -0700 (PDT) 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=3SSd7U0mfpRtILoNxpZr4mNRqP4/6E8RAuaYIFoidz0=; b=iOq2JDeNmQKy6HPjDLmuLn2XOY4uePXbSbRB7lutdGe0lpxwdK3+UE9ua+kE1dWOVX GmOvAJ19b+OXPXgzKqBJQ/e4QDpRg9c79OGI3a4RcrDEcJhvllJZ6gOBvnEyO4fQUMrN JQZymN06xyn4odz8NJrgmACfoxU1f20RAWrMMzUZyf6BRwJKytOusP/CQPyr7OJ6E0ov gZEGhXiOD2DGN1PuyMh8cqMu3dfpfuMeG1ZZ6fgO9ISs8JqfWYMPY4RQHiwXKp/UhXdB FvgqpMRTLjGADnU1O6PF9GuGJcCJy6vGVQW8QiSzQyVbAyVqyTFfa9gT2Jijd9BnWc0s KT6A== X-Gm-Message-State: ALoCoQl4VNvhFdmdHM4FoGgNj0LYKsxitxRSk1HUzt4LD4toGJRYMKgokRytXCFxMJrXqRh9abJA MIME-Version: 1.0 X-Received: by 10.152.87.205 with SMTP id ba13mr39778711lab.37.1438205982133; Wed, 29 Jul 2015 14:39:42 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 29 Jul 2015 14:39:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2015 14:39:42 -0700 Message-ID: From: Andy Bierman To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=001a11c3539aade3af051c0a6c2e Archived-At: Cc: secdir@ietf.org, draft-mm-netconf-time-capability.all@ietf.org, ietf , Netconf Subject: Re: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 21:39:55 -0000 --001a11c3539aade3af051c0a6c2e Content-Type: text/plain; charset=UTF-8 Hi, I am curious if this is a security concern. When an event is scheduled, the ID and its scheduled time are sent out in a notification to potentially all clients. notification netconf-scheduled-message { leaf schedule-id { type string; description "The ID of the scheduled message."; } leaf scheduled-time { type yang:date-and-time; description "The time at which the RPC is scheduled to be performed."; } description "Indicates that a scheduled message was received."; reference "draft-mm-netconf-time-capability : Time Capability in NETCONF"; } Any client can get these notifications and know the ID (to cancel it) and the scheduled time. Is is a security issue that any client can get the schedule-id and use it to cancel the scheduled RPC? Andy On Wed, Jul 29, 2015 at 2:15 PM, Olafur Gudmundsson wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document is ready for publication > The document is well written. > > The security considerations are clear and accurate. I would like highlight > one omission though. > This capability allows an attacker once it has gained access to schedule > events in the future even > though attackers access has been detected and revoked. > > Olafur > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c3539aade3af051c0a6c2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am curious if this is a security = concern.
When an event is scheduled, the ID and its scheduled tim= e
are sent out in a notification to potentially all clients.

notification netc=
onf-scheduled-message {
        leaf schedule-id {
          type string;
          description
            "The ID of the scheduled message.";
        }

        leaf scheduled-time {
          type yang:date-and-time;
          description
            "The time at which the RPC is scheduled to be performed.&q=
uot;;
        }

        description
          "Indicates that a scheduled message was received.";

        reference
          "draft-mm-netconf-time-capability:
           Time Capability in NETCONF";
      }


Any client can get these n= otifications and know the ID (to cancel it)
and the scheduled time.

Is is a security issue that any client can get the sched= ule-id
and use it to cancel the scheduled R= PC?

Andy

On Wed, Ju= l 29, 2015 at 2:15 PM, Olafur Gudmundsson <ogud@ogud.com> wrote:=
I have reviewed this= document as part of the security directorate's=C2=A0
ongoing effort to review a= ll IETF documents being processed by the=C2=A0
IESG.=C2=A0 These comments were written= primarily for the benefit of the=C2=A0
security area directors.=C2=A0 Document editor= s and WG chairs should treat=C2=A0
these comments just like any other last call commen= ts.

This document= is ready for publication
The document is well written.

The security considerations are clear and accur= ate. I would like highlight one omission though. =C2=A0
This capability allows an atta= cker once it has gained access to schedule events in the future even=C2=A0<= /div>
though atta= ckers access has been detected and revoked.=C2=A0

Olafur=C2=A0

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


--001a11c3539aade3af051c0a6c2e-- From nobody Wed Jul 29 14:52:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F98C1B2DA8 for ; Wed, 29 Jul 2015 14:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7UFNW2mRIDCp for ; Wed, 29 Jul 2015 14:52:37 -0700 (PDT) Received: from ni.com (skprod2.natinst.com [130.164.80.23]) (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 0D00D1B2BCF for ; Wed, 29 Jul 2015 14:52:36 -0700 (PDT) Received: from US-AUS-MAIL4.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod2.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id t6TLqa8V028465; Wed, 29 Jul 2015 16:52:36 -0500 In-Reply-To: References: <20150726072614.GD16276@elstar.local> To: "Ersue, Mehmet (Nokia - DE/Munich)" MIME-Version: 1.0 X-KeepSent: FC51B66B:02615053-86257E91:007594E6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP6 November 22, 2013 From: Rodney Cummings Message-ID: Date: Wed, 29 Jul 2015 16:52:36 -0500 X-MIMETrack: Serialize by Router on US-AUS-MAIL4/AUS/M/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 07/29/2015 04:52:36 PM, Serialize complete at 07/29/2015 04:52:36 PM Content-Type: multipart/alternative; boundary="=_alternative 00782BA786257E91_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-07-29_11:, , signatures=0 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 21:52:39 -0000 This is a multipart message in MIME format. --=_alternative 00782BA786257E91_= Content-Type: text/plain; charset="US-ASCII" Hi Mehmet, I'm not so certain that IoT has a specific use case per se. The problem is that IoT devices generally do not implement multiple options... they tend to focus on the minimal set of features that are required. For RESTful web services in general, correct me if I am wrong, but XML is not mandated, and JSON is not mandated. A device could implement both, but for IoT, it is more likely that a device will implement only one. If an IoT device has already implemented RESTful web services using XML (only), and that IoT device needs to add YANG management support as a server, then RESTCONF is very appealing. If an IoT device has already implemented RESTful web services using JSON (only), and that IoT device needs to add YANG management support as a server, then RESTCONF is not applicable as specified in the current draft. Regardless of the arguments pro or con, this IoT device simply will not change from JSON to XML. Thanks, Rodney "Netconf" wrote on 07/26/2015 12:06:14 PM: > From: "Ersue, Mehmet (Nokia - DE/Munich)" > To: ext Andy Bierman , Juergen Schoenwaelder > , Netconf , > Date: 07/26/2015 12:06 PM > Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited > Sent by: "Netconf" > > I heard several times the argument that JSON would be the better > choice for IoT. > Is RESTCONF indeed the right protocol for IoT? > > Those who favor the use of RESTCONF + JSON for IoT should elaborate > their use case. > > Cheers, > Mehmet > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Sunday, July 26, 2015 6:44 PM > To: Juergen Schoenwaelder; Andy Bierman; Netconf > Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited > > > > On Sun, Jul 26, 2015 at 12:26 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > On Sat, Jul 25, 2015 at 02:32:48PM -0700, Andy Bierman wrote: > > Hi, > > > > It would be good if we could close this issue soon. > > I am not in favor of changing the previous consensus call. > > > > At first I thought JSON would be good for RESTCONF, > > until I implemented it. It is not appropriate for streaming servers. > > The complexity and memory required and just as bad or worse > > than XML, especially once namespaces and attributes are > > added. > > > > JSON is fine if the entire document is in memory, > > but that's not how NETCONF/RESTCONF servers work. > > I would probably change my position from 'make XML mandatory' to leave > it undefined. I do see scenarios where servers will only do JSON > because this is what the clients they interact with expect. > > > Could the XRD returned for the initial GET on /.well-known > be used to return the encoding formats supported by the server? > That way it will not cost an extra round-trip to find out if the > server supports XML, JSON, or both. > > If so, I would also change my position. Let the market decide > if it is acceptable to be a JSON-only server. > > > /js > > Andy > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=_alternative 00782BA786257E91_= Content-Type: text/html; charset="US-ASCII" Hi Mehmet,

I'm not so certain that IoT has a specific use case per se. The problem is that IoT devices generally do not implement multiple options... they tend to focus on the minimal set of features that are required.

For RESTful web services in general, correct me if I am wrong, but XML is not mandated, and JSON is not mandated. A device could implement both, but for IoT, it is more likely that a device will implement only one.

If an IoT device has already implemented RESTful web services using XML (only), and that IoT device needs to add YANG management support as a server, then RESTCONF is very appealing.

If an IoT device  has already implemented RESTful web services using JSON (only), and that IoT device needs to add YANG management support as a server, then RESTCONF is not applicable as specified in the current draft. Regardless of the arguments pro or con, this IoT device simply will not change from JSON to XML.

Thanks,
Rodney

"Netconf" <netconf-bounces@ietf.org> wrote on 07/26/2015 12:06:14 PM:

> From: "Ersue, Mehmet (Nokia - DE/Munich)" <mehmet.ersue@nokia.com>
> To: ext Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de>, Netconf <netconf@ietf.org>,
> Date: 07/26/2015 12:06 PM
> Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited
> Sent by: "Netconf" <netconf-bounces@ietf.org>
>
> I heard several times the argument that JSON would be the better
> choice for IoT.
> Is RESTCONF indeed the right protocol for IoT?
>  
> Those who favor the use of RESTCONF + JSON for IoT should elaborate
> their use case.
>  
> Cheers,
> Mehmet
>  
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman
> Sent: Sunday, July 26, 2015 6:44 PM
> To: Juergen Schoenwaelder; Andy Bierman; Netconf
> Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited
>  
>  
>  
> On Sun, Jul 26, 2015 at 12:26 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> On Sat, Jul 25, 2015 at 02:32:48PM -0700, Andy Bierman wrote:
> > Hi,
> >
> > It would be good if we could close this issue soon.
> > I am not in favor of changing the previous consensus call.
> >
> > At first I thought JSON would be good for RESTCONF,
> > until I implemented it.  It is not appropriate for streaming servers.
> > The complexity and memory required and just as bad or worse
> > than XML, especially once namespaces and attributes are
> > added.
> >
> > JSON is fine if the entire document is in memory,
> > but that's not how NETCONF/RESTCONF servers work.
>
> I would probably change my position from 'make XML mandatory' to leave
> it undefined. I do see scenarios where servers will only do JSON
> because this is what the clients they interact with expect.
>  
>  
> Could the XRD returned for the initial GET on  /.well-known
> be used to return the encoding formats supported by the server?
> That way it will not cost an extra round-trip to find out if the
> server supports XML, JSON, or both.
>  
> If so, I would also change my position. Let the market decide
> if it is acceptable to be a JSON-only server.
>  
>  
> /js
>  
> Andy
>  
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>  _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
 --=_alternative 00782BA786257E91_=-- From nobody Wed Jul 29 23:43:14 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FD41A8849; Wed, 29 Jul 2015 23:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 FVTLXE9zgHgH; Wed, 29 Jul 2015 23:43:08 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 2D9231A870F; Wed, 29 Jul 2015 23:43:08 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t6U6YfdI024771; Wed, 29 Jul 2015 23:43:07 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 1vv91rpu8d-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jul 2015 23:43:06 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 30 Jul 2015 09:43:03 +0300 Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Thu, 30 Jul 2015 09:43:03 +0300 From: Tal Mizrahi To: Andy Bierman , Olafur Gudmundsson Thread-Topic: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx Thread-Index: AQHQykcigNupE2ajyEaQCVpIBzXexJ3zkGIg Date: Thu, 30 Jul 2015 06:43:02 +0000 Message-ID: <0960eb5365954b73afde1c70ba5164a0@IL-EXCH01.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_0960eb5365954b73afde1c70ba5164a0ILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-07-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1507300120 Archived-At: Cc: Netconf , "draft-mm-netconf-time-capability.all@ietf.org" , ietf , "secdir@ietf.org" Subject: Re: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 06:43:10 -0000 --_000_0960eb5365954b73afde1c70ba5164a0ILEXCH01marvellcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KWW91IG1ha2UgYSBnb29kIHBvaW50Lg0KV2UgaW50ZW5kIHRvIGFkZCB0ZXh0 IChzZWUgYmVsb3cpIHRoYXQgZGVzY3JpYmVzIHRoaXMgcG9pbnQgaW4gdGhlIG5leHQgdmVyc2lv biBvZiB0aGUgZHJhZnQuDQpQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgZnVydGhlciBj b21tZW50cy4NCg0KDQpIZXJlIGlzIHRoZSB1cGRhdGVkIHRleHQgb24gdGhlIGxhc3QgcGFyYWdy YXBoIG9mIHRoZSBzZWN1cml0eSBzZWN0aW9uOg0KDQpUaGlzIFlBTkcgbW9kdWxlIGRlZmluZXMg dGhlIDxjYW5jZWwtc2NoZWR1bGU+IFJQQy4gVGhpcyBSUEMgbWF5IGJlIGNvbnNpZGVyZWQgc2Vu c2l0aXZlIG9yIHZ1bG5lcmFibGUgaW4gc29tZSBuZXR3b3JrIGVudmlyb25tZW50cy4gU2luY2Ug dGhlIHZhbHVlIG9mIHRoZSA8c2NoZWR1bGUtaWQ+IGlzIGtub3duIHRvIGFsbCB0aGUgY2xpZW50 cyB0aGF0IGFyZSBzdWJzY3JpYmVkIHRvIG5vdGlmaWNhdGlvbnMgZnJvbSB0aGUgc2VydmVyLCB0 aGUgPGNhbmNlbC1zY2hlZHVsZT4gUlBDIG1heSBiZSB1c2VkIG1hbGljaW91c2x5IHRvIGF0dGFj ayBzZXJ2ZXJzIGJ5IGNhbmNlbGluZyB0aGVpciBwZW5kaW5nIFJQQ3MuIFRoaXMgYXR0YWNrIGlz IGFkZHJlc3NlZCBpbiB0d28gbGF5ZXJzOiAoaSkgc2VjdXJpdHkgYXQgdGhlIHRyYW5zcG9ydCBs YXllciwgbGltaXRpbmcgdGhlIGF0dGFjayBvbmx5IHRvIGNsaWVudHMgdGhhdCBoYXZlIHN1Y2Nl c3NmdWxseSBpbml0aWF0ZWQgYSBzZWN1cmUgc2Vzc2lvbiB3aXRoIHRoZSBzZXJ2ZXIsIGFuZCAo aWkpIHRoZSBhdXRob3JpemF0aW9uIGxldmVsIHJlcXVpcmVkIHRvIGNhbmNlbCBhbiBSUEMgc2hv dWxkIGJlIHRoZSBzYW1lIGFzIHRoZSBsZXZlbCByZXF1aXJlZCB0byBzY2hlZHVsZSBpdCwgbGlt aXRpbmcgdGhlIGF0dGFjayBvbmx5IHRvIGF0dGFja2VycyB3aXRoIGFuIGF1dGhvcml6YXRpb24g bGV2ZWwgdGhhdCBpcyBlcXVhbCB0byBvciBoaWdoZXIgdGhhbiB0aGF0IG9mIHRoZSBjbGllbnQg dGhhdCBpbml0aWF0ZWQgdGhlIHNjaGVkdWxlZCBSUEMuDQoNCg0KVGhhbmtzLA0KVGFsLg0KDQoN CkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDMwLCAyMDE1IDEyOjQwIEFN DQpUbzogT2xhZnVyIEd1ZG11bmRzc29uDQpDYzogc2VjZGlyQGlldGYub3JnOyBkcmFmdC1tbS1u ZXRjb25mLXRpbWUtY2FwYWJpbGl0eS5hbGxAaWV0Zi5vcmc7IGlldGY7IE5ldGNvbmYNClN1Ympl Y3Q6IFJlOiBbTmV0Y29uZl0gU2VjLURpciBSZXZpZXc6IGRyYWZ0LW1tLW5ldGNvbmYtdGltZS1j YXBhYmlsaXR5LTA1LnR4DQoNCkhpLA0KDQpJIGFtIGN1cmlvdXMgaWYgdGhpcyBpcyBhIHNlY3Vy aXR5IGNvbmNlcm4uDQpXaGVuIGFuIGV2ZW50IGlzIHNjaGVkdWxlZCwgdGhlIElEIGFuZCBpdHMg c2NoZWR1bGVkIHRpbWUNCmFyZSBzZW50IG91dCBpbiBhIG5vdGlmaWNhdGlvbiB0byBwb3RlbnRp YWxseSBhbGwgY2xpZW50cy4NCg0KDQpub3RpZmljYXRpb24gbmV0Y29uZi1zY2hlZHVsZWQtbWVz c2FnZSB7DQoNCiAgICAgICAgbGVhZiBzY2hlZHVsZS1pZCB7DQoNCiAgICAgICAgICB0eXBlIHN0 cmluZzsNCg0KICAgICAgICAgIGRlc2NyaXB0aW9uDQoNCiAgICAgICAgICAgICJUaGUgSUQgb2Yg dGhlIHNjaGVkdWxlZCBtZXNzYWdlLiI7DQoNCiAgICAgICAgfQ0KDQoNCg0KICAgICAgICBsZWFm IHNjaGVkdWxlZC10aW1lIHsNCg0KICAgICAgICAgIHR5cGUgeWFuZzpkYXRlLWFuZC10aW1lOw0K DQogICAgICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAgICAgICAgIlRoZSB0aW1lIGF0IHdoaWNo IHRoZSBSUEMgaXMgc2NoZWR1bGVkIHRvIGJlIHBlcmZvcm1lZC4iOw0KDQogICAgICAgIH0NCg0K DQoNCiAgICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAgICAgICJJbmRpY2F0ZXMgdGhhdCBhIHNj aGVkdWxlZCBtZXNzYWdlIHdhcyByZWNlaXZlZC4iOw0KDQogICAgICAgIHJlZmVyZW5jZQ0KDQog ICAgICAgICAgImRyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5PGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eT46DQoNCiAgICAg ICAgICAgVGltZSBDYXBhYmlsaXR5IGluIE5FVENPTkYiOw0KDQogICAgICB9DQoNCg0KDQpBbnkg Y2xpZW50IGNhbiBnZXQgdGhlc2Ugbm90aWZpY2F0aW9ucyBhbmQga25vdyB0aGUgSUQgKHRvIGNh bmNlbCBpdCkNCmFuZCB0aGUgc2NoZWR1bGVkIHRpbWUuDQoNCklzIGlzIGEgc2VjdXJpdHkgaXNz dWUgdGhhdCBhbnkgY2xpZW50IGNhbiBnZXQgdGhlIHNjaGVkdWxlLWlkDQphbmQgdXNlIGl0IHRv IGNhbmNlbCB0aGUgc2NoZWR1bGVkIFJQQz8NCg0KDQpBbmR5DQoNCg0KT24gV2VkLCBKdWwgMjks IDIwMTUgYXQgMjoxNSBQTSwgT2xhZnVyIEd1ZG11bmRzc29uIDxvZ3VkQG9ndWQuY29tPG1haWx0 bzpvZ3VkQG9ndWQuY29tPj4gd3JvdGU6DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQpvbmdvaW5nIGVmZm9ydCB0byBy ZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCklFU0cuICBU aGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0 aGUNCnNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hh aXJzIHNob3VsZCB0cmVhdA0KdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0 IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u DQpUaGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuLg0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgYXJlIGNsZWFyIGFuZCBhY2N1cmF0ZS4gSSB3b3VsZCBsaWtlIGhpZ2hsaWdodCBvbmUg b21pc3Npb24gdGhvdWdoLg0KVGhpcyBjYXBhYmlsaXR5IGFsbG93cyBhbiBhdHRhY2tlciBvbmNl IGl0IGhhcyBnYWluZWQgYWNjZXNzIHRvIHNjaGVkdWxlIGV2ZW50cyBpbiB0aGUgZnV0dXJlIGV2 ZW4NCnRob3VnaCBhdHRhY2tlcnMgYWNjZXNzIGhhcyBiZWVuIGRldGVjdGVkIGFuZCByZXZva2Vk Lg0KDQpPbGFmdXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRj b25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mDQoNCg== --_000_0960eb5365954b73afde1c70ba5164a0ILEXCH01marvellcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWVubG87DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uaG9lbnpiDQoJe21zby1z dHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IG1ha2Ug YSBnb29kIHBvaW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGludGVuZCB0 byBhZGQgdGV4dCAoc2VlIGJlbG93KSB0aGF0IGRlc2NyaWJlcyB0aGlzIHBvaW50IGluIHRoZSBu ZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Q bGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgZnVydGhlciBjb21tZW50cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZXJlIGlzIHRoZSB1cGRhdGVk IHRleHQgb24gdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoZSBzZWN1cml0eSBzZWN0aW9uOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhpcyBZQU5HIG1vZHVsZSBkZWZpbmVzIHRoZSAmbHQ7Y2FuY2VsLXNjaGVkdWxlJmd0 OyBSUEMuIFRoaXMgUlBDIG1heSBiZSBjb25zaWRlcmVkIHNlbnNpdGl2ZSBvciB2dWxuZXJhYmxl IGluIHNvbWUgbmV0d29yayBlbnZpcm9ubWVudHMuIFNpbmNlIHRoZSB2YWx1ZSBvZiB0aGUNCiAm bHQ7c2NoZWR1bGUtaWQmZ3Q7IGlzIGtub3duIHRvIGFsbCB0aGUgY2xpZW50cyB0aGF0IGFyZSBz dWJzY3JpYmVkIHRvIG5vdGlmaWNhdGlvbnMgZnJvbSB0aGUgc2VydmVyLCB0aGUgJmx0O2NhbmNl bC1zY2hlZHVsZSZndDsgUlBDIG1heSBiZSB1c2VkIG1hbGljaW91c2x5IHRvIGF0dGFjayBzZXJ2 ZXJzIGJ5IGNhbmNlbGluZyB0aGVpciBwZW5kaW5nIFJQQ3MuIFRoaXMgYXR0YWNrIGlzIGFkZHJl c3NlZCBpbiB0d28gbGF5ZXJzOiAoaSkgc2VjdXJpdHkgYXQgdGhlDQogdHJhbnNwb3J0IGxheWVy LCBsaW1pdGluZyB0aGUgYXR0YWNrIG9ubHkgdG8gY2xpZW50cyB0aGF0IGhhdmUgc3VjY2Vzc2Z1 bGx5IGluaXRpYXRlZCBhIHNlY3VyZSBzZXNzaW9uIHdpdGggdGhlIHNlcnZlciwgYW5kIChpaSkg dGhlIGF1dGhvcml6YXRpb24gbGV2ZWwgcmVxdWlyZWQgdG8gY2FuY2VsIGFuIFJQQyBzaG91bGQg YmUgdGhlIHNhbWUgYXMgdGhlIGxldmVsIHJlcXVpcmVkIHRvIHNjaGVkdWxlIGl0LCBsaW1pdGlu ZyB0aGUgYXR0YWNrDQogb25seSB0byBhdHRhY2tlcnMgd2l0aCBhbiBhdXRob3JpemF0aW9uIGxl dmVsIHRoYXQgaXMgZXF1YWwgdG8gb3IgaGlnaGVyIHRoYW4gdGhhdCBvZiB0aGUgY2xpZW50IHRo YXQgaW5pdGlhdGVkIHRoZSBzY2hlZHVsZWQgUlBDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVybWFuPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDMwLCAyMDE1IDEyOjQwIEFNPGJyPg0KPGI+VG86 PC9iPiBPbGFmdXIgR3VkbXVuZHNzb248YnI+DQo8Yj5DYzo8L2I+IHNlY2RpckBpZXRmLm9yZzsg ZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHkuYWxsQGlldGYub3JnOyBpZXRmOyBOZXRj b25mPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gU2VjLURpciBSZXZpZXc6IGRy YWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5LTA1LnR4PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBjdXJpb3VzIGlmIHRoaXMgaXMgYSBzZWN1 cml0eSBjb25jZXJuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2hlbiBhbiBldmVudCBpcyBzY2hlZHVsZWQsIHRoZSBJRCBhbmQgaXRzIHNjaGVk dWxlZCB0aW1lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hcmUgc2VudCBvdXQgaW4gYSBub3RpZmljYXRpb24gdG8gcG90ZW50aWFsbHkgYWxsIGNs aWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5ub3RpZmljYXRpb24gbmV0Y29uZi1zY2hlZHVsZWQtbWVzc2FnZSB7PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgc2NoZWR1bGUtaWQg ezxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 eXBlIHN0cmluZzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhlIElEIG9mIHRoZSBzY2hlZHVs ZWQgbWVzc2FnZS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVh ZiBzY2hlZHVsZWQtdGltZSB7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHR5cGUgeWFuZzpkYXRlLWFuZC10aW1lOzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDtUaGUgdGltZSBhdCB3aGljaCB0aGUgUlBDIGlzIHNjaGVkdWxlZCB0byBiZSBwZXJm b3JtZWQuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt9 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0 aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZxdW90O0luZGljYXRlcyB0aGF0IGEgc2NoZWR1bGVkIG1lc3NhZ2Ugd2FzIHJlY2VpdmVkLiZx dW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNl PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tbS1uZXRjb25m LXRpbWUtY2FwYWJpbGl0eSI+ZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHk8L2E+Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW55IGNsaWVudCBjYW4gZ2V0IHRoZXNlIG5vdGlmaWNhdGlvbnMgYW5k IGtub3cgdGhlIElEICh0byBjYW5jZWwgaXQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgdGhlIHNjaGVkdWxlZCB0aW1lLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyBpcyBhIHNlY3Vy aXR5IGlzc3VlIHRoYXQgYW55IGNsaWVudCBjYW4gZ2V0IHRoZSBzY2hlZHVsZS1pZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHVzZSBpdCB0 byBjYW5jZWwgdGhlIHNjaGVkdWxlZCBSUEM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCAyOSwgMjAxNSBhdCAyOjE1IFBNLCBP bGFmdXIgR3VkbXVuZHNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpvZ3VkQG9ndWQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+b2d1ZEBvZ3VkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O01lbmxvJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5vbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+SUVTRy4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2VyZSB3 cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPnNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxv JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ VGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+VGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWVubG8mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBhcmUgY2xlYXIgYW5kIGFjY3VyYXRlLiBJIHdvdWxkIGxpa2UgaGlnaGxpZ2h0IG9uZSBv bWlzc2lvbiB0aG91Z2guICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGlzIGNhcGFi aWxpdHkgYWxsb3dzIGFuIGF0dGFja2VyIG9uY2UgaXQgaGFzIGdhaW5lZCBhY2Nlc3MgdG8gc2No ZWR1bGUgZXZlbnRzIGluIHRoZSBmdXR1cmUgZXZlbiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTQuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij50aG91Z2ggYXR0YWNrZXJzIGFjY2VzcyBoYXMgYmVlbiBkZXRlY3RlZCBhbmQgcmV2b2tl ZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVv dDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojODg4ODg4Ij5PbGFmdXImbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_0960eb5365954b73afde1c70ba5164a0ILEXCH01marvellcom_-- From nobody Wed Jul 29 23:44:33 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136FC1A8A47; Wed, 29 Jul 2015 23:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 UeNKks0xoKEt; Wed, 29 Jul 2015 23:44:30 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 7C5441A88A0; Wed, 29 Jul 2015 23:44:30 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t6U6ZNkH015227; Wed, 29 Jul 2015 23:44:28 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 1vv9yp5qxm-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jul 2015 23:44:28 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 30 Jul 2015 09:44:26 +0300 Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Thu, 30 Jul 2015 09:44:26 +0300 From: Tal Mizrahi To: Olafur Gudmundsson , ietf , "netconf@ietf.org" , "draft-mm-netconf-time-capability.all@ietf.org" Thread-Topic: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx Thread-Index: AQHQykPII6R5rilafEWsJYafMYxlJp3zkXSQ Date: Thu, 30 Jul 2015 06:44:26 +0000 Message-ID: <0bde13a98445401fb9a19a1c950f77f2@IL-EXCH01.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_0bde13a98445401fb9a19a1c950f77f2ILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-07-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1507300120 Archived-At: Cc: "secdir@ietf.org" Subject: Re: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 06:44:32 -0000 --_000_0bde13a98445401fb9a19a1c950f77f2ILEXCH01marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Olafur, Thanks for the feedback. >This capability allows an attacker once it has gained access to schedule e= vents in the future even >though attackers access has been detected and revoked. We will add a paragraph that describes this potential threat to the next ve= rsion of the draft. Thanks, Tal. From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Olafur Gudmund= sson Sent: Thursday, July 30, 2015 12:16 AM To: ietf; netconf@ietf.org; draft-mm-netconf-time-capability.all@ietf.org Cc: secdir@ietf.org Subject: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication The document is well written. The security considerations are clear and accurate. I would like highlight = one omission though. This capability allows an attacker once it has gained access to schedule ev= ents in the future even though attackers access has been detected and revoked. Olafur --_000_0bde13a98445401fb9a19a1c950f77f2ILEXCH01marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Olafur,

 <= /p>

Thanks for the feedback.<= o:p>

 <= /p>

>This capability allows an attacker once it= has gained access to schedule events in the future even 

>though attackers access has been detected = and revoked. 

 <= /p>

We will add a paragraph t= hat describes this potential threat to the next version of the draft.<= /o:p>

 <= /p>

Thanks,=

Tal.

 <= /p>

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of Olafur Gudmundsson
Sent: Thursday, July 30, 2015 12:16 AM
To: ietf; netconf@ietf.org; draft-mm-netconf-time-capability.all@iet= f.org
Cc: secdir@ietf.org
Subject: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-= 05.tx

 

I have reviewed this document as part of the s= ecurity directorate's 

ongoing effort to review all IETF documents be= ing processed by the 

IESG.  These comments were written primar= ily for the benefit of the 

security area directors.  Document editor= s and WG chairs should treat 

these comments just like any other last call c= omments.

 

This document is ready for publication

The document is well written.

 

The security considerations are clear and accu= rate. I would like highlight one omission though.  <= /p>

This capability allows an attacker once it has= gained access to schedule events in the future even 

though attackers access has been detected and = revoked. 

 

Olafur 

--_000_0bde13a98445401fb9a19a1c950f77f2ILEXCH01marvellcom_-- From nobody Fri Jul 31 18:03:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4871A907E for ; Fri, 31 Jul 2015 18:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 YbrjXVKautyY for ; Fri, 31 Jul 2015 18:03:23 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 7D7051A9034 for ; Fri, 31 Jul 2015 18:03:22 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t7113Jhd028040 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 1 Aug 2015 01:03:19 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t7113HEK030885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Aug 2015 03:03:18 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sat, 1 Aug 2015 03:03:17 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.210]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0248.002; Sat, 1 Aug 2015 03:03:17 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: ext Ladislav Lhotka , Andy Bierman , Netconf Thread-Topic: [Netconf] RESTCONF #24:mandatory encoding revisited Thread-Index: AQHQyd71YF8HTysoA0etBY7Xg/CGjZ32VK0w Date: Sat, 1 Aug 2015 01:03:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: multipart/mixed; boundary="_002_E4DE949E6CE3E34993A2FF8AE79131F8197718C1DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 22719 X-purgate-ID: 151667::1438391000-000058E2-4F54D05A/0/0 Archived-At: Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 01:03:25 -0000 --_002_E4DE949E6CE3E34993A2FF8AE79131F8197718C1DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lada, you might be also interested to read:=20 https://mailarchive.ietf.org/arch/msg/netconf/YSEbLd-nnI0dlkeiIeGW-z6JqDg=20 In the sake of progress Bert and I declared at that time consensus. As far as I understand peoples interest and opinions changed since last Oct= ober. It makes sense to repeat the opinion poll. Mehmet=20 -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ladislav L= hotka Sent: Wednesday, July 29, 2015 11:14 AM To: Andy Bierman; Netconf Subject: Re: [Netconf] RESTCONF #24:mandatory encoding revisited Andy Bierman writes: > Hi, > > It would be good if we could close this issue soon. > I am not in favor of changing the previous consensus call. I am in favor of changing it. The consensus call that was done before Honolulu meeting was IMO very problematic and I had strong objections against it - the opinions were 10:7 in favor of making XML mandatory. See this thread: https://mailarchive.ietf.org/arch/search/?email_list=3Dnetconf&gbt=3D1&inde= x=3D8EhIVndveGw2QrHTefsYsADPC6Y Recently, other people expressed their preference, and explained technical reasons, for NOT doing so. > > At first I thought JSON would be good for RESTCONF, > until I implemented it. It is not appropriate for streaming servers. > The complexity and memory required and just as bad or worse > than XML, especially once namespaces and attributes are > added. Not all servers need to stream data. > > JSON is fine if the entire document is in memory, > but that's not how NETCONF/RESTCONF servers work. You probably mean your NETCONF/RESTCONF servers. Small devices have configurations that easily fit into memory, and small devices are exactly those for which XML support is a considerable burden. Lada > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_002_E4DE949E6CE3E34993A2FF8AE79131F8197718C1DEMUMBX005nsnin_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Sat, 01 Aug 2015 01:03:12 GMT"; modification-date="Sat, 01 Aug 2015 01:03:12 GMT" Received: from DEMUHTC001.nsn-intra.net (10.159.42.32) by DEMUHTC014.nsn-intra.net (10.159.42.45) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Oct 2014 19:43:53 +0200 Received: from demuprx016.emea.nsn-intra.net (10.159.42.122) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Oct 2014 19:43:52 +0200 Received: from demumfd001.nsn-inter.net (DEMUMFD001 [93.183.12.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s99HhqJg008816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Oct 2014 19:43:52 +0200 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s99Hhoww017020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Oct 2014 17:43:51 GMT Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F8D1AD469; Thu, 9 Oct 2014 10:43:48 -0700 (PDT) Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4261AD466 for ; Thu, 9 Oct 2014 10:43:45 -0700 (PDT) Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvVCsEY3bcXB for ; Thu, 9 Oct 2014 10:43:42 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216401AD467 for ; Thu, 9 Oct 2014 10:43:41 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s99HhcIw016747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Oct 2014 17:43:39 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s99Hhbd1013861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 19:43:38 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 19:43:37 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: ext Andy Bierman , Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity Thread-Topic: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity Thread-Index: AQHP4kuCWskhNgGUiUOwBv6Ya3YWfZwoCczQ Sender: Netconf Date: Thu, 9 Oct 2014 17:43:36 +0000 Message-ID: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: DEMUHTC001.nsn-intra.net X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-purgate-id: 151667::1412876631-0000437E-E7D92D19/9/30015 x-purgate-ad: Categorized by eleven eXpurgate (R) http://www.eleven.de x-purgate: This mail is sent in bulk (visit http://www.eleven.de for further information) x-purgate-size: 13923 x-purgate-type: bulk x-originating-ip: [10.159.42.103] x-original-to: netconf@ietfa.amsl.com x-mailman-version: 2.1.15 delivered-to: netconf@ietfa.amsl.com x-beenthere: netconf@ietf.org x-virus-scanned: amavisd-new at amsl.com errors-to: netconf-bounces@ietf.org list-id: Network Configuration WG mailing list list-post: x-spam-score: -6.9 list-archive: x-spam-level: x-spam-status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1412876629; bh=w+5MkZCZlhXo/WVHTH8+AsAD7SkDat1hIINXtPyHMH0=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=ekWFgABoTuGfvsBLmpEPvwrIWwdR1FcsNcDlqpypqla385/rrEPtzs7ImtoFg+LLH Vgtkk+w5TCLjMMg6Z7VT9qDyjcIfxafK+jQk58md8NQ+1AKlDEKsQECMTJEazcTjNm QG/6cNusqC9zT1rye2wqCphpoqvQyDbSa1fa8jYY= x-spam-flag: NO Content-Type: multipart/mixed; boundary="_004_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_" MIME-Version: 1.0 --_004_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_ Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_" --_000_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, All, in reality it was 8 for a) and 8 for d) until Mahesh changed his mind in fa= vor of d). However with the conclusion mail below you may count both co-chair=92s vote= s in favor of a). We indeed think that a) had reasonable support with good technical argument= s, which are mainly =93less options, less complexity, better understood=94. You may count the co-chairs now to =93old-school=94 but we believe that a) = improves interoperability. Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierm= an Sent: Tuesday, October 07, 2014 6:27 PM To: Bert Wijnen (IETF) Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your op= inion on RESTCONF modularity Hi, On Tue, Oct 7, 2014 at 12:23 AM, Bert Wijnen (IETF) > wrote: Dear NETCONF WG participants, Appologies for being a bit late with trying to draw a conclusion on this one. As WG chairs, we believe that option a) had reasonable support with good technical arguments why the choice was for that option. On pure numerical count, we believe that option c won, but it was/is also clear that it just complicates things and has more risk of interoperability problems. I think you meant that (d) got the most. And it wasn't "whatever it chooses= ", it was "XML or JSON or both". So we as chairs propose to go with option a). If anyone still has REAL STRONG objections, pls speak up before the end of this week. If we hear none by Friday Okt 10th, we conclude that we have (rough) consensus to go with option a) Bert and Mehmet. Andy On 02/09/14 12:23, Bert Wijnen (IETF) wrote: On 26/08/14 22:49, Andy Bierman wrote: Perhaps the co-chairs should decide how to proceed somehow. Dear NETCONF WG participants, do you have an opinion? So far I have seen only a few people express their opinion. Please speak up so that we (WG chairs) have better data to judge if we do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. Please speak your mind about these options: a) XML is mandatory b) JSON is mandatory c) XML and JSON are both mandatory d) Both XML and JSON mandatory on client, server can implement whatever it chooses. Not clear yet how the client would find out, but that would of cours= e be something to be worked out if we choose this option Bert _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_ Content-Type: text/html; charset="Windows-1252" Content-ID: <57F1F39C0D2B1F4EB93004DB098F42E0@internal.nsn.com> Content-Transfer-Encoding: quoted-printable

Hi Andy, All,

 

in reality it was 8 for a)= and 8 for d) until Mahesh changed his mind in favor of d).

However with the conclusio= n mail below you may count both co-chair=92s votes in favor of a).

 

We indeed think that a) ha= d reasonable support with good technical arguments, which are mainly =93les= s options, less complexity, better understood=94.

You may count the co-chair= s now to =93old-school=94 but we believe that a) improves interoperability.=

 

Mehmet=

 

From: Netconf [m= ailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman
Sent: Tuesday, October 07, 2014 6:27 PM
To: Bert Wijnen (IETF)
Cc: Netconf
Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express = your opinion on RESTCONF modularity

 

Hi,

 

 

 

On Tue, Oct 7, 2014= at 12:23 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:

Dear NETCONF WG par= ticipants,

Appologies for being a bit late with trying to draw a conclusion on this one.

As WG chairs, we believe that option a) had reasonable support with
good technical arguments why the choice was for that option.

On pure numerical count, we believe that option c won, but it was/is also clear that it just complicates things and has more risk of
interoperability problems.

 

 

I think you meant t= hat (d) got the most. And it wasn't "whatever it chooses",

it was "XML or= JSON or both".

 

 


So we as chairs propose to go with option a).

If anyone still has REAL STRONG objections, pls speak up before
the end of this week. If we hear none by Friday Okt 10th,
we conclude that we have (rough) consensus to go with option a)<= /span>

 

Bert and Mehmet.

 

Andy

 

 

On 02/09/14 12:23, = Bert Wijnen (IETF) wrote:

On 26/08/14 22:49, = Andy Bierman wrote:


Perhaps the co-chairs should decide how to proceed somehow.


Dear NETCONF WG participants, do you have an opinion?

So far I have seen only a few people express their opinion.

Please speak up so that we (WG chairs) have better data to judge if we
do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014.
Please speak your mind about these options:

a) XML is mandatory
b) JSON is mandatory
c) XML and JSON are both mandatory
d) Both XML and JSON mandatory on client,
    server can implement whatever it chooses.
    Not clear yet how the client would find out, but that would o= f course
    be something to be worked out if we choose this option

Bert

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


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

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_-- --_004_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=136; creation-date="Thu, 09 Oct 2014 17:43:54 GMT"; modification-date="Thu, 09 Oct 2014 17:43:54 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_004_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_-- --_002_E4DE949E6CE3E34993A2FF8AE79131F8197718C1DEMUMBX005nsnin_--