From nobody Fri Dec 2 02:14:21 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93044129622 for ; Fri, 2 Dec 2016 02:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D53sygROPlri for ; Fri, 2 Dec 2016 02:14:17 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B618129554 for ; Fri, 2 Dec 2016 02:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3608; q=dns/txt; s=iport; t=1480673656; x=1481883256; h=to:from:subject:message-id:date:mime-version; bh=O7AhCKQz32jlfja+asLP8kSKYf9JXyzdImSuUjb8TUg=; b=gw0z6pwxI7vN5UzrinR15hnJtxfY4bCAKAv+0qc8z9238MbgLH+ygMuA 9sHgFPBKDYUKPSGNEzIX1LV8C+ZWIyymw04A0GP9gfBLYZY4BaxK18Pgo UbKzULdzqFLu66d13IfHbIiwZmHt2O87X3pKQZxD0hHxIfltlAJuBrYDg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAQCSSEFY/xbLJq1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBgzgBAQEBAXcuWI1GpmWDE4IPggYpiE8UAQIBAQEBAQEBYiiFEm8GPgJfAQw?= =?us-ascii?q?IAQGIaw6PC51FgikvixABAQEBBgEBAQEBIoY+gX2KK4I/HgWUeoVphkuKSYoNh?= =?us-ascii?q?iyKHYduHzd4Ew6FVj00AYcVK4IQAQEB?= X-IronPort-AV: E=Sophos;i="5.33,729,1477958400"; d="scan'208,217";a="647549576" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 10:14:14 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uB2AEEaS015916; Fri, 2 Dec 2016 10:14:14 GMT To: YANG Doctors , "dromasca@gmail.com" , "rkrejci@cesnet.cz" From: Benoit Claise Message-ID: Date: Fri, 2 Dec 2016 11:14:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FB6D47DB0D927A53423463C8" Archived-At: Subject: [yang-doctors] Welcome Radek as new YANG doctor X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 10:14:19 -0000 This is a multi-part message in MIME format. --------------FB6D47DB0D927A53423463C8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, It's my pleasure to announce a new YANG doctor: Radek Krejčí. Radek has been developing libyang and yanglint See https://github.com/CESNET/libyang: Provided Features * Parsing (and validating) schemas in YANG format. * Parsing (and validating) schemas in YIN format. * Parsing, validating and printing instance data in XML format. * Parsing, validating and printing instance data in JSON format (RFC 7951 ). * Manipulation with the instance data. * Support for default values in the instance data (RFC 6243 ). * yanglint - features rich YANG tool. Current implementation covers YANG 1.0 (RFC 6020 ) as well as YANG 1.1 (RFC 7950 ). With Radek's help, I've adding the yanglint compiler to http://www.claise.be/IETFYANGPageCompilation.html Not only Radek resolved some issues with his compiler, but he has been comparing the different compiler results, filing issues and warning draft authors. Thanks Radek. Regards, Benoit --------------FB6D47DB0D927A53423463C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

It's my pleasure to announce a new YANG doctor: Radek Krejčí.
Radek has been developing libyang and yanglint
See https://github.com/CESNET/libyang:

Provided Features

  • Parsing (and validating) schemas in YANG format.
  • Parsing (and validating) schemas in YIN format.
  • Parsing, validating and printing instance data in XML format.
  • Parsing, validating and printing instance data in JSON format (RFC 7951).
  • Manipulation with the instance data.
  • Support for default values in the instance data (RFC 6243).
  • yanglint - features rich YANG tool.

Current implementation covers YANG 1.0 (RFC 6020) as well as YANG 1.1 (RFC 7950).

With Radek's help, I've adding the yanglint compiler to http://www.claise.be/IETFYANGPageCompilation.html
Not only Radek resolved some issues with his compiler, but he has been comparing the different compiler results, filing issues and warning draft authors.

Thanks Radek.

Regards, Benoit

--------------FB6D47DB0D927A53423463C8-- From nobody Fri Dec 2 09:30:35 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDC11295D5; Fri, 2 Dec 2016 09:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA8Lb1smc8rg; Fri, 2 Dec 2016 09:30:29 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149171295D2; Fri, 2 Dec 2016 09:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3066; q=dns/txt; s=iport; t=1480699829; x=1481909429; h=from:subject:to:cc:message-id:date:mime-version; bh=J6VwwZNJiHyYhL6274uVNlZEDMfa1NTzBCbMyWqLVnI=; b=Xl+pBPWXKn9vDGJu783RtEBWRqoPTzyQy1TT/j+pQteXrO/Nu4URsg/i XeEy3yQTVhtpnQJFoAUjY72FTTnmvHLYyujzOFMEVlg9a+vKiKXtitaKC W80mjo7bNLo8e6XhX3iisZusSzbBFVzxYBQjL9kzyq82zjmcT4W/8HM27 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AwD4rkFY/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAXmBBrQqgxOEFSmFeYJeEQECAQEBAQEBAWIohRJWHwE9Al8?= =?us-ascii?q?BDAgBAYhrDqw3gikviwEBAQEBAQUBAQEBAQEBIIY+gX2BVohVgl0FmmOGS4pJg?= =?us-ascii?q?kKHS4Ysih6HbzUheBMOhBCBRj00AYh9AQEB?= X-IronPort-AV: E=Sophos;i="5.33,287,1477958400"; d="scan'208,217";a="648583095" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 17:30:27 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uB2HUQnH025356; Fri, 2 Dec 2016 17:30:26 GMT From: Benoit Claise To: NETMOD Working Group , YANG Doctors Message-ID: Date: Fri, 2 Dec 2016 18:30:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------292CD7C4FDE4001F8A2D1C39" Archived-At: Subject: [yang-doctors] IETF YANG module compilation: now four different compilers to check your modules. X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:30:31 -0000 This is a multi-part message in MIME format. --------------292CD7C4FDE4001F8A2D1C39 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, During the IETF hackathon, I inserted two more compilers part of the daily cron job on my web site. Next to pyang, confdc, we know have yangdump-pro (from Yumaworks) and yanglint (thanks to Radek for the help) See for the results here . The compilation field is based on the outcome of the 4 compilers, to the best of my knowledge, as there is a little bit of analytic here. As you can see, the number of YANG modules that pass compilation dropped . This is fine, as the quality of the YANG modules will eventually improve. The comparison of 4 different compilers helped tremendously finding bugs in the compilers on one hand (many are solved already or will be solved in the next compiler version), and clarifying the YANG specifications on the other hand (perfect timing as draft-ietf-netmod-rfc6087bis-09 is being finalized). I advice you to look up your YANG modules on the web site. The new compilers might have discovered new issues. Regards, Benoit --------------292CD7C4FDE4001F8A2D1C39 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

During the IETF hackathon, I inserted two more compilers part of the daily cron job on my web site.
Next to pyang, confdc, we know have yangdump-pro (from Yumaworks) and yanglint (thanks to Radek for the help)

See for the results here.
The compilation field is based on the outcome of the 4 compilers, to the best of my knowledge, as there is a little bit of analytic here.

As you can see, the number of YANG modules that pass compilation dropped.
This is fine, as the quality of the YANG modules will eventually improve.
The comparison of 4 different compilers helped tremendously finding bugs in the compilers on one hand (many are solved already or will be solved in the next compiler version), and clarifying the YANG specifications on the other hand (perfect timing as draft-ietf-netmod-rfc6087bis-09 is being finalized).

I advice you to look up your YANG modules on the web site. The new compilers might have discovered new issues.

Regards, Benoit
 


 


--------------292CD7C4FDE4001F8A2D1C39-- From nobody Fri Dec 2 13:17:52 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978EC120725; Fri, 2 Dec 2016 13:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V965sJeLN00h; Fri, 2 Dec 2016 13:17:42 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D60128E19; Fri, 2 Dec 2016 13:17:42 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3DA90AD6; Fri, 2 Dec 2016 22:17:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id W91W629jsNTN; Fri, 2 Dec 2016 22:17:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 2 Dec 2016 22:17:39 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6C1C2005F; Fri, 2 Dec 2016 22:17:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rfaenLYUGshu; Fri, 2 Dec 2016 22:17:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65F632005E; Fri, 2 Dec 2016 22:17:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3D8C03D9AA52; Fri, 2 Dec 2016 22:17:39 +0100 (CET) Date: Fri, 2 Dec 2016 22:17:39 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20161202211739.GB90771@elstar.local> Mail-Followup-To: Benoit Claise , NETMOD Working Group , YANG Doctors References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [yang-doctors] IETF YANG module compilation: now four different compilers to check your modules. X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:17:45 -0000 Benoit, would it be possible to create a table that does _not_ include the specific error messages but provides the error messages via separate links? I am usually getting lost while scrolling through tables of this size... /js On Fri, Dec 02, 2016 at 06:30:27PM +0100, Benoit Claise wrote: > Dear all, > > During the IETF hackathon, I inserted two more compilers part of the daily > cron job on my web site. > Next to pyang, confdc, we know have yangdump-pro (from Yumaworks) and > yanglint (thanks to Radek for the help) > > See for the results here > . > The compilation field is based on the outcome of the 4 compilers, to the > best of my knowledge, as there is a little bit of analytic here. > > As you can see, the number of YANG modules that pass compilation dropped > . > This is fine, as the quality of the YANG modules will eventually improve. > The comparison of 4 different compilers helped tremendously finding bugs in > the compilers on one hand (many are solved already or will be solved in the > next compiler version), and clarifying the YANG specifications on the other > hand (perfect timing as draft-ietf-netmod-rfc6087bis-09 is being finalized). > > I advice you to look up your YANG modules on the web site. The new compilers > might have discovered new issues. > > Regards, Benoit > > > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Dec 3 06:58:04 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC5F129891; Sat, 3 Dec 2016 06:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abk5ADna5xaq; Sat, 3 Dec 2016 06:58:01 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35C9129890; Sat, 3 Dec 2016 06:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1853; q=dns/txt; s=iport; t=1480777081; x=1481986681; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=YoC365yyyKP9T/HzWRO1qQU82jmHoOop0v6VuYtf3z4=; b=dCRlNeWAbQuxr3QTpJ6YlY9jBV7JfqOmeFALbO+tBUkb5kv1YdRSVEiX SGroTpQr0kIt2uQlf4HOjQZaWj2g4C8z0QvqQ1gpqkaQG+Nr/Ij+Hcwv5 kowl70Vr/jLy3/nzWF5tXhEcIWtpk0nDjB/g2x/oRo5iicC8vAMSpRYQj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AADb3EJY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAXmBBo1HlwuUfYIIHguFeQKCXBQBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQEEAQE2NhsLGCMLJzAGAQwGAgEBiGsOr2yLPgEBAQEBAQEDAQEBAQEBASCGP?= =?us-ascii?q?oF9gVaBCIoLHgEEmmaGS4pMgkKHT4Ysih+DY4QNHzd4Ew4jg22BRj00AYl/AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.33,736,1477958400"; d="scan'208";a="647580329" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2016 14:57:34 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uB3EvXa7021536; Sat, 3 Dec 2016 14:57:34 GMT To: NETMOD Working Group , YANG Doctors References: <20161202211739.GB90771@elstar.local> From: Benoit Claise Message-ID: <4e87b595-fb1c-50b3-076e-513300e7c721@cisco.com> Date: Sat, 3 Dec 2016 15:57:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20161202211739.GB90771@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [yang-doctors] IETF YANG module compilation: now four different compilers to check your modules. X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 14:58:03 -0000 Hi Juergen, Thanks for the interest. I could, but this is a presentation layer task, and hence a low priority for me :-) Regards, Benoit > Benoit, > > would it be possible to create a table that does _not_ include the > specific error messages but provides the error messages via separate > links? I am usually getting lost while scrolling through tables of > this size... > > /js > > On Fri, Dec 02, 2016 at 06:30:27PM +0100, Benoit Claise wrote: >> Dear all, >> >> During the IETF hackathon, I inserted two more compilers part of the daily >> cron job on my web site. >> Next to pyang, confdc, we know have yangdump-pro (from Yumaworks) and >> yanglint (thanks to Radek for the help) >> >> See for the results here >> . >> The compilation field is based on the outcome of the 4 compilers, to the >> best of my knowledge, as there is a little bit of analytic here. >> >> As you can see, the number of YANG modules that pass compilation dropped >> . >> This is fine, as the quality of the YANG modules will eventually improve. >> The comparison of 4 different compilers helped tremendously finding bugs in >> the compilers on one hand (many are solved already or will be solved in the >> next compiler version), and clarifying the YANG specifications on the other >> hand (perfect timing as draft-ietf-netmod-rfc6087bis-09 is being finalized). >> >> I advice you to look up your YANG modules on the web site. The new compilers >> might have discovered new issues. >> >> Regards, Benoit >> >> >> >> >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors > From nobody Wed Dec 7 08:01:36 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638741294F9; Wed, 7 Dec 2016 08:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SG3-jQDI2fV; Wed, 7 Dec 2016 08:01:27 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E06221294EF; Wed, 7 Dec 2016 08:01:21 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 345A01CC00C7; Wed, 7 Dec 2016 17:01:23 +0100 (CET) From: Ladislav Lhotka To: draft-ietf-rtgwg-yang-rip.all@ietf.org Date: Wed, 07 Dec 2016 17:01:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: yang-doctors@ietf.org Subject: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-rip-02 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 16:01:34 -0000 Hi, I was assigned to be the YANG doctor for this document. Here is my review: **** General comments Overall, the module is in a good shape and integrates nicely with the core routing data model [RFC 8022]. The I-D text is rather scarce, apart from the module it essentially contains only boilerplate stuff. Some information about the context in which this module is supposed to be used, design decisions etc. would be certainly useful. A non-normative appendix with a configuration example (instance data) would also help people that are not fluent in YANG to understand what data are included in this model. Some parts of the model =E2=80=93 "distribute-list", "redistribute", "bfd", "authentication" on interfaces (or at least the "key" list) =E2=80=93 are probably not specific to RIP and could be used by other protocols as well. If it is so, it would be better to model them separately as general mechanisms. Documents containing YANG modules that are imported by ietf-rip should appear among normative references. One way to achieve this (which is also useful by itself) is to include a table of namespace prefixes, see e.g. https://tools.ietf.org/html/rfc8022#section-2.3 **** Specific comments - Matching identities is done in the old YANG 1.0 way, for example: when "rt:type =3D 'rip:ripv2' or rt:type =3D 'rip:ripng'" This is fragile because the identities are matched based on string equality, so the result depends on the choice of the namespace prefix. Unless there is a strong reason not to use YANG 1.1, this is much simpler and more rubust when "derived-from(rt:type, 'rip:rip')" - In "redistribution", the must expressions are outright broken, e.g. for IS-IS: must "../../../../../rt:control-plane-protocol" + "[rt:name =3D current()]/type =3D 'isis'" { ... } First, the ietf-rip module also needs to import ietf-isis, and then the must statement can be rewritten like so: must "derived-from-or-self(" + "../../../../../rt:control-plane-protocol" + "[rt:name =3D current()]/type, 'isis:isis')" - Some descriptions could mention that the parameter (feature etc.) only applies to RIP. For example, in feature interface-statistics { description "This feature indicates that the system supports collecting per-interface statistic data."; } I would add "... related to RIP." at the end. - Maybe it's absolutely clear to experts but the name and description of the "neighbor-configuration" feature look like the feature can make neighbors remotely configurable. I had to look up where it is used to find out what's the real meaning. Perhaps something like "explicit-neighbors" might be easier to understand? - The name of "no-supply" leaf looks strange. I checked a couple of CLIs and they use "passive", "passive-interface" or "send-options" for preventing RIP updates from being sent. - In "split-horizon" leaf, I would use "poison-reverse" enum rather than "poison". Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Dec 7 10:17:21 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FDA1296FA; Wed, 7 Dec 2016 10:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2COidHXVkKv6; Wed, 7 Dec 2016 10:17:18 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEC6129548; Wed, 7 Dec 2016 10:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=342; q=dns/txt; s=iport; t=1481134638; x=1482344238; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=FARsRV3i6gLfNeTkRWxlOGVa/G5O1C9eF7KLqrklu3o=; b=acLR2fjU0g1HMuPjh1auy+fxK3i7sFIiv4pXXdsXarzNpehx6jQtUocj B9TtdRInz83gWNjmycQGvgI+vaXfsfYpwe0bv0azSdclCkKbCPW2ej54B a8tZ7FK9+vnikDqwtqea60+XWT8kwfkvt1Akid7Zx8xeEG11ytbFRR3zK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHCAD5UEhY/xbLJq1eHAEBBAEBCgEBg?= =?us-ascii?q?zkBAQEBAXmBB7dHhBYrhW2CSBABAgEBAQEBAQFiKIUSFXYCJgJfAQwIAQGIaw6?= =?us-ascii?q?oJoIpizUBAQEHAiWBC4UzgX2ELYV9gl0FlHyFapEYgVwBiDWGLYogg2OEDjYge?= =?us-ascii?q?BMOhVY9hz8rghABAQE?= X-IronPort-AV: E=Sophos;i="5.33,314,1477958400"; d="scan'208";a="690267847" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2016 18:17:13 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB7IHD3M007635; Wed, 7 Dec 2016 18:17:13 GMT To: NETMOD Working Group , YANG Doctors From: Benoit Claise Message-ID: <3d4a849b-f18f-69d8-bea6-52adce698a18@cisco.com> Date: Wed, 7 Dec 2016 19:17:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [yang-doctors] Blog: YANG Opensource Tools for Data Modeling-driven Management X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 18:17:20 -0000 Dear all, This blog describes some of the opensource tools around YANG. While there exist some tools around the YANG language validation, I want to cover the bigger landscape of data modeling-driven management tools. http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driven-management/ Enjoy. Regards, B. From nobody Tue Dec 13 08:52:21 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F17E12943D for ; Tue, 13 Dec 2016 08:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W80vWBBdfK2w for ; Tue, 13 Dec 2016 08:52:19 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 F2BFD12943A for ; Tue, 13 Dec 2016 08:52:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0164C24064D for ; Tue, 13 Dec 2016 08:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1481647938; bh=B77Jl9rV3MMjKK1SV97jlDusQb9EXMNFBZqucp11WZc=; h=To:From:Subject:Date:From; b=Dn+w8QFoK3E1Giw6JkA991X+J3Oiyjh04/qe+aKmOKmlca7i0GaZqqeNNnKPlBsFR AQDFUMvT4E38R6Wn5dT82se9wITWCGulu7QVmaI08UGy26KbjHE1AxgOqBT91GbuLk XkwCPWGhGDrm7KR+DEURWI2h6JEe7wAueIC0dThw= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A54872466FC for ; Tue, 13 Dec 2016 08:52:17 -0800 (PST) To: YANG Doctors From: "Joel M. Halpern" Message-ID: Date: Tue, 13 Dec 2016 11:52:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [yang-doctors] YANG usage of top level lists X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 16:52:20 -0000 I notice that although YANG allows lists directly in modules, I almost never see such usage. Is there a reason that this is avoided? For example, I note that no one seems to have thought it strange that in the SUPA model I repeatedly use top level containers with just lists inside them, rather than putting the lists directly in the module. I did that because I thought it was necessary. Is there a reason it is a good idea, or should I just put the lists directly in the module? Thank you, Joel From nobody Tue Dec 13 09:00:46 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54367129B9E for ; Tue, 13 Dec 2016 09:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2oqKIISLf_s for ; Tue, 13 Dec 2016 09:00:42 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6F8129B9C for ; Tue, 13 Dec 2016 09:00:10 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id n21so122633627qka.3 for ; Tue, 13 Dec 2016 09:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NgJxM0i6ex5aPiK6vu0EQgHYY4GI4vXSzkLXisoXpME=; b=GlSGpIJVjpOBBodoIBN1hyuyimTuJ9+XO675RIAc+/Zg+9DOtcXkTli4IWBOzO87Ab j67NVWIOsSA1DfhaphmgXjeXl9npzxTkPWaggDXyX+Acx53QNHbvtB4BVbQuBFauQz0h 1nISYTsNh5o0U5IvmHqyFBzkEGenoa2F1RxdwnDzFJIFqCSlpPlcwOjMIA7Q35hqKaC5 XLKzvZyOvWLUkpiOkNLv50JdG8dzzfkTegKjBVhWCl/PyTrE0BuwVMbBaI/9QDI2BI/D fHuWDCR+1iDRL0JUaaVDZJbG3feZVD9WIhCe3H8G8zT7qxXwd8DYX7U+2SEYGYhOxYll kSmQ== 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:from:date :message-id:subject:to:cc; bh=NgJxM0i6ex5aPiK6vu0EQgHYY4GI4vXSzkLXisoXpME=; b=eOl5pxagbmluX1gFJ8zlGFMAl3vw0yTAbKQS+9G6SBjWZM1sXPWX/tMt7t/P7INx9s HWXqNjmEvpgnW3QvobMKqe/ZhvyNL/GGKNG0HZ005TjlidZHPvHpvLIeA3zdgGNYaWfv ZyKmDw5wU+NIpWMG1WmWeYUnnIEcT3DvISYi2RNk6co6Q/qNz3Uml1gaePi3eZdoZ5IG +XoVymJOQamh/dXk9YB1AemCfb48+Roo5uXib1GvDLPbhl0Ws9vKzwDZs6BQ8VPWNVlq Ifvq3lpglf4A2BKRsEVjIGQP4H1D1Vm3NbsSHoHqTKlnZTkXo4upfZsEpH6jZrZh92Iv mo7w== X-Gm-Message-State: AKaTC02vIf/Xr/kpS2ZdzHJs6HQmkd1P7je/jzXDliICH6Ym6FJatjmQkl5qUSU+xfjbCYzVR7mB12iThzdF7g== X-Received: by 10.55.76.150 with SMTP id z144mr80963106qka.194.1481648409094; Tue, 13 Dec 2016 09:00:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Tue, 13 Dec 2016 09:00:08 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Tue, 13 Dec 2016 09:00:08 -0800 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a114a88681b7f1305438d278f Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] YANG usage of top level lists X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 17:00:44 -0000 --001a114a88681b7f1305438d278f Content-Type: text/plain; charset=UTF-8 Hi, There are a few reasons this practice might be a good idea 1) REST resource model uses a collection of instances which maps in YANG to a container with a list in it 2) There is no standard way to delete all list instances at once so putting the list in a container allows the container to be deleted and all child list instances 3) a large number of siblings may impact server performance Andy On Tue, Dec 13, 2016 at 8:52 AM, Joel M. Halpern wrote: > I notice that although YANG allows lists directly in modules, I almost > never see such usage. Is there a reason that this is avoided? For > example, I note that no one seems to have thought it strange that in the > SUPA model I repeatedly use top level containers with just lists inside > them, rather than putting the lists directly in the module. I did that > because I thought it was necessary. Is there a reason it is a good idea, > or should I just put the lists directly in the module? > > Thank you, > Joel > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > --001a114a88681b7f1305438d278f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

There are a few reasons this practi= ce might be a good idea

1) REST resource model use= s a collection of instances which maps
in YANG to a container wit= h a list in it=C2=A0

2) There is no standard way t= o delete all list instances at once so putting the
=C2=A0 =C2=A0 = list in a container allows the container to be deleted and all child list i= nstances

3) a large number of siblings may impact = server performance=C2=A0


Andy
=


On Tue, Dec 13, 2016 at 8:52 AM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
I notice that alt= hough YANG allows lists directly in modules, I almost never see such usage.= =C2=A0 Is there a reason that this is avoided?=C2=A0 =C2=A0 For example, I = note that no one seems to have thought it strange that in the SUPA model I = repeatedly use top level containers with just lists inside them, rather tha= n putting the lists directly in the module.=C2=A0 I did that because I thou= ght it was necessary.=C2=A0 Is there a reason it is a good idea, or should = I just put the lists directly in the module?

Thank you,
Joel

_______________________________________________
yang-doctors mailing list
yang-doctors@iet= f.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors

--001a114a88681b7f1305438d278f-- From nobody Tue Dec 13 23:10:46 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF33129854 for ; Tue, 13 Dec 2016 23:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuVht7ReZEyS for ; Tue, 13 Dec 2016 23:10:43 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0E425129534 for ; Tue, 13 Dec 2016 23:10:42 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id A195A1CC00C9; Wed, 14 Dec 2016 08:10:43 +0100 (CET) From: Ladislav Lhotka To: "Joel M. Halpern" , YANG Doctors In-Reply-To: References: Date: Wed, 14 Dec 2016 08:10:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [yang-doctors] YANG usage of top level lists X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 07:10:45 -0000 "Joel M. Halpern" writes: > I notice that although YANG allows lists directly in modules, I almost > never see such usage. Is there a reason that this is avoided? For > example, I note that no one seems to have thought it strange that in the > SUPA model I repeatedly use top level containers with just lists inside > them, rather than putting the lists directly in the module. I did that > because I thought it was necessary. Is there a reason it is a good > idea, or should I just put the lists directly in the module? XML doesn't have the concept of lists, so in XML encoding it is possible that list entries are interleaved with other sibling elements. For example, if we have in YANG list a { ... } leaf b { ... } this is possible in XML encoding: ... ... ... This may or may not be a problem. JSON has arrays, so this issue doesn't exist in JSON encoding at all, and extra containers usually just add an extra hierarchy level. Lada > > Thank you, > Joel > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 19 04:55:15 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBC51299FD for ; Mon, 19 Dec 2016 04:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKcaRwcMo75I for ; Mon, 19 Dec 2016 04:55:12 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E081299FA for ; Mon, 19 Dec 2016 04:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14150; q=dns/txt; s=iport; t=1482152111; x=1483361711; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=6o3hKQfL3oxVRYSMgr8Ik0ZUTYEBELgo0/mO/Q4ztAs=; b=AOdEE3PpOErhlsCPgDryrV3ztnB8hQS5ZoXNa7uBr6xtNDFCnzILc7ig GhifdA58/2ywbSiUYy0NTqI6rtC9YY6MKdDN7v7hO4r5f6kir5f7HVO5J QfSsYaNZsx6a4TlOEmJpWpVg21kxEpFWzz3ur8x2x2rUq6iN+ZeheC3Hb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AAA92FdY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAXmBBo1Pc5Vlj2mDFoIPggoshXYCgjcUAQIBAQEBAQE?= =?us-ascii?q?BYiiEaAECBBIRSA4QCRMDAQIrAgJNAggGDQYCAQEeiEkOijGPVQGNdoIoL4pcA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYY2gX2CXIQSEQEsEIJkgl0FiGKSDoZSimK?= =?us-ascii?q?BdIUDgyeGL4o0g2WEDx83Yx8VDoYCPTSGLoIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,373,1477958400"; d="scan'208,217";a="648006082" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2016 12:54:59 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBJCsxe0011166; Mon, 19 Dec 2016 12:54:59 GMT References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> To: YANG Doctors From: Benoit Claise X-Forwarded-Message-Id: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> Message-ID: <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> Date: Mon, 19 Dec 2016 13:54:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------25BFB134363B01641609594D" Archived-At: Subject: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 12:55:14 -0000 This is a multi-part message in MIME format. --------------25BFB134363B01641609594D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit YANG experts, I would like to understand your from if I missed anything, if I've been smoking too much, or if you support this statement. Regards, B. -------- Forwarded Message -------- Subject: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) Date: Mon, 19 Dec 2016 04:48:53 -0800 From: Benoit Claise To: The IESG CC: cbor@ietf.org, cbor-chairs@ietf.org Benoit Claise has entered the following ballot position for charter-ietf-cbor-00-04: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Sorry for this late BLOCK. I had a very quick call with Alexey before the last IESG telechat: I want to understand if I missed anything. I filed a quick "NO RECORD" COMMENT. Then, we discussed some more during the telechat itself. And now, I finally had the time to think some more about this. My BLOCK is about this charter paragraph: Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it would be useful if protocol specifications could use a description format for the data in CBOR-encoded messages. The CBOR data definition language (CDDL, based on draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. The CBOR WG will complete the development of this specification by creating an Informational or Standards Track RFC. In OPS, we need automation. And automation will come from data models as, from data models, we're able to generate APIs. In the world of data modeling-driven management, we have: YANG as a data modeling language, with ABNF specifications YANG data modules, written with the YANG data modeling language different encodings, such as XML, JSON, or CBOR (draft-ietf-core-yang-cbor-03) protocols such as NETCONF or RESTCONF for configuration/monitoring/capabilities discovery note: working on pub/sub protocol (aka telemetry) for events See the first picture at http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driven-management/ Btw, I should add cbor. Now, in this proposed WG, you want to define a new data modeling language, "The CBOR data definition language" When I ask the question: So the structure of what could be accessed on a managed device?, you answer: No. While CDDL could be used to describe the structure of data at rest (a data store), that is not the objective. CDDL is used to define the structure of data in flight, e.g. a protocol message going from a node to a different node. (Using a term popular in semantic interoperability work in the health care domain, CDDL is about "structural interoperability” — it can tell you that there is supposed to be a data item “cheese-firmness” in the message and out of what set of values it needs to come, but it cannot tell you what the specific values mean in the real world or what cheese firmness is in the first place on a semantic level.) But what about the semantic definition (which is in YANG modules) of this information? This is key for management. I guess that the next item you'll want after this milestone is exactly data models and semantic, right? There are many schemas for IoT and I'm not trying to impose YANG in the IoT world but I want to understand why we need duplication. Note that there was an IAB-organized workshop on IoT data modeling in the past (https://www.iab.org/activities/workshops/iotsi/) However, it seems to me that your effort is exactly the reverse of data modeling driven management? You have an encoding, and then you want a new schema language Next, you'll need a mechanism to discover what is available on the managed devices, a mechanism to know the device capabilities, a mechanism for pub/sub, ... And you will redo the full OPS stack, for IoT (hence duplication). And, obviously, in the end, we will need a mapping between the two data modeling languages: YANG and CDDL. What is specific here? I wanted to write: what's specific to IoT here, but I don't even see IoT in the charter. There is just a kind of IoT reference in RFC7049 abstract. Why do we need this duplication within the IETF? Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work? Those are completely inline with data modeling-driven management and this charter seems to contradict this effort? What do I miss? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- OLD: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data model to include binary data and an extensibility model NEW: Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data interchange format to include binary data and an extensibility model Note: - In OPS, we make a clear distinction between the (YANG) data model, and the encoding (XML, JSON, etc.) - RFC 7159 mentions "data interchange format" in his abstract - I see in RFC 7049: The format defined here follows some specific design goals that are not well met by current formats. The underlying data model is an extended version of the JSON data model [RFC4627]. This is a mistake. Great we will have a new charter to accomplish this work - And don't forget the milestones. Regards, Benoit . --------------25BFB134363B01641609594D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit YANG experts,

I would like to understand your from if I missed anything, if I've been smoking too much, or if you support this statement.

Regards, B.


-------- Forwarded Message --------
Subject: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT)
Date: Mon, 19 Dec 2016 04:48:53 -0800
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
CC: cbor@ietf.org, cbor-chairs@ietf.org


Benoit Claise has entered the following ballot position for
charter-ietf-cbor-00-04: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-cbor/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Sorry for this late BLOCK.
I had a very quick call with Alexey before the last IESG telechat: I want
to understand if I missed anything.
I filed a quick "NO RECORD" COMMENT.
Then, we discussed some more during the telechat itself.
And now, I finally had the time to think some more about this.

My BLOCK is about this charter paragraph:

    Similar to the way ABNF (RFC 5234/7405) can be used to describe the
set of valid messages in a text representation, it would be useful if
protocol specifications could use a description format for the data in
CBOR-encoded messages. The CBOR data definition language (CDDL, based on
draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a
description technique that has already been used in CORE, ANIMA, CDNI,
and efforts outside the IETF. The CBOR WG will complete the development
of this specification by creating an Informational or Standards Track
RFC.


In OPS, we need automation. And automation will come from data models as,
from data models, we're able to generate APIs.
In the world of data modeling-driven management, we have:
    YANG as a data modeling language, with ABNF specifications
    YANG data modules, written with the YANG data modeling language
    different encodings, such as XML, JSON, or CBOR
(draft-ietf-core-yang-cbor-03)
    protocols such as NETCONF or RESTCONF for
configuration/monitoring/capabilities discovery
    note: working on pub/sub protocol (aka telemetry) for events

See the first picture at
http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driven-management/
Btw, I should add cbor.

Now, in this proposed WG, you want to define a new data modeling
language, "The CBOR data definition language"
When I ask the question: So the structure of what could be accessed on a
managed device?, you answer:

    No. While CDDL could be used to describe the structure of data at
rest (a data store), that is not the objective. CDDL is used to define
the structure of data in flight, e.g. a protocol message going from a
node to a different node. (Using a term popular in semantic
interoperability work in the health care domain, CDDL is about
"structural interoperability” — it can tell you that there is supposed to
be a data item “cheese-firmness” in the message and out of what set of
values it needs to come, but it cannot tell you what the specific values
mean in the real world or what cheese firmness is in the first place on a
semantic level.) 


But what about the semantic definition (which is in YANG modules) of this
information? This is key for management.
I guess that the next item you'll want after this milestone is exactly
data models and semantic, right?

There are many schemas for IoT and I'm not trying to impose YANG in the
IoT world but I want to understand why we need duplication.
Note that there was an IAB-organized workshop on IoT data modeling in the
past (https://www.iab.org/activities/workshops/iotsi/)
However, it seems to me that your effort is exactly the reverse of data
modeling driven management? You have an encoding, and then you want a new
schema language

Next, you'll need a mechanism to discover what is available on the
managed devices, a mechanism to know the device capabilities, a mechanism
for pub/sub, ...
And you will redo the full OPS stack, for IoT (hence duplication). And,
obviously, in the end, we will need a mapping between the two data
modeling languages: YANG and CDDL.

What is specific here?  I wanted to write: what's specific to IoT here,
but I don't even see IoT in the charter. There is just a kind of IoT
reference in RFC7049 abstract.
Why do we need this duplication within the IETF?
Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work?
Those are completely inline with data modeling-driven management and this
charter seems to contradict this effort?
What do I miss?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

OLD:

Concise Binary Object Representation (CBOR, RFC 7049) extends the
JavaScript Object Notation (JSON, RFC 7159) data model to include binary
data
and an extensibility model

NEW:
Concise Binary Object Representation (CBOR, RFC 7049) extends the
JavaScript Object Notation (JSON, RFC 7159) data interchange format to
include binary data
and an extensibility model

Note: 
- In OPS, we make a clear distinction between the (YANG) data model, and
the encoding (XML, JSON, etc.)
- RFC 7159 mentions "data interchange format" in his abstract
- I see in RFC 7049:
   The format defined here follows some specific design goals that are
   not well met by current formats.  The underlying data model is an
   extended version of the JSON data model [RFC4627]. 
This is a mistake. Great we will have a new charter to accomplish this
work

- And don't forget the milestones.

Regards, Benoit


.

--------------25BFB134363B01641609594D-- From nobody Mon Dec 19 05:21:53 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B12D129A34 for ; Mon, 19 Dec 2016 05:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE60Tff5sBVW for ; Mon, 19 Dec 2016 05:21:50 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3891C1294DF for ; Mon, 19 Dec 2016 05:21:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 071967C8; Mon, 19 Dec 2016 14:21:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jeeKb320bfyI; Mon, 19 Dec 2016 14:21:48 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 Dec 2016 14:21:48 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2DED2007A; Mon, 19 Dec 2016 14:21:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ifYYXzBzEUjf; Mon, 19 Dec 2016 14:21:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F87220079; Mon, 19 Dec 2016 14:21:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CDD643DD5DFC; Mon, 19 Dec 2016 14:21:47 +0100 (CET) Date: Mon, 19 Dec 2016 14:21:47 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20161219132147.GC2012@elstar.local> Mail-Followup-To: Benoit Claise , YANG Doctors References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:21:51 -0000 On Mon, Dec 19, 2016 at 01:54:59PM +0100, Benoit Claise wrote: > YANG experts, > > I would like to understand your from if I missed anything, if I've been > smoking too much, or if you support this statement. > Smoking? I expected perhaps a drink too much. ;-) There is one point I like to make, well perhaps two... a) In YANG, we do not really have a way to define just a data structure, i.e., a message format. Everything is more or less tied to the notion of datastores. We have tried to work around this a couple of times but as of today we do not have first class support for plain data structures. What CDDL is focussing on right now is plain data structures (e.g. message formats) and hence the starting point is different (but yes if CDDL gains traction, then they will be sooner or later look at the other things YANG does cover reasonably well today). b) Encodings and definition languages for encodings come and go. Are you planning to 'block' all of them? Is it worth it or is perhaps cheaper to let them go? When we brought YANG to the IETF, this was not immediately liked because there were already other data definition languages. On second try, we managed to get a working group and it seems we had luck to create something that got traction. Are we now in the position to block others (like others were trying to block us a couple of years ago)? That written, it might be useful to ask for a concise statement why YANG and YANG to CBOR is not providing what is needed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Dec 19 05:32:46 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6161129A53 for ; Mon, 19 Dec 2016 05:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeelHvuYCZ1B for ; Mon, 19 Dec 2016 05:32:43 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1725129A58 for ; Mon, 19 Dec 2016 05:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2282; q=dns/txt; s=iport; t=1482154351; x=1483363951; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4XYEwTIPaZQVZwMghnsfytfykXyMZo5UwLSjWY6HBvA=; b=A6U1YCJRv5c6JAgGfO+bETf0wtAvwg0g3Y9xJr19SWAeLMHWgXJGLCbf vPNpgILIP1YTeDmOZuD0MP2jWiSbnITaa9kHGtexr3mqwrUaNIPyC4iSy zx6K/HHDC9SAe9SFbg3vJENaVleY8LYmv8ZzOWKKcwtrPMRwXBYdx0vu/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAh4VdY/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR+BYAeNSJZYkn+CD4IKhiICgX0/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDARIoMQENDAQCAQgOAwQBAQEeCQcfExQJCAIEAQ0FCBqIQQiZQgGQH?= =?us-ascii?q?osLAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYsPigMeBZpwARqREJBWjhmEDgEfN4E?= =?us-ascii?q?lhDyBRXKHT4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,373,1477958400"; d="scan'208";a="362733898" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2016 13:32:31 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uBJDWV2u016611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2016 13:32:31 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Dec 2016 07:32:30 -0600 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1210.000; Mon, 19 Dec 2016 07:32:30 -0600 From: "Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco)" To: Juergen Schoenwaelder , "Benoit Claise (bclaise)" Thread-Topic: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) Thread-Index: AQHSWfcmfyJlpdRn0EWQDZk/X1fJnKEPplmA//+c8gA= Date: Mon, 19 Dec 2016 13:32:30 +0000 Message-ID: References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> <20161219132147.GC2012@elstar.local> In-Reply-To: <20161219132147.GC2012@elstar.local> 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.61.84.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:32:45 -0000 > -----Original Message----- > From: yang-doctors [mailto:yang-doctors-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Monday, December 19, 2016 2:22 PM > To: Benoit Claise (bclaise) > Cc: YANG Doctors > Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cb= or-00- > 04: (with BLOCK and COMMENT) >=20 > On Mon, Dec 19, 2016 at 01:54:59PM +0100, Benoit Claise wrote: > > YANG experts, > > > > I would like to understand your from if I missed anything, if I've > > been smoking too much, or if you support this statement. > > >=20 > Smoking? I expected perhaps a drink too much. ;-) >=20 > There is one point I like to make, well perhaps two... >=20 > a) In YANG, we do not really have a way to define just a data > structure, i.e., a message format. Everything is more or less tied > to the notion of datastores. We have tried to work around this a > couple of times but as of today we do not have first class support > for plain data structures. What CDDL is focussing on right now is > plain data structures (e.g. message formats) and hence the starting > point is different (but yes if CDDL gains traction, then they will > be sooner or later look at the other things YANG does cover > reasonably well today). For what it's worth in ODL we use notifications to model individual protoco= l messages. These instantiate groupings, which are also instantiated in the= datastores, providing the ability to move structured data between the two. >=20 > b) Encodings and definition languages for encodings come and go. Are > you planning to 'block' all of them? Is it worth it or is perhaps > cheaper to let them go? When we brought YANG to the IETF, this was > not immediately liked because there were already other data > definition languages. On second try, we managed to get a working > group and it seems we had luck to create something that got > traction. Are we now in the position to block others (like others > were trying to block us a couple of years ago)? Encodings are not really a problem, different languages (with unaligned met= amodels) tend to create barriers to adoption. Regards, Robert From nobody Mon Dec 19 05:36:24 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1889E12943B for ; Mon, 19 Dec 2016 05:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTHARuhh6wK8 for ; Mon, 19 Dec 2016 05:36:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9B74E129A79 for ; Mon, 19 Dec 2016 05:36:08 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id D4B031AE028C; Mon, 19 Dec 2016 14:36:06 +0100 (CET) Date: Mon, 19 Dec 2016 14:36:05 +0100 (CET) Message-Id: <20161219.143605.1083517024286619510.mbj@tail-f.com> To: rovarga@cisco.com From: Martin Bjorklund In-Reply-To: References: <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> <20161219132147.GC2012@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: yang-doctors@ietf.org Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:36:16 -0000 "Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco)" wrote: > > -----Original Message----- > > From: yang-doctors [mailto:yang-doctors-bounces@ietf.org] On Behalf Of > > Juergen Schoenwaelder > > Sent: Monday, December 19, 2016 2:22 PM > > To: Benoit Claise (bclaise) > > Cc: YANG Doctors > > Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on > > charter-ietf-cbor-00- > > 04: (with BLOCK and COMMENT) > > > > On Mon, Dec 19, 2016 at 01:54:59PM +0100, Benoit Claise wrote: > > > YANG experts, > > > > > > I would like to understand your from if I missed anything, if I've > > > been smoking too much, or if you support this statement. > > > > > > > Smoking? I expected perhaps a drink too much. ;-) > > > > There is one point I like to make, well perhaps two... > > > > a) In YANG, we do not really have a way to define just a data > > structure, i.e., a message format. Everything is more or less tied > > to the notion of datastores. We have tried to work around this a > > couple of times but as of today we do not have first class support > > for plain data structures. What CDDL is focussing on right now is > > plain data structures (e.g. message formats) and hence the starting > > point is different (but yes if CDDL gains traction, then they will > > be sooner or later look at the other things YANG does cover > > reasonably well today). > > For what it's worth in ODL we use notifications to model individual > protocol messages. These instantiate groupings, which are also > instantiated in the datastores, providing the ability to move > structured data between the two. And we're using an extension called tailf:structure. The drawback with using an extension for this is that it cannot be augmented with standard "augment". So it needs to be added to the core YANG language. /martin > > b) Encodings and definition languages for encodings come and go. Are > > you planning to 'block' all of them? Is it worth it or is perhaps > > cheaper to let them go? When we brought YANG to the IETF, this was > > not immediately liked because there were already other data > > definition languages. On second try, we managed to get a working > > group and it seems we had luck to create something that got > > traction. Are we now in the position to block others (like others > > were trying to block us a couple of years ago)? > > Encodings are not really a problem, different languages (with > unaligned metamodels) tend to create barriers to adoption. > > Regards, > Robert > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > From nobody Mon Dec 19 06:13:36 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49080129474 for ; Mon, 19 Dec 2016 06:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 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, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP2H4WdzwA1T for ; Mon, 19 Dec 2016 06:13:32 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC89129ADA for ; Mon, 19 Dec 2016 06:13:29 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be] (unknown [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be]) by mail.nic.cz (Postfix) with ESMTPSA id D517387B4C; Mon, 19 Dec 2016 15:13:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482156807; bh=UG8pA+a2JgG7PP88Zrz0QrytKGJ+c+/HQZYeeofFA8s=; h=From:Date:To; b=N5RO/ot4hbwwgi0m7+YhQC7A4eAs53eQ9wd65HzgsJWTHy3BkehGc9VhwLQZtm48C XnD+72ZIVWVzDRtJibPyojgm3EqYJLFp13NVFNCde00zgSNL/Aq4qT6EZb2rxji3fk /n7P2tbysH8qJ+T2sPGwFXwKM+/ZsJoGsEq0iRWU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 19 Dec 2016 15:13:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A11FFC4-CAEE-4B70-936A-C57479DFCD97@nic.cz> References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> <20161219132147.GC2012@elstar.local> To: "Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco)" X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 14:13:35 -0000 > On 19 Dec 2016, at 14:32, Robert Varga -X (rovarga - PANTHEON = TECHNOLOGIES at Cisco) wrote: >=20 >> -----Original Message----- >> From: yang-doctors [mailto:yang-doctors-bounces@ietf.org] On Behalf = Of >> Juergen Schoenwaelder >> Sent: Monday, December 19, 2016 2:22 PM >> To: Benoit Claise (bclaise) >> Cc: YANG Doctors >> Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on = charter-ietf-cbor-00- >> 04: (with BLOCK and COMMENT) >>=20 >> On Mon, Dec 19, 2016 at 01:54:59PM +0100, Benoit Claise wrote: >>> YANG experts, >>>=20 >>> I would like to understand your from if I missed anything, if I've >>> been smoking too much, or if you support this statement. >>>=20 >>=20 >> Smoking? I expected perhaps a drink too much. ;-) >>=20 >> There is one point I like to make, well perhaps two... >>=20 >> a) In YANG, we do not really have a way to define just a data >> structure, i.e., a message format. Everything is more or less tied >> to the notion of datastores. We have tried to work around this a >> couple of times but as of today we do not have first class support >> for plain data structures. What CDDL is focussing on right now is >> plain data structures (e.g. message formats) and hence the starting >> point is different (but yes if CDDL gains traction, then they will >> be sooner or later look at the other things YANG does cover >> reasonably well today). >=20 > For what it's worth in ODL we use notifications to model individual = protocol messages. These instantiate groupings, which are also = instantiated in the datastores, providing the ability to move structured = data between the two. >=20 >>=20 >> b) Encodings and definition languages for encodings come and go. Are >> you planning to 'block' all of them? Is it worth it or is perhaps >> cheaper to let them go? When we brought YANG to the IETF, this was >> not immediately liked because there were already other data >> definition languages. On second try, we managed to get a working >> group and it seems we had luck to create something that got >> traction. Are we now in the position to block others (like others >> were trying to block us a couple of years ago)? >=20 > Encodings are not really a problem, different languages (with = unaligned metamodels) tend to create barriers to adoption. Right, because XML, JSON and CBOR are not just different encodings, so, = for example, XML schema languages might be a good choice for XML but are = of no use for JSON and CBOR. Lada >=20 > Regards, > Robert >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 19 09:27:47 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655B6129C22 for ; Mon, 19 Dec 2016 09:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4GYKUPreSIB for ; Mon, 19 Dec 2016 09:27:41 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 55764127ABE for ; Mon, 19 Dec 2016 09:27:41 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id c47so153449065qtc.2 for ; Mon, 19 Dec 2016 09:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EH56b/VMe+4arGY1PapdxHNH6mLSo8o6YQr1D2Bv5Vg=; b=YXKV2pAc/WlAShlxAwobR8CTxiMSXFWkE5HdO7tsZMWtcpEejQEWDGMThWOGJ3Pqdl GuETRZGOtknyjQUgxzPIzGNVSVly/E8gaIes11Lf/DvrFAj8iZrlUdpfV35VvR38DH6x 9oGkZPtpONYRtRgVuEO/60qySQgn4+XwuZVbXrPRXKCxsx5ZOX4nhGW95aWNIlTsCIf6 6uQA9C5GD8UJVf+vTNWOhcxgZAtd3GPQnXWzByR9ZfMCsXBVxAXo9sUWyi8n9olIhc2D rA/09p+j/4EnaadDXJyVozKHsbgc/CDZPGJXy0wKMUSM1M7lH+iVbn0344VKte2yh+OX IQXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EH56b/VMe+4arGY1PapdxHNH6mLSo8o6YQr1D2Bv5Vg=; b=Dc4QKPV9ZoLrc3USBUlvhV9xe3X+sbXjKrN002G5wcPTCibin6zT/Z/hMKtPZcKyL+ BOwunH3aTsWkdlnwZH6gRtQM8eMIibr2M1fu/mRIhihDP5zI3FP28F8mFJv278umj/mb Ih+JX/qOxrXjQzjROVJ6nmHVhvPxIQlgPrdBYtqohzie/Kgpw/87Fd8+0YxlCkuSDWIs U+XO+ZW973DLPZnFO6Z0v74tM/gXRjvrH7dQt5ygMqPt3RTt0BetHt3gCCLOeSIGQiN6 rfW6CwhRw8D5Alan2zfkXl/Y8BIoukv2/TMcA1a+TPoR7M4A6GhOwu7qqCt94KI/DImN wbXw== X-Gm-Message-State: AIkVDXKyQfEXi/sFfze2aaREbWF/8Fw/C7PYtCavE5MWjT3SZuwWg3xtzZFxhn62Vs3NX3XqdwoDhPx5rlcw7w== X-Received: by 10.200.40.211 with SMTP id j19mr18105553qtj.72.1482168460408; Mon, 19 Dec 2016 09:27:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Mon, 19 Dec 2016 09:27:39 -0800 (PST) In-Reply-To: <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> From: Andy Bierman Date: Mon, 19 Dec 2016 09:27:39 -0800 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a1149e954949f920544063c69 Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 17:27:45 -0000 --001a1149e954949f920544063c69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We also have a proprietary system for describing protocol messages, internal data structures, model of XRD for RESTCONF, etc. Sometimes this is done with plain YANG modules including augment. If the server does not advertise the module then the client cannot get fooled by the misuse of YANG. It would be useful to have a standard way of defining YANG data structures. The CORE WG is very divided about using YANG. (Look at SenML for example!) YANG is too heavyweight for sensors and actuators, and many view IoT and nothing more than that. The work that concerns me is SID, which attempts to use a single uint32 to identify every possible schema node in every possible module into a 1-dimensional numbering space. It is not an accident that identifiers in SMIv2 or YANG are based on immutable properties of the language. It is very risky to base the naming scheme on properties that can change from release to release. The client and server must agree on the conceptual managed objects. It can be very hard to detect bugs of this nature. Read their draft and see what you think: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ On Mon, Dec 19, 2016 at 4:54 AM, Benoit Claise wrote: > YANG experts, > > I would like to understand your from if I missed anything, if I've been > smoking too much, or if you support this statement. > > Regards, B. > > > -------- Forwarded Message -------- > Subject: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK > and COMMENT) > Date: Mon, 19 Dec 2016 04:48:53 -0800 > From: Benoit Claise > To: The IESG > CC: cbor@ietf.org, cbor-chairs@ietf.org > > Benoit Claise has entered the following ballot position for > charter-ietf-cbor-00-04: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here:https:= //datatracker.ietf.org/doc/charter-ietf-cbor/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > Sorry for this late BLOCK. > I had a very quick call with Alexey before the last IESG telechat: I want > to understand if I missed anything. > I filed a quick "NO RECORD" COMMENT. > Then, we discussed some more during the telechat itself. > And now, I finally had the time to think some more about this. > > My BLOCK is about this charter paragraph: > > Similar to the way ABNF (RFC 5234/7405) can be used to describe the > set of valid messages in a text representation, it would be useful if > protocol specifications could use a description format for the data in > CBOR-encoded messages. The CBOR data definition language (CDDL, based on > draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a > description technique that has already been used in CORE, ANIMA, CDNI, > and efforts outside the IETF. The CBOR WG will complete the development > of this specification by creating an Informational or Standards Track > RFC. > > > In OPS, we need automation. And automation will come from data models as, > from data models, we're able to generate APIs. > In the world of data modeling-driven management, we have: > YANG as a data modeling language, with ABNF specifications > YANG data modules, written with the YANG data modeling language > different encodings, such as XML, JSON, or CBOR > (draft-ietf-core-yang-cbor-03) > protocols such as NETCONF or RESTCONF for > configuration/monitoring/capabilities discovery > note: working on pub/sub protocol (aka telemetry) for events > > See the first picture athttp://www.claise.be/2016/12/yang-opensource-tool= s-for-data-modeling-driven-management/ > Btw, I should add cbor. > > Now, in this proposed WG, you want to define a new data modeling > language, "The CBOR data definition language" > When I ask the question: So the structure of what could be accessed on a > managed device?, you answer: > > No. While CDDL could be used to describe the structure of data at > rest (a data store), that is not the objective. CDDL is used to define > the structure of data in flight, e.g. a protocol message going from a > node to a different node. (Using a term popular in semantic > interoperability work in the health care domain, CDDL is about > "structural interoperability=E2=80=9D =E2=80=94 it can tell you that ther= e is supposed to > be a data item =E2=80=9Ccheese-firmness=E2=80=9D in the message and out o= f what set of > values it needs to come, but it cannot tell you what the specific values > mean in the real world or what cheese firmness is in the first place on a > semantic level.) > > > But what about the semantic definition (which is in YANG modules) of this > information? This is key for management. > I guess that the next item you'll want after this milestone is exactly > data models and semantic, right? > > There are many schemas for IoT and I'm not trying to impose YANG in the > IoT world but I want to understand why we need duplication. > Note that there was an IAB-organized workshop on IoT data modeling in the > past (https://www.iab.org/activities/workshops/iotsi/) > However, it seems to me that your effort is exactly the reverse of data > modeling driven management? You have an encoding, and then you want a new > schema language > > Next, you'll need a mechanism to discover what is available on the > managed devices, a mechanism to know the device capabilities, a mechanism > for pub/sub, ... > And you will redo the full OPS stack, for IoT (hence duplication). And, > obviously, in the end, we will need a mapping between the two data > modeling languages: YANG and CDDL. > > What is specific here? I wanted to write: what's specific to IoT here, > but I don't even see IoT in the charter. There is just a kind of IoT > reference in RFC7049 abstract. > Why do we need this duplication within the IETF? > Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work? > Those are completely inline with data modeling-driven management and this > charter seems to contradict this effort? > What do I miss? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > OLD: > > Concise Binary Object Representation (CBOR, RFC 7049) extends the > JavaScript Object Notation (JSON, RFC 7159) data model to include binary > data > and an extensibility model > > NEW: > Concise Binary Object Representation (CBOR, RFC 7049) extends the > JavaScript Object Notation (JSON, RFC 7159) data interchange format to > include binary data > and an extensibility model > > Note: > - In OPS, we make a clear distinction between the (YANG) data model, and > the encoding (XML, JSON, etc.) > - RFC 7159 mentions "data interchange format" in his abstract > - I see in RFC 7049: > The format defined here follows some specific design goals that are > not well met by current formats. The underlying data model is an > extended version of the JSON data model [RFC4627]. > This is a mistake. Great we will have a new charter to accomplish this > work > > - And don't forget the milestones. > > Regards, Benoit > > > . > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > --001a1149e954949f920544063c69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We also have a proprietary system f= or describing protocol messages,
internal data structures, model = of XRD for RESTCONF, etc.
Sometimes this is done with plain YANG = modules including augment.
If the server does not advertise the m= odule then the client cannot get
fooled by the misuse of YANG.

It would be useful to have a standard way of definin= g YANG data structures.

The CORE WG is very divide= d about using YANG.
(Look at SenML for example!)
YANG i= s too heavyweight for sensors and actuators, and many view IoT
an= d nothing more than that.

The work that concerns m= e is SID, which attempts to use a single uint32
to identify every= possible schema node in every possible module into
a 1-dimension= al numbering space.=C2=A0 It is not an accident that identifiers
= in SMIv2 or YANG are based on immutable properties of the language.
It is very risky to base the naming scheme on properties that can change=
from release to release. The client and server must agree on the= conceptual
managed objects. It can be very hard to detect bugs o= f this nature.

Read their draft and see what you t= hink:
<= div>



On Mon, Dec 19, 2016 at 4:54 AM, Benoit Cl= aise <bclaise@cisco.com> wrote:
=20 =20 =20
YANG experts,

I would like to understand your from if I missed anything, if I've been smoking too much, or if you support this statement.

Regards, B.


-------- Forwarded Message --------
Subject: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT)
Date: Mon, 19 Dec 2016 04:48:53 -0800
From: Benoit Claise <bclaise@= cisco.com>
To: The IESG <iesg@ietf.org>=
CC: cbor@ietf.org, cbor-chairs@ietf.org


Benoit Claise has entered the following ballot position for
charter-ietf-cbor-00-04: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatra=
cker.ietf.org/doc/charter-ietf-cbor/



-----------------------------------------------------------------=
-----
BLOCK:
-----------------------------------------------------------------=
-----

Sorry for this late BLOCK.
I had a very quick call with Alexey before the last IESG telechat: I want
to understand if I missed anything.
I filed a quick "NO RECORD" COMMENT.
Then, we discussed some more during the telechat itself.
And now, I finally had the time to think some more about this.

My BLOCK is about this charter paragraph:

    Similar to the way ABNF (RFC 5234/7405) can be used to describe the
set of valid messages in a text representation, it would be useful if
protocol specifications could use a description format for the data in
CBOR-encoded messages. The CBOR data definition language (CDDL, based on
draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a
description technique that has already been used in CORE, ANIMA, CDNI,
and efforts outside the IETF. The CBOR WG will complete the development
of this specification by creating an Informational or Standards Track
RFC.


In OPS, we need automation. And automation will come from data models as,
from data models, we're able to generate APIs.
In the world of data modeling-driven management, we have:
    YANG as a data modeling language, with ABNF specifications
    YANG data modules, written with the YANG data modeling language
    different encodings, such as XML, JSON, or CBOR
(draft-ietf-core-yang-cbor-03)
    protocols such as NETCONF or RESTCONF for
configuration/monitoring/capabilities discovery
    note: working on pub/sub protocol (aka telemetry) for events

See the first picture at
http://www.claise.be/2016/12/yang-opensource-tool=
s-for-data-modeling-driven-management/
Btw, I should add cbor.

Now, in this proposed WG, you want to define a new data modeling
language, "The CBOR data definition language"
When I ask the question: So the structure of what could be accessed on a
managed device?, you answer:

    No. While CDDL could be used to describe the structure of data at
rest (a data store), that is not the objective. CDDL is used to define
the structure of data in flight, e.g. a protocol message going from a
node to a different node. (Using a term popular in semantic
interoperability work in the health care domain, CDDL is about
"structural interoperability=E2=80=9D =E2=80=94 it can tell you that t=
here is supposed to
be a data item =E2=80=9Ccheese-firmness=E2=80=9D in the message and out of =
what set of
values it needs to come, but it cannot tell you what the specific values
mean in the real world or what cheese firmness is in the first place on a
semantic level.)=20


But what about the semantic definition (which is in YANG modules) of this
information? This is key for management.
I guess that the next item you'll want after this milestone is exactly
data models and semantic, right?

There are many schemas for IoT and I'm not trying to impose YANG in the
IoT world but I want to understand why we need duplication.
Note that there was an IAB-organized workshop on IoT data modeling in the
past (https://www.i=
ab.org/activities/workshops/iotsi/)
However, it seems to me that your effort is exactly the reverse of data
modeling driven management? You have an encoding, and then you want a new
schema language

Next, you'll need a mechanism to discover what is available on the
managed devices, a mechanism to know the device capabilities, a mechanism
for pub/sub, ...
And you will redo the full OPS stack, for IoT (hence duplication). And,
obviously, in the end, we will need a mapping between the two data
modeling languages: YANG and CDDL.

What is specific here?  I wanted to write: what's specific to IoT here,
but I don't even see IoT in the charter. There is just a kind of IoT
reference in RFC7049 abstract.
Why do we need this duplication within the IETF?
Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work=
?
Those are completely inline with data modeling-driven management and this
charter seems to contradict this effort?
What do I miss?


-----------------------------------------------------------------=
-----
COMMENT:
-----------------------------------------------------------------=
-----

OLD:

Concise Binary Object Representation (CBOR, RFC 7049) extends the
JavaScript Object Notation (JSON, RFC 7159) data model to include binary
data
and an extensibility model

NEW:
Concise Binary Object Representation (CBOR, RFC 7049) extends the
JavaScript Object Notation (JSON, RFC 7159) data interchange format to
include binary data
and an extensibility model

Note:=20
- In OPS, we make a clear distinction between the (YANG) data model, and
the encoding (XML, JSON, etc.)
- RFC 7159 mentions "data interchange format" in his abstract
- I see in RFC 7049:
   The format defined here follows some specific design goals that are
   not well met by current formats.  The underlying data model is an
   extended version of the JSON data model [RFC4627].=20
This is a mistake. Great we will have a new charter to accomplish this
work

- And don't forget the milestones.

Regards, Benoit


.


_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors


--001a1149e954949f920544063c69-- From nobody Tue Dec 20 11:06:00 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785441295AC for ; Tue, 20 Dec 2016 11:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2eHI3rv8hkC for ; Tue, 20 Dec 2016 11:05:56 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0111.outbound.protection.outlook.com [104.47.42.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E6A12959E for ; Tue, 20 Dec 2016 11:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+vxQgn1ddP+Qc73pabdCsEnpNtLzM4FUBEx0ZIi3zQs=; b=JwiJqKGA1wYop9QC1JqRAk7sZ/De/joOQZ6HH15qAw1VVLAA7RC1HjmuD4rEeGCmhKbeixD4NoKwAmRTM7PzQXFhQDDgf5wqiMkY/ITiLxS7eMA9rfhK/C5R/70jt40v1Usq5BfctLJ9w3eB35GwMbu5GZY9a3nQEeyl9CPco1Q= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.5; Tue, 20 Dec 2016 19:05:55 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0803.010; Tue, 20 Dec 2016 19:05:54 +0000 From: Kent Watsen To: Andy Bierman , Benoit Claise Thread-Topic: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) Thread-Index: AQHSWfcnzkTEbu9HXE+yqpQhJReBIqEPhnaAgAFZ9YA= Date: Tue, 20 Dec 2016 19:05:54 +0000 Message-ID: <4841087D-DD10-4613-B227-3481F0A618EB@juniper.net> References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@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/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 3e0d4d16-4628-42e6-45d5-08d4290b394e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:2cgD3Ohdn5IX9VQF3WsMY7P3rHZcDZ93PFZFRnznuZPpJZ51uFETqSnRyiC797mbH3ybX9IfDxTE6VfwNCF79huZr/aAFB4fgLvndC6hseYKkTuGrTrwRxUSxI9RbtjLUXNeYNLFb5URek/N/2yvhDQrOXd0g17oEj57Vmcft+ip8MDDfLFPEC1YLPGi0O2w1/c1BC111EdNpyGT/bXKgmnbFwlLmL8RVZKC2JkgK8C9SqqqWFurstIE462FySVFG06QLIk4qrZsEyOUhBSVYj6wndQtIYXsGnCvyQMTJ2H7bCWhJmasgr1arOc0ISayR/M2b8mTgzGsVTFt1JLK0hPqbG1BiRjkF9m7r1aSnCHhWCrlQc9X1ub8R7qeE+opV3ZScA7AMLklzP3+G/AiKhk+qBMY7w936cZD02DAdIgutuySblUnWLS/zQRReIkles86pY+/1cRI0/ZQMdo22w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(120809045254105)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0162ACCC24 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(199003)(57704003)(189002)(76104003)(54094003)(24454002)(377454003)(86362001)(92566002)(229853002)(230783001)(68736007)(38730400001)(7906003)(82746002)(2900100001)(6116002)(3846002)(102836003)(2950100002)(5660300001)(189998001)(25786008)(7736002)(6486002)(77096006)(3280700002)(83506001)(3660700001)(606005)(6436002)(83716003)(6512006)(6506006)(8676002)(81156014)(101416001)(50986999)(33656002)(8936002)(5001770100001)(36756003)(4001350100001)(97736004)(76176999)(561944003)(54356999)(106356001)(105586002)(122556002)(106116001)(99286002)(4326007)(2906002)(81166006)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_4841087DDD104613B2273481F0A618EBjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2016 19:05:54.6750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 19:05:58 -0000 --_000_4841087DDD104613B2273481F0A618EBjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyB0aGUgaXNzdWUgSSByYWlzZWQgZHVyaW5nIHRoZSBORVRDT05GIHNlc3Npb24gaW4g U2VvdWwuICBCb3RoIHRoZSB6ZXJvdG91Y2ggYW5kIHRoZSB2b3VjaGVyIGRyYWZ0cyBhcmUgY3Vy cmVudGx5IHVzaW5nIGEgWUFORyBtb2R1bGUgdG8gZGVmaW5lIGEgZGF0YSBzdHJ1Y3R1cmUsIHdo aWNoIHRoZXkgY2xhaW0gaXMgZW5jb2RlZCB0aGUgc2FtZSBhcyBpZiByZXR1cm5lZCBieSBhIFJF U1RDT05GIHNlcnZlciB1c2luZyBhIEdFVCByZXF1ZXN0IHdpdGggYSBVUkwgdG8gdGhlIHNwZWNp ZmljIHJlc291cmNlLg0KDQpJIHN0aWxsIG5lZWQgdG8gZm9ybWFsbHkgcmFpc2UgdGhpcyBhcyBh biBpc3N1ZSBibG9ja2luZyB0aGVzZSBkcmFmdHMsIGJ1dCBhc3N1bWluZyB3ZSBhcmUgYWJsZSB0 byByZXNvbHZlIHRoaXMgWUFORyBtYXBwaW5nIGlzc3VlLCBhbmQgdGhlcmUgYWxyZWFkeSBleGlz dHMgYSBDQk9SIGVuY29kaW5nLCB0aGVuIEkgd29uZGVyIGlmIHRoaXMgd291bGQgYmUgc3VmZmlj aWVudCBhbmQgbmVnYXRlIHRoZSBuZWVkIHRvIGRlZmluZSBDRERMLg0KDQpLZW50DQoNCg0KRnJv bTogeWFuZy1kb2N0b3JzIDx5YW5nLWRvY3RvcnMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm IG9mIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0KRGF0ZTogTW9uZGF5LCBEZWNl bWJlciAxOSwgMjAxNiBhdCAxMjoyNyBQTQ0KVG86IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lz Y28uY29tPg0KQ2M6IFlBTkcgRG9jdG9ycyA8eWFuZy1kb2N0b3JzQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFt5YW5nLWRvY3RvcnNdIEZ3ZDogQmVub2l0IENsYWlzZSdzIEJsb2NrIG9uIGNoYXJ0 ZXItaWV0Zi1jYm9yLTAwLTA0OiAod2l0aCBCTE9DSyBhbmQgQ09NTUVOVCkNCg0KSGksDQoNCldl IGFsc28gaGF2ZSBhIHByb3ByaWV0YXJ5IHN5c3RlbSBmb3IgZGVzY3JpYmluZyBwcm90b2NvbCBt ZXNzYWdlcywNCmludGVybmFsIGRhdGEgc3RydWN0dXJlcywgbW9kZWwgb2YgWFJEIGZvciBSRVNU Q09ORiwgZXRjLg0KU29tZXRpbWVzIHRoaXMgaXMgZG9uZSB3aXRoIHBsYWluIFlBTkcgbW9kdWxl cyBpbmNsdWRpbmcgYXVnbWVudC4NCklmIHRoZSBzZXJ2ZXIgZG9lcyBub3QgYWR2ZXJ0aXNlIHRo ZSBtb2R1bGUgdGhlbiB0aGUgY2xpZW50IGNhbm5vdCBnZXQNCmZvb2xlZCBieSB0aGUgbWlzdXNl IG9mIFlBTkcuDQoNCkl0IHdvdWxkIGJlIHVzZWZ1bCB0byBoYXZlIGEgc3RhbmRhcmQgd2F5IG9m IGRlZmluaW5nIFlBTkcgZGF0YSBzdHJ1Y3R1cmVzLg0KDQpUaGUgQ09SRSBXRyBpcyB2ZXJ5IGRp dmlkZWQgYWJvdXQgdXNpbmcgWUFORy4NCihMb29rIGF0IFNlbk1MIGZvciBleGFtcGxlISkNCllB TkcgaXMgdG9vIGhlYXZ5d2VpZ2h0IGZvciBzZW5zb3JzIGFuZCBhY3R1YXRvcnMsIGFuZCBtYW55 IHZpZXcgSW9UDQphbmQgbm90aGluZyBtb3JlIHRoYW4gdGhhdC4NCg0KVGhlIHdvcmsgdGhhdCBj b25jZXJucyBtZSBpcyBTSUQsIHdoaWNoIGF0dGVtcHRzIHRvIHVzZSBhIHNpbmdsZSB1aW50MzIN CnRvIGlkZW50aWZ5IGV2ZXJ5IHBvc3NpYmxlIHNjaGVtYSBub2RlIGluIGV2ZXJ5IHBvc3NpYmxl IG1vZHVsZSBpbnRvDQphIDEtZGltZW5zaW9uYWwgbnVtYmVyaW5nIHNwYWNlLiAgSXQgaXMgbm90 IGFuIGFjY2lkZW50IHRoYXQgaWRlbnRpZmllcnMNCmluIFNNSXYyIG9yIFlBTkcgYXJlIGJhc2Vk IG9uIGltbXV0YWJsZSBwcm9wZXJ0aWVzIG9mIHRoZSBsYW5ndWFnZS4NCkl0IGlzIHZlcnkgcmlz a3kgdG8gYmFzZSB0aGUgbmFtaW5nIHNjaGVtZSBvbiBwcm9wZXJ0aWVzIHRoYXQgY2FuIGNoYW5n ZQ0KZnJvbSByZWxlYXNlIHRvIHJlbGVhc2UuIFRoZSBjbGllbnQgYW5kIHNlcnZlciBtdXN0IGFn cmVlIG9uIHRoZSBjb25jZXB0dWFsDQptYW5hZ2VkIG9iamVjdHMuIEl0IGNhbiBiZSB2ZXJ5IGhh cmQgdG8gZGV0ZWN0IGJ1Z3Mgb2YgdGhpcyBuYXR1cmUuDQoNClJlYWQgdGhlaXIgZHJhZnQgYW5k IHNlZSB3aGF0IHlvdSB0aGluazoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtY29yZS1zaWQvDQoNCg0KDQoNCk9uIE1vbiwgRGVjIDE5LCAyMDE2IGF0IDQ6NTQg QU0sIEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2Nv LmNvbT4+IHdyb3RlOg0KWUFORyBleHBlcnRzLA0KDQpJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFu ZCB5b3VyIGZyb20gaWYgSSBtaXNzZWQgYW55dGhpbmcsIGlmIEkndmUgYmVlbiBzbW9raW5nIHRv byBtdWNoLCBvciBpZiB5b3Ugc3VwcG9ydCB0aGlzIHN0YXRlbWVudC4NCg0KUmVnYXJkcywgQi4N Cg0KDQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDoNCg0KQmVu b2l0IENsYWlzZSdzIEJsb2NrIG9uIGNoYXJ0ZXItaWV0Zi1jYm9yLTAwLTA0OiAod2l0aCBCTE9D SyBhbmQgQ09NTUVOVCkNCg0KRGF0ZToNCg0KTW9uLCAxOSBEZWMgMjAxNiAwNDo0ODo1MyAtMDgw MA0KDQpGcm9tOg0KDQpCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT48bWFpbHRvOmJj bGFpc2VAY2lzY28uY29tPg0KDQpUbzoNCg0KVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+PG1haWx0 bzppZXNnQGlldGYub3JnPg0KDQpDQzoNCg0KY2JvckBpZXRmLm9yZzxtYWlsdG86Y2JvckBpZXRm Lm9yZz4sIGNib3ItY2hhaXJzQGlldGYub3JnPG1haWx0bzpjYm9yLWNoYWlyc0BpZXRmLm9yZz4N Cg0KDQoNCkJlbm9pdCBDbGFpc2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9z aXRpb24gZm9yDQoNCmNoYXJ0ZXItaWV0Zi1jYm9yLTAwLTA0OiBCbG9jaw0KDQoNCg0KV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsDQoNCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVz LiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQoNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KDQoNCg0KDQoNCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90 IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1jYm9yLw0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCkJMT0NLOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpTb3JyeSBmb3IgdGhpcyBsYXRlIEJM T0NLLg0KDQpJIGhhZCBhIHZlcnkgcXVpY2sgY2FsbCB3aXRoIEFsZXhleSBiZWZvcmUgdGhlIGxh c3QgSUVTRyB0ZWxlY2hhdDogSSB3YW50DQoNCnRvIHVuZGVyc3RhbmQgaWYgSSBtaXNzZWQgYW55 dGhpbmcuDQoNCkkgZmlsZWQgYSBxdWljayAiTk8gUkVDT1JEIiBDT01NRU5ULg0KDQpUaGVuLCB3 ZSBkaXNjdXNzZWQgc29tZSBtb3JlIGR1cmluZyB0aGUgdGVsZWNoYXQgaXRzZWxmLg0KDQpBbmQg bm93LCBJIGZpbmFsbHkgaGFkIHRoZSB0aW1lIHRvIHRoaW5rIHNvbWUgbW9yZSBhYm91dCB0aGlz Lg0KDQoNCg0KTXkgQkxPQ0sgaXMgYWJvdXQgdGhpcyBjaGFydGVyIHBhcmFncmFwaDoNCg0KDQoN CiAgICBTaW1pbGFyIHRvIHRoZSB3YXkgQUJORiAoUkZDIDUyMzQvNzQwNSkgY2FuIGJlIHVzZWQg dG8gZGVzY3JpYmUgdGhlDQoNCnNldCBvZiB2YWxpZCBtZXNzYWdlcyBpbiBhIHRleHQgcmVwcmVz ZW50YXRpb24sIGl0IHdvdWxkIGJlIHVzZWZ1bCBpZg0KDQpwcm90b2NvbCBzcGVjaWZpY2F0aW9u cyBjb3VsZCB1c2UgYSBkZXNjcmlwdGlvbiBmb3JtYXQgZm9yIHRoZSBkYXRhIGluDQoNCkNCT1It ZW5jb2RlZCBtZXNzYWdlcy4gVGhlIENCT1IgZGF0YSBkZWZpbml0aW9uIGxhbmd1YWdlIChDRERM LCBiYXNlZCBvbg0KDQpkcmFmdC1ncmVldmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGwpIGlzIGEg cHJvcG9zYWwgZm9yIHN1Y2ggYQ0KDQpkZXNjcmlwdGlvbiB0ZWNobmlxdWUgdGhhdCBoYXMgYWxy ZWFkeSBiZWVuIHVzZWQgaW4gQ09SRSwgQU5JTUEsIENETkksDQoNCmFuZCBlZmZvcnRzIG91dHNp ZGUgdGhlIElFVEYuIFRoZSBDQk9SIFdHIHdpbGwgY29tcGxldGUgdGhlIGRldmVsb3BtZW50DQoN Cm9mIHRoaXMgc3BlY2lmaWNhdGlvbiBieSBjcmVhdGluZyBhbiBJbmZvcm1hdGlvbmFsIG9yIFN0 YW5kYXJkcyBUcmFjaw0KDQpSRkMuDQoNCg0KDQoNCg0KSW4gT1BTLCB3ZSBuZWVkIGF1dG9tYXRp b24uIEFuZCBhdXRvbWF0aW9uIHdpbGwgY29tZSBmcm9tIGRhdGEgbW9kZWxzIGFzLA0KDQpmcm9t IGRhdGEgbW9kZWxzLCB3ZSdyZSBhYmxlIHRvIGdlbmVyYXRlIEFQSXMuDQoNCkluIHRoZSB3b3Js ZCBvZiBkYXRhIG1vZGVsaW5nLWRyaXZlbiBtYW5hZ2VtZW50LCB3ZSBoYXZlOg0KDQogICAgWUFO RyBhcyBhIGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2UsIHdpdGggQUJORiBzcGVjaWZpY2F0aW9ucw0K DQogICAgWUFORyBkYXRhIG1vZHVsZXMsIHdyaXR0ZW4gd2l0aCB0aGUgWUFORyBkYXRhIG1vZGVs aW5nIGxhbmd1YWdlDQoNCiAgICBkaWZmZXJlbnQgZW5jb2RpbmdzLCBzdWNoIGFzIFhNTCwgSlNP Tiwgb3IgQ0JPUg0KDQooZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci0wMykNCg0KICAgIHByb3Rv Y29scyBzdWNoIGFzIE5FVENPTkYgb3IgUkVTVENPTkYgZm9yDQoNCmNvbmZpZ3VyYXRpb24vbW9u aXRvcmluZy9jYXBhYmlsaXRpZXMgZGlzY292ZXJ5DQoNCiAgICBub3RlOiB3b3JraW5nIG9uIHB1 Yi9zdWIgcHJvdG9jb2wgKGFrYSB0ZWxlbWV0cnkpIGZvciBldmVudHMNCg0KDQoNClNlZSB0aGUg Zmlyc3QgcGljdHVyZSBhdA0KDQpodHRwOi8vd3d3LmNsYWlzZS5iZS8yMDE2LzEyL3lhbmctb3Bl bnNvdXJjZS10b29scy1mb3ItZGF0YS1tb2RlbGluZy1kcml2ZW4tbWFuYWdlbWVudC8NCg0KQnR3 LCBJIHNob3VsZCBhZGQgY2Jvci4NCg0KDQoNCk5vdywgaW4gdGhpcyBwcm9wb3NlZCBXRywgeW91 IHdhbnQgdG8gZGVmaW5lIGEgbmV3IGRhdGEgbW9kZWxpbmcNCg0KbGFuZ3VhZ2UsICJUaGUgQ0JP UiBkYXRhIGRlZmluaXRpb24gbGFuZ3VhZ2UiDQoNCldoZW4gSSBhc2sgdGhlIHF1ZXN0aW9uOiBT byB0aGUgc3RydWN0dXJlIG9mIHdoYXQgY291bGQgYmUgYWNjZXNzZWQgb24gYQ0KDQptYW5hZ2Vk IGRldmljZT8sIHlvdSBhbnN3ZXI6DQoNCg0KDQogICAgTm8uIFdoaWxlIENEREwgY291bGQgYmUg dXNlZCB0byBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9mIGRhdGEgYXQNCg0KcmVzdCAoYSBkYXRh IHN0b3JlKSwgdGhhdCBpcyBub3QgdGhlIG9iamVjdGl2ZS4gQ0RETCBpcyB1c2VkIHRvIGRlZmlu ZQ0KDQp0aGUgc3RydWN0dXJlIG9mIGRhdGEgaW4gZmxpZ2h0LCBlLmcuIGEgcHJvdG9jb2wgbWVz c2FnZSBnb2luZyBmcm9tIGENCg0Kbm9kZSB0byBhIGRpZmZlcmVudCBub2RlLiAoVXNpbmcgYSB0 ZXJtIHBvcHVsYXIgaW4gc2VtYW50aWMNCg0KaW50ZXJvcGVyYWJpbGl0eSB3b3JrIGluIHRoZSBo ZWFsdGggY2FyZSBkb21haW4sIENEREwgaXMgYWJvdXQNCg0KInN0cnVjdHVyYWwgaW50ZXJvcGVy YWJpbGl0eeKAnSDigJQgaXQgY2FuIHRlbGwgeW91IHRoYXQgdGhlcmUgaXMgc3VwcG9zZWQgdG8N Cg0KYmUgYSBkYXRhIGl0ZW0g4oCcY2hlZXNlLWZpcm1uZXNz4oCdIGluIHRoZSBtZXNzYWdlIGFu ZCBvdXQgb2Ygd2hhdCBzZXQgb2YNCg0KdmFsdWVzIGl0IG5lZWRzIHRvIGNvbWUsIGJ1dCBpdCBj YW5ub3QgdGVsbCB5b3Ugd2hhdCB0aGUgc3BlY2lmaWMgdmFsdWVzDQoNCm1lYW4gaW4gdGhlIHJl YWwgd29ybGQgb3Igd2hhdCBjaGVlc2UgZmlybW5lc3MgaXMgaW4gdGhlIGZpcnN0IHBsYWNlIG9u IGENCg0Kc2VtYW50aWMgbGV2ZWwuKQ0KDQoNCg0KDQoNCkJ1dCB3aGF0IGFib3V0IHRoZSBzZW1h bnRpYyBkZWZpbml0aW9uICh3aGljaCBpcyBpbiBZQU5HIG1vZHVsZXMpIG9mIHRoaXMNCg0KaW5m b3JtYXRpb24/IFRoaXMgaXMga2V5IGZvciBtYW5hZ2VtZW50Lg0KDQpJIGd1ZXNzIHRoYXQgdGhl IG5leHQgaXRlbSB5b3UnbGwgd2FudCBhZnRlciB0aGlzIG1pbGVzdG9uZSBpcyBleGFjdGx5DQoN CmRhdGEgbW9kZWxzIGFuZCBzZW1hbnRpYywgcmlnaHQ/DQoNCg0KDQpUaGVyZSBhcmUgbWFueSBz Y2hlbWFzIGZvciBJb1QgYW5kIEknbSBub3QgdHJ5aW5nIHRvIGltcG9zZSBZQU5HIGluIHRoZQ0K DQpJb1Qgd29ybGQgYnV0IEkgd2FudCB0byB1bmRlcnN0YW5kIHdoeSB3ZSBuZWVkIGR1cGxpY2F0 aW9uLg0KDQpOb3RlIHRoYXQgdGhlcmUgd2FzIGFuIElBQi1vcmdhbml6ZWQgd29ya3Nob3Agb24g SW9UIGRhdGEgbW9kZWxpbmcgaW4gdGhlDQoNCnBhc3QgKGh0dHBzOi8vd3d3LmlhYi5vcmcvYWN0 aXZpdGllcy93b3Jrc2hvcHMvaW90c2kvKQ0KDQpIb3dldmVyLCBpdCBzZWVtcyB0byBtZSB0aGF0 IHlvdXIgZWZmb3J0IGlzIGV4YWN0bHkgdGhlIHJldmVyc2Ugb2YgZGF0YQ0KDQptb2RlbGluZyBk cml2ZW4gbWFuYWdlbWVudD8gWW91IGhhdmUgYW4gZW5jb2RpbmcsIGFuZCB0aGVuIHlvdSB3YW50 IGEgbmV3DQoNCnNjaGVtYSBsYW5ndWFnZQ0KDQoNCg0KTmV4dCwgeW91J2xsIG5lZWQgYSBtZWNo YW5pc20gdG8gZGlzY292ZXIgd2hhdCBpcyBhdmFpbGFibGUgb24gdGhlDQoNCm1hbmFnZWQgZGV2 aWNlcywgYSBtZWNoYW5pc20gdG8ga25vdyB0aGUgZGV2aWNlIGNhcGFiaWxpdGllcywgYSBtZWNo YW5pc20NCg0KZm9yIHB1Yi9zdWIsIC4uLg0KDQpBbmQgeW91IHdpbGwgcmVkbyB0aGUgZnVsbCBP UFMgc3RhY2ssIGZvciBJb1QgKGhlbmNlIGR1cGxpY2F0aW9uKS4gQW5kLA0KDQpvYnZpb3VzbHks IGluIHRoZSBlbmQsIHdlIHdpbGwgbmVlZCBhIG1hcHBpbmcgYmV0d2VlbiB0aGUgdHdvIGRhdGEN Cg0KbW9kZWxpbmcgbGFuZ3VhZ2VzOiBZQU5HIGFuZCBDRERMLg0KDQoNCg0KV2hhdCBpcyBzcGVj aWZpYyBoZXJlPyAgSSB3YW50ZWQgdG8gd3JpdGU6IHdoYXQncyBzcGVjaWZpYyB0byBJb1QgaGVy ZSwNCg0KYnV0IEkgZG9uJ3QgZXZlbiBzZWUgSW9UIGluIHRoZSBjaGFydGVyLiBUaGVyZSBpcyBq dXN0IGEga2luZCBvZiBJb1QNCg0KcmVmZXJlbmNlIGluIFJGQzcwNDkgYWJzdHJhY3QuDQoNCldo eSBkbyB3ZSBuZWVkIHRoaXMgZHVwbGljYXRpb24gd2l0aGluIHRoZSBJRVRGPw0KDQpXaHkgZG9u J3QgZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvciBhbmQgZHJhZnQtdmFuZGVyc3Rvay1jb3JlLWNv bWkgd29yaz8NCg0KVGhvc2UgYXJlIGNvbXBsZXRlbHkgaW5saW5lIHdpdGggZGF0YSBtb2RlbGlu Zy1kcml2ZW4gbWFuYWdlbWVudCBhbmQgdGhpcw0KDQpjaGFydGVyIHNlZW1zIHRvIGNvbnRyYWRp Y3QgdGhpcyBlZmZvcnQ/DQoNCldoYXQgZG8gSSBtaXNzPw0KDQoNCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KQ09NTUVOVDoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KT0xEOg0KDQoNCg0KQ29uY2lz ZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SLCBSRkMgNzA0OSkgZXh0ZW5kcyB0 aGUNCg0KSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04sIFJGQyA3MTU5KSBkYXRhIG1v ZGVsIHRvIGluY2x1ZGUgYmluYXJ5DQoNCmRhdGENCg0KYW5kIGFuIGV4dGVuc2liaWxpdHkgbW9k ZWwNCg0KDQoNCk5FVzoNCg0KQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChD Qk9SLCBSRkMgNzA0OSkgZXh0ZW5kcyB0aGUNCg0KSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24g KEpTT04sIFJGQyA3MTU5KSBkYXRhIGludGVyY2hhbmdlIGZvcm1hdCB0bw0KDQppbmNsdWRlIGJp bmFyeSBkYXRhDQoNCmFuZCBhbiBleHRlbnNpYmlsaXR5IG1vZGVsDQoNCg0KDQpOb3RlOg0KDQot IEluIE9QUywgd2UgbWFrZSBhIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gdGhlIChZQU5HKSBk YXRhIG1vZGVsLCBhbmQNCg0KdGhlIGVuY29kaW5nIChYTUwsIEpTT04sIGV0Yy4pDQoNCi0gUkZD IDcxNTkgbWVudGlvbnMgImRhdGEgaW50ZXJjaGFuZ2UgZm9ybWF0IiBpbiBoaXMgYWJzdHJhY3QN Cg0KLSBJIHNlZSBpbiBSRkMgNzA0OToNCg0KICAgVGhlIGZvcm1hdCBkZWZpbmVkIGhlcmUgZm9s bG93cyBzb21lIHNwZWNpZmljIGRlc2lnbiBnb2FscyB0aGF0IGFyZQ0KDQogICBub3Qgd2VsbCBt ZXQgYnkgY3VycmVudCBmb3JtYXRzLiAgVGhlIHVuZGVybHlpbmcgZGF0YSBtb2RlbCBpcyBhbg0K DQogICBleHRlbmRlZCB2ZXJzaW9uIG9mIHRoZSBKU09OIGRhdGEgbW9kZWwgW1JGQzQ2MjddLg0K DQpUaGlzIGlzIGEgbWlzdGFrZS4gR3JlYXQgd2Ugd2lsbCBoYXZlIGEgbmV3IGNoYXJ0ZXIgdG8g YWNjb21wbGlzaCB0aGlzDQoNCndvcmsNCg0KDQoNCi0gQW5kIGRvbid0IGZvcmdldCB0aGUgbWls ZXN0b25lcy4NCg0KDQoNClJlZ2FyZHMsIEJlbm9pdA0KDQoNCg0KDQoNCi4NCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp5YW5nLWRvY3RvcnMg bWFpbGluZyBsaXN0DQp5YW5nLWRvY3RvcnNAaWV0Zi5vcmc8bWFpbHRvOnlhbmctZG9jdG9yc0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8veWFuZy1kb2N0 b3JzDQoNCg== --_000_4841087DDD104613B2273481F0A618EBjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xv cjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlRoaXMgaXMgdGhl IGlzc3VlIEkgcmFpc2VkIGR1cmluZyB0aGUgTkVUQ09ORiBzZXNzaW9uIGluIFNlb3VsLiZuYnNw OyBCb3RoIHRoZSB6ZXJvdG91Y2ggYW5kIHRoZSB2b3VjaGVyIGRyYWZ0cyBhcmUgY3VycmVudGx5 IHVzaW5nIGEgWUFORyBtb2R1bGUgdG8gZGVmaW5lIGEgZGF0YSBzdHJ1Y3R1cmUsIHdoaWNoIHRo ZXkgY2xhaW0gaXMgZW5jb2RlZCB0aGUgc2FtZQ0KIGFzIGlmIHJldHVybmVkIGJ5IGEgUkVTVENP TkYgc2VydmVyIHVzaW5nIGEgR0VUIHJlcXVlc3Qgd2l0aCBhIFVSTCB0byB0aGUgc3BlY2lmaWMg cmVzb3VyY2UuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmkiPkkgc3RpbGwgbmVlZCB0byBmb3JtYWxseSByYWlzZSB0aGlzIGFzIGFuIGlzc3Vl IGJsb2NraW5nIHRoZXNlIGRyYWZ0cywgYnV0IGFzc3VtaW5nIHdlIGFyZSBhYmxlIHRvIHJlc29s dmUgdGhpcyBZQU5HIG1hcHBpbmcgaXNzdWUsIGFuZCB0aGVyZSBhbHJlYWR5IGV4aXN0cyBhIENC T1IgZW5jb2RpbmcsIHRoZW4gSSB3b25kZXIgaWYgdGhpcyB3b3VsZA0KIGJlIHN1ZmZpY2llbnQg YW5kIG5lZ2F0ZSB0aGUgbmVlZCB0byBkZWZpbmUgQ0RETC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPnlhbmctZG9jdG9y cyAmbHQ7eWFuZy1kb2N0b3JzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBBbmR5 IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9u ZGF5LCBEZWNlbWJlciAxOSwgMjAxNiBhdCAxMjoyNyBQTTxicj4NCjxiPlRvOiA8L2I+QmVub2l0 IENsYWlzZSAmbHQ7YmNsYWlzZUBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5ZQU5HIERv Y3RvcnMgJmx0O3lhbmctZG9jdG9yc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFt5YW5nLWRvY3RvcnNdIEZ3ZDogQmVub2l0IENsYWlzZSdzIEJsb2NrIG9uIGNoYXJ0ZXIt aWV0Zi1jYm9yLTAwLTA0OiAod2l0aCBCTE9DSyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFsc28gaGF2ZSBhIHBy b3ByaWV0YXJ5IHN5c3RlbSBmb3IgZGVzY3JpYmluZyBwcm90b2NvbCBtZXNzYWdlcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludGVybmFsIGRh dGEgc3RydWN0dXJlcywgbW9kZWwgb2YgWFJEIGZvciBSRVNUQ09ORiwgZXRjLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZXRpbWVzIHRoaXMg aXMgZG9uZSB3aXRoIHBsYWluIFlBTkcgbW9kdWxlcyBpbmNsdWRpbmcgYXVnbWVudC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBzZXJ2 ZXIgZG9lcyBub3QgYWR2ZXJ0aXNlIHRoZSBtb2R1bGUgdGhlbiB0aGUgY2xpZW50IGNhbm5vdCBn ZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZv b2xlZCBieSB0aGUgbWlzdXNlIG9mIFlBTkcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIHVzZWZ1bCB0byBoYXZlIGEgc3Rh bmRhcmQgd2F5IG9mIGRlZmluaW5nIFlBTkcgZGF0YSBzdHJ1Y3R1cmVzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgQ09SRSBXRyBpcyB2 ZXJ5IGRpdmlkZWQgYWJvdXQgdXNpbmcgWUFORy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihMb29rIGF0IFNlbk1MIGZvciBleGFtcGxlISk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllBTkcgaXMg dG9vIGhlYXZ5d2VpZ2h0IGZvciBzZW5zb3JzIGFuZCBhY3R1YXRvcnMsIGFuZCBtYW55IHZpZXcg SW9UPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5h bmQgbm90aGluZyBtb3JlIHRoYW4gdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHdvcmsgdGhhdCBjb25jZXJucyBtZSBpcyBTSUQs IHdoaWNoIGF0dGVtcHRzIHRvIHVzZSBhIHNpbmdsZSB1aW50MzI8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIGlkZW50aWZ5IGV2ZXJ5IHBvc3Np YmxlIHNjaGVtYSBub2RlIGluIGV2ZXJ5IHBvc3NpYmxlIG1vZHVsZSBpbnRvPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIDEtZGltZW5zaW9uYWwg bnVtYmVyaW5nIHNwYWNlLiZuYnNwOyBJdCBpcyBub3QgYW4gYWNjaWRlbnQgdGhhdCBpZGVudGlm aWVyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ aW4gU01JdjIgb3IgWUFORyBhcmUgYmFzZWQgb24gaW1tdXRhYmxlIHByb3BlcnRpZXMgb2YgdGhl IGxhbmd1YWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXQgaXMgdmVyeSByaXNreSB0byBiYXNlIHRoZSBuYW1pbmcgc2NoZW1lIG9uIHByb3Bl cnRpZXMgdGhhdCBjYW4gY2hhbmdlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5mcm9tIHJlbGVhc2UgdG8gcmVsZWFzZS4gVGhlIGNsaWVudCBhbmQg c2VydmVyIG11c3QgYWdyZWUgb24gdGhlIGNvbmNlcHR1YWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1hbmFnZWQgb2JqZWN0cy4gSXQgY2FuIGJl IHZlcnkgaGFyZCB0byBkZXRlY3QgYnVncyBvZiB0aGlzIG5hdHVyZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVhZCB0aGVpciBkcmFmdCBh bmQgc2VlIHdoYXQgeW91IHRoaW5rOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1jb3JlLXNpZC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtY29yZS1zaWQvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIERlYyAxOSwgMjAxNiBhdCA0OjU0 IEFNLCBCZW5vaXQgQ2xhaXNlICZsdDs8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj5iY2xhaXNlQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZQU5HIGV4 cGVydHMsPGJyPg0KPGJyPg0KSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgeW91ciBmcm9tIGlm IEkgbWlzc2VkIGFueXRoaW5nLCBpZiBJJ3ZlIGJlZW4gc21va2luZyB0b28gbXVjaCwgb3IgaWYg eW91IHN1cHBvcnQgdGhpcyBzdGF0ZW1lbnQuPGJyPg0KPGJyPg0KUmVnYXJkcywgQi48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQotLS0tLS0t LSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n PSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmln aHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5TdWJqZWN0OiA8bzpwPjwvbzpwPjwvYj48 L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CZW5vaXQgQ2xhaXNlJ3MgQmxvY2sgb24gY2hhcnRlci1pZXRmLWNib3It MDAtMDQ6ICh3aXRoIEJMT0NLIGFuZCBDT01NRU5UKTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv dHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4g MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0i dGV4dC1hbGlnbjpyaWdodCI+PGI+RGF0ZTogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0 ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TW9uLCAxOSBEZWMgMjAxNiAwNDo0ODo1MyAtMDgwMDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv dHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4g MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0i dGV4dC1hbGlnbjpyaWdodCI+PGI+RnJvbTogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0 ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QmVub2l0IENsYWlzZSA8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj4NCiZsdDtiY2xhaXNlQGNpc2NvLmNvbSZndDs8L2E+PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5UbzogPG86cD48L286cD48L2I+PC9wPg0KPC90 ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIElFU0cgPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj4mbHQ7aWVzZ0BpZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0 ZXh0LWFsaWduOnJpZ2h0Ij48Yj5DQzogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBz dHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg aHJlZj0ibWFpbHRvOmNib3JAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jYm9yQGlldGYub3Jn PC9hPiwNCjxhIGhyZWY9Im1haWx0bzpjYm9yLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmNib3ItY2hhaXJzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPkJlbm9pdCBDbGFpc2Ug aGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPG86cD48L286cD48 L3ByZT4NCjxwcmU+Y2hhcnRlci1pZXRmLWNib3ItMDAtMDQ6IEJsb2NrPG86cD48L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2hlbiByZXNwb25kaW5nLCBw bGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPG86cD48 L286cD48L3ByZT4NCjxwcmU+ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5p bnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PG86cD48L286cD48L3By ZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRl ci1pZXRmLWNib3IvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvY2hhcnRlci1pZXRmLWNib3IvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5CTE9DSzo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U29ycnkgZm9y IHRoaXMgbGF0ZSBCTE9DSy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIGhhZCBhIHZlcnkgcXVp Y2sgY2FsbCB3aXRoIEFsZXhleSBiZWZvcmUgdGhlIGxhc3QgSUVTRyB0ZWxlY2hhdDogSSB3YW50 PG86cD48L286cD48L3ByZT4NCjxwcmU+dG8gdW5kZXJzdGFuZCBpZiBJIG1pc3NlZCBhbnl0aGlu Zy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIGZpbGVkIGEgcXVpY2sgJnF1b3Q7Tk8gUkVDT1JE JnF1b3Q7IENPTU1FTlQuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlbiwgd2UgZGlzY3Vzc2Vk IHNvbWUgbW9yZSBkdXJpbmcgdGhlIHRlbGVjaGF0IGl0c2VsZi48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5BbmQgbm93LCBJIGZpbmFsbHkgaGFkIHRoZSB0aW1lIHRvIHRoaW5rIHNvbWUgbW9yZSBh Ym91dCB0aGlzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPk15IEJMT0NLIGlzIGFib3V0IHRoaXMgY2hhcnRlciBwYXJhZ3JhcGg6PG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFNpbWlsYXIgdG8gdGhlIHdheSBBQk5GIChSRkMgNTIzNC83NDA1KSBjYW4gYmUgdXNl ZCB0byBkZXNjcmliZSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZXQgb2YgdmFsaWQgbWVz c2FnZXMgaW4gYSB0ZXh0IHJlcHJlc2VudGF0aW9uLCBpdCB3b3VsZCBiZSB1c2VmdWwgaWY8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5wcm90b2NvbCBzcGVjaWZpY2F0aW9ucyBjb3VsZCB1c2UgYSBk ZXNjcmlwdGlvbiBmb3JtYXQgZm9yIHRoZSBkYXRhIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+ Q0JPUi1lbmNvZGVkIG1lc3NhZ2VzLiBUaGUgQ0JPUiBkYXRhIGRlZmluaXRpb24gbGFuZ3VhZ2Ug KENEREwsIGJhc2VkIG9uPG86cD48L286cD48L3ByZT4NCjxwcmU+ZHJhZnQtZ3JlZXZlbmJvc2No LWFwcHNhd2ctY2Jvci1jZGRsKSBpcyBhIHByb3Bvc2FsIGZvciBzdWNoIGE8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5kZXNjcmlwdGlvbiB0ZWNobmlxdWUgdGhhdCBoYXMgYWxyZWFkeSBiZWVuIHVz ZWQgaW4gQ09SRSwgQU5JTUEsIENETkksPG86cD48L286cD48L3ByZT4NCjxwcmU+YW5kIGVmZm9y dHMgb3V0c2lkZSB0aGUgSUVURi4gVGhlIENCT1IgV0cgd2lsbCBjb21wbGV0ZSB0aGUgZGV2ZWxv cG1lbnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vZiB0aGlzIHNwZWNpZmljYXRpb24gYnkgY3Jl YXRpbmcgYW4gSW5mb3JtYXRpb25hbCBvciBTdGFuZGFyZHMgVHJhY2s8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5SRkMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SW4gT1BTLCB3ZSBuZWVkIGF1 dG9tYXRpb24uIEFuZCBhdXRvbWF0aW9uIHdpbGwgY29tZSBmcm9tIGRhdGEgbW9kZWxzIGFzLDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmZyb20gZGF0YSBtb2RlbHMsIHdlJ3JlIGFibGUgdG8gZ2Vu ZXJhdGUgQVBJcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JbiB0aGUgd29ybGQgb2YgZGF0YSBt b2RlbGluZy1kcml2ZW4gbWFuYWdlbWVudCwgd2UgaGF2ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsgWUFORyBhcyBhIGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2UsIHdp dGggQUJORiBzcGVjaWZpY2F0aW9uczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyBZQU5HIGRhdGEgbW9kdWxlcywgd3JpdHRlbiB3aXRoIHRoZSBZQU5HIGRhdGEgbW9k ZWxpbmcgbGFuZ3VhZ2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsg ZGlmZmVyZW50IGVuY29kaW5ncywgc3VjaCBhcyBYTUwsIEpTT04sIG9yIENCT1I8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4oZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci0wMyk8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgcHJvdG9jb2xzIHN1Y2ggYXMgTkVUQ09ORiBv ciBSRVNUQ09ORiBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jb25maWd1cmF0aW9uL21vbml0 b3JpbmcvY2FwYWJpbGl0aWVzIGRpc2NvdmVyeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyBub3RlOiB3b3JraW5nIG9uIHB1Yi9zdWIgcHJvdG9jb2wgKGFrYSB0ZWxl bWV0cnkpIGZvciBldmVudHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT5TZWUgdGhlIGZpcnN0IHBpY3R1cmUgYXQ8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48YSBocmVmPSJodHRwOi8vd3d3LmNsYWlzZS5iZS8yMDE2LzEyL3lhbmctb3BlbnNvdXJj ZS10b29scy1mb3ItZGF0YS1tb2RlbGluZy1kcml2ZW4tbWFuYWdlbWVudC8iIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vd3d3LmNsYWlzZS5iZS8yMDE2LzEyL3lhbmctb3BlbnNvdXJjZS10b29scy1m b3ItZGF0YS1tb2RlbGluZy1kcml2ZW4tbWFuYWdlbWVudC88L2E+PG86cD48L286cD48L3ByZT4N CjxwcmU+QnR3LCBJIHNob3VsZCBhZGQgY2Jvci48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Ob3csIGluIHRoaXMgcHJvcG9zZWQgV0csIHlvdSB3 YW50IHRvIGRlZmluZSBhIG5ldyBkYXRhIG1vZGVsaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+ bGFuZ3VhZ2UsICZxdW90O1RoZSBDQk9SIGRhdGEgZGVmaW5pdGlvbiBsYW5ndWFnZSZxdW90Ozxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPldoZW4gSSBhc2sgdGhlIHF1ZXN0aW9uOiBTbyB0aGUgc3Ry dWN0dXJlIG9mIHdoYXQgY291bGQgYmUgYWNjZXNzZWQgb24gYTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPm1hbmFnZWQgZGV2aWNlPywgeW91IGFuc3dlcjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgTm8uIFdoaWxl IENEREwgY291bGQgYmUgdXNlZCB0byBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9mIGRhdGEgYXQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXN0IChhIGRhdGEgc3RvcmUpLCB0aGF0IGlzIG5vdCB0 aGUgb2JqZWN0aXZlLiBDRERMIGlzIHVzZWQgdG8gZGVmaW5lPG86cD48L286cD48L3ByZT4NCjxw cmU+dGhlIHN0cnVjdHVyZSBvZiBkYXRhIGluIGZsaWdodCwgZS5nLiBhIHByb3RvY29sIG1lc3Nh Z2UgZ29pbmcgZnJvbSBhPG86cD48L286cD48L3ByZT4NCjxwcmU+bm9kZSB0byBhIGRpZmZlcmVu dCBub2RlLiAoVXNpbmcgYSB0ZXJtIHBvcHVsYXIgaW4gc2VtYW50aWM8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5pbnRlcm9wZXJhYmlsaXR5IHdvcmsgaW4gdGhlIGhlYWx0aCBjYXJlIGRvbWFpbiwg Q0RETCBpcyBhYm91dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZxdW90O3N0cnVjdHVyYWwgaW50 ZXJvcGVyYWJpbGl0eeKAnSDigJQgaXQgY2FuIHRlbGwgeW91IHRoYXQgdGhlcmUgaXMgc3VwcG9z ZWQgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5iZSBhIGRhdGEgaXRlbSDigJxjaGVlc2UtZmly bW5lc3PigJ0gaW4gdGhlIG1lc3NhZ2UgYW5kIG91dCBvZiB3aGF0IHNldCBvZjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnZhbHVlcyBpdCBuZWVkcyB0byBjb21lLCBidXQgaXQgY2Fubm90IHRlbGwg eW91IHdoYXQgdGhlIHNwZWNpZmljIHZhbHVlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1lYW4g aW4gdGhlIHJlYWwgd29ybGQgb3Igd2hhdCBjaGVlc2UgZmlybW5lc3MgaXMgaW4gdGhlIGZpcnN0 IHBsYWNlIG9uIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZW1hbnRpYyBsZXZlbC4pIDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPkJ1dCB3aGF0IGFib3V0IHRoZSBzZW1hbnRpYyBkZWZpbml0 aW9uICh3aGljaCBpcyBpbiBZQU5HIG1vZHVsZXMpIG9mIHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5pbmZvcm1hdGlvbj8gVGhpcyBpcyBrZXkgZm9yIG1hbmFnZW1lbnQuPG86cD48L286cD48 L3ByZT4NCjxwcmU+SSBndWVzcyB0aGF0IHRoZSBuZXh0IGl0ZW0geW91J2xsIHdhbnQgYWZ0ZXIg dGhpcyBtaWxlc3RvbmUgaXMgZXhhY3RseTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRhdGEgbW9k ZWxzIGFuZCBzZW1hbnRpYywgcmlnaHQ/PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+VGhlcmUgYXJlIG1hbnkgc2NoZW1hcyBmb3IgSW9UIGFuZCBJ J20gbm90IHRyeWluZyB0byBpbXBvc2UgWUFORyBpbiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5Jb1Qgd29ybGQgYnV0IEkgd2FudCB0byB1bmRlcnN0YW5kIHdoeSB3ZSBuZWVkIGR1cGxpY2F0 aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5vdGUgdGhhdCB0aGVyZSB3YXMgYW4gSUFCLW9y Z2FuaXplZCB3b3Jrc2hvcCBvbiBJb1QgZGF0YSBtb2RlbGluZyBpbiB0aGU8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5wYXN0ICg8YSBocmVmPSJodHRwczovL3d3dy5pYWIub3JnL2FjdGl2aXRpZXMv d29ya3Nob3BzL2lvdHNpLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlhYi5vcmcvYWN0 aXZpdGllcy93b3Jrc2hvcHMvaW90c2kvPC9hPik8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ib3dl dmVyLCBpdCBzZWVtcyB0byBtZSB0aGF0IHlvdXIgZWZmb3J0IGlzIGV4YWN0bHkgdGhlIHJldmVy c2Ugb2YgZGF0YTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1vZGVsaW5nIGRyaXZlbiBtYW5hZ2Vt ZW50PyBZb3UgaGF2ZSBhbiBlbmNvZGluZywgYW5kIHRoZW4geW91IHdhbnQgYSBuZXc8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5zY2hlbWEgbGFuZ3VhZ2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5OZXh0LCB5b3UnbGwgbmVlZCBhIG1lY2hhbmlz bSB0byBkaXNjb3ZlciB3aGF0IGlzIGF2YWlsYWJsZSBvbiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5tYW5hZ2VkIGRldmljZXMsIGEgbWVjaGFuaXNtIHRvIGtub3cgdGhlIGRldmljZSBjYXBh YmlsaXRpZXMsIGEgbWVjaGFuaXNtPG86cD48L286cD48L3ByZT4NCjxwcmU+Zm9yIHB1Yi9zdWIs IC4uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFuZCB5b3Ugd2lsbCByZWRvIHRoZSBmdWxsIE9Q UyBzdGFjaywgZm9yIElvVCAoaGVuY2UgZHVwbGljYXRpb24pLiBBbmQsPG86cD48L286cD48L3By ZT4NCjxwcmU+b2J2aW91c2x5LCBpbiB0aGUgZW5kLCB3ZSB3aWxsIG5lZWQgYSBtYXBwaW5nIGJl dHdlZW4gdGhlIHR3byBkYXRhPG86cD48L286cD48L3ByZT4NCjxwcmU+bW9kZWxpbmcgbGFuZ3Vh Z2VzOiBZQU5HIGFuZCBDRERMLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPldoYXQgaXMgc3BlY2lmaWMgaGVyZT8mbmJzcDsgSSB3YW50ZWQgdG8g d3JpdGU6IHdoYXQncyBzcGVjaWZpYyB0byBJb1QgaGVyZSw8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5idXQgSSBkb24ndCBldmVuIHNlZSBJb1QgaW4gdGhlIGNoYXJ0ZXIuIFRoZXJlIGlzIGp1c3Qg YSBraW5kIG9mIElvVDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJlZmVyZW5jZSBpbiBSRkM3MDQ5 IGFic3RyYWN0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldoeSBkbyB3ZSBuZWVkIHRoaXMgZHVw bGljYXRpb24gd2l0aGluIHRoZSBJRVRGPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldoeSBkb24n dCBkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yIGFuZCBkcmFmdC12YW5kZXJzdG9rLWNvcmUtY29t aSB3b3JrPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRob3NlIGFyZSBjb21wbGV0ZWx5IGlubGlu ZSB3aXRoIGRhdGEgbW9kZWxpbmctZHJpdmVuIG1hbmFnZW1lbnQgYW5kIHRoaXM8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5jaGFydGVyIHNlZW1zIHRvIGNvbnRyYWRpY3QgdGhpcyBlZmZvcnQ/PG86 cD48L286cD48L3ByZT4NCjxwcmU+V2hhdCBkbyBJIG1pc3M/PG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNPTU1FTlQ6PG86cD48 L286cD48L3ByZT4NCjxwcmU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9MRDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Db25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVz ZW50YXRpb24gKENCT1IsIFJGQyA3MDQ5KSBleHRlbmRzIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPkphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uIChKU09OLCBSRkMgNzE1OSkgZGF0YSBtb2Rl bCB0byBpbmNsdWRlIGJpbmFyeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRhdGE8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5hbmQgYW4gZXh0ZW5zaWJpbGl0eSBtb2RlbDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5FVzo8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5Db25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1IsIFJGQyA3 MDQ5KSBleHRlbmRzIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkphdmFTY3JpcHQgT2JqZWN0 IE5vdGF0aW9uIChKU09OLCBSRkMgNzE1OSkgZGF0YSBpbnRlcmNoYW5nZSBmb3JtYXQgdG88bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5pbmNsdWRlIGJpbmFyeSBkYXRhPG86cD48L286cD48L3ByZT4N CjxwcmU+YW5kIGFuIGV4dGVuc2liaWxpdHkgbW9kZWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Ob3RlOiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4tIEluIE9QUywgd2UgbWFrZSBhIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gdGhlIChZQU5H KSBkYXRhIG1vZGVsLCBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgZW5jb2RpbmcgKFhN TCwgSlNPTiwgZXRjLik8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIFJGQyA3MTU5IG1lbnRpb25z ICZxdW90O2RhdGEgaW50ZXJjaGFuZ2UgZm9ybWF0JnF1b3Q7IGluIGhpcyBhYnN0cmFjdDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPi0gSSBzZWUgaW4gUkZDIDcwNDk6PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBmb3JtYXQgZGVmaW5lZCBoZXJlIGZvbGxvd3Mgc29tZSBz cGVjaWZpYyBkZXNpZ24gZ29hbHMgdGhhdCBhcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgbm90IHdlbGwgbWV0IGJ5IGN1cnJlbnQgZm9ybWF0cy4mbmJzcDsgVGhlIHVuZGVy bHlpbmcgZGF0YSBtb2RlbCBpcyBhbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBleHRlbmRlZCB2ZXJzaW9uIG9mIHRoZSBKU09OIGRhdGEgbW9kZWwgW1JGQzQ2MjddLiA8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGlzIGEgbWlzdGFrZS4gR3JlYXQgd2Ugd2lsbCBoYXZl IGEgbmV3IGNoYXJ0ZXIgdG8gYWNjb21wbGlzaCB0aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+ d29yazxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl Pi0gQW5kIGRvbid0IGZvcmdldCB0aGUgbWlsZXN0b25lcy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLCBCZW5vaXQ8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KeWFuZy1kb2N0b3JzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzp5YW5nLWRvY3RvcnNAaWV0Zi5vcmciPnlhbmctZG9jdG9yc0BpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3lh bmctZG9jdG9ycyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8veWFuZy1kb2N0b3JzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4841087DDD104613B2273481F0A618EBjunipernet_-- From nobody Tue Dec 20 11:23:13 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50712965D for ; Tue, 20 Dec 2016 11:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H43s6RBn_dV for ; Tue, 20 Dec 2016 11:23:10 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE2712948F for ; Tue, 20 Dec 2016 11:23:09 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id u25so48412589qki.2 for ; Tue, 20 Dec 2016 11:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oonAApPHHCcGkM0u4Vwm3hMaT7Vaznfg2jGGID0zNJY=; b=AtBH2waP5TNlaqNOTqeyjTRGRA9OISZNVnRIBAocG1X8YX7W+5sSL1hpkibZ8Clqu/ +387s9KoXKNHJ31l6fsDPGLRvzM3tmXiM6/wrhKMItfAKxiyIGEFNX9OZ0w/G+qASnVp xc5KjYvRbKrInAnw3k4rAVvpSjhtrcDxrHMWkA9uhftllUmkuYKqAYNwtf+gAUxo6y3L xruWp8IO0NrTbkj//GozFlufaUtrDF0TymH6GIB9N1KhpGz5AJfJD6vw4avbvkHUwOBS +dUpm2uW9Bb2spz4xiIDqTakWqjIJcQS60S/JCjiPw0A+p3XS/j8HclLefH7Zz8YGqNc VWvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oonAApPHHCcGkM0u4Vwm3hMaT7Vaznfg2jGGID0zNJY=; b=RsDl8H/da/76Vwmchu3LXxUI4FOvi+ZirZQNXB7nJcJ7BOfPbh4jTa5N4KtuXbuF4n aK3TdVhhaZL98l2uJulVrw9zlz8EEAqpHDJSm2bd7KvFTE/eiJgdkhqAGJai/7f0wiL8 Q0kCaEMeep06d84Kdg85mamyhxcRFuv53X0kIaaXy7XVAdTE/KsMDuAZYeRqXcDYvzr/ W+HGwSmATTO0XHkqEEB14HXW57l4Wz796qNl5Gj1twSajh2hdh+hwhvHLgSGidAdxM5U 3ojvWPpw6i36F4eQ2kR79MnIBnnjKHDvbly4EAANnaloEPnmpd2TCBDJ2ZZl6wdcskez xviw== X-Gm-Message-State: AIkVDXLpA8Ef+yFtDHP/vyTt+ypdj4MZ8uLLByE8thyROUM+01rQfkzN+G5SVnaEi9HlkJY615PNVX2HuhzYoA== X-Received: by 10.55.135.197 with SMTP id j188mr1027996qkd.71.1482261788965; Tue, 20 Dec 2016 11:23:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Tue, 20 Dec 2016 11:23:08 -0800 (PST) In-Reply-To: <4841087D-DD10-4613-B227-3481F0A618EB@juniper.net> References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> <4841087D-DD10-4613-B227-3481F0A618EB@juniper.net> From: Andy Bierman Date: Tue, 20 Dec 2016 11:23:08 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=94eb2c0777e6654ffb05441bf721 Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 19:23:12 -0000 --94eb2c0777e6654ffb05441bf721 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Did you read this draft? https://www.ietf.org/id/draft-greevenbosch-appsawg-cbor-cddl-09.txt Kind of a toy compared to YANG. e.g., no concept of modules, revisions, interactions between modules. However, I do not want to go back to "DML beauty contest" mode like we had before YANG. Ironically, APPS area originally blocked YANG because they already had DSDL= . Now they are working on a tinker-toy language that is just for CBOR encoding? This draft does not impact YANG. There is a YANG to CBOR draft in progress= . (It doesn't actually work, but maybe it can be fixed) CDDL would be a separate unrelated language that also happens to have a CBOR encoding. Obviously YANG advocates do not think we need both, but I prefer to let IETFers flail in their own sandbox, rather than take away their sand. Andy On Tue, Dec 20, 2016 at 11:05 AM, Kent Watsen wrote: > This is the issue I raised during the NETCONF session in Seoul. Both the > zerotouch and the voucher drafts are currently using a YANG module to > define a data structure, which they claim is encoded the same as if > returned by a RESTCONF server using a GET request with a URL to the > specific resource. > > > > I still need to formally raise this as an issue blocking these drafts, bu= t > assuming we are able to resolve this YANG mapping issue, and there alread= y > exists a CBOR encoding, then I wonder if this would be sufficient and > negate the need to define CDDL. > > > > Kent > > > > > > *From: *yang-doctors on behalf of Andy > Bierman > *Date: *Monday, December 19, 2016 at 12:27 PM > *To: *Benoit Claise > *Cc: *YANG Doctors > *Subject: *Re: [yang-doctors] Fwd: Benoit Claise's Block on > charter-ietf-cbor-00-04: (with BLOCK and COMMENT) > > > > Hi, > > > > We also have a proprietary system for describing protocol messages, > > internal data structures, model of XRD for RESTCONF, etc. > > Sometimes this is done with plain YANG modules including augment. > > If the server does not advertise the module then the client cannot get > > fooled by the misuse of YANG. > > > > It would be useful to have a standard way of defining YANG data structure= s. > > > > The CORE WG is very divided about using YANG. > > (Look at SenML for example!) > > YANG is too heavyweight for sensors and actuators, and many view IoT > > and nothing more than that. > > > > The work that concerns me is SID, which attempts to use a single uint32 > > to identify every possible schema node in every possible module into > > a 1-dimensional numbering space. It is not an accident that identifiers > > in SMIv2 or YANG are based on immutable properties of the language. > > It is very risky to base the naming scheme on properties that can change > > from release to release. The client and server must agree on the conceptu= al > > managed objects. It can be very hard to detect bugs of this nature. > > > > Read their draft and see what you think: > > https://datatracker.ietf.org/doc/draft-ietf-core-sid/ > > > > > > > > > > On Mon, Dec 19, 2016 at 4:54 AM, Benoit Claise wrote: > > YANG experts, > > I would like to understand your from if I missed anything, if I've been > smoking too much, or if you support this statement. > > Regards, B. > > > > -------- Forwarded Message -------- > > *Subject: * > > Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT= ) > > *Date: * > > Mon, 19 Dec 2016 04:48:53 -0800 > > *From: * > > Benoit Claise > > *To: * > > The IESG > > *CC: * > > cbor@ietf.org, cbor-chairs@ietf.org > > > > Benoit Claise has entered the following ballot position for > > charter-ietf-cbor-00-04: Block > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-cbor/ > > > > > > > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > Sorry for this late BLOCK. > > I had a very quick call with Alexey before the last IESG telechat: I want > > to understand if I missed anything. > > I filed a quick "NO RECORD" COMMENT. > > Then, we discussed some more during the telechat itself. > > And now, I finally had the time to think some more about this. > > > > My BLOCK is about this charter paragraph: > > > > Similar to the way ABNF (RFC 5234/7405) can be used to describe the > > set of valid messages in a text representation, it would be useful if > > protocol specifications could use a description format for the data in > > CBOR-encoded messages. The CBOR data definition language (CDDL, based on > > draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a > > description technique that has already been used in CORE, ANIMA, CDNI, > > and efforts outside the IETF. The CBOR WG will complete the development > > of this specification by creating an Informational or Standards Track > > RFC. > > > > > > In OPS, we need automation. And automation will come from data models as, > > from data models, we're able to generate APIs. > > In the world of data modeling-driven management, we have: > > YANG as a data modeling language, with ABNF specifications > > YANG data modules, written with the YANG data modeling language > > different encodings, such as XML, JSON, or CBOR > > (draft-ietf-core-yang-cbor-03) > > protocols such as NETCONF or RESTCONF for > > configuration/monitoring/capabilities discovery > > note: working on pub/sub protocol (aka telemetry) for events > > > > See the first picture at > > http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driv= en-management/ > > Btw, I should add cbor. > > > > Now, in this proposed WG, you want to define a new data modeling > > language, "The CBOR data definition language" > > When I ask the question: So the structure of what could be accessed on a > > managed device?, you answer: > > > > No. While CDDL could be used to describe the structure of data at > > rest (a data store), that is not the objective. CDDL is used to define > > the structure of data in flight, e.g. a protocol message going from a > > node to a different node. (Using a term popular in semantic > > interoperability work in the health care domain, CDDL is about > > "structural interoperability=E2=80=9D =E2=80=94 it can tell you that ther= e is supposed to > > be a data item =E2=80=9Ccheese-firmness=E2=80=9D in the message and out o= f what set of > > values it needs to come, but it cannot tell you what the specific values > > mean in the real world or what cheese firmness is in the first place on a > > semantic level.) > > > > > > But what about the semantic definition (which is in YANG modules) of this > > information? This is key for management. > > I guess that the next item you'll want after this milestone is exactly > > data models and semantic, right? > > > > There are many schemas for IoT and I'm not trying to impose YANG in the > > IoT world but I want to understand why we need duplication. > > Note that there was an IAB-organized workshop on IoT data modeling in the > > past (https://www.iab.org/activities/workshops/iotsi/) > > However, it seems to me that your effort is exactly the reverse of data > > modeling driven management? You have an encoding, and then you want a new > > schema language > > > > Next, you'll need a mechanism to discover what is available on the > > managed devices, a mechanism to know the device capabilities, a mechanism > > for pub/sub, ... > > And you will redo the full OPS stack, for IoT (hence duplication). And, > > obviously, in the end, we will need a mapping between the two data > > modeling languages: YANG and CDDL. > > > > What is specific here? I wanted to write: what's specific to IoT here, > > but I don't even see IoT in the charter. There is just a kind of IoT > > reference in RFC7049 abstract. > > Why do we need this duplication within the IETF? > > Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work? > > Those are completely inline with data modeling-driven management and this > > charter seems to contradict this effort? > > What do I miss? > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > OLD: > > > > Concise Binary Object Representation (CBOR, RFC 7049) extends the > > JavaScript Object Notation (JSON, RFC 7159) data model to include binary > > data > > and an extensibility model > > > > NEW: > > Concise Binary Object Representation (CBOR, RFC 7049) extends the > > JavaScript Object Notation (JSON, RFC 7159) data interchange format to > > include binary data > > and an extensibility model > > > > Note: > > - In OPS, we make a clear distinction between the (YANG) data model, and > > the encoding (XML, JSON, etc.) > > - RFC 7159 mentions "data interchange format" in his abstract > > - I see in RFC 7049: > > The format defined here follows some specific design goals that are > > not well met by current formats. The underlying data model is an > > extended version of the JSON data model [RFC4627]. > > This is a mistake. Great we will have a new charter to accomplish this > > work > > > > - And don't forget the milestones. > > > > Regards, Benoit > > > > > > . > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > > --94eb2c0777e6654ffb05441bf721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Did you read this draft?
=


Kind of a toy = compared to YANG.
e.g., no concept of modules, revisions, interac= tions between modules.

However, I do not want to g= o back to "DML beauty contest" mode
like we had before = YANG.

Ironically, APPS area originally blocked YAN= G because they already had DSDL.
Now they are working on a tinker= -toy language that is just for CBOR encoding?

This= draft does not impact YANG.=C2=A0 There is a YANG to CBOR draft in progres= s.
(It doesn't actually work, but maybe it can be fixed)

CDDL would be a separate unrelated language that also = happens to have a CBOR encoding.
Obviously YANG advocates do not = think we need both, but I prefer to let IETFers
flail in their ow= n sandbox, rather than take away their sand.


<= /div>
Andy



On Tue, Dec 20, 2016 at 11:05 AM, Ke= nt Watsen <kwatsen@juniper.net> wrote:

This is the issu= e I raised during the NETCONF session in Seoul.=C2=A0 Both the zerotouch an= d the voucher drafts are currently using a YANG module to define a data str= ucture, which they claim is encoded the same as if returned by a RESTCONF server using a GET request with a URL to the = specific resource.=C2=A0

=C2=A0=

I still need to = formally raise this as an issue blocking these drafts, but assuming we are = able to resolve this YANG mapping issue, and there already exists a CBOR en= coding, then I wonder if this would be sufficient and negate the need to define CDDL.

=C2=A0=

Kent

=C2=A0=

=C2=A0=

F= rom: yang-doctors <yang-doctors-b= ounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
Date: Monday, December 19, 2016 at 12:27 PM
To: Benoit Claise <bclaise@cisco.com>
Cc: YANG Doctors <yang-doctors@ietf.org>
Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charte= r-ietf-cbor-00-04: (with BLOCK and COMMENT)

=C2=A0

Hi,

=C2=A0

We also have a proprietary system for describing pro= tocol messages,

internal data structures, model of XRD for RESTCONF,= etc.

Sometimes this is done with plain YANG modules inclu= ding augment.

If the server does not advertise the module then the= client cannot get

fooled by the misuse of YANG.

=C2=A0

It would be useful to have a standard way of definin= g YANG data structures.

=C2=A0

The CORE WG is very divided about using YANG.=

(Look at SenML for example!)

YANG is too heavyweight for sensors and actuators, a= nd many view IoT

and nothing more than that.

=C2=A0

The work that concerns me is SID, which attempts to = use a single uint32

to identify every possible schema node in every poss= ible module into

a 1-dimensional numbering space.=C2=A0 It is not an = accident that identifiers

in SMIv2 or YANG are based on immutable properties o= f the language.

It is very risky to base the naming scheme on proper= ties that can change

from release to release. The client and server must = agree on the conceptual

managed objects. It can be very hard to detect bugs = of this nature.

=C2=A0

Read their draft and see what you think:

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Dec 19, 2016 at 4:54 AM, Benoit Claise <<= a href=3D"mailto:bclaise@cisco.com" target=3D"_blank">bclaise@cisco.com= > wrote:

YANG experts,

I would like to understand your from if I missed anything, if I've been= smoking too much, or if you support this statement.

Regards, B.



-------- Forwarded Message --------

Subjec= t:

Benoit Claise's Block on charter-ietf-cbor-00-04= : (with BLOCK and COMMENT)

Date: =

Mon, 19 Dec 2016 04:48:53 -0800

From: =

Benoit Claise <bclaise@cisco.com>

To:

The IESG <iesg@ietf.org>

CC:

c= bor@ietf.org, cbor-chairs@ietf.= org

=C2=A0<= /p>

Benoit Claise has entered the following ballot position for<=
/u>
charter-ietf-cbor-00-04: Block
=C2=A0
When responding, please keep the subject line intact and reply to all<=
u>
email addresses included in the To and CC lines. (Feel free to cut thi=
s
introductory paragraph, however.)
=C2=A0
=C2=A0
=C2=A0
The document, along with other ballot positions, can be found here:=
https://datatracker.ietf.org/doc/charter-ietf-cbor/=
=C2=A0
=C2=A0
=C2=A0
------------------------------------------------------------=
----------
BLOCK:
------------------------------------------------------------=
----------
=C2=A0
Sorry for this late BLOCK.
I had a very quick call with Alexey before the last IESG telechat: I w=
ant
to understand if I missed anything.
I filed a quick "NO RECORD" COMMENT.
Then, we discussed some more during the telechat itself.=
And now, I finally had the time to think some more about this.<=
u>
=C2=A0
My BLOCK is about this charter paragraph:
=C2=A0
=C2=A0=C2=A0=C2=A0 Similar to the way ABNF (RFC 5234/7405) can be used=
 to describe the
set of valid messages in a text representation, it would be useful if<=
u>
protocol specifications could use a description format for the data in=
CBOR-encoded messages. The CBOR data definition language (CDDL, based =
on
draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a=
description technique that has already been used in CORE, ANIMA, CDNI,=
and efforts outside the IETF. The CBOR WG will complete the developmen=
t
of this specification by creating an Informational or Standards Track<=
u>
RFC.
=C2=A0
=C2=A0
In OPS, we need automation. And automation will come from data models =
as,
from data models, we're able to generate APIs.
In the world of data modeling-driven management, we have:
=C2=A0=C2=A0=C2=A0 YANG as a data modeling language, with ABNF specifi=
cations
=C2=A0=C2=A0=C2=A0 YANG data modules, written with the YANG data model=
ing language
=C2=A0=C2=A0=C2=A0 different encodings, such as XML, JSON, or CBOR<=
/u>
(draft-ietf-core-yang-cbor-03)
=C2=A0=C2=A0=C2=A0 protocols such as NETCONF or RESTCONF for=
configuration/monitoring/capabilities discovery
=C2=A0=C2=A0=C2=A0 note: working on pub/sub protocol (aka telemetry) f=
or events
=C2=A0
See the first picture at
http://www.claise.be/2016/1=
2/yang-opensource-tools-for-data-modeling-driven-management/=
Btw, I should add cbor.
=C2=A0
Now, in this proposed WG, you want to define a new data modeling
language, "The CBOR data definition language"<=
/pre>
When I ask the question: So the structure of what could be accessed on=
 a
managed device?, you answer:
=C2=A0
=C2=A0=C2=A0=C2=A0 No. While CDDL could be used to describe the struct=
ure of data at
rest (a data store), that is not the objective. CDDL is used to define=
the structure of data in flight, e.g. a protocol message going from a<=
u>
node to a different node. (Using a term popular in semantic<=
/u>
interoperability work in the health care domain, CDDL is about<=
u>
"structural interoperability=E2=80=9D =E2=80=94 it can tell you t=
hat there is supposed to
be a data item =E2=80=9Ccheese-firmness=E2=80=9D in the message and ou=
t of what set of
values it needs to come, but it cannot tell you what the specific valu=
es
mean in the real world or what cheese firmness is in the first place o=
n a
semantic level.) 
=C2=A0
=C2=A0
But what about the semantic definition (which is in YANG modules) of t=
his
information? This is key for management.
I guess that the next item you'll want after this milestone is exa=
ctly
data models and semantic, right?
=C2=A0
There are many schemas for IoT and I'm not trying to impose YANG i=
n the
IoT world but I want to understand why we need duplication.<=
/u>
Note that there was an IAB-organized workshop on IoT data modeling in =
the
past (https://www.iab.org/activities/workshops/iotsi/)<=
/u>
However, it seems to me that your effort is exactly the reverse of dat=
a
modeling driven management? You have an encoding, and then you want a =
new
schema language
=C2=A0
Next, you'll need a mechanism to discover what is available on the=
managed devices, a mechanism to know the device capabilities, a mechan=
ism
for pub/sub, ...
And you will redo the full OPS stack, for IoT (hence duplication). And=
,
obviously, in the end, we will need a mapping between the two data<=
/u>
modeling languages: YANG and CDDL.
=C2=A0
What is specific here?=C2=A0 I wanted to write: what's specific to=
 IoT here,
but I don't even see IoT in the charter. There is just a kind of I=
oT
reference in RFC7049 abstract.
Why do we need this duplication within the IETF?
Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi=
 work?
Those are completely inline with data modeling-driven management and t=
his
charter seems to contradict this effort?
What do I miss?
=C2=A0
=C2=A0
------------------------------------------------------------=
----------
COMMENT:
------------------------------------------------------------=
----------
=C2=A0
OLD:
=C2=A0
Concise Binary Object Representation (CBOR, RFC 7049) extends the
JavaScript Object Notation (JSON, RFC 7159) data model to include bina=
ry
data
and an extensibility model
=C2=A0
NEW:
Concise Binary Object Representation (CBOR, RFC 7049) extends the
JavaScript Object Notation (JSON, RFC 7159) data interchange format to=
include binary data
and an extensibility model
=C2=A0
Note: 
- In OPS, we make a clear distinction between the (YANG) data model, a=
nd
the encoding (XML, JSON, etc.)
- RFC 7159 mentions "data interchange format" in his abstrac=
t
- I see in RFC 7049:
=C2=A0=C2=A0 The format defined here follows some specific design goal=
s that are
=C2=A0=C2=A0 not well met by current formats.=C2=A0 The underlying dat=
a model is an
=C2=A0=C2=A0 extended version of the JSON data model [RFC4627]. 
This is a mistake. Great we will have a new charter to accomplish this=
work
=C2=A0
- And don't forget the milestones.
=C2=A0
Regards, Benoit
=C2=A0
=C2=A0
.
=C2=A0


_______________________________________________
yang-doctors mailing list
yang-doctors@iet= f.org
https://www.ietf.org/mailman/listinfo/yang-doctors=

=C2=A0


--94eb2c0777e6654ffb05441bf721-- From nobody Thu Dec 22 06:27:08 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3381293F4 for ; Thu, 22 Dec 2016 06:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 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_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2laDmdJjV2a4 for ; Thu, 22 Dec 2016 06:27:06 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE0E1200A0 for ; Thu, 22 Dec 2016 06:27:06 -0800 (PST) Received: from [192.168.1.172] (ip4-83-240-38-102.cust.nbox.cz [83.240.38.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 30CF9200F0; Thu, 22 Dec 2016 15:27:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1482416824; bh=F+MrAgQwSfyYhYsuDV3mqLRDQYWAm8B0ELQBmb/+ec4=; h=Cc:To:From:Subject:Date; b=XY9bz8zT2lhPuAoBf/idcsUZc5ypyJORUBi8HIIWDK46aXuwmMJM5h8Nv9mzmzUTd qNGjo6UUY5Tss9UzN6kZYKDi3LuFjbF5k9hSStjvt8bK9ZktrN4zwhRQDDixOXYD9Q k8A7RgO4uucymWfo4AjMmmH9dkZMjOs1rzIh7unw= To: draft-ietf-rtgwg-yang-vrrp@tools.ietf.org From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Organization: CESNET, z.s.p.o. Message-ID: Date: Thu, 22 Dec 2016 15:27:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: yang-doctors@ietf.org Subject: [yang-doctors] YANG Doctors review for draft-ietf-rtgwg-yang-vrrp X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:27:08 -0000 Hi, I was asked to review the draft-ietf-rtgwg-yang-vrrp document, here are my comments: - overall, the module is in a good shape, the common compilers are able to parse it and do not complain about anything - the I-D text is very brief - some more detailed text about the scope, relationship to other (augmented) modules and use cases for the module would be welcome. Similarly, I would appreciate more detailed description of the specific sections of the module. The use cases can be demonstrated on configuration data examples which are now completely missing. - it seems to me that at least some of the leafs in notifications are supposed to be mandatory, maybe not only in notifications, but I'm not expert in this area. - e.g. the interface leaf in vrrp-virtual-router-error-event notification, the leaf is then also used in path expression for vrid-v4 (vrid-v6) leafref - module imports ietf-interfaces and ietf-ip, thus it MUST contain normative references to RFC 7223 and RFC RFC 7277 - in I-D's reference section as well as in the module (as other imported modules are already referenced) - unify the new-master-reason-type enums' names: (master-)preempted vs master-no-response - the local module prefix SHOULD be used instead of no prefix in all path expressions (e.g. vrid-v4, vrid-v6) - consider changing type of the version leaf in vrrp-common-attributes grouping to identityref - that way it would be possible only to augment the current module for any future version of the protocol, enumeration is limiting - vrrp-v3-attributes grouping seems as an addition to the vrrp-common-attributes (at least it is always used together with vrrp-common-attributes). Do you see (e.g. in some other module) a use case to instantiate vrrp-common-attributes without vrrp-v3-attributes? If not, the vrrp-v3-attributes should be placed into vrrp-v3-attributes grouping. It is also question if it needs in that case a separate grouping, the accept-mode leaf could be placed directly into the common grouping just with the when condition. - having a key of the "network" list named "network" (in vrrp-ipv4-attributes/track) seems as a bad design, try to rename the list or its key, also the descriptions of the network list and its container networks are not very clear. - the names in the comments behind the closing brackets inside the vrrp-ipv4-attributes/track container are wrong (e.g. track-interfaces instead of interfaces or track-networks instead of networks) - the previous 2 notes also apply to vrrp-ipv6-attributes grouping - vrrp-state-attributes/up-time - uptime is usually interpreted as a time duration, but here it is used as a moment in time, so if it is not defined this way in VRRP protocol, consider renaming - vrrp-state-attributes/last-event - are the events really so generic that the type here must be a string? Maybe having identities for them could help readability and understandability. Radek From nobody Fri Dec 23 06:52:23 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50B81295A5 for ; Fri, 23 Dec 2016 06:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.601 X-Spam-Level: X-Spam-Status: No, score=-16.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EfpskfaKKGP for ; Fri, 23 Dec 2016 06:52:22 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B52412947F for ; Fri, 23 Dec 2016 06:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=375; q=dns/txt; s=iport; t=1482504741; x=1483714341; h=subject:references:cc:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=IBeQc2P0ZuYSsRDTAixB4fmJRFXT0J/vs3eXKvIlRdk=; b=Nt8jokowRIX9Zgxbos4khR9VztTw5m9fNu1rFQVmIcP341WIGpWa/O0s ExHn33svMGIu/tJ5Slgi9AxDWtg1eKEQLLwxMAP5pl+J5eiJpKTaXimnd E/cqILTXSSDBU5trnFq7t9O9uWrg/Mq9Pn8dKaDuPVn9CPERnOb3GV34x 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2FgB2OV1Y/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAYErIC6OUZUzkzSEGAKGIAImghERAQIBAQEBAQEBYiiEYAk?= =?us-ascii?q?GIxVBEAsaAiYCAlcTCAEBhW6CfaphBYEsgieKfQEBAQEBBQEBAQEkMlmFPYICg?= =?us-ascii?q?mCHThGCLh4BBJp6kTyBXQGIR4YvikaHdjUhAYEHFg2BC4M/gUY9iTwBAQU?= X-IronPort-AV: E=Sophos;i="5.33,393,1477958400"; d="scan'208";a="648154646" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2016 14:52:19 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBNEqIBj028071 for ; Fri, 23 Dec 2016 14:52:19 GMT References: <148215173321.19483.4829837986369811135.idtracker@ietfa.amsl.com> <0c8b0b32-8f99-eaf9-4d88-69e0a2dc90bc@cisco.com> <4841087D-DD10-4613-B227-3481F0A618EB@juniper.net> Cc: YANG Doctors From: Benoit Claise Message-ID: <75366a53-d6ab-7b4e-16f6-7f618e16314a@cisco.com> Date: Fri, 23 Dec 2016 15:52:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT) X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 14:52:22 -0000 Dear all, The point behind this BLOCK (btw, I never liked the BLOCK term; I prefer DISCUSS, like for documents) was to get different view points regarding this proposed CBOR maintenance and extensions charter. Thank you for sharing your views. This was exactly what was expected from this group. Enjoy your Christmas break, if you take one. Regards, Benoit