From nobody Mon Jun 2 02:50:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4641A02F7 for ; Mon, 2 Jun 2014 02:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqjhh0ZZsXpY for ; Mon, 2 Jun 2014 02:49:58 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E9D1A02F6 for ; Mon, 2 Jun 2014 02:49:58 -0700 (PDT) Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.0.954.9; Mon, 2 Jun 2014 09:49:51 +0000 Message-ID: <032401cf7e47$990bd120$4001a8c0@gateway.2wire.net> From: t.petch To: "Alberto Gonzalez Prieto (albertgo)" , Andy Bierman , Ladislav Lhotka References: Date: Mon, 2 Jun 2014 10:46:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AM3PR07CA0030.eurprd07.prod.outlook.com (10.141.45.158) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0230B09AC4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(377454003)(13464003)(164054003)(92726001)(77156001)(19580395003)(83322001)(77982001)(86362001)(62236002)(42186004)(23756003)(101416001)(88136002)(19580405001)(87976001)(33646001)(47776003)(80022001)(102836001)(79102001)(81686999)(44716002)(20776003)(85852003)(89996001)(83072002)(64706001)(76176999)(50986999)(66066001)(81816999)(76482001)(50226001)(84392001)(93916002)(46102001)(74662001)(62966002)(61296002)(21056001)(14496001)(81342001)(104166001)(87286001)(99396002)(74502001)(4396001)(50466002)(81542001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB055; H:AMXPRD0310HT003.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ToeSuxy16oK1Sg35A1MD1caeo0s Cc: Netconf Subject: Re: [Netconf] [OPSAWG] config persistence X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 09:50:02 -0000 ----- Original Message ----- From: "Alberto Gonzalez Prieto (albertgo)" To: "Andy Bierman" ; "Ladislav Lhotka" Cc: "Netconf" Sent: Saturday, May 31, 2014 12:23 AM Subject: Re: [Netconf] [OPSAWG] config persistence I think NETCONF is explicit about the semantics of the running configuration. The system MUST be aware of the desired state of the system as embodied in the running datastore. The system uses that information, along with all sorts of other information, to perform its functions. The resulting operational state will be data model and implementation specific. I understand the text above identifies running datastore with "desired state" (vs. operational state ?) >From RFC 6241: "running configuration datastore: A configuration datastore holding the complete configuration currently active on the device." "A configuration datastore is defined as the complete set of configuration data that is required to get a device from its initial default state into a desired operational state." I could not find a definition of "active configuration" in the RFC. But considering the second snippet, I understand that, in the absence of stimuli, the contents of the running datastore and the operational state must be eventually consistent. Is this correct? Reading that question, I am uncertain whether or not you are using the terminology as NETCONF does. Configuration, as you quote, is what it take to get the box up, but is restricted to what you might put in through the CLI, or some such. The rest of the data on the box is state, which can be divided into read-only statistics and operational state, the latter being the data learnt from protocols - DHCP, BGP, NTP, IS-IS ... - and data generated by the box when, eg, a card is hot plugged and the box dynamically generates an entry in the interface list for it. So, the "running datastore" consists of the running configuration, statistics and operational state. The operational state does not exist anywhere else, in NETCONF terminology, so there is nothing for it to be consistent with; and it is only as stable as the protocols that update it, whereas the running configuration stays the same until it is updated by NETCONF (or, perhaps, by another configuration protocol, such as CLI, SNMP, ... although little is said in the NETCONF RFC about the interactions between the different ways of configuring a box, a topic that recurs on this list). The active configuration is not defined AFAIK but I think is clearly the configuration that the box is currently using, as appears in the running configuration datastore, as distinct from a configuration in the candidate, startup or user-defined configuration datastores. Note that in RFC6241, almost every use of the term datastore is qualified by the term configuration, hinting, but never quite saying, that the use of the term datastore without qualification means something more general, and I have used "datastore" in that way just above using quotes to suggest that my use thereof is a bit flaky. Most other RFC are not so precise in the use of the term datastore and use it without qualification when the context makes it fairly clear that configuration datastore is implied. And in an e-mail, when someone uses the term datastore, it may be impossible to tell whether they have a configuration datastore or some other kind of datastore in mind:-( Tom Petch That would mean that if the desired state would stop being operational (say this is caused by some permanent failure) or could not be made operational, the running datastore contents should change. Thanks, Alberto ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Jun 2 10:21:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0295A1A025C for ; Mon, 2 Jun 2014 10:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTLsSaHU1dEM for ; Mon, 2 Jun 2014 10:21:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C481A024D for ; Mon, 2 Jun 2014 10:21:32 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.949.11; Mon, 2 Jun 2014 17:21:25 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) with mapi id 15.00.0949.001; Mon, 2 Jun 2014 17:21:25 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-server-model-00.txt Thread-Index: AQHPfMMpy38pT2oUC0O8Pp31DmmI1ptd0ZEA Date: Mon, 2 Jun 2014 17:21:24 +0000 Message-ID: References: <20140531112504.9472.58713.idtracker@ietfa.amsl.com> In-Reply-To: <20140531112504.9472.58713.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0230B09AC4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(24454002)(377454003)(199002)(189002)(377424004)(164054003)(479174003)(15374003)(21056001)(36756003)(81542001)(99286001)(83506001)(76482001)(77982001)(46102001)(99396002)(4396001)(81342001)(2656002)(83322001)(31966008)(66066001)(74662001)(92726001)(79102001)(54356999)(86362001)(80022001)(76176999)(74502001)(20776003)(83072002)(101416001)(19580395003)(50986999)(19580405001)(92566001)(87936001)(64706001)(85852003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <16765A076A3359459ECCE3A72753ED24@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dKIN9DIUlWjp66eHRTR7NFe1Hm4 Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-server-model-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:21:38 -0000 This update, which is published as a WG -00 draft now, includes the following changes: * Changed title to "NETCONF Server Configuration Model" * Mapped inbound/outbound to listen/call-home * Restructured YANG module to place transport selection deeper into the tree, providing a more intuitive data model * Added section "Keep-Alives for SSH and TLS" * Updated the Security Considerations section * Added text for supporting VRFs via augments * Factored the TLS-AUTH config into another module augmenting the "ietf-system" module What's not included is moving any text to other documents, per comments from Tom. I felt that there was enough changes already for now. FWIW, I'm not happy with the current structure of this document right now. The addition of a 2nd YANG module, "ietf-system-tls-auth", as well as the new sections for keep-alives and VRFs, makes even the Table of Contents seem untidy. I'll update it ASAP so it flows better for reviews. Next up: draft-ietf-netconf-zero-touch Thanks, Kent On 5/31/14, 7:25 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Server Configuration Model > Authors : Kent Watsen > Juergen Schoenwaelder > Filename : draft-ietf-netconf-server-model-00.txt > Pages : 29 > Date : 2014-05-30 > >Abstract: > This draft defines a NETCONF server configuration data model. This > data model enables configuration of the NETCONF service itself, > including which transports it supports, what ports they listen on, > whether they support device-initiated connections, and associated > parameters. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-server-model-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jun 2 16:42:49 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3E61A03E5; Mon, 2 Jun 2014 16:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEu4CWOnfw4m; Mon, 2 Jun 2014 16:42:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F21241A03C7; Mon, 2 Jun 2014 16:42:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140602234243.459.87897.idtracker@ietfa.amsl.com> Date: Mon, 02 Jun 2014 16:42:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/_e0ka3VPXrKi_wPgLRxzTFHxBJk Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-server-model-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 23:42:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Server Configuration Model Authors : Kent Watsen Juergen Schoenwaelder Filename : draft-ietf-netconf-server-model-01.txt Pages : 30 Date : 2014-06-02 Abstract: This draft defines a NETCONF server configuration data model. This data model enables configuration of the NETCONF service itself, including which transports it supports, what ports they listen on, whether they support device-initiated connections, and associated parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-server-model-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-server-model-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 2 16:47:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CDF1A03C7 for ; Mon, 2 Jun 2014 16:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4I4WoBH_qPq for ; Mon, 2 Jun 2014 16:47:36 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80AF1A0341 for ; Mon, 2 Jun 2014 16:47:36 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.949.11; Mon, 2 Jun 2014 23:47:30 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) with mapi id 15.00.0949.001; Mon, 2 Jun 2014 23:47:30 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-server-model-01.txt Thread-Index: AQHPfrxz1D28OVG91UegBOvLEUe/oJteOX2A Date: Mon, 2 Jun 2014 23:47:30 +0000 Message-ID: References: <20140602234243.459.87897.idtracker@ietfa.amsl.com> In-Reply-To: <20140602234243.459.87897.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0230B09AC4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(164054003)(377454003)(189002)(199002)(24454002)(51704005)(377424004)(479174003)(101416001)(76482001)(74502001)(31966008)(46102001)(2656002)(50986999)(20776003)(99286001)(21056001)(77982001)(79102001)(86362001)(4396001)(66066001)(36756003)(83506001)(92726001)(74662001)(81342001)(85852003)(83322001)(92566001)(19580405001)(19580395003)(54356999)(99396002)(80022001)(76176999)(83072002)(87936001)(81542001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3m2iOrZU2-_Y-BIX6Q7K4YlboRw Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-server-model-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 23:47:39 -0000 Changes include: * Restructured document so it flows better * Added trusted-ca-certs and trusted-client-certs objects into the ietf-system-tls-auth module This is a good version for folks to review. Thanks, Kent On 6/2/14, 7:42 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Server Configuration Model > Authors : Kent Watsen > Juergen Schoenwaelder > Filename : draft-ietf-netconf-server-model-01.txt > Pages : 30 > Date : 2014-06-02 > >Abstract: > This draft defines a NETCONF server configuration data model. This > data model enables configuration of the NETCONF service itself, > including which transports it supports, what ports they listen on, > whether they support device-initiated connections, and associated > parameters. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-server-model-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-server-model-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jun 3 06:10:44 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BCC1A0278 for ; Tue, 3 Jun 2014 06:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jQYOHUUSy4W for ; Tue, 3 Jun 2014 06:10:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839401A01F6 for ; Tue, 3 Jun 2014 06:10:09 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id B2E27ED1550; Tue, 3 Jun 2014 15:10:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1401801001; bh=oJhvcKT25O0U98awwxDXI5tutETtw7fxQ5eT3VIpyRo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=kvypjfvHs2FuL2UG1BNDwfI0FzfjBpAn91s8uIjBLgrKa7p2hcK/znt39v+asWwCH HARILcj3FZzZbF8+uivx6X+W7iWWIY4vw3JPbxAYjvD9i5tybwlt7uzIT6rFZDRztU DheQyjezgtdxSYizVHPKDeTergf5qKq2l123L1k8= Message-ID: <538DC8DC.4060504@cesnet.cz> Date: Tue, 03 Jun 2014 15:08:44 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andy Bierman , Ladislav Lhotka References: <4987B7A3-DA0A-4145-A080-F1AC1BE466E2@nic.cz> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060801010903020700050308" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/s-LjOeCUr7oGHWRq1s0l9tdsmG0 Cc: Netconf Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:10:31 -0000 This is a multi-part message in MIME format. --------------060801010903020700050308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Dne 29.5.2014 17:35, Andy Bierman napsal(a): > > > > On Thu, May 29, 2014 at 6:16 AM, Ladislav Lhotka > wrote: > > > On 29 May 2014, at 14:31, Andy Bierman > wrote: > > > > > > > > > On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka > wrote: > > Hi, > > > > I am moving this discussion to the NETCONF mailing list. > > > > Andy Bierman > > writes: > > ... > > > > > > I don't agree NETCONF/YANG persistence is ill-defined. > > > It is not uniform. There are a few variants, identified by > > > capability URIs. > > > > I'd say persistence is at least under-defined. For example, it > doesn't seem to be clear from 6241 whether candidate is persistent. > > > > > > OK > > > > sec 8.3.5.2 says: > > > > When a client fails with outstanding changes to the candidate > > configuration, recovery can be difficult. To facilitate easy > > recovery, any outstanding changes are discarded when the lock is > > released, whether explicitly with the operation or > > > > implicitly from session failure. > > IMO it is odd that candidate is cleaned up only if it was locked. > > If a client edits candidate and then closes the session somehow > the changes are left behind. > > The RFC is silent about the contents of candidate at boot-time. > Our server always boots > > with the candidate and running having the same contents. > Otherwise the candidate is > > dirty at boot-time and cannot be locked by any session until a > discard-changes is invoked. > > There is also no explicit requirement to boot with any > particular candidate contents, so > > booting with the contents of running is compliant. > > I think an alternative interpretation of the 6241 text is that > candidate is a persistent staging area that survives reboots and > is only reverted to running after discard-changes. So a client can > close a session, then later open a new one and start editing where > he left off. > > > > There is no text that says anything about the initial state of candidate. > Does any known implementation behave this way? > (Note that the shared candidate is a horrible place to toss some edits > and come back later to finish up. The shared candidate is not really > intended to left unlocked so partial edits from various clients can > accumulate.) > > libnetconf/netopeer server does. Since RFC doesn't say anything about initial state of the candidate, we don't do anything with its content. So initially, it is empty and any change is persistent. The only thing that libnetconf do automatically with candidate content is copy-config from running (discarding the changes) on unlock. I think that it's better to be consistent in "candidate is dirty" than the approach "it may be consistent with running datastore at some time .... or not". Therefore I don't think, that come back later and continue in editing is a good idea - in our implementation, candidate is always considered to be dirty and if you want to work with it, you are supposed to lock it and (or at least) initiate its content. Radek > Lada > > > Andy > > > > > > > > Lada > > > > Andy > > > > > > > > > > The XMLCONF design team (pre-4741) tried very hard to > > > get the router vendors to agree on a single transaction model > > > but it was way too big a change, and (of course) each vendor > > > thought their way was better, so the standard should use that. > > > We ended up with 3 configuration datastores (candidate, > running, startup). > > > The transaction models that can be used with these datastores > > > are compatible with specific router CLI architectures. > > > > > > Two particular vendors do not agree on how to recover > > > from the "unreachable" problem. If the operator makes > > > config changes that break the connectivity to the device, > > > then the device has to recover somehow. > > > > > > M1: do not persist the changes until they are proven to > > > be correct. Force the device to reboot with the saved > > > (known good) config if things go bad. > > > > > > M2: persist the changes right away. Pick some timeout > > > and if the client does not follow up with a confirmation > > > before the timeout, automatically revert to the version > > > that was running before the transaction started. > > > > > > RFC 6241 could be more clear on the motivation for the > > > capabilities and operations that support various transaction > models. > > > Maybe that is what you meant by 'ill-defined'. > > > > > > > > > Andy > > > > > > So the two objects controlling Notifications seem clearly > configuration, > > >> whether or not the setting of them persists or is lost on > reboot. You > > >> could create a YANG module which controls the setting of > these two > > >> objects for SNMP usage but I think that even the IESG might > see that > > >> that is an unusual approach, as opposed to making them > read-write in > > >> SMI! > > >> > > >> When I first read the draft IESG statement, it was unclear to > me whether > > >> or not the authors fully understood what they had written. > > >> > > >> Tom Petch > > >> > > >> > (*1) > http://www.ietf.org/iesg/statement/writable-mib-module.html > > >> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00 > > >> > > > >> > Hirochika > > >> > > > >> > > > >> > On May 27, 2014, at 3:55 AM, joel jaeggli > wrote: > > >> > > > >> > > yeah if you want to discuss it with the ops/management > ADs and the > > >> > > chairs that's fine. > > >> > > > > >> > > I don't think there's a reason to involve the whole iesg. > > >> > > > > >> > > Thanks > > >> > > joel > > >> > > > > >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote: > > >> > >> js and Joel, > > >> > >> > > >> > >> Thank you for your comments. > > >> > >> > > >> > >> I agree that the IESG statement seems to be talking about > > >> configuration, > > >> > >> but I cannot definitely say that the objects I listed in my > > >> previous E-mail > > >> > >> are out of the IESG statement's scope. > > >> > >> > > >> > >> I think it would be better to move this issue to the > IESG, but I > > >> don't keep > > >> > >> up the procedure. May I, as an author of the draft, > send an E-mail > > >> > >> stating this issue to iesg@ietf.org > , CCing WG? Or ask WG chairs to > > >> > >> handle it? > > >> > >> > > >> > >> Thank you. > > >> > >> Hirochika > > >> > >> > > >> > >> > > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli > > wrote: > > >> > >> > > >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote: > > >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli > wrote: > > >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote: > > >> > >>>>>> Asai, > > >> > >>>>>> > > >> > >>>>>> the IESG statement is here: > > >> > >>>>>> > > >> > >>>>>> > http://www.ietf.org/iesg/statement/writable-mib-module.html > > >> > >>>>>> > > >> > >>>>>> My reading is that it specifically talks about > configuration. > > >> While > > >> > >>>>>> the discussion started with "lets ban all write > access", it may > > >> be > > >> > >>>>>> important to note that the final statement does not > say this. > > >> Hence, > > >> > >>>>>> I am not sure we have to remove the MAX-ACCESS > read-write. > > >> > >>>>> > > >> > >>>>> some of the vm options do cause me existential peril. The > > >> remaining > > >> > >>>>> one's however do not. so I think Juergen's assessment > is a > > >> correct one. > > >> > >>>>> The statement seems to be serving it's purpose! > > >> >>>> > > >> > >>>> Joel, can you please decrypt your message so that it > becomes > > >> perhaps > > >> > >>>> actionable? > > >> > >>> > > >> > >>> I'm agreeing with you. > > >> > >>> > > >> > >>>> /js > > >> > -- > > >> > Hirochika Asai >, The University of Tokyo > > >> > > > >> > _______________________________________________ > > >> > OPSAWG mailing list > > >> > OPSAWG@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/opsawg > > >> > > >> _______________________________________________ > > >> OPSAWG mailing list > > >> OPSAWG@ietf.org > > >> https://www.ietf.org/mailman/listinfo/opsawg > > >> > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsawg > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Radek Krejci mobile: +420 732 212 714 office: +420 234 680 256 e-mail: rkrejci@cesnet.cz CESNET Association of Legal Entities 160 00 Praha 6, Zikova 4 Czech Republic --------------060801010903020700050308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dne 29.5.2014 17:35, Andy Bierman napsal(a):



On Thu, May 29, 2014 at 6:16 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

On 29 May 2014, at 14:31, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Hi,
>
> I am moving this discussion to the NETCONF mailing list.
>
> Andy Bierman <andy@yumaworks.com> writes:
> ...
> >
> > I don't agree NETCONF/YANG persistence is ill-defined.
> > It is not uniform. There are a few variants, identified by
> > capability URIs.
>
> I'd say persistence is at least under-defined. For example, it doesn't seem to be clear from 6241 whether candidate is persistent.
>
>
> OK
>
> sec 8.3.5.2 says:
>
>    When a client fails with outstanding changes to the candidate
>    configuration, recovery can be difficult.  To facilitate easy
>    recovery, any outstanding changes are discarded when the lock is
>    released, whether explicitly with the <unlock> operation or
>
>  implicitly from session failure.
> IMO it is odd that candidate is cleaned up only if it was locked.
> If a client edits candidate and then closes the session somehow the changes are left behind.
> The RFC is silent about the contents of candidate at boot-time. Our server always boots
> with the candidate and running having the same contents.  Otherwise the candidate is
> dirty at boot-time and cannot be locked by any session until a discard-changes is invoked.
> There is also no explicit requirement to boot with any particular candidate contents, so
> booting with the contents of running is compliant.

I think an alternative interpretation of the 6241 text is that candidate is a persistent staging area that survives reboots and is only reverted to running after discard-changes. So a client can close a session, then later open a new one and start editing where he left off.



There is no text that says anything about the initial state of candidate.
Does any known implementation behave this way?
(Note that the shared candidate is a horrible place to toss some edits
and come back later to finish up.  The shared candidate is not really
intended to left unlocked so partial edits from various clients can accumulate.)



libnetconf/netopeer server does. Since RFC doesn't say anything about initial state of the candidate, we don't do anything with its content. So initially, it is empty and any change is persistent. The only thing that libnetconf do automatically with candidate content is copy-config from running (discarding the changes) on unlock.

I think that it's better to be consistent in "candidate is dirty" than the approach "it may be consistent with running datastore at some time .... or not". Therefore I don't think, that come back later and continue in editing is a good idea - in our implementation, candidate is always considered to be dirty and if you want to work with it, you are supposed to lock it and (or at least) initiate its content.

Radek

Lada


Andy
 
>
>
> Lada
>
> Andy
>
>
> >
> > The XMLCONF design team (pre-4741) tried very hard to
> > get the router vendors to agree on a single transaction model
> > but it was way too big a change, and (of course) each vendor
> > thought their way was better, so the standard should use that.
> > We ended up with 3 configuration datastores (candidate, running, startup).
> > The transaction models that can be used with these datastores
> > are compatible with specific router CLI architectures.
> >
> > Two particular vendors do not agree on how to recover
> > from the "unreachable" problem.  If the operator makes
> > config changes that break the connectivity to the device,
> > then the device has to recover somehow.
> >
> >   M1: do not persist the changes until they are proven to
> >         be correct.  Force the device to reboot with the saved
> >         (known good) config if things go bad.
> >
> >   M2: persist the changes right away.  Pick some timeout
> >         and if the client does not follow up with a confirmation
> >         before the timeout, automatically revert to the version
> >         that was running before the transaction started.
> >
> > RFC 6241 could be more clear on the motivation for the
> > capabilities and operations that support various transaction models.
> > Maybe that is what you meant by 'ill-defined'.
> >
> >
> > Andy
> >
> > So the two objects controlling Notifications seem clearly configuration,
> >> whether or not the setting of them persists or is lost on reboot.  You
> >> could create a YANG module which controls the setting of these two
> >> objects for SNMP usage but I think that even the IESG might see that
> >> that is an unusual approach, as opposed to making them read-write in
> >> SMI!
> >>
> >> When I first read the draft IESG statement, it was unclear to me whether
> >> or not the authors fully understood what they had written.
> >>
> >> Tom Petch
> >>
> >> > (*1) http://www.ietf.org/iesg/statement/writable-mib-module.html
> >> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> >> >
> >> > Hirochika
> >> >
> >> >
> >> > On May 27, 2014, at 3:55 AM, joel jaeggli <joelja@bogus.com> wrote:
> >> >
> >> > > yeah if you want to discuss it with the ops/management ADs and the
> >> > > chairs that's fine.
> >> > >
> >> > > I don't think there's a reason to involve the whole iesg.
> >> > >
> >> > > Thanks
> >> > > joel
> >> > >
> >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> >> > >> js and Joel,
> >> > >>
> >> > >> Thank you for your comments.
> >> > >>
> >> > >> I agree that the IESG statement seems to be talking about
> >> configuration,
> >> > >> but I cannot definitely say that the objects I listed in my
> >> previous E-mail
> >> > >> are out of the IESG statement's scope.
> >> > >>
> >> > >> I think it would be better to move this issue to the IESG, but I
> >> don't keep
> >> > >> up the procedure.  May I, as an author of the draft, send an E-mail
> >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG chairs to
> >> > >> handle it?
> >> > >>
> >> > >> Thank you.
> >> > >> Hirochika
> >> > >>
> >> > >>
> >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli <joelja@bogus.com> wrote:
> >> > >>
> >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli wrote:
> >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> >> > >>>>>> Asai,
> >> > >>>>>>
> >> > >>>>>> the IESG statement is here:
> >> > >>>>>>
> >> > >>>>>> http://www.ietf.org/iesg/statement/writable-mib-module.html
> >> > >>>>>>
> >> > >>>>>> My reading is that it specifically talks about configuration.
> >> While
> >> > >>>>>> the discussion started with "lets ban all write access", it may
> >> be
> >> > >>>>>> important to note that the final statement does not say this.
> >> Hence,
> >> > >>>>>> I am not sure we have to remove the MAX-ACCESS read-write.
> >> > >>>>>
> >> > >>>>> some of the vm options do cause me existential peril. The
> >> remaining
> >> > >>>>> one's however do not. so I think Juergen's assessment  is a
> >> correct one.
> >> > >>>>> The statement seems to be serving it's purpose!
> >> >>>>
> >> > >>>> Joel, can you please decrypt your message so that it becomes
> >> perhaps
> >> > >>>> actionable?
> >> > >>>
> >> > >>> I'm agreeing with you.
> >> > >>>
> >> > >>>> /js
> >> > --
> >> > Hirochika Asai <panda@hongo.wide.ad.jp>, The University of Tokyo
> >> >
> >> > _______________________________________________
> >> > OPSAWG mailing list
> >> > OPSAWG@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >> _______________________________________________
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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







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


-- 
Radek Krejci
mobile: +420 732 212 714
office: +420 234 680 256
e-mail: rkrejci@cesnet.cz

CESNET
Association of Legal Entities
160 00 Praha 6, Zikova 4
Czech Republic
--------------060801010903020700050308-- From nobody Wed Jun 4 01:24:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7551A003A for ; Wed, 4 Jun 2014 01:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ5d8_E5ZKF9 for ; Wed, 4 Jun 2014 01:24:36 -0700 (PDT) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EB51A0108 for ; Wed, 4 Jun 2014 01:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1915; q=dns/txt; s=iport; t=1401870270; x=1403079870; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WOD3PMLjgz15OXIO2H0Hj2Wh779hzJSR7Zv3vfa1RyA=; b=iIPbRN6eYJG/ejzrzJCIlp3UqSnczlnn8RpiP8iwjbcwAFu7KdSccZxm IFLahnttbrKDzNjFZzmJfUQ6iigYVrWPy5Y/gWh52j7rl4ZehjR6qDij2 XVZ1qlA7dXAOtKsXq95ZcReWOw8NUKNRHWqLgqIfctOFRPE3DZ+kXEAbs Y=; X-IronPort-AV: E=Sophos;i="4.98,971,1392163200"; d="scan'208";a="11003143" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 04 Jun 2014 08:24:28 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s548ONTb023573; Wed, 4 Jun 2014 08:24:25 GMT Message-ID: <538ED7B7.3030309@cisco.com> Date: Wed, 04 Jun 2014 10:24:23 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com References: <20140505152117.0327618000D@rfc-editor.org> In-Reply-To: <20140505152117.0327618000D@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/JqcU05objTAJUZM-sg7OJXW89kM Cc: ksekera@cisco.com, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 08:24:38 -0000 Dear all, Is this right? Regards, B > The following errata report has been submitted for RFC6241, > "Network Configuration Protocol (NETCONF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3980 > > -------------------------------------- > Type: Technical > Reported by: Klement Sekera > > Section: 6.2.5 > > Original Text > ------------- > o If any sibling nodes of the selection node are instance identifier > components for a conceptual data structure (e.g., list key leaf), > then they MAY also be included in the filter output. > > Corrected Text > -------------- > o If any sibling nodes of a node are instance identifier > components for a conceptual data structure (e.g., list key leaf), > then they MAY also be included in the filter output. > > Notes > ----- > The intent is to allow the server to always include the key node values and the wording accidentally does not cover this case. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6241 (draft-ietf-netconf-4741bis-10) > -------------------------------------- > Title : Network Configuration Protocol (NETCONF) > Publication Date : June 2011 > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > From nobody Wed Jun 4 02:54:52 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA91A01BB for ; Wed, 4 Jun 2014 02:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoTkHz3NuF2X for ; Wed, 4 Jun 2014 02:54:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B46F1A019A for ; Wed, 4 Jun 2014 02:54:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3F7F79D6; Wed, 4 Jun 2014 11:54:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3j1tBQpByBYd; Wed, 4 Jun 2014 11:54:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 4 Jun 2014 11:54:40 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE33B20017; Wed, 4 Jun 2014 11:54:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id maOo-j5DvYcP; Wed, 4 Jun 2014 11:54:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D4C820013; Wed, 4 Jun 2014 11:54:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A88DE2D51172; Wed, 4 Jun 2014 11:54:38 +0200 (CEST) Date: Wed, 4 Jun 2014 11:54:38 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20140604095438.GB7993@elstar.local> Mail-Followup-To: Benoit Claise , rob.enns@gmail.com, mbj@tail-f.com, andy@yumaworks.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com, ksekera@cisco.com, netconf@ietf.org References: <20140505152117.0327618000D@rfc-editor.org> <538ED7B7.3030309@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <538ED7B7.3030309@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/aRxhloJ8_DCBxq-CoVh13MPvjOQ Cc: rob.enns@gmail.com, joelja@bogus.com, ksekera@cisco.com, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 09:54:50 -0000 I am not sure since in the new text 'node' is rather unspecified. For me, it would help to have a example demonstrating what is broken and how the proposed change fixes things. Ideally, this should be sent to the WG mailing list. /js On Wed, Jun 04, 2014 at 10:24:23AM +0200, Benoit Claise wrote: > Dear all, > > Is this right? > > Regards, B > >The following errata report has been submitted for RFC6241, > >"Network Configuration Protocol (NETCONF)". > > > >-------------------------------------- > >You may review the report below and at: > >http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3980 > > > >-------------------------------------- > >Type: Technical > >Reported by: Klement Sekera > > > >Section: 6.2.5 > > > >Original Text > >------------- > >o If any sibling nodes of the selection node are instance identifier > > components for a conceptual data structure (e.g., list key leaf), > > then they MAY also be included in the filter output. > > > >Corrected Text > >-------------- > >o If any sibling nodes of a node are instance identifier > > components for a conceptual data structure (e.g., list key leaf), > > then they MAY also be included in the filter output. > > > >Notes > >----- > >The intent is to allow the server to always include the key node values > >and the wording accidentally does not cover this case. > > > >Instructions: > >------------- > >This errata is currently posted as "Reported". If necessary, please > >use "Reply All" to discuss whether it should be verified or > >rejected. When a decision is reached, the verifying party (IESG) > >can log in to change the status and edit the report, if necessary. > > > >-------------------------------------- > >RFC6241 (draft-ietf-netconf-4741bis-10) > >-------------------------------------- > >Title : Network Configuration Protocol (NETCONF) > >Publication Date : June 2011 > >Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, > >Ed., A. Bierman, Ed. > >Category : PROPOSED STANDARD > >Source : Network Configuration > >Area : Operations and Management > >Stream : IETF > >Verifying Party : IESG > >. > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jun 4 03:22:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B5B1A024A for ; Wed, 4 Jun 2014 03:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9mN2v2x6t4N for ; Wed, 4 Jun 2014 03:22:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310341A0239 for ; Wed, 4 Jun 2014 03:22:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHV17377; Wed, 04 Jun 2014 10:22:37 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Jun 2014 11:21:35 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Jun 2014 11:22:22 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 4 Jun 2014 18:22:13 +0800 From: "Liubing (Leo)" To: Netconf Thread-Topic: Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt Thread-Index: AQHPf97ZguH8jW6EdUWevnlZT6o6Dg== Date: Wed, 4 Jun 2014 10:22:12 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3aSmi5rO59LCJSilSCilxJPwPUw Cc: Zhengguangying , Yangang Subject: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:22:47 -0000 SGkgYWxsLA0KDQpXZSd2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQsIHdoaWNoIGlzIGFib3V0IE5FVENP TkYgZGF0YSBmcmFnbWVudGF0aW9uLg0KDQpUaGUgYmFzaWMgaWRlYSBpcywgd2hlbiBOTVMgaXMg cmV0cmlldmluZyBhIGxhcmdlIHNpemUgb2YgZGF0YSBpbiB0aGUgZGV2aWNlLCB0aGUgPHJwYy1y ZXBseT4gbWlnaHQgYmUgdmVyeSBiaWcgKGUuZy4gdGhlIHJvdXRlcyBpbiBhIGNvcmUgcm91dGVy KS4NCkN1cnJlbnRseSB0aGVyZSBhcmUgbWFpbmx5IHR3byBtZXRob2RzIG9mIGhhbmRsaW5nIHRo ZSBiaWcgPHJwYy1yZXBseT46IG9uZSBpcyBzdHJlYW0tb3JpZW50ZWQgaGFuZGxpbmc7IHRoZSBv dGhlciBpcyBqdXN0IHJlcXVlc3QgYSBwb3J0aW9uIG9mIHRoZSBkYXRhLg0KDQpUaGlzIGRyYWZ0 IGNvbnNpZGVycyBib3RoIHRoZSB0d28gbWV0aG9kcyBhcmUgcHJvYmxlbWF0aWMgaW4gc29tZSBz aXR1YXRpb25zLCBhbmQgcHJvcG9zZXMgYSBuZXcgbWV0aG9kIHdoaWNoIGFsbG93cyB0aGUgbGFy Z2Ugc2l6ZSA8cnBjLXJlcGx5PiB0byBiZSBmcmFnbWVudGVkIGluIE5FVENPTkYgbGV2ZWwuDQoN ClBsZWFzZSByZWFkIHRoZSBkcmFmdCBhbmQgY29tbWVudC4NCk1hbnkgdGhhbmtzIQ0KDQpCZXN0 IHJlZ2FyZHMsDQpCaW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogV2VkbmVzZGF5LCBKdW5lIDA0LCAyMDE0IDU6MjcgUE0NClRvOiBMaXViaW5nIChMZW8p OyBMaXViaW5nIChMZW8pOyBaaGVuZ2d1YW5neWluZzsgWmhlbmdndWFuZ3lpbmcNClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRh dGlvbi0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LW5ldGNvbmYt ZnJhZ21lbnRhdGlvbi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg QmluZyBMaXUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJh ZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbg0KUmV2aXNpb246CTAwDQpUaXRsZToJCUEgTkVU Q09ORiBFeHRlbnNpb24gZm9yIERhdGEgRnJhZ21lbnRhdGlvbg0KRG9jdW1lbnQgZGF0ZToJMjAx NC0wNi0wNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTINClVSTDog ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUt bmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24vDQpI dG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LW5ldGNv bmYtZnJhZ21lbnRhdGlvbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBpbnRy b2R1Y2VzIGFuIGV4dGVuc2lvbiB0byBORVRDT05GIChOZXR3b3JrDQogICBDb25maWd1cmF0aW9u KSBwcm90b2NvbC4gVGhlIGV4dGVuc2lvbiBhbGxvd3MgTkVUQ09ORiB0byBoYW5kbGUgbGFyZ2UN CiAgIHNpemUgZGF0YSBhcyBmcmFnbWVudGVkIFJQQyBtZXNzYWdlcy4gU3BlY2lmaWNhbGx5LCB0 aGlzIGRvY3VtZW50DQogICBkZWZpbmVzIGEgbmV3IDxnZXQtYmxvY2s+IGNhcGFiaWxpdHkgYW5k IHJlbGV2YW50IG9wZXJhdGlvbnMgdG8NCiAgIGhhbmRsZSB0aGUgZnJhZ21lbnRhdGlvbnMuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Jun 4 03:24:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A367D1A0285 for ; Wed, 4 Jun 2014 03:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v962JUgpVP70 for ; Wed, 4 Jun 2014 03:24:31 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6813F1A0275 for ; Wed, 4 Jun 2014 03:24:30 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id B9A651280484; Wed, 4 Jun 2014 12:23:29 +0200 (CEST) Date: Wed, 04 Jun 2014 12:24:23 +0200 (CEST) Message-Id: <20140604.122423.1320188282940387836.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140604095438.GB7993@elstar.local> References: <20140505152117.0327618000D@rfc-editor.org> <538ED7B7.3030309@cisco.com> <20140604095438.GB7993@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Fe_G1UuCibFLQGImRPIH3ykPbjM Cc: rob.enns@gmail.com, joelja@bogus.com, ksekera@cisco.com, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:24:32 -0000 Juergen Schoenwaelder wrote: > I am not sure since in the new text 'node' is rather unspecified. For > me, it would help to have a example demonstrating what is broken Assume this model: container servers { list server { key name; leaf name { ... } leaf ip { ... } leaf port { ... } } } and this data on the server: foo 10.0.0.1 80 bar 10.0.0.1 25 Now, with this filter: 80 It is, according to 6241, ok to return: foo 10.0.0.1 80 (because 'name' is a sibling to the selection node 'ip') However, with this filter: 80 a strict interpretation of 6241 seems to suggest that this is illegal to return: foo 80 ... but that doesn't make much sense. The intention of the text was to allow keys to be inserted everywhere in the returned subtrees. This said, I am not convinced the proposed change fixes this. The subtree filter specification text is pretty difficult to interpret... > and > how the proposed change fixes things. Ideally, this should be sent to > the WG mailing list. This thread is sent to the WG ML. /martin From nobody Wed Jun 4 03:31:23 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BDE1A02A7 for ; Wed, 4 Jun 2014 03:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_glHPyIA0Aa for ; Wed, 4 Jun 2014 03:31:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F04A1A02A3 for ; Wed, 4 Jun 2014 03:31:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 311BF752; Wed, 4 Jun 2014 12:31:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JZeXZj6n8lO1; Wed, 4 Jun 2014 12:31:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 4 Jun 2014 12:31:12 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEEA92002C; Wed, 4 Jun 2014 12:31:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MkgGm8k-2vAX; Wed, 4 Jun 2014 12:31:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A49E20013; Wed, 4 Jun 2014 12:31:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9570E2D51295; Wed, 4 Jun 2014 12:31:10 +0200 (CEST) Date: Wed, 4 Jun 2014 12:31:09 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140604103109.GA8220@elstar.local> Mail-Followup-To: Martin Bjorklund , bclaise@cisco.com, rob.enns@gmail.com, andy@yumaworks.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com, ksekera@cisco.com, netconf@ietf.org References: <20140505152117.0327618000D@rfc-editor.org> <538ED7B7.3030309@cisco.com> <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140604.122423.1320188282940387836.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gVohCGcho1FVbtN4Ll1MlJoSNjY Cc: rob.enns@gmail.com, joelja@bogus.com, ksekera@cisco.com, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:31:22 -0000 On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > I am not sure since in the new text 'node' is rather unspecified. For > > me, it would help to have a example demonstrating what is broken > > Assume this model: > > container servers { > list server { > key name; > leaf name { ... } > leaf ip { ... } > leaf port { ... } > } > } > > and this data on the server: > > > > foo > 10.0.0.1 > 80 > > > bar > 10.0.0.1 > 25 > > > > Now, with this filter: > > > > 80 > > > > > It is, according to 6241, ok to return: > > > > foo > 10.0.0.1 > 80 > > > > (because 'name' is a sibling to the selection node 'ip') > > > However, with this filter: > > > > 80 > > > > a strict interpretation of 6241 seems to suggest that this is illegal > to return: > > > > foo > 80 > > > > ... but that doesn't make much sense. > > The intention of the text was to allow keys to be inserted everywhere > in the returned subtrees. > > > This said, I am not convinced the proposed change fixes this. The > subtree filter specification text is pretty difficult to interpret... > So any key leafs that are child nodes of any Containment Nodes of the Subtree Filter can be added? Would that be more accurate? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jun 4 03:39:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF3E1A02D7 for ; Wed, 4 Jun 2014 03:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVrklF81UT5o for ; Wed, 4 Jun 2014 03:39:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id EADB91A02CA for ; Wed, 4 Jun 2014 03:39:01 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 848AF1280484; Wed, 4 Jun 2014 12:38:01 +0200 (CEST) Date: Wed, 04 Jun 2014 12:38:55 +0200 (CEST) Message-Id: <20140604.123855.1971075702450619730.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140604103109.GA8220@elstar.local> References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WFOas6RVcltGRxj6fqRLULZyfU8 Cc: rob.enns@gmail.com, joelja@bogus.com, ksekera@cisco.com, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:39:04 -0000 Juergen Schoenwaelder wrote: > On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > I am not sure since in the new text 'node' is rather unspecified. For > > > me, it would help to have a example demonstrating what is broken > > > > Assume this model: > > > > container servers { > > list server { > > key name; > > leaf name { ... } > > leaf ip { ... } > > leaf port { ... } > > } > > } > > > > and this data on the server: > > > > > > > > foo > > 10.0.0.1 > > 80 > > > > > > bar > > 10.0.0.1 > > 25 > > > > > > > > Now, with this filter: > > > > > > > > 80 > > > > > > > > > > It is, according to 6241, ok to return: > > > > > > > > foo > > 10.0.0.1 > > 80 > > > > > > > > (because 'name' is a sibling to the selection node 'ip') > > > > > > However, with this filter: > > > > > > > > 80 > > > > > > > > a strict interpretation of 6241 seems to suggest that this is illegal > > to return: > > > > > > > > foo > > 80 > > > > > > > > ... but that doesn't make much sense. > > > > The intention of the text was to allow keys to be inserted everywhere > > in the returned subtrees. > > > > > > This said, I am not convinced the proposed change fixes this. The > > subtree filter specification text is pretty difficult to interpret... > > > > So any key leafs that are child nodes of any Containment Nodes of > the Subtree Filter can be added? Would that be more accurate? I think so, but the current text is in section 6.2.5 which talks about content match nodes. This is a bit confusing - what happens if you don't have any content match nodes? Your sentence belongs to text that discuss subtree filter in general, maybe somewhere in section 6.3. /martin From nobody Wed Jun 4 05:12:16 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FE71A01D1 for ; Wed, 4 Jun 2014 05:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj_7nwxeyHcB for ; Wed, 4 Jun 2014 05:12:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD831A01C9 for ; Wed, 4 Jun 2014 05:12:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EC96DAD6; Wed, 4 Jun 2014 14:11:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1Dz3thnBg1Es; Wed, 4 Jun 2014 14:11:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 4 Jun 2014 14:11:57 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 872F020013; Wed, 4 Jun 2014 14:11:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id O-4fBsC-xH2A; Wed, 4 Jun 2014 14:11:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0CCE20017; Wed, 4 Jun 2014 14:11:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 22BD72D513A4; Wed, 4 Jun 2014 14:11:55 +0200 (CEST) Date: Wed, 4 Jun 2014 14:11:54 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140604121154.GA8481@elstar.local> Mail-Followup-To: Martin Bjorklund , bclaise@cisco.com, rob.enns@gmail.com, andy@yumaworks.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com, ksekera@cisco.com, netconf@ietf.org References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140604.123855.1971075702450619730.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zdwj_MxPceaFT9di9qyeacSTeus Cc: rob.enns@gmail.com, joelja@bogus.com, ksekera@cisco.com, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 12:12:13 -0000 On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > I am not sure since in the new text 'node' is rather unspecified. For > > > > me, it would help to have a example demonstrating what is broken > > > > > > Assume this model: > > > > > > container servers { > > > list server { > > > key name; > > > leaf name { ... } > > > leaf ip { ... } > > > leaf port { ... } > > > } > > > } > > > > > > and this data on the server: > > > > > > > > > > > > foo > > > 10.0.0.1 > > > 80 > > > > > > > > > bar > > > 10.0.0.1 > > > 25 > > > > > > > > > > > > Now, with this filter: > > > > > > > > > > > > 80 > > > > > > > > > > > > > > > It is, according to 6241, ok to return: > > > > > > > > > > > > foo > > > 10.0.0.1 > > > 80 > > > > > > > > > > > > (because 'name' is a sibling to the selection node 'ip') > > > > > > > > > However, with this filter: > > > > > > > > > > > > 80 > > > > > > > > > > > > a strict interpretation of 6241 seems to suggest that this is illegal > > > to return: > > > > > > > > > > > > foo > > > 80 > > > > > > > > > > > > ... but that doesn't make much sense. > > > > > > The intention of the text was to allow keys to be inserted everywhere > > > in the returned subtrees. > > > > > > > > > This said, I am not convinced the proposed change fixes this. The > > > subtree filter specification text is pretty difficult to interpret... > > > > > > > So any key leafs that are child nodes of any Containment Nodes of > > the Subtree Filter can be added? Would that be more accurate? > > I think so, but the current text is in section 6.2.5 which talks about > content match nodes. This is a bit confusing - what happens if you > don't have any content match nodes? > > Your sentence belongs to text that discuss subtree filter in general, > maybe somewhere in section 6.3. > Yes, that makes sense to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bpilka@cisco.com Wed Jun 4 05:56:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376C51A01E0 for ; Wed, 4 Jun 2014 05:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvUCrc-ZWnlZ for ; Wed, 4 Jun 2014 05:56:48 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A711A01D5 for ; Wed, 4 Jun 2014 05:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=909; q=dns/txt; s=iport; t=1401886602; x=1403096202; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=1Tl6Ii9wp/Bjv0vEmRe2sXQRcKubMX3Wt7+3mUfKLL4=; b=MhZkvB8WuV2uSR9RXS9dQwNSleY9n54p6CS0MQXPilgYZI1ZxnhXyadw 7EQfRfJ4dhALPxJH8WCHxqaX/hnJfxSNlf2D8UcEJXsUiFcQRh+v8aDYD 18Z/2Lnn4IKQwbjZoU5ErMPQdU4PpNqxIjd9leNr3X0WD7xKS8T9Uuurf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPUWj1OtJssW/2dsb2JhbABZyEZ0gmQ/AT0EEhgDAgECAVgIAQGIPpxvtQsXjm+EKgEDmg+Gb4xHgzo7 X-IronPort-AV: E=Sophos;i="4.98,973,1392163200"; d="scan'208";a="73682819" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 04 Jun 2014 12:56:37 +0000 Received: from [10.61.216.156] ([10.61.216.156]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s54Cub1i003773 for ; Wed, 4 Jun 2014 12:56:37 GMT Message-ID: <538F178E.6060400@cisco.com> Date: Wed, 04 Jun 2014 14:56:46 +0200 From: Boris Pilka User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nAcIik7vTBwRZBb2emXu_BmMGl4 X-Mailman-Approved-At: Wed, 04 Jun 2014 06:04:15 -0700 Subject: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 12:59:47 -0000 Hi, could you, please, clarify the following for me: RFC5277 section 3.2.3. 'A NETCONF server implementation supporting the notification capability MUST support the "NETCONF" notification event stream. This stream contains all NETCONF XML event notifications supported by the NETCONF server. The exact string "NETCONF" is used during the advertisement of stream support during the operation on and during the operation. Definition of the event notifications and their contents, beyond the inclusion of , for this event stream is outside the scope of this document.' Imagine 20 streams being present on Netconf Server apart from NETCONF stream. Does the section above suggests, that notifications from all 20 streams should be also be sent in a NETCONF stream ? Thank you very much, Boris Pilka From nobody Wed Jun 4 08:33:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5121A037B for ; Wed, 4 Jun 2014 08:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2ya0XpaeSkO for ; Wed, 4 Jun 2014 08:33:03 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777F21A0376 for ; Wed, 4 Jun 2014 08:33:03 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id 63so16258741qgz.30 for ; Wed, 04 Jun 2014 08:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YRj0YK5oN3ZaMO8T1eyDK1fEZOeCIyHB/YVH022zBmw=; b=YuzBk+lnahTHceQsezEJKXXVe3Bk1qxM0r8ZHGTAS+s2+l8UZWaLYtsWgn3XKZeThl zUUVt0FKlp0uc9ZdxQpdjJJSh+b4kYUpt7ZKtJ4MHSKpEuz7xCfjmsJ3ypZstfTjPJhg mimOz5C265b5k6f6LqEKhGGehRxLolvDnsElG9L+zmW4Eg/yiv8iniLbpfnEIv0dPUc6 K8wYOXqVyt0RvJVHM2HwQhjphLRzP8RO0LzqQVnsdXkntvtQbRywhlNCt63wZGr4FrCW N8sie0fFimzQovOhJtFnL9mZZ+SXsymUbMDUoKOmVdAsEV2oxEWbTVnZEBCY0sa48N8C 1aRA== MIME-Version: 1.0 X-Received: by 10.224.0.70 with SMTP id 6mr7484304qaa.100.1401895976041; Wed, 04 Jun 2014 08:32:56 -0700 (PDT) Received: by 10.229.58.74 with HTTP; Wed, 4 Jun 2014 08:32:55 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> Date: Wed, 4 Jun 2014 23:32:55 +0800 Message-ID: From: chong feng To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=047d7bdc96c8aa051b04fb0457b4 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Nmaoti-EH4StkkNP_xGUp2nVnX8 Cc: Zhengguangying , Netconf , Yangang Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 15:33:05 -0000 --047d7bdc96c8aa051b04fb0457b4 Content-Type: text/plain; charset=UTF-8 Hi, I have reviewed this new draft. I understand your solution is that NETCONF server reserve break points and wait for client to retrieve the next response. I think it's not a good solution, because server may need to reserve many break points if there a large number of concurrent requests. It's too heavy for server. And, the server must be stateful if it support get-block capability. The other questions and comments are listed below: 1. Get-block capability should not change the get-config operation's behavior. If client use get-config operation to retrieve data, all data must be sent in one response or get-block capability should add a parameter to get-config operation to indicate the response data will be fragmented. 2. A set-id can be aged? when client never send a request to retrieve the next fragment for a long time, I think this set-id should be aged, otherwise, server will be reserve more and more set-ids. 3. A set-id is unique in session level or server level? 4. If a session is killed or closed, other session can retrieved the next fragment if the client provide the correct set-id? /frank 2014-06-04 18:22 GMT+08:00 Liubing (Leo) : > Hi all, > > We've posted a new draft, which is about NETCONF data fragmentation. > > The basic idea is, when NMS is retrieving a large size of data in the > device, the might be very big (e.g. the routes in a core > router). > Currently there are mainly two methods of handling the big : > one is stream-oriented handling; the other is just request a portion of the > data. > > This draft considers both the two methods are problematic in some > situations, and proposes a new method which allows the large size > to be fragmented in NETCONF level. > > Please read the draft and comment. > Many thanks! > > Best regards, > Bing > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, June 04, 2014 5:27 PM > To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying > Subject: New Version Notification for > draft-liu-netconf-fragmentation-00.txt > > > A new version of I-D, draft-liu-netconf-fragmentation-00.txt > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > Name: draft-liu-netconf-fragmentation > Revision: 00 > Title: A NETCONF Extension for Data Fragmentation > Document date: 2014-06-04 > Group: Individual Submission > Pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-liu-netconf-fragmentation-00.txt > Status: > https://datatracker.ietf.org/doc/draft-liu-netconf-fragmentation/ > Htmlized: > http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00 > > > Abstract: > This document introduces an extension to NETCONF (Network > Configuration) protocol. The extension allows NETCONF to handle large > size data as fragmented RPC messages. Specifically, this document > defines a new capability and relevant operations to > handle the fragmentations. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --047d7bdc96c8aa051b04fb0457b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0 =C2=A0I have reviewed this new draft.
=
=C2=A0 =C2=A0I understand your solution is that NETCONF server reserve= break points and wait for client to retrieve the next response.
I think it= 9;s not a good solution, because server may need to reserve many break poin= ts if there a large number of concurrent requests.
It's too heavy= for server. And, the server must be stateful if it support get-block capab= ility.
=C2=A0
The other questions and comments are listed below:
1. Get-bloc= k capability should not change the get-config operation's behavior. If = client use get-config operation to retrieve data,
<= font color=3D"#000000"> all data= must be sent in one response or get-block capability should add a paramete= r to get-config operation to indicate the=C2=A0
re= sponse data will be fragmented.
2. A set-id can be aged? when= client never send a request to retrieve the next fragment for a long time,= I think this set-id should be aged,
oth= erwise, server will be reserve more and more set-ids.
<= div> 3. A se= t-id is unique in session level or server level?
4. If = a session is killed or closed, other session can retrieved the next fragmen= t if the client provide the correct set-id?
/f= rank


2014-06-04 18:22 GMT+08:00 Liubing (Leo) <leo.liubin= g@huawei.com>:
Hi all,

We've posted a new draft, which is about NETCONF data fragmentation.
The basic idea is, when NMS is retrieving a large size of data in the devic= e, the <rpc-reply> might be very big (e.g. the routes in a core route= r).
Currently there are mainly two methods of handling the big <rpc-reply>= ;: one is stream-oriented handling; the other is just request a portion of = the data.

This draft considers both the two methods are problematic in some situation= s, and proposes a new method which allows the large size <rpc-reply> = to be fragmented in NETCONF level.

Please read the draft and comment.
Many thanks!

Best regards,
Bing

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Wednesday, June 04, 2014 5:27 PM
To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying
Subject: New Version Notification for draft-liu-netconf-fragmentation-00.tx= t


A new version of I-D, draft-liu-netconf-fragmentation-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-liu-netconf-fragmentation Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A NETCONF Extension for Data Fragm= entation
Document date: =C2=A02014-06-04
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A012
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-liu-netconf-fragmentation-00.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracke= r.ietf.org/doc/draft-liu-netconf-fragmentation/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/= draft-liu-netconf-fragmentation-00


Abstract:
=C2=A0 =C2=A0This document introduces an extension to NETCONF (Network
=C2=A0 =C2=A0Configuration) protocol. The extension allows NETCONF to handl= e large
=C2=A0 =C2=A0size data as fragmented RPC messages. Specifically, this docum= ent
=C2=A0 =C2=A0defines a new <get-block> capability and relevant operat= ions to
=C2=A0 =C2=A0handle the fragmentations.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

--047d7bdc96c8aa051b04fb0457b4-- From nobody Wed Jun 4 09:20:15 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3E71A02E2 for ; Wed, 4 Jun 2014 09:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_fMWZAmsn-G for ; Wed, 4 Jun 2014 09:20:11 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBEA1A021E for ; Wed, 4 Jun 2014 09:20:11 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id cm18so7148882qab.22 for ; Wed, 04 Jun 2014 09:20:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m8xy+SjWDPnp/luqH6aqkmq/yTfR57mdFCa7VSujJvA=; b=Py7UMusdyL7Mqu2bWy/Ths2PaRYbQJc/jlzHWW2N6JHRe5MVn6cAXnrvOU3/XpsywX xePx0Q6RAU+QcJqHO0LFjqMpbYIm5QEpYUZLL/FMSO+DcP6xGaiIliB3HkkvrU5soNSx 5o0UA/Us4HGR+QLGbRI2RGWKGvcJKIN3VtanvbZr9VyDMDsbpzBrIL4W+dqCf7KJxWG2 olY8X56DleR0HH8DgY/2hDg3RCbDB7tZXTCajnUnNuYRDa0q9IGATDBxOEbH9FE3kzbm 6/TNCEUILAA2LR7rW9SOtlOL4HS+et1YMsljghuaTs8Ef7j7HnfR5jIwEFCNbdjQ1ttI XZqQ== X-Gm-Message-State: ALoCoQnqQQvYVJVKEAqCloj+J+MYpByKDFf4oG0rrtxahNyKJCX3ZrV/50NNTM32gfMf6sg6K85l MIME-Version: 1.0 X-Received: by 10.140.27.245 with SMTP id 108mr67284823qgx.18.1401898805068; Wed, 04 Jun 2014 09:20:05 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 4 Jun 2014 09:20:05 -0700 (PDT) In-Reply-To: <538F178E.6060400@cisco.com> References: <538F178E.6060400@cisco.com> Date: Wed, 4 Jun 2014 09:20:05 -0700 Message-ID: From: Andy Bierman To: Boris Pilka Content-Type: multipart/alternative; boundary=001a11c1526049c4b304fb050013 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gmaWLC3EN5W85me5kBfeb1VnE9w Cc: Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:20:13 -0000 --001a11c1526049c4b304fb050013 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 4, 2014 at 5:56 AM, Boris Pilka wrote: > Hi, > > could you, please, clarify the following for me: > > RFC5277 section 3.2.3. > 'A NETCONF server implementation supporting the notification > capability MUST support the "NETCONF" notification event stream. > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. The exact string "NETCONF" is used during the > advertisement of stream support during the operation on > and during the operation. Definition > of the event notifications and their contents, beyond the inclusion > of , for this event stream is outside the scope of this > document.' > > Imagine 20 streams being present on Netconf Server apart from NETCONF > stream. > > kind of hard, unless you are adding filtering into the stream definition. > Does the section above suggests, that notifications from all 20 streams > should be also be sent in a NETCONF stream ? > > No, but this probably needs clarification. The standard notifications defined in YANG (e.g., RFC 6470) are expected to show up on the NETCONF stream. You can put whatever content on whatever stream you want, but for standard notification definitions, they must at (at least) be in the NETCONF stream. Thank you very much, > > Boris Pilka > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c1526049c4b304fb050013 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 5:56 AM, Boris Pilka <<= a href=3D"mailto:bpilka@cisco.com" target=3D"_blank">bpilka@cisco.com&g= t; wrote:
Hi,

could you, please, clarify the following for me:

RFC5277 section 3.2.3.
'A NETCONF server implementation supporting the notification
=A0 =A0capability MUST support the "NETCONF" notification event s= tream.
=A0 =A0This stream contains all NETCONF XML event notifications supported b= y
=A0 =A0the NETCONF server. =A0The exact string "NETCONF" is used = during the
=A0 =A0advertisement of stream support during the <get> operation on<= br> =A0 =A0<streams> and during the <create-subscription> operation= . =A0Definition
=A0 =A0of the event notifications and their contents, beyond the inclusion<= br> =A0 =A0of <eventTime>, for this event stream is outside the scope of = this
=A0 =A0document.'

Imagine 20 streams being present on Netconf Server apart from NETCONF strea= m.


kind of hard, unless you are adding fi= ltering into the stream definition.
=A0
Does the section above suggests, that notifications from all 20 streams sho= uld be also be sent in a NETCONF stream ?


No, but this probably needs clarificat= ion.
The standard notifications defined in YANG (e.g., RFC 6470)<= /div>
are expected to show up on the NETCONF stream. =A0You can put wha= tever
content on whatever stream you want, but for standard notification def= initions,
they must at (at least) be in the NETCONF stream.
=




Thank you very much,

Boris Pilka



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

--001a11c1526049c4b304fb050013-- From nobody Wed Jun 4 09:43:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F551A0307 for ; Wed, 4 Jun 2014 09:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suwC2tQDFvot for ; Wed, 4 Jun 2014 09:43:24 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867401A0318 for ; Wed, 4 Jun 2014 09:43:19 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id a108so15785643qge.8 for ; Wed, 04 Jun 2014 09:43:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9UxT/OZiLTbFlS0hbIkDzbieSmfD4Le7eGE0P4k77LE=; b=bTynjWrNd4gs1xvOaffT3VN+auwYbJXBBFzf3iF89MM7oqJ6iWaQehbp1uI4bO6lYx IlqM5NNXiZYHRWcVK6loT+ANSDyzXEEPlHa6hFY6pC5IzgcuWVv+hqu7HLbdDC6U3B3A PGckxrAP8VkdWWGPyJOIZFko7Mp9bOhoE/Otx8AjhaI59O8w6MIy5vhOE+jffonS6BS4 GHYBQVQXbDMUx4pizQd9mGTpcqLXDd0XfLBXOrexH78Nf+NS3TrtA1gUzhfLx+kI648r FDZwEirNN0aGNoJBpHqTxtwQPiBy2bTNDUXNEkbxXxCojby6co86Yqr4rw7e06Y+eMg6 7qfA== X-Gm-Message-State: ALoCoQl4ECYfNCk9zOUE22jUC9SKwn8uIlK23QR30YN9mlV3Rbf1JmYug+DL95OdX4RQ7Dd3Fu6m MIME-Version: 1.0 X-Received: by 10.140.41.75 with SMTP id y69mr69038363qgy.34.1401900192701; Wed, 04 Jun 2014 09:43:12 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 4 Jun 2014 09:43:12 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> Date: Wed, 4 Jun 2014 09:43:12 -0700 Message-ID: From: Andy Bierman To: chong feng Content-Type: multipart/alternative; boundary=001a11c126baff568304fb05525e Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7CnbJXkc0JomA0zdL2nN18yy5TQ Cc: Zhengguangying , Netconf , Yangang Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:43:27 -0000 --001a11c126baff568304fb05525e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 4, 2014 at 8:32 AM, chong feng wrote: > Hi, > I have reviewed this new draft. > I understand your solution is that NETCONF server reserve break points > and wait for client to retrieve the next response. > I think it's not a good solution, because server may need to reserve many > break points if there a large number of concurrent requests. > It's too heavy for server. And, the server must be stateful if it support > get-block capability. > > I agree with these concerns. Holding a snapshot of state data for interactive retrieval by the client is very expensive. I do not agree with the premise that the client needs to know the key values in advance. An "iterator" approach allows a list resource to be retrieved in chunks. This is what RESTCONF is going to do, and NETCONF could add a similar RPC function: rpc get-list { input { leaf target { type schema-instance-identifier; description "Identifies subtree to retrieve."; } leaf start { type uint32; default 0; description "Number of entries to skip before starting retrieval"; } leaf max-entries { type uint32 { range "1..max"; } default 25; description "Maximum number of list entries to retrieve"; } } output { anyxml data { description "Contains the requested data"; } } } /if:interfaces/if:interface .... first entry ... .... 25th entry /if:interfaces/if:interface 25 .... 26th entry ... .... 50th entry There is a problem with rapidly changing lists (could get repeat entries on miss some entries), but the snapshot approach uses too much memory, and if the list instances change rapidly, a stale snapshot is not very useful. Andy The other questions and comments are listed below: > 1. Get-block capability should not change the get-config operation's > behavior. If client use get-config operation to retrieve data, > all data must be sent in one response or get-block capability should add a > parameter to get-config operation to indicate the > response data will be fragmented. > 2. A set-id can be aged? when client never send a request to retrieve the > next fragment for a long time, I think this set-id should be aged, > otherwise, server will be reserve more and more set-ids. > 3. A set-id is unique in session level or server level? > 4. If a session is killed or closed, other session can retrieved the next > fragment if the client provide the correct set-id? > /frank > > > 2014-06-04 18:22 GMT+08:00 Liubing (Leo) : > >> Hi all, >> >> We've posted a new draft, which is about NETCONF data fragmentation. >> >> The basic idea is, when NMS is retrieving a large size of data in the >> device, the might be very big (e.g. the routes in a core >> router). >> Currently there are mainly two methods of handling the big : >> one is stream-oriented handling; the other is just request a portion of the >> data. >> >> This draft considers both the two methods are problematic in some >> situations, and proposes a new method which allows the large size >> to be fragmented in NETCONF level. >> >> Please read the draft and comment. >> Many thanks! >> >> Best regards, >> Bing >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, June 04, 2014 5:27 PM >> To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying >> Subject: New Version Notification for >> draft-liu-netconf-fragmentation-00.txt >> >> >> A new version of I-D, draft-liu-netconf-fragmentation-00.txt >> has been successfully submitted by Bing Liu and posted to the IETF >> repository. >> >> Name: draft-liu-netconf-fragmentation >> Revision: 00 >> Title: A NETCONF Extension for Data Fragmentation >> Document date: 2014-06-04 >> Group: Individual Submission >> Pages: 12 >> URL: >> http://www.ietf.org/internet-drafts/draft-liu-netconf-fragmentation-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-liu-netconf-fragmentation/ >> Htmlized: >> http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00 >> >> >> Abstract: >> This document introduces an extension to NETCONF (Network >> Configuration) protocol. The extension allows NETCONF to handle large >> size data as fragmented RPC messages. Specifically, this document >> defines a new capability and relevant operations to >> handle the fragmentations. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c126baff568304fb05525e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 8:32 AM, chong feng <fengchongllly@gm= ail.com> wrote:
Hi,
=A0 =A0I have reviewed this new d= raft.
=A0 =A0I understand your solution is that NETCONF server reserve break= points and wait for client to retrieve the next response.
I think it= 9;s not a good solution, because server may need to reserve many break poin= ts if there a large number of concurrent requests.
It's too heavy= for server. And, the server must be stateful if it support get-block capab= ility.
=A0

I agree with these co= ncerns. =A0Holding a snapshot of state data for interactive retrieval
=
by the client is very expensive.=A0


I do not agree with the premise that the client needs to know the key valu= es in advance.
An "iterator" approach allows a list res= ource to be retrieved in chunks. =A0This is what RESTCONF
is going to do, and NETCONF could add a similar RPC function:

=A0 =A0rpc get-list {
=A0 =A0 =A0input {
=A0 =A0 =A0 =A0leaf target {
=A0 =A0 =A0 =A0 =A0 type schema-i= nstance-identifier;
=A0 =A0 =A0 =A0 =A0 description "Identifies subtree to retrieve.&= quot;;
=A0 =A0 =A0 }
=A0 =A0 =A0 leaf start {
=A0 =A0 =A0 =A0 =A0type uint32;
=A0 =A0 =A0 =A0 =A0default 0;
=A0 =A0 =A0 =A0 =A0description "Number of entries to skip befo= re starting retrieval";
=A0 =A0 =A0 }
=A0 =A0 =A0 leaf max-entries {
=A0 = =A0 =A0 =A0 type uint32 { range "1..max"; }
=A0 =A0 =A0= =A0 default 25;
=A0 =A0 =A0 =A0 description "Maximum number= of list entries to retrieve";
=A0 =A0 =A0 }
=A0 =A0 }
=A0 =A0 output {
=A0 =A0 =A0 =A0anyxml data {
=A0 =A0 =A0 =A0 =A0 description &qu= ot;Contains the requested data";
=A0 =A0 =A0 =A0}
= =A0 =A0 }
=A0 }

=A0 <rpc>
=A0 =A0 <get-list>
=A0 =A0 = =A0 <target>/if:interfaces/if:interface</target>
=A0 = =A0 </get-list>
=A0 </rpc>

<= br>
=A0 <rpc-reply>
=A0 =A0 =A0<data>
=A0 =A0 =A0 =A0 <interfaces>
=A0 =A0 =A0 =A0 =A0 =A0<interface> =A0 .... first entry <= /interface>
=A0 =A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 = =A0 =A0 =A0<interface> =A0 .... 25th entry </interface>
=A0 =A0 =A0 =A0 </interfaces>
=A0 =A0 =A0</da= ta>
=A0 </rpc-reply>


=
=A0 =A0<rpc>
=A0 =A0 <get-list>
=A0 = =A0 =A0 <target>/if:interfaces/if:interface</target>
=A0 =A0 =A0 <start>25</start>
=A0 =A0 </get-l= ist>
=A0 </rpc>


= =A0 <rpc-reply>
=A0 =A0 =A0<data>
=A0 =A0 = =A0 =A0 <interfaces>
=A0 =A0 =A0 =A0 =A0 =A0<interface> =A0 .... 26th entry </inte= rface>
=A0 =A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 = =A0 =A0<interface> =A0 .... 50th entry </interface>
=A0 =A0 =A0 =A0 </interfaces>
=A0 =A0 =A0</data>
=A0 </rpc-reply>


There is a problem with rapidly changing lists
(could get repeat entries on miss some entries), but the snap= shot
approach uses too much memory, and if the list instances
change rapidly, a stale snapshot is not very useful.


Andy





The other questio= ns and comments are listed below:
1. Get-bloc= k capability should not change the get-config operation's behavior. If = client use get-config operation to retrieve data,
all dat= a must be sent in one response or get-block capability should add a paramet= er to get-config operation to indicate the=A0
re= sponse data will be fragmented.
2. A set-id can be aged? when= client never send a request to retrieve the next fragment for a long time,= I think this set-id should be aged,
oth= erwise, server will be reserve more and more set-ids.
<= div> 3. A se= t-id is unique in session level or server level?
4. If = a session is killed or closed, other session can retrieved the next fragmen= t if the client provide the correct set-id?
/f= rank


2014-06-04 18:22 GMT+08:00 Liubing (Leo) <leo.liubin= g@huawei.com>:
Hi all,

We've posted a new draft, which is about NETCONF data fragmentation.
The basic idea is, when NMS is retrieving a large size of data in the devic= e, the <rpc-reply> might be very big (e.g. the routes in a core route= r).
Currently there are mainly two methods of handling the big <rpc-reply>= ;: one is stream-oriented handling; the other is just request a portion of = the data.

This draft considers both the two methods are problematic in some situation= s, and proposes a new method which allows the large size <rpc-reply> = to be fragmented in NETCONF level.

Please read the draft and comment.
Many thanks!

Best regards,
Bing

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, June 04, 2014 5:27 PM
To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying
Subject: New Version Notification for draft-liu-netconf-fragmentation-00.tx= t


A new version of I-D, draft-liu-netconf-fragmentation-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name: =A0 =A0 =A0 =A0 =A0 draft-liu-netconf-fragmentation
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0A NETCONF Extension for Data Fragmentation
Document date: =A02014-06-04
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A012
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.o= rg/internet-drafts/draft-liu-netconf-fragmentation-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/d= oc/draft-liu-netconf-fragmentation/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-liu= -netconf-fragmentation-00


Abstract:
=A0 =A0This document introduces an extension to NETCONF (Network
=A0 =A0Configuration) protocol. The extension allows NETCONF to handle larg= e
=A0 =A0size data as fragmented RPC messages. Specifically, this document =A0 =A0defines a new <get-block> capability and relevant operations t= o
=A0 =A0handle the fragmentations.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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


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


--001a11c126baff568304fb05525e-- From nobody Wed Jun 4 10:37:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9389A1A032E for ; Wed, 4 Jun 2014 10:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMLmbiplecAi for ; Wed, 4 Jun 2014 10:37:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2801A0306 for ; Wed, 4 Jun 2014 10:37:15 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 4 Jun 2014 17:37:07 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) with mapi id 15.00.0949.001; Wed, 4 Jun 2014 17:37:07 +0000 From: Kent Watsen To: Andy Bierman , Boris Pilka Thread-Topic: [Netconf] Should Default Event Stream contain really all the notifications ? Thread-Index: AQHPf/Wst9fUvt4Fekut84FjcjIKLJthIcSA///Sc4A= Date: Wed, 4 Jun 2014 17:37:07 +0000 Message-ID: References: <538F178E.6060400@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(164054003)(199002)(189002)(74662001)(99286001)(4396001)(31966008)(2656002)(76482001)(81542001)(92726001)(99396002)(92566001)(77982001)(83322001)(46102001)(87936001)(50986999)(85852003)(83072002)(80022001)(81342001)(20776003)(101416001)(74502001)(54356999)(21056001)(79102001)(36756003)(64706001)(83506001)(66066001)(76176999)(16236675002)(86362001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: multipart/alternative; boundary="_000_CFB4CF3474A1Ckwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Ii86fvvXvRfCih-st7Y5p08HPNo Cc: Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:37:19 -0000 --_000_CFB4CF3474A1Ckwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does the section above suggests, that notifications from all 20 streams sho= uld be also be sent in a NETCONF stream ? > No, but this probably needs clarification. [KENT] really? I always thought that "all" meant "all"? Wasn't the motiv= ation to guarantee access all the events? > The standard notifications defined in YANG (e.g., RFC 6470) > are expected to show up on the NETCONF stream. You can put whatever > content on whatever stream you want, but for standard notification defini= tions, > they must at (at least) be in the NETCONF stream. [KENT] Right, assuming the server advertises "ietf-netconf-notifications"..= . Thanks, Kent --_000_CFB4CF3474A1Ckwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Does the section above suggests, that notifications from all 20 streams sho= uld be also be sent in a NETCONF stream ?


> No, but this probably needs clarification.

[KENT] really?  I always thought that "all" meant "= ;all"?   Wasn't the motivation to guarantee access all the events= ?


> The standard notifications defined in YANG (e.g., RFC 6470)
> are expected to show up on the NETCONF stream.  You can put = whatever
> content on whatever stream you want, but for standard notificatio= n definitions,
> they must at (at least) be in the NETCONF stream.

[KENT] Right, assuming the server advertises "ietf-netconf-notifi= cations"...
Tha= nks,
Ken= t

--_000_CFB4CF3474A1Ckwatsenjunipernet_-- From nobody Wed Jun 4 10:58:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58091A02B7 for ; Wed, 4 Jun 2014 10:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLnvDXEpAtBu for ; Wed, 4 Jun 2014 10:58:09 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7221A0254 for ; Wed, 4 Jun 2014 10:58:09 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j15so7588255qaq.9 for ; Wed, 04 Jun 2014 10:58:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gQhnjub2JvozzZI6EhXaEPjMGXlWE942k4NPesUxeIM=; b=OxO3W2VIpjkVp8BTr7Hyk/hebGwe72s48X14QDN0iB+7TlrnttzUApkBPHesk7QFLO 9ISi6WTE3wYFPNfw0/yPyzVvCJzi9oUmgaI3w7Tf1lE0x0kih51QAOk3UCb/UbkNVaRA ibQUX/e4ZuLOfvG1nIiguzU5kA8uy1rhjKOHhCCQzTgICY3Kz6pUxPGUHGjR1d+KfcCT TbGm5jiWlf+8CMF+kT6Q7YLEil80+7CyTCOIEsvYcN2kwSY2jB+Wevf3fJQZoXF2fpN+ /yjjawXE68rU01FUXBsuh7bt1L6MN/u0OoKE1bOPdehknaIjBcM/QwRng8e668tvvZuG 7h5g== X-Gm-Message-State: ALoCoQmmZw03QV9Ll2dhzr5HyJZ97Sge/vfYc/4TUT9F+Bf3lSCBremCeYbqyTV1qebpWTY+EhC6 MIME-Version: 1.0 X-Received: by 10.224.24.134 with SMTP id v6mr9017891qab.88.1401904682981; Wed, 04 Jun 2014 10:58:02 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 4 Jun 2014 10:58:02 -0700 (PDT) In-Reply-To: References: <538F178E.6060400@cisco.com> Date: Wed, 4 Jun 2014 10:58:02 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c252c6a3974104fb065e78 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Uzlv4JNQcFp7v4QtsDggqa-f2W0 Cc: Boris Pilka , Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:58:11 -0000 --001a11c252c6a3974104fb065e78 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 4, 2014 at 10:37 AM, Kent Watsen wrote: > > Does the section above suggests, that notifications from all 20 >> streams should be also be sent in a NETCONF stream ? >> >> > > No, but this probably needs clarification. > > [KENT] really? I always thought that "all" meant "all"? Wasn't the > motivation to guarantee access all the events? > > This stream contains all NETCONF XML event notifications supported by the NETCONF server. It says "NETCONF XML". Does this imply that a SYSLOG text stream also needs to be wrapped in XML and sent as a element on the NETCONF stream? I hope not. Probably needs clarification. ;-) Andy > > The standard notifications defined in YANG (e.g., RFC 6470) > > are expected to show up on the NETCONF stream. You can put whatever > > content on whatever stream you want, but for standard notification > definitions, > > they must at (at least) be in the NETCONF stream. > > [KENT] Right, assuming the server advertises > "ietf-netconf-notifications"... > > I was pointing out that the RFC explicitly requires NETCONF stream support. I suppose all YANG notification-stmts advertised by the NETCONF server need to be in the NETCONF stream. > Thanks, > Kent > > > Andy --001a11c252c6a3974104fb065e78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 10:37 AM, Kent Watsen <= kwatsen@juniper.ne= t> wrote:

Does the section above suggests, that notifications from all 20 streams sho= uld be also be sent in a NETCONF stream ?


> No, but this probably needs clarification.

[KENT] really? =A0I always thought that "all" meant "al= l"? =A0 Wasn't the motivation to guarantee access all the events?<= /div>


=A0 =A0This stream contains all NETCONF X= ML event notifications supported by
=A0 =A0the= NETCONF server. =A0

It says "NETCONF = XML".
Does this imply that a SYSLOG text stream also needs t= o be wrapped in XML
and sent as a <notification> element on the NETCONF stream? =A0I= hope not.

Probably needs clarification. ;-)
=


Andy



> The standard notifications defined in YANG (e.g., RFC 6470)
> are expected to show up on the NETCONF stream. =A0You can put wha= tever
> content on whatever stream you want, but for standard notificatio= n definitions,
> they must at (at least) be in the NETCONF stream.

[KENT] Right, assuming the server advertises "ietf-netconf-notifi= cations"...


I was pointing out that the= RFC explicitly requires NETCONF stream support.
I suppose all YA= NG notification-stmts advertised by the NETCONF server
need to be in the NETCONF stream.

=A0
Thanks,<= /span>
Kent



Andy

--001a11c252c6a3974104fb065e78-- From nobody Wed Jun 4 11:30:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324231A02F8 for ; Wed, 4 Jun 2014 11:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzVC1FUUk5wG for ; Wed, 4 Jun 2014 11:30:10 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201461A02E1 for ; Wed, 4 Jun 2014 11:30:09 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id w61so8779976wes.26 for ; Wed, 04 Jun 2014 11:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WiyV66MpTfxqcIaQNqb6EO6AlQpENv5LDs80fdd92IQ=; b=HlqZqtUK09WDkG7NWdyOmUw48ximX8+5grpwxhA0P+OTCW5obU4ZD90NS6D5iTjHTq 3hx752F70RSaqKhWmyy+b6a9sbO8yTU5ilc8fgxYVpp1ApCBKvYBgjd0+guFOCiCHPD7 YWfR2JShq7BaneJx9UUSK9RyfinsyfZWAqrufDWLuqyYRnnhBG4Uu/L3hm1La/M5xnjx d7CkdpkOq+ruLG/I/BeHM8h6+zm67u6G4Ua/zuGfjfM0LBsWekd/sDE3FAh80y99vNfi gEr1TbKaaGVNI2EoBn5rT/iN/iP9Ltz4xT2GLKGdf6x3ggEjbicf8JmGkSnD2lO7Tw6u Q/aQ== X-Received: by 10.15.34.4 with SMTP id d4mr3123636eev.51.1401906603016; Wed, 04 Jun 2014 11:30:03 -0700 (PDT) Received: from [10.61.221.89] (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id p9sm7718648eeg.32.2014.06.04.11.30.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 11:30:01 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Giles Heron In-Reply-To: Date: Wed, 4 Jun 2014 19:30:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <538F178E.6060400@cisco.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/LL8AOehaTLkH9iqrXZ6lxrrqw7Q Cc: Boris Pilka , Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 18:30:12 -0000 Hi Andy, On 4 Jun 2014, at 18:58, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jun 4, 2014 at 10:37 AM, Kent Watsen = wrote: >=20 > Does the section above suggests, that notifications from all 20 = streams should be also be sent in a NETCONF stream ? >=20 >=20 > > No, but this probably needs clarification. >=20 > [KENT] really? I always thought that "all" meant "all"? Wasn't the = motivation to guarantee access all the events? >=20 >=20 > This stream contains all NETCONF XML event notifications supported = by > the NETCONF server. =20 >=20 > It says "NETCONF XML". > Does this imply that a SYSLOG text stream also needs to be wrapped in = XML > and sent as a element on the NETCONF stream? I hope = not. agreed. but would you ever send a syslog text stream in using NETCONF = notifications? I thought all NETCONF notifications were XML-formatted? = So if you were sending SYSLOG over NETCONF presumably you'd wrap it in = XML first? So then it'd be "NETCONF XML" :) > Probably needs clarification. ;-) >=20 yup. Giles >=20 > Andy >=20 >=20 >=20 > > The standard notifications defined in YANG (e.g., RFC 6470) > > are expected to show up on the NETCONF stream. You can put whatever > > content on whatever stream you want, but for standard notification = definitions, > > they must at (at least) be in the NETCONF stream. >=20 > [KENT] Right, assuming the server advertises = "ietf-netconf-notifications"... >=20 >=20 > I was pointing out that the RFC explicitly requires NETCONF stream = support. > I suppose all YANG notification-stmts advertised by the NETCONF server > need to be in the NETCONF stream. >=20 > =20 > Thanks, > Kent >=20 >=20 >=20 > Andy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jun 4 11:31:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731731A02E1 for ; Wed, 4 Jun 2014 11:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wljb4hpRFtp for ; Wed, 4 Jun 2014 11:31:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18541A031B for ; Wed, 4 Jun 2014 11:31:21 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 4 Jun 2014 18:31:13 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) with mapi id 15.00.0949.001; Wed, 4 Jun 2014 18:31:13 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] Should Default Event Stream contain really all the notifications ? Thread-Index: AQHPf/Wst9fUvt4Fekut84FjcjIKLJthIcSA///Sc4CAAEjrAP//xjOA Date: Wed, 4 Jun 2014 18:31:12 +0000 Message-ID: References: <538F178E.6060400@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(51704005)(66066001)(81342001)(92726001)(74662001)(86362001)(50986999)(93886002)(16236675002)(36756003)(80022001)(87936001)(101416001)(31966008)(99396002)(77982001)(83322001)(85852003)(4396001)(21056001)(46102001)(74502001)(99286001)(83506001)(81542001)(20776003)(76176999)(64706001)(79102001)(2656002)(54356999)(92566001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: multipart/alternative; boundary="_000_CFB4DBCD74A6Dkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1i4V_6gfCDv9DUEfL4RK12KmXuo Cc: Boris Pilka , Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 18:31:24 -0000 --_000_CFB4DBCD74A6Dkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. > > It says "NETCONF XML". > Does this imply that a SYSLOG text stream also needs to be wrapped in XML > and sent as a element on the NETCONF stream? I hope not. My interpretation is that the NETCONF stream contains all notifications def= ined by all YANG modules advertised by the device. Only problem is the R= FC5277 doesn't mention YANG anywhere... That reading would exclude SYSLOG messages, thankfully. > Probably needs clarification. ;-) Right, e.g., what is "NETCONF XML" ? --_000_CFB4DBCD74A6Dkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <23654E1A977EB542AB03629EF085E49D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
>    This stream contains all NETCONF XML event notificat= ions supported by
>    the NETCONF server.  
>
> It says "NETCONF XML".
> Does this imply that a SYSLOG text stream also needs to be wrappe= d in XML
> and sent as a <notification> element on the NETCONF stream?=  I hope not.

My interpretation is that the NETCONF stream contains all notification= s defined by all YANG modules advertised by the device.    Only p= roblem is the RFC5277 doesn't mention YANG anywhere...

That reading would exclude SYSLOG messages, thankfully.


> Probably needs clarification. ;-)

Right, e.g., what is "NETCONF XML" ?


--_000_CFB4DBCD74A6Dkwatsenjunipernet_-- From nobody Wed Jun 4 12:42:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288F31A0262 for ; Wed, 4 Jun 2014 12:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpiIphGPKork for ; Wed, 4 Jun 2014 12:42:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8981A026B for ; Wed, 4 Jun 2014 12:42:11 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id C53941280DB8; Wed, 4 Jun 2014 21:41:08 +0200 (CEST) Date: Wed, 04 Jun 2014 21:42:03 +0200 (CEST) Message-Id: <20140604.214203.11301501.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <538F178E.6060400@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/BrubETMzLQFqWFQjxBAiedlYGfg Cc: bpilka@cisco.com, netconf@ietf.org Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:42:19 -0000 Andy Bierman wrote: > On Wed, Jun 4, 2014 at 5:56 AM, Boris Pilka wrote: > > > Hi, > > > > could you, please, clarify the following for me: > > > > RFC5277 section 3.2.3. > > 'A NETCONF server implementation supporting the notification > > capability MUST support the "NETCONF" notification event stream. > > This stream contains all NETCONF XML event notifications supported by > > the NETCONF server. The exact string "NETCONF" is used during the > > advertisement of stream support during the operation on > > and during the operation. Definition > > of the event notifications and their contents, beyond the inclusion > > of , for this event stream is outside the scope of this > > document.' > > > > Imagine 20 streams being present on Netconf Server apart from NETCONF > > stream. > > > > > kind of hard, unless you are adding filtering into the stream definition. > > > > Does the section above suggests, that notifications from all 20 streams > > should be also be sent in a NETCONF stream ? > > > > > No, but this probably needs clarification. > The standard notifications defined in YANG (e.g., RFC 6470) > are expected to show up on the NETCONF stream. RFC 6470 is explicit about this: This module defines the following notifications for the 'NETCONF' stream ... > You can put whatever > content on whatever stream you want, but for standard notification > definitions, > they must at (at least) be in the NETCONF stream. There's nothing in 6020 that says in which stream a YANG-defined notification is sent. I don't agree that all YANG-defined notifications MUST be sent over the "NETCONF" stream. I do agree that this text in 5277 is unclear: This stream contains all NETCONF XML event notifications supported by the NETCONF server /martin From nobody Wed Jun 4 13:38:39 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B061A02F0 for ; Wed, 4 Jun 2014 13:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjjSecY-k1bT for ; Wed, 4 Jun 2014 13:38:36 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA7D1A0024 for ; Wed, 4 Jun 2014 13:38:35 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id j5so78379qga.14 for ; Wed, 04 Jun 2014 13:38:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I9ke3TZBYbIEvcaI7ajKZsMgY4YHiDecVnx2X7wJzjY=; b=XiV09eMBOJQYqOm+JdbZ8qEvOdGb5TA0K74e89hvJIONoPUOLW9MTi1f+AAXkUhcJH LxQN6F72b/jSRCqjq6Sv/9MjMhaUMq5PD0zJGoK+/HpdUL1zzl3H8tcRRZss1lUwzpFS hsL7bRqTgJhTlujFD6fmMEMZSg889jaPC33JtKiIK8mjKXF5dQMh67KdiEoNx79eBtaz aAkUoUUgeIpSBJjtuO1KAoB/mpVtNgm9U/AJbXbqn6a8Bz7OlOBTxA9+IlJiwZUJrqpB OUUyXwsqYfjhpWMmRPztOqSNdMiCTeRd7RCBGD+EF797yTUfdCjfYg7Kp1lq1hlnph4O wNZA== X-Gm-Message-State: ALoCoQmtwX9sMcEzfEQMGVT5VYBt6xdSY0eDi0iEczoZ6Dkago7Totz7PsDJ1gu6khaFoOPKx1KM MIME-Version: 1.0 X-Received: by 10.224.79.198 with SMTP id q6mr10286679qak.99.1401914309472; Wed, 04 Jun 2014 13:38:29 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 4 Jun 2014 13:38:29 -0700 (PDT) In-Reply-To: <20140604.214203.11301501.mbj@tail-f.com> References: <538F178E.6060400@cisco.com> <20140604.214203.11301501.mbj@tail-f.com> Date: Wed, 4 Jun 2014 13:38:29 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bdca5da6c0e4504fb089c38 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pmSsz5_9TZ1qBERYGLEb1PClOGw Cc: Boris Pilka , Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:38:38 -0000 --047d7bdca5da6c0e4504fb089c38 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 4, 2014 at 12:42 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Jun 4, 2014 at 5:56 AM, Boris Pilka wrote: > > > > > Hi, > > > > > > could you, please, clarify the following for me: > > > > > > RFC5277 section 3.2.3. > > > 'A NETCONF server implementation supporting the notification > > > capability MUST support the "NETCONF" notification event stream. > > > This stream contains all NETCONF XML event notifications supported > by > > > the NETCONF server. The exact string "NETCONF" is used during the > > > advertisement of stream support during the operation on > > > and during the operation. > Definition > > > of the event notifications and their contents, beyond the inclusion > > > of , for this event stream is outside the scope of this > > > document.' > > > > > > Imagine 20 streams being present on Netconf Server apart from NETCONF > > > stream. > > > > > > > > kind of hard, unless you are adding filtering into the stream definition. > > > > > > > Does the section above suggests, that notifications from all 20 streams > > > should be also be sent in a NETCONF stream ? > > > > > > > > No, but this probably needs clarification. > > The standard notifications defined in YANG (e.g., RFC 6470) > > are expected to show up on the NETCONF stream. > > RFC 6470 is explicit about this: > > This module defines the following notifications for the 'NETCONF' > stream ... > > So you are suggesting the RFC that defines the notification-stmts should decide the appropriate streams? OK > > You can put whatever > > content on whatever stream you want, but for standard notification > > definitions, > > they must at (at least) be in the NETCONF stream. > > There's nothing in 6020 that says in which stream a YANG-defined > notification is sent. I don't agree that all YANG-defined > notifications MUST be sent over the "NETCONF" stream. > > OK -- but each RFC that defines any notifications MUST be explicit about which streams are mandatory to support. (we only have 1 to choose from now but that may not be true forever). > I do agree that this text in 5277 is unclear: > > This stream contains all NETCONF XML event notifications supported > by the NETCONF server > > It certainly does suggest all notifications sent in the NETCONF protocol that are encoded in XML. As pointed out, that could all of them since the element encoded in XML is the only official message allowed. A NETCONF notification has to conform to this XSD: The time the event was generated by the event source. Note the child element followed by a single element that conforms to the "notificationContent" complex type? notification foo; ... .... could be anything; empty, string, or complex node All notifications from any stream could conform to this schema. But what is the intent of the NETCONF WG wrt/ usage of streams? My recollection is that for other usage "syslog" was used as the use-case, but never actually defined in any way. There is no intent to create duplicate events (I hope). If 2 streams are just different encodings (of the element) then it makes no sense to add them to the NETCONF stream. It would be nice if the client had some way of knowing what notification events to expect on which stream (after parsing all the YANG modules in the server message). Without further notification work, IMO the "all" means everything. There is only 1 standard stream. Until there are more than 1, any new standards work would just constrain vendors. > > /martin > > Andy --047d7bdca5da6c0e4504fb089c38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 12:42 PM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <and= y@yumaworks.com> wrote:
> On Wed, Jun 4, 2014 at 5:56 AM, Boris Pilka <bpilka@cisco.com> wrote:
>
> > Hi,
> >
> > could you, please, clarify the following for me:
> >
> > RFC5277 section 3.2.3.
> > 'A NETCONF server implementation supporting the notification<= br> > > =A0 =A0capability MUST support the "NETCONF" notificati= on event stream.
> > =A0 =A0This stream contains all NETCONF XML event notifications s= upported by
> > =A0 =A0the NETCONF server. =A0The exact string "NETCONF"= ; is used during the
> > =A0 =A0advertisement of stream support during the <get> ope= ration on
> > =A0 =A0<streams> and during the <create-subscription>= operation. =A0Definition
> > =A0 =A0of the event notifications and their contents, beyond the = inclusion
> > =A0 =A0of <eventTime>, for this event stream is outside the= scope of this
> > =A0 =A0document.'
> >
> > Imagine 20 streams being present on Netconf Server apart from NET= CONF
> > stream.
> >
> >
> kind of hard, unless you are adding filtering into the stream definiti= on.
>
>
> > Does the section above suggests, that notifications from all 20 s= treams
> > should be also be sent in a NETCONF stream ?
> >
> >
> No, but this probably needs clarification.
> The standard notifications defined in YANG (e.g., RFC 6470)
> are expected to show up on the NETCONF stream.

RFC 6470 is explicit about this:

=A0 =A0This module defines the following notifications for the 'NETCONF= '
=A0 =A0stream ...


So you are suggesting the RFC that def= ines the notification-stmts
should decide the appropriate streams= ? =A0OK

=A0
> You can put whatever
> content on whatever stream you want, but for standard notification
> definitions,
> they must at (at least) be in the NETCONF stream.

There's nothing in 6020 that says in which stream a YANG-defined
notification is sent. =A0I don't agree that all YANG-defined
notifications MUST be sent over the "NETCONF" stream.



OK -- but each RFC that= defines any notifications MUST be explicit about
which streams a= re mandatory to support. =A0(we only have 1 to choose from now
but that may not be true forever).

=A0
I do agree that this text in 5277 is unclear:

=A0 This stream contains all NETCONF XML event notifications supported
=A0 by the NETCONF server



It certainly does suggest all notifications= sent in the NETCONF protocol
that are encoded in XML. =A0As poin= ted out, that could all of them
since the <notification> element encoded in XML is the only offi= cial message
allowed.

A NETCONF notifica= tion has to conform to this XSD:



     <!-- <Notification> operation -->
     <xs:complexType name=3D"NotificationContentType"/>

    <xs:element name=3D"notificationContent"
        type=3D"NotificationContentType" abstract=3D"true&qu=
ot;/>

    <xs:complexType name=3D"NotificationType">
        <xs:sequence>
            <xs:element name=3D"eventTime" type=3D"xs:dat=
eTime">
              <xs:annotation>
                <xs:documentation>
                The time the event was generated by the event source.
                </xs:documentation>
              </xs:annotation>
            </xs:element>
            <xs:element ref=3D"notificationContent"/>
        </xs:sequence>
    </xs:complexType>

    <xs:element name=3D"notification" type=3D"Notificatio=
nType"/>

Note the child <eventTime> element fol= lowed by a single element that
conforms to the "notificationContent" complex type?

=A0 notification foo;

=A0 <not= ification>
=A0 =A0 =A0<eventTime>...</eventTime>
=A0 =A0 =A0<foo>
=A0 =A0 =A0 =A0 .... could be anything; em= pty, string, or complex node
=A0 =A0 =A0</foo>
= =A0 </notification>


All notif= ications from any stream could conform to this schema.
But what is the intent of the NETCONF WG wrt/ usage of streams?
<= div>My recollection is that for other usage =A0"syslog" was used = as the
use-case, but never actually defined in any way.

There is no intent to create duplicate events (I hope).
If 2 streams are just different encodings (of the <foo> element= )
then it makes no sense to add them to the NETCONF stream.
It would be nice if the client had some way of knowing what
= notification events to expect on which stream (after parsing all
= the YANG modules in the server <hello> message).

Without further notification work, IMO the "all" means every= thing.
There is only 1 standard stream. Until there are more than= 1,
any new standards work would just constrain vendors.


=A0

/martin


Andy<= /div>

--047d7bdca5da6c0e4504fb089c38-- From nobody Wed Jun 4 18:00:11 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73601A03E6; Wed, 4 Jun 2014 18:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.6 X-Spam-Level: X-Spam-Status: No, score=-96.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTH6kC7gQS1j; Wed, 4 Jun 2014 18:00:04 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 90B711A03DB; Wed, 4 Jun 2014 18:00:03 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id E2BA514EB4F5; Thu, 5 Jun 2014 08:59:47 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id A4E6DCC73A4; Thu, 5 Jun 2014 08:59:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s550xiEc074323; Thu, 5 Jun 2014 08:59:44 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> To: Andy Bierman MIME-Version: 1.0 X-KeepSent: 2D55619C:083DFE8D-48257CEE:0004A77E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Thu, 5 Jun 2014 08:59:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-05 08:59:45, Serialize complete at 2014-06-05 08:59:45 Content-Type: multipart/alternative; boundary="=_alternative 000577C048257CEE_=" X-MAIL: mse01.zte.com.cn s550xiEc074323 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/PtQoseP_aCnm4_zhkhOxCIUymv4 Cc: Zhengguangying , Netconf , Netconf , Yangang Subject: [Netconf] =?gb2312?b?tPC4tDogUmU6ICBOZXRjb25mIGZyYWdtZW50YXRpb24t?= =?gb2312?b?Ly9GVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUt?= =?gb2312?b?bmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA==?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 01:00:09 -0000 This is a multipart message in MIME format. --=_alternative 000577C048257CEE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 YW5keSwNCiAgIEhvdyB0byBwcm9jZXNzIG5lc3RlZCBsaXN0cyB1c2luZyB5b3VyIHNvbHV0aW9u Pw0KIA0KRm9yIGV4YW1wbGU6DQogICBsaXN0IGZvbyB7DQogICAgICAga2V5IGE7DQogICAgICAg bGVhZiBhIHsuLi59DQogICAgICAgbGVhZiBiIHsuLi59DQogICAgICAgbGlzdCBuZXN0ZWQtZm9v IHsNCiAgICAgICAgICAgIGtleSBuZXN0ZWQtYTsNCiAgICAgICAgICAgIGxlYWYgbmVzdGVkLWEg ey4uLn0NCiAgICAgICAgICAgIGxlYWYgbmV0c3RlZC1iIHsuLi59DQogICAgICAgfQ0KICAgfQ0K DQogIElmIHJlcXVlc3QgaXM6DQogIDxycGM+DQogICAgIDxnZXQtbGlzdD4NCiAgICAgICA8dGFy Z2V0Pi9mb288L3RhcmdldD4NCiAgICAgPC9nZXQtbGlzdD4NCiAgIDwvcnBjPiANCiAgV2hhdCBp cyB0aGUgcmVzcG9uc2U/DQoNCkFuZCwgYW5vdGhlciBxdWVzdGlvbjoNClN0YXJ0LWluZGV4IGlz IG5vdCByZWxpYWJsZSwgaWYgc29tZSBlbnRyaWVzIGFyZSBkZWxldGVkLiBJIHRoaW5rIHlvdSBj YW4gDQp1c2Ugc3RhcnQga2V5IGluc3RlYWQuDQoNCg0KDQovZnJhbmsNCg0KIk5ldGNvbmYiIDxu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+INC009ogMjAxNC0wNi0wNSAwMDo0MzoxMjoNCg0KPiBB bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gDQo+ILeivP7IyzogICJOZXRjb25mIiA8 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPg0KPiANCj4gMjAxNC0wNi0wNSAwMDo0Mw0KPiANCj4g ytW8/sjLDQo+IA0KPiBjaG9uZyBmZW5nIDxmZW5nY2hvbmdsbGx5QGdtYWlsLmNvbT4sIA0KPiAN Cj4gs63LzQ0KPiANCj4gWmhlbmdndWFuZ3lpbmcgPHpoZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb20+ LCBOZXRjb25mIA0KPiA8bmV0Y29uZkBpZXRmLm9yZz4sIFlhbmdhbmcgPHlhbmdhbmdAaHVhd2Vp LmNvbT4NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbTmV0Y29uZl0gTmV0Y29uZiBmcmFnbWVudGF0 aW9uLS8vRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiANCj4gZm9yIGRyYWZ0LWxpdS1uZXRj b25mLWZyYWdtZW50YXRpb24tMDAudHh0DQo+IA0KPiANCg0KPiBPbiBXZWQsIEp1biA0LCAyMDE0 IGF0IDg6MzIgQU0sIGNob25nIGZlbmcgPGZlbmdjaG9uZ2xsbHlAZ21haWwuY29tPiANCndyb3Rl Og0KPiBIaSwNCj4gICAgSSBoYXZlIHJldmlld2VkIHRoaXMgbmV3IGRyYWZ0Lg0KPiAgICBJIHVu ZGVyc3RhbmQgeW91ciBzb2x1dGlvbiBpcyB0aGF0IE5FVENPTkYgc2VydmVyIHJlc2VydmUgYnJl YWsgDQo+IHBvaW50cyBhbmQgd2FpdCBmb3IgY2xpZW50IHRvIHJldHJpZXZlIHRoZSBuZXh0IHJl c3BvbnNlLg0KPiBJIHRoaW5rIGl0J3Mgbm90IGEgZ29vZCBzb2x1dGlvbiwgYmVjYXVzZSBzZXJ2 ZXIgbWF5IG5lZWQgdG8gcmVzZXJ2ZQ0KPiBtYW55IGJyZWFrIHBvaW50cyBpZiB0aGVyZSBhIGxh cmdlIG51bWJlciBvZiBjb25jdXJyZW50IHJlcXVlc3RzLg0KPiBJdCdzIHRvbyBoZWF2eSBmb3Ig c2VydmVyLiBBbmQsIHRoZSBzZXJ2ZXIgbXVzdCBiZSBzdGF0ZWZ1bCBpZiBpdCANCj4gc3VwcG9y dCBnZXQtYmxvY2sgY2FwYWJpbGl0eS4NCj4gIA0KPiANCj4gSSBhZ3JlZSB3aXRoIHRoZXNlIGNv bmNlcm5zLiAgSG9sZGluZyBhIHNuYXBzaG90IG9mIHN0YXRlIGRhdGEgZm9yIA0KPiBpbnRlcmFj dGl2ZSByZXRyaWV2YWwNCj4gYnkgdGhlIGNsaWVudCBpcyB2ZXJ5IGV4cGVuc2l2ZS4gDQo+IA0K PiBJIGRvIG5vdCBhZ3JlZSB3aXRoIHRoZSBwcmVtaXNlIHRoYXQgdGhlIGNsaWVudCBuZWVkcyB0 byBrbm93IHRoZSANCj4ga2V5IHZhbHVlcyBpbiBhZHZhbmNlLg0KPiBBbiAiaXRlcmF0b3IiIGFw cHJvYWNoIGFsbG93cyBhIGxpc3QgcmVzb3VyY2UgdG8gYmUgcmV0cmlldmVkIGluIA0KPiBjaHVu a3MuICBUaGlzIGlzIHdoYXQgUkVTVENPTkYNCj4gaXMgZ29pbmcgdG8gZG8sIGFuZCBORVRDT05G IGNvdWxkIGFkZCBhIHNpbWlsYXIgUlBDIGZ1bmN0aW9uOg0KPiANCj4gICAgcnBjIGdldC1saXN0 IHsNCj4gICAgICBpbnB1dCB7DQo+ICAgICAgICBsZWFmIHRhcmdldCB7DQo+ICAgICAgICAgICB0 eXBlIHNjaGVtYS1pbnN0YW5jZS1pZGVudGlmaWVyOw0KPiAgICAgICAgICAgZGVzY3JpcHRpb24g IklkZW50aWZpZXMgc3VidHJlZSB0byByZXRyaWV2ZS4iOw0KPiAgICAgICB9DQo+ICAgICAgIGxl YWYgc3RhcnQgew0KPiAgICAgICAgICB0eXBlIHVpbnQzMjsNCj4gICAgICAgICAgZGVmYXVsdCAw Ow0KPiAgICAgICAgICBkZXNjcmlwdGlvbiAiTnVtYmVyIG9mIGVudHJpZXMgdG8gc2tpcCBiZWZv cmUgc3RhcnRpbmcgDQpyZXRyaWV2YWwiOw0KPiAgICAgICB9DQo+ICAgICAgIGxlYWYgbWF4LWVu dHJpZXMgew0KPiAgICAgICAgIHR5cGUgdWludDMyIHsgcmFuZ2UgIjEuLm1heCI7IH0NCj4gICAg ICAgICBkZWZhdWx0IDI1Ow0KPiAgICAgICAgIGRlc2NyaXB0aW9uICJNYXhpbXVtIG51bWJlciBv ZiBsaXN0IGVudHJpZXMgdG8gcmV0cmlldmUiOw0KPiAgICAgICB9DQo+ICAgICB9DQo+ICAgICBv dXRwdXQgew0KPiAgICAgICAgYW55eG1sIGRhdGEgew0KPiAgICAgICAgICAgZGVzY3JpcHRpb24g IkNvbnRhaW5zIHRoZSByZXF1ZXN0ZWQgZGF0YSI7DQo+ICAgICAgICB9DQo+ICAgICB9DQo+ICAg fQ0KPiANCj4gICA8cnBjPg0KPiAgICAgPGdldC1saXN0Pg0KPiAgICAgICA8dGFyZ2V0Pi9pZjpp bnRlcmZhY2VzL2lmOmludGVyZmFjZTwvdGFyZ2V0Pg0KPiAgICAgPC9nZXQtbGlzdD4NCj4gICA8 L3JwYz4NCj4gDQo+ICAgPHJwYy1yZXBseT4NCj4gICAgICA8ZGF0YT4NCj4gICAgICAgICA8aW50 ZXJmYWNlcz4NCj4gICAgICAgICAgICA8aW50ZXJmYWNlPiAgIC4uLi4gZmlyc3QgZW50cnkgPC9p bnRlcmZhY2U+DQo+ICAgICAgICAgICAgLi4uDQo+ICAgICAgICAgICAgPGludGVyZmFjZT4gICAu Li4uIDI1dGggZW50cnkgPC9pbnRlcmZhY2U+DQo+ICAgICAgICAgPC9pbnRlcmZhY2VzPg0KPiAg ICAgIDwvZGF0YT4NCj4gICA8L3JwYy1yZXBseT4NCj4gDQo+ICAgIDxycGM+DQo+ICAgICA8Z2V0 LWxpc3Q+DQo+ICAgICAgIDx0YXJnZXQ+L2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlPC90YXJn ZXQ+DQo+ICAgICAgIDxzdGFydD4yNTwvc3RhcnQ+DQo+ICAgICA8L2dldC1saXN0Pg0KPiAgIDwv cnBjPg0KPiANCj4gICA8cnBjLXJlcGx5Pg0KPiAgICAgIDxkYXRhPg0KPiAgICAgICAgIDxpbnRl cmZhY2VzPg0KPiAgICAgICAgICAgIDxpbnRlcmZhY2U+ICAgLi4uLiAyNnRoIGVudHJ5IDwvaW50 ZXJmYWNlPg0KPiAgICAgICAgICAgIC4uLg0KPiAgICAgICAgICAgIDxpbnRlcmZhY2U+ICAgLi4u LiA1MHRoIGVudHJ5IDwvaW50ZXJmYWNlPg0KPiAgICAgICAgIDwvaW50ZXJmYWNlcz4NCj4gICAg ICA8L2RhdGE+DQo+ICAgPC9ycGMtcmVwbHk+DQo+IA0KPiBUaGVyZSBpcyBhIHByb2JsZW0gd2l0 aCByYXBpZGx5IGNoYW5naW5nIGxpc3RzDQo+IChjb3VsZCBnZXQgcmVwZWF0IGVudHJpZXMgb24g bWlzcyBzb21lIGVudHJpZXMpLCBidXQgdGhlIHNuYXBzaG90DQo+IGFwcHJvYWNoIHVzZXMgdG9v IG11Y2ggbWVtb3J5LCBhbmQgaWYgdGhlIGxpc3QgaW5zdGFuY2VzDQo+IGNoYW5nZSByYXBpZGx5 LCBhIHN0YWxlIHNuYXBzaG90IGlzIG5vdCB2ZXJ5IHVzZWZ1bC4NCj4gDQo+IEFuZHkNCj4gDQo+ IFRoZSBvdGhlciBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSBsaXN0ZWQgYmVsb3c6DQo+IDEu IEdldC1ibG9jayBjYXBhYmlsaXR5IHNob3VsZCBub3QgY2hhbmdlIHRoZSBnZXQtY29uZmlnIG9w ZXJhdGlvbidzDQo+IGJlaGF2aW9yLiBJZiBjbGllbnQgdXNlIGdldC1jb25maWcgb3BlcmF0aW9u IHRvIHJldHJpZXZlIGRhdGEsDQo+IGFsbCBkYXRhIG11c3QgYmUgc2VudCBpbiBvbmUgcmVzcG9u c2Ugb3IgZ2V0LWJsb2NrIGNhcGFiaWxpdHkgc2hvdWxkDQo+IGFkZCBhIHBhcmFtZXRlciB0byBn ZXQtY29uZmlnIG9wZXJhdGlvbiB0byBpbmRpY2F0ZSB0aGUgDQo+IHJlc3BvbnNlIGRhdGEgd2ls bCBiZSBmcmFnbWVudGVkLg0KPiAyLiBBIHNldC1pZCBjYW4gYmUgYWdlZD8gd2hlbiBjbGllbnQg bmV2ZXIgc2VuZCBhIHJlcXVlc3QgdG8gDQo+IHJldHJpZXZlIHRoZSBuZXh0IGZyYWdtZW50IGZv ciBhIGxvbmcgdGltZSwgSSB0aGluayB0aGlzIHNldC1pZCANCj4gc2hvdWxkIGJlIGFnZWQsDQo+ IG90aGVyd2lzZSwgc2VydmVyIHdpbGwgYmUgcmVzZXJ2ZSBtb3JlIGFuZCBtb3JlIHNldC1pZHMu DQo+IDMuIEEgc2V0LWlkIGlzIHVuaXF1ZSBpbiBzZXNzaW9uIGxldmVsIG9yIHNlcnZlciBsZXZl bD8NCj4gNC4gSWYgYSBzZXNzaW9uIGlzIGtpbGxlZCBvciBjbG9zZWQsIG90aGVyIHNlc3Npb24g Y2FuIHJldHJpZXZlZCB0aGUNCj4gbmV4dCBmcmFnbWVudCBpZiB0aGUgY2xpZW50IHByb3ZpZGUg dGhlIGNvcnJlY3Qgc2V0LWlkPw0KPiAvZnJhbmsNCj4gDQoNCj4gMjAxNC0wNi0wNCAxODoyMiBH TVQrMDg6MDAgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT46DQo+IEhpIGFs bCwNCj4gDQo+IFdlJ3ZlIHBvc3RlZCBhIG5ldyBkcmFmdCwgd2hpY2ggaXMgYWJvdXQgTkVUQ09O RiBkYXRhIGZyYWdtZW50YXRpb24uDQo+IA0KPiBUaGUgYmFzaWMgaWRlYSBpcywgd2hlbiBOTVMg aXMgcmV0cmlldmluZyBhIGxhcmdlIHNpemUgb2YgZGF0YSBpbiANCj4gdGhlIGRldmljZSwgdGhl IDxycGMtcmVwbHk+IG1pZ2h0IGJlIHZlcnkgYmlnIChlLmcuIHRoZSByb3V0ZXMgaW4gYSANCj4g Y29yZSByb3V0ZXIpLg0KPiBDdXJyZW50bHkgdGhlcmUgYXJlIG1haW5seSB0d28gbWV0aG9kcyBv ZiBoYW5kbGluZyB0aGUgYmlnIDxycGMtDQo+IHJlcGx5Pjogb25lIGlzIHN0cmVhbS1vcmllbnRl ZCBoYW5kbGluZzsgdGhlIG90aGVyIGlzIGp1c3QgcmVxdWVzdCBhDQo+IHBvcnRpb24gb2YgdGhl IGRhdGEuDQo+IA0KPiBUaGlzIGRyYWZ0IGNvbnNpZGVycyBib3RoIHRoZSB0d28gbWV0aG9kcyBh cmUgcHJvYmxlbWF0aWMgaW4gc29tZSANCj4gc2l0dWF0aW9ucywgYW5kIHByb3Bvc2VzIGEgbmV3 IG1ldGhvZCB3aGljaCBhbGxvd3MgdGhlIGxhcmdlIHNpemUgDQo+IDxycGMtcmVwbHk+IHRvIGJl IGZyYWdtZW50ZWQgaW4gTkVUQ09ORiBsZXZlbC4NCj4gDQo+IFBsZWFzZSByZWFkIHRoZSBkcmFm dCBhbmQgY29tbWVudC4NCj4gTWFueSB0aGFua3MhDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IEJp bmcNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDog V2VkbmVzZGF5LCBKdW5lIDA0LCAyMDE0IDU6MjcgUE0NCj4gVG86IExpdWJpbmcgKExlbyk7IExp dWJpbmcgKExlbyk7IFpoZW5nZ3Vhbmd5aW5nOyBaaGVuZ2d1YW5neWluZw0KPiBTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRh dGlvbi0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LW5l dGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBCaW5nIExpdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIA0KcmVwb3NpdG9yeS4NCj4g DQo+IE5hbWU6ICAgICAgICAgICBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uDQo+IFJl dmlzaW9uOiAgICAgICAwMA0KPiBUaXRsZTogICAgICAgICAgQSBORVRDT05GIEV4dGVuc2lvbiBm b3IgRGF0YSBGcmFnbWVudGF0aW9uDQo+IERvY3VtZW50IGRhdGU6ICAyMDE0LTA2LTA0DQo+IEdy b3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6ICAgICAgICAgIDEy DQo+IFVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1saXUtDQo+IG5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQNCj4gU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1uZXRjb25mLQ0K PiBmcmFnbWVudGF0aW9uLw0KPiBIdG1saXplZDogICAgICAgDQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwDQo+IA0KPiANCj4gQWJz dHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBhbiBleHRlbnNpb24gdG8gTkVU Q09ORiAoTmV0d29yaw0KPiAgICBDb25maWd1cmF0aW9uKSBwcm90b2NvbC4gVGhlIGV4dGVuc2lv biBhbGxvd3MgTkVUQ09ORiB0byBoYW5kbGUgbGFyZ2UNCj4gICAgc2l6ZSBkYXRhIGFzIGZyYWdt ZW50ZWQgUlBDIG1lc3NhZ2VzLiBTcGVjaWZpY2FsbHksIHRoaXMgZG9jdW1lbnQNCj4gICAgZGVm aW5lcyBhIG5ldyA8Z2V0LWJsb2NrPiBjYXBhYmlsaXR5IGFuZCByZWxldmFudCBvcGVyYXRpb25z IHRvDQo+ICAgIGhhbmRsZSB0aGUgZnJhZ21lbnRhdGlvbnMuDQo+IA0KPiANCj4gDQo+IA0KPiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiANCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IA0KdG9vbHMuaWV0Zi5vcmcNCj4gLg0KPiANCj4gVGhlIElFVEYg U2VjcmV0YXJpYXQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29u ZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiBOZXRjb25m QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u Zg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJl d2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3Ig dGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFu IGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJp YnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0 ZWx5Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBh biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlh dGVseS4NCg== --=_alternative 000577C048257CEE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuZHksPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7SG93IHRvIHByb2Nlc3MgbmVzdGVk IGxpc3RzDQp1c2luZyB5b3VyIHNvbHV0aW9uPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Rm9yIGV4YW1wbGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bGlzdCBmb28gezwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7a2V5IGE7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtsZWFmIGEgey4uLn08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYWYgYiB7Li4ufTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7bGlzdCBuZXN0ZWQtZm9vDQp7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K a2V5IG5lc3RlZC1hOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmxlYWYgbmVzdGVkLWEg ey4uLn08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpsZWFmIG5ldHN0ZWQtYiB7Li4ufTwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwO308L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyBJZiByZXF1ZXN0IGlzOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjx0dD48Zm9udCBzaXplPTI+ICZsdDtycGMmZ3Q7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZs dDtnZXQtbGlzdCZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt0YXJnZXQmZ3Q7L2ZvbyZsdDsvdGFyZ2V0Jmd0OzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbHQ7L2dl dC1saXN0Jmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7Jm5ic3A7 ICZsdDsvcnBjJmd0OzwvZm9udD48L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFdoYXQg aXMgdGhlIHJlc3BvbnNlPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+QW5kLCBhbm90aGVyIHF1ZXN0aW9uOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+U3RhcnQtaW5kZXggaXMgbm90IHJlbGlhYmxlLCBpZiBzb21lDQpl bnRyaWVzIGFyZSBkZWxldGVkLiBJIHRoaW5rIHlvdSBjYW4gdXNlIHN0YXJ0IGtleSBpbnN0ZWFk LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+L2ZyYW5rPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7TmV0 Y29uZiZxdW90OyAmbHQ7bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnJmd0Ow0K0LTT2iAyMDE0LTA2 LTA1IDAwOjQzOjEyOjxicj4NCjxicj4NCiZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3 b3Jrcy5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyC3orz+ yMs6ICZuYnNwOyZxdW90O05ldGNvbmYmcXVvdDsgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9y ZyZndDs8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAy MDE0LTA2LTA1IDAwOjQzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsgY2hvbmcgZmVuZyAmbHQ7ZmVuZ2Nob25nbGxseUBnbWFpbC5jb20mZ3Q7LCA8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgWmhlbmdndWFuZ3lp bmcgJmx0O3poZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb20mZ3Q7LCBOZXRjb25mIDxicj4NCiZndDsg Jmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCBZYW5nYW5nICZsdDt5YW5nYW5nQGh1YXdlaS5jb20m Z3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM 4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJlOiBb TmV0Y29uZl0gTmV0Y29uZiBmcmFnbWVudGF0aW9uLS8vRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbg0KPGJyPg0KJmd0OyBmb3IgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50 eHQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+ DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgT24gV2VkLCBKdW4gNCwg MjAxNCBhdCA4OjMyIEFNLCBjaG9uZyBmZW5nICZsdDtmZW5nY2hvbmdsbGx5QGdtYWlsLmNvbSZn dDsNCndyb3RlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBIaSw8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO0kgaGF2ZSBy ZXZpZXdlZCB0aGlzIG5ldyBkcmFmdC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgJm5ic3A7ICZuYnNwO0kgdW5kZXJzdGFuZCB5b3VyIHNvbHV0aW9uIGlzIHRoYXQNCk5F VENPTkYgc2VydmVyIHJlc2VydmUgYnJlYWsgPGJyPg0KJmd0OyBwb2ludHMgYW5kIHdhaXQgZm9y IGNsaWVudCB0byByZXRyaWV2ZSB0aGUgbmV4dCByZXNwb25zZS48L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSSB0aGluayBpdCdzIG5vdCBhIGdvb2Qgc29sdXRpb24sIGJl Y2F1c2Ugc2VydmVyDQptYXkgbmVlZCB0byByZXNlcnZlPGJyPg0KJmd0OyBtYW55IGJyZWFrIHBv aW50cyBpZiB0aGVyZSBhIGxhcmdlIG51bWJlciBvZiBjb25jdXJyZW50IHJlcXVlc3RzLjwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJdCdzIHRvbyBoZWF2eSBmb3Igc2Vy dmVyLiBBbmQsIHRoZSBzZXJ2ZXIgbXVzdA0KYmUgc3RhdGVmdWwgaWYgaXQgPGJyPg0KJmd0OyBz dXBwb3J0IGdldC1ibG9jayBjYXBhYmlsaXR5LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyBJIGFncmVlIHdpdGggdGhlc2UgY29uY2VybnMuICZuYnNwO0hvbGRpbmcgYSBz bmFwc2hvdCBvZiBzdGF0ZSBkYXRhDQpmb3IgPGJyPg0KJmd0OyBpbnRlcmFjdGl2ZSByZXRyaWV2 YWw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgYnkgdGhlIGNsaWVudCBp cyB2ZXJ5IGV4cGVuc2l2ZS4mbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgPGJyPg0KJmd0OyBJIGRvIG5vdCBhZ3JlZSB3aXRoIHRoZSBwcmVtaXNlIHRoYXQgdGhl IGNsaWVudCBuZWVkcyB0byBrbm93IHRoZQ0KPGJyPg0KJmd0OyBrZXkgdmFsdWVzIGluIGFkdmFu Y2UuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFuICZxdW90O2l0ZXJh dG9yJnF1b3Q7IGFwcHJvYWNoIGFsbG93cyBhIGxpc3QNCnJlc291cmNlIHRvIGJlIHJldHJpZXZl ZCBpbiA8YnI+DQomZ3Q7IGNodW5rcy4gJm5ic3A7VGhpcyBpcyB3aGF0IFJFU1RDT05GPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGlzIGdvaW5nIHRvIGRvLCBhbmQgTkVU Q09ORiBjb3VsZCBhZGQgYSBzaW1pbGFyDQpSUEMgZnVuY3Rpb246PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3JwYyBnZXQtbGlz dCB7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7aW5wdXQgezwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFmIHRhcmdldCB7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlw ZSBzY2hlbWEtaW5zdGFuY2UtaWRlbnRpZmllcjs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXNjcmlwdGlv bg0KJnF1b3Q7SWRlbnRpZmllcyBzdWJ0cmVlIHRvIHJldHJpZXZlLiZxdW90Ozs8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBs ZWFmIHN0YXJ0IHs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgdWludDMyOzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ZGVmYXVsdCAwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVzY3JpcHRpb24NCiZxdW90O051bWJlciBvZiBl bnRyaWVzIHRvIHNraXAgYmVmb3JlIHN0YXJ0aW5nIHJldHJpZXZhbCZxdW90Ozs8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBs ZWFmIG1heC1lbnRyaWVzIHs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHR5cGUgdWludDMyIHsgcmFuZ2UNCiZxdW90OzEu Lm1heCZxdW90OzsgfTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVmYXVsdCAyNTs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlc2NyaXB0aW9u ICZxdW90O01heGltdW0NCm51bWJlciBvZiBsaXN0IGVudHJpZXMgdG8gcmV0cmlldmUmcXVvdDs7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IH08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNw OyB9PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsg b3V0cHV0IHs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7YW55eG1sIGRhdGEgezwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlc2NyaXB0 aW9uDQomcXVvdDtDb250YWlucyB0aGUgcmVxdWVzdGVkIGRhdGEmcXVvdDs7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyB9PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyB9PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZsdDtycGMmZ3Q7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJmx0 O2dldC1saXN0Jmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbHQ7dGFyZ2V0Jmd0Oy9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFj ZSZsdDsvdGFyZ2V0Jmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDsgJm5ic3A7ICZsdDsvZ2V0LWxpc3QmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbHQ7L3JwYyZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJmx0O3JwYy1yZXBseSZndDs8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7 ZGF0YSZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtpbnRlcmZhY2VzJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZsdDtpbnRlcmZhY2UmZ3Q7DQombmJzcDsgLi4uLiBmaXJzdCBlbnRyeSAmbHQ7L2ludGVy ZmFjZSZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7aW50ZXJmYWNlJmd0Ow0KJm5ic3A7IC4uLi4gMjV0aCBlbnRyeSAmbHQ7L2ludGVyZmFj ZSZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDsvaW50ZXJmYWNlcyZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2RhdGEmZ3Q7PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbHQ7L3JwYy1yZXBseSZn dDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7Jmx0O3JwYyZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgJm5ic3A7ICZuYnNwOyAmbHQ7Z2V0LWxpc3QmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt0YXJnZXQmZ3Q7L2lmOmlu dGVyZmFjZXMvaWY6aW50ZXJmYWNlJmx0Oy90YXJnZXQmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtzdGFydCZndDsyNSZs dDsvc3RhcnQmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OyAmbmJzcDsgJmx0Oy9nZXQtbGlzdCZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7ICZsdDsvcnBjJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbHQ7cnBjLXJlcGx5Jmd0OzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtkYXRh Jmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0O2ludGVyZmFjZXMmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O2ludGVyZmFjZSZndDsNCiZuYnNwOyAuLi4uIDI2dGggZW50cnkgJmx0Oy9pbnRlcmZhY2Um Z3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Li4uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0 O2ludGVyZmFjZSZndDsNCiZuYnNwOyAuLi4uIDUwdGggZW50cnkgJmx0Oy9pbnRlcmZhY2UmZ3Q7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbHQ7L2ludGVyZmFjZXMmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9kYXRhJmd0OzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJmx0Oy9ycGMtcmVwbHkmZ3Q7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhlcmUgaXMg YSBwcm9ibGVtIHdpdGggcmFwaWRseSBjaGFuZ2luZyBsaXN0czwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAoY291bGQgZ2V0IHJlcGVhdCBlbnRyaWVzIG9uIG1pc3Mgc29t ZSBlbnRyaWVzKSwNCmJ1dCB0aGUgc25hcHNob3Q8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgYXBwcm9hY2ggdXNlcyB0b28gbXVjaCBtZW1vcnksIGFuZCBpZiB0aGUgbGlz dA0KaW5zdGFuY2VzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGNoYW5n ZSByYXBpZGx5LCBhIHN0YWxlIHNuYXBzaG90IGlzIG5vdCB2ZXJ5DQp1c2VmdWwuPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQW5keTwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFRoZSBvdGhlciBxdWVzdGlv bnMgYW5kIGNvbW1lbnRzIGFyZSBsaXN0ZWQgYmVsb3c6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDEuIEdldC1ibG9jayBjYXBhYmlsaXR5IHNob3VsZCBub3QgY2hhbmdl IHRoZQ0KZ2V0LWNvbmZpZyBvcGVyYXRpb24nczxicj4NCiZndDsgYmVoYXZpb3IuIElmIGNsaWVu dCB1c2UgZ2V0LWNvbmZpZyBvcGVyYXRpb24gdG8gcmV0cmlldmUgZGF0YSw8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgYWxsIGRhdGEgbXVzdCBiZSBzZW50IGluIG9uZSBy ZXNwb25zZSBvciBnZXQtYmxvY2sNCmNhcGFiaWxpdHkgc2hvdWxkPGJyPg0KJmd0OyBhZGQgYSBw YXJhbWV0ZXIgdG8gZ2V0LWNvbmZpZyBvcGVyYXRpb24gdG8gaW5kaWNhdGUgdGhlJm5ic3A7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHJlc3BvbnNlIGRhdGEgd2lsbCBi ZSBmcmFnbWVudGVkLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyLiBB IHNldC1pZCBjYW4gYmUgYWdlZD8gd2hlbiBjbGllbnQgbmV2ZXIgc2VuZA0KYSByZXF1ZXN0IHRv IDxicj4NCiZndDsgcmV0cmlldmUgdGhlIG5leHQgZnJhZ21lbnQgZm9yIGEgbG9uZyB0aW1lLCBJ IHRoaW5rIHRoaXMgc2V0LWlkIDxicj4NCiZndDsgc2hvdWxkIGJlIGFnZWQsPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IG90aGVyd2lzZSwgc2VydmVyIHdpbGwgYmUgcmVz ZXJ2ZSBtb3JlIGFuZCBtb3JlDQpzZXQtaWRzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAzLiBBIHNldC1pZCBpcyB1bmlxdWUgaW4gc2Vzc2lvbiBsZXZlbCBvciBzZXJ2 ZXINCmxldmVsPzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA0LiBJZiBh IHNlc3Npb24gaXMga2lsbGVkIG9yIGNsb3NlZCwgb3RoZXIgc2Vzc2lvbg0KY2FuIHJldHJpZXZl ZCB0aGU8YnI+DQomZ3Q7IG5leHQgZnJhZ21lbnQgaWYgdGhlIGNsaWVudCBwcm92aWRlIHRoZSBj b3JyZWN0IHNldC1pZD88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgL2Zy YW5rPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyMDE0LTA2LTA0IDE4OjIyIEdNVCswODow MCBMaXViaW5nIChMZW8pICZsdDtsZW8ubGl1YmluZ0BodWF3ZWkuY29tJmd0Ozo8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSGkgYWxsLDxicj4NCiZndDsgPGJyPg0KJmd0 OyBXZSd2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQsIHdoaWNoIGlzIGFib3V0IE5FVENPTkYgZGF0YSBm cmFnbWVudGF0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgYmFzaWMgaWRlYSBpcywgd2hl biBOTVMgaXMgcmV0cmlldmluZyBhIGxhcmdlIHNpemUgb2YgZGF0YSBpbg0KPGJyPg0KJmd0OyB0 aGUgZGV2aWNlLCB0aGUgJmx0O3JwYy1yZXBseSZndDsgbWlnaHQgYmUgdmVyeSBiaWcgKGUuZy4g dGhlIHJvdXRlcw0KaW4gYSA8YnI+DQomZ3Q7IGNvcmUgcm91dGVyKS48YnI+DQomZ3Q7IEN1cnJl bnRseSB0aGVyZSBhcmUgbWFpbmx5IHR3byBtZXRob2RzIG9mIGhhbmRsaW5nIHRoZSBiaWcgJmx0 O3JwYy08YnI+DQomZ3Q7IHJlcGx5Jmd0Ozogb25lIGlzIHN0cmVhbS1vcmllbnRlZCBoYW5kbGlu ZzsgdGhlIG90aGVyIGlzIGp1c3QgcmVxdWVzdA0KYTxicj4NCiZndDsgcG9ydGlvbiBvZiB0aGUg ZGF0YS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBkcmFmdCBjb25zaWRlcnMgYm90aCB0aGUg dHdvIG1ldGhvZHMgYXJlIHByb2JsZW1hdGljIGluIHNvbWUNCjxicj4NCiZndDsgc2l0dWF0aW9u cywgYW5kIHByb3Bvc2VzIGEgbmV3IG1ldGhvZCB3aGljaCBhbGxvd3MgdGhlIGxhcmdlIHNpemUN Cjxicj4NCiZndDsgJmx0O3JwYy1yZXBseSZndDsgdG8gYmUgZnJhZ21lbnRlZCBpbiBORVRDT05G IGxldmVsLjxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2UgcmVhZCB0aGUgZHJhZnQgYW5kIGNv bW1lbnQuPGJyPg0KJmd0OyBNYW55IHRoYW5rcyE8YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVzdCBy ZWdhcmRzLDxicj4NCiZndDsgQmluZzxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFs8 L2ZvbnQ+PC90dD48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj48dHQ+ PGZvbnQgc2l6ZT0yPm1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD48 L2E+PHR0Pjxmb250IHNpemU9Mj5dPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDQs IDIwMTQgNToyNyBQTTxicj4NCiZndDsgVG86IExpdWJpbmcgKExlbyk7IExpdWJpbmcgKExlbyk7 IFpoZW5nZ3Vhbmd5aW5nOyBaaGVuZ2d1YW5neWluZzxicj4NCiZndDsgU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAw LnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dDxicj4NCiZndDsgaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5nIExpdSBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGDQpyZXBvc2l0b3J5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBOYW1lOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb248YnI+ DQomZ3Q7IFJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwMDxicj4NCiZndDsgVGl0bGU6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBIE5FVENPTkYgRXh0ZW5zaW9uIGZv ciBEYXRhDQpGcmFnbWVudGF0aW9uPGJyPg0KJmd0OyBEb2N1bWVudCBkYXRlOiAmbmJzcDsyMDE0 LTA2LTA0PGJyPg0KJmd0OyBHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0luZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NCiZndDsgUGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsxMjxicj4NCiZndDsgVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS0iPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LTwvZm9udD48L3R0PjwvYT48dHQ+ PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dDxicj4N CiZndDsgU3RhdHVzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9mb250PjwvdHQ+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LW5ldGNvbmYt Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWxpdS1uZXRjb25mLTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsg ZnJhZ21lbnRhdGlvbi88YnI+DQomZ3Q7IEh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8 L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUt bmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDA8L2ZvbnQ+PC90 dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBB YnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGludHJvZHVjZXMg YW4gZXh0ZW5zaW9uIHRvIE5FVENPTkYgKE5ldHdvcms8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtD b25maWd1cmF0aW9uKSBwcm90b2NvbC4gVGhlIGV4dGVuc2lvbiBhbGxvd3MgTkVUQ09ORg0KdG8g aGFuZGxlIGxhcmdlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7c2l6ZSBkYXRhIGFzIGZyYWdtZW50 ZWQgUlBDIG1lc3NhZ2VzLiBTcGVjaWZpY2FsbHksIHRoaXMNCmRvY3VtZW50PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ZGVmaW5lcyBhIG5ldyAmbHQ7Z2V0LWJsb2NrJmd0OyBjYXBhYmlsaXR5IGFu ZCByZWxldmFudA0Kb3BlcmF0aW9ucyB0bzxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2hhbmRsZSB0 aGUgZnJhZ21lbnRhdGlvbnMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo8YnI+DQomZ3Q7IHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zzxicj4NCiZndDsgLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxi cj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IE5ldGNv bmZAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9mb250PjwvdHQ+PC9hPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE5ldGNvbmYgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyBOZXRjb25mQGlldGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90 dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZj48 dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 IE5ldGNvbmZAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPjx0dD48Zm9udCBzaXplPTI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9mb250PjwvdHQ+PC9h Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQoNCjxicj48cHJlPjxmb250IGNv bG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0 dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVu ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9u LCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9y PSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVk IGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVk IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBu b3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBk aXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1t ZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 000577C048257CEE_=-- From nobody Wed Jun 4 18:16:02 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739061A03E7 for ; Wed, 4 Jun 2014 18:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.972 X-Spam-Level: *** X-Spam-Status: No, score=3.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0Hn40AQizWf for ; Wed, 4 Jun 2014 18:15:58 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3441A03E6 for ; Wed, 4 Jun 2014 18:15:58 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so440625qaq.3 for ; Wed, 04 Jun 2014 18:15:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=06ZHOLeZFQCDo7K0bXYqHo0NdkfG3iQFadognyed8I0=; b=gsqomlKifIZmQPpQ+vCDNFnBEOE4Z0vQ/6b+/LeJjCKYRa8FkB+sSXbeyMgs+OPZhB VNQJ2gxq066u8Is3ogDy0vepjjxEuOcjy7uHmfFUl/FqeY96vyXXqmvuRNSZ8NNyQPiQ 143ewrw3QeFp5vu5DAMGoSYyPRfhAtT1F21tdADdHq1O8rO2cE4nHViheDsb3sRJxPO0 gVorjasqdeYIMBIbLB1D9+As5N3WAfDqWsL/w379eE0Y0x2PaiogBJ1RbBGWnewVqB8M j5ek7nDgrwFp6cp/uPKtxKvHMnwt0w/qKogRMLB/sOHsmlGN8Fuhzsrz4EKSNhIk0884 dKsg== X-Gm-Message-State: ALoCoQmotXNozOq7r0zI7EJrSQQphFu+Cy8EK/lIomb4/QdyYNFOJQPBgC4vCTyhWCXSV2sRvFzO MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr77602692qai.16.1401930951407; Wed, 04 Jun 2014 18:15:51 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 4 Jun 2014 18:15:51 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> Date: Wed, 4 Jun 2014 18:15:51 -0700 Message-ID: From: Andy Bierman To: feng.chong33@zte.com.cn Content-Type: multipart/alternative; boundary=001a11c20e7a5becaf04fb0c7c35 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/RrWQ6xgt6y0D7C_SApWt5Fxl1Wg Cc: Zhengguangying , Netconf , Netconf , Yangang Subject: Re: [Netconf] =?gb2312?b?tPC4tDogUmU6ICBOZXRjb25mIGZyYWdtZW50YXRpb24t?= =?gb2312?b?Ly9GVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUt?= =?gb2312?b?bmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA==?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 01:16:00 -0000 --001a11c20e7a5becaf04fb0c7c35 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Wed, Jun 4, 2014 at 5:59 PM, wrote: > andy, > How to process nested lists using your solution? > > I am not suggesting a standard solution, but IMO the client picks the list it wants to iterate over, not the server. If the client doesn't know how the server will break up the subtree, it will have a lot of work guessing what all the fragments mean. > For example: > list foo { > key a; > leaf a {...} > leaf b {...} > list nested-foo { > key nested-a; > leaf nested-a {...} > leaf netsted-b {...} > } > } > > If request is: > > > /foo > > > What is the response? > > And, another question: > Start-index is not reliable, if some entries are deleted. I think you can > use start key instead. > > If the server can support snapshots of large lists (solutions like RMON2 usrHistoryTable have been around for decades) then it can provide that feature without changing NETCONF. Data skew due to polling latency is a different problem then limiting the size of data that is processed by a client in 1 reply. > > > /frank > Andy > > "Netconf" =D0=B4=D3=DA 2014-06-05 00:43:12: > > > Andy Bierman > > =B7=A2=BC=FE=C8=CB: "Netconf" > > > > 2014-06-05 00:43 > > > > =CA=D5=BC=FE=C8=CB > > > > chong feng , > > > > =B3=AD=CB=CD > > > > Zhengguangying , Netconf > > , Yangang > > > > =D6=F7=CC=E2 > > > > Re: [Netconf] Netconf fragmentation-//FW: New Version Notification > > for draft-liu-netconf-fragmentation-00.txt > > > > > > > On Wed, Jun 4, 2014 at 8:32 AM, chong feng > wrote: > > Hi, > > I have reviewed this new draft. > > I understand your solution is that NETCONF server reserve break > > points and wait for client to retrieve the next response. > > I think it's not a good solution, because server may need to reserve > > many break points if there a large number of concurrent requests. > > It's too heavy for server. And, the server must be stateful if it > > support get-block capability. > > > > > > I agree with these concerns. Holding a snapshot of state data for > > interactive retrieval > > by the client is very expensive. > > > > I do not agree with the premise that the client needs to know the > > key values in advance. > > An "iterator" approach allows a list resource to be retrieved in > > chunks. This is what RESTCONF > > is going to do, and NETCONF could add a similar RPC function: > > > > rpc get-list { > > input { > > leaf target { > > type schema-instance-identifier; > > description "Identifies subtree to retrieve."; > > } > > leaf start { > > type uint32; > > default 0; > > description "Number of entries to skip before starting > retrieval"; > > } > > leaf max-entries { > > type uint32 { range "1..max"; } > > default 25; > > description "Maximum number of list entries to retrieve"; > > } > > } > > output { > > anyxml data { > > description "Contains the requested data"; > > } > > } > > } > > > > > > > > /if:interfaces/if:interface > > > > > > > > > > > > > > .... first entry > > ... > > .... 25th entry > > > > > > > > > > > > > > /if:interfaces/if:interface > > 25 > > > > > > > > > > > > > > .... 26th entry > > ... > > .... 50th entry > > > > > > > > > > There is a problem with rapidly changing lists > > (could get repeat entries on miss some entries), but the snapshot > > approach uses too much memory, and if the list instances > > change rapidly, a stale snapshot is not very useful. > > > > Andy > > > > The other questions and comments are listed below: > > 1. Get-block capability should not change the get-config operation's > > behavior. If client use get-config operation to retrieve data, > > all data must be sent in one response or get-block capability should > > add a parameter to get-config operation to indicate the > > response data will be fragmented. > > 2. A set-id can be aged? when client never send a request to > > retrieve the next fragment for a long time, I think this set-id > > should be aged, > > otherwise, server will be reserve more and more set-ids. > > 3. A set-id is unique in session level or server level? > > 4. If a session is killed or closed, other session can retrieved the > > next fragment if the client provide the correct set-id? > > /frank > > > > > 2014-06-04 18:22 GMT+08:00 Liubing (Leo) : > > Hi all, > > > > We've posted a new draft, which is about NETCONF data fragmentation. > > > > The basic idea is, when NMS is retrieving a large size of data in > > the device, the might be very big (e.g. the routes in a > > core router). > > Currently there are mainly two methods of handling the big > reply>: one is stream-oriented handling; the other is just request a > > portion of the data. > > > > This draft considers both the two methods are problematic in some > > situations, and proposes a new method which allows the large size > > to be fragmented in NETCONF level. > > > > Please read the draft and comment. > > Many thanks! > > > > Best regards, > > Bing > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org > ] > > Sent: Wednesday, June 04, 2014 5:27 PM > > To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying > > Subject: New Version Notification for > draft-liu-netconf-fragmentation-00.txt > > > > > > A new version of I-D, draft-liu-netconf-fragmentation-00.txt > > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > > > Name: draft-liu-netconf-fragmentation > > Revision: 00 > > Title: A NETCONF Extension for Data Fragmentation > > Document date: 2014-06-04 > > Group: Individual Submission > > Pages: 12 > > URL: http://www.ietf.org/internet-drafts/draft-liu- > > netconf-fragmentation-00.txt > > Status: https://datatracker.ietf.org/doc/draft-liu-netconf- > > fragmentation/ > > Htmlized: > http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00 > > > > > > Abstract: > > This document introduces an extension to NETCONF (Network > > Configuration) protocol. The extension allows NETCONF to handle larg= e > > size data as fragmented RPC messages. Specifically, this document > > defines a new capability and relevant operations to > > handle the fragmentations. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org > > . > > > > The IETF Secretariat > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > --001a11c20e7a5becaf04fb0c7c35 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 5:59 PM, <feng.chong33@zte.com.cn> wrote:
andy,
   How to process nested lists using your solution?
   

I am not suggesting a standard solutio= n, but IMO the client picks the
list it wants to iterate over, no= t the server.  If the client doesn't know
how the server= will break up the subtree, it will have a lot of work
guessing what all the fragments mean.

 <= /div>
For example:<= /font>
   list foo {
       key a;
       leaf a {...}
       leaf b {...}
       list nested-foo {
            key nested-a;
            leaf nested-a {...}
            leaf netsted-b {...}
       }
   }

  If request is:
  <rpc>
     <get-list>
       <target>/foo</target><= /font>
     </get-list>
   </rpc>
  What is the response?

And, another question:
Start-index is not reliable, if some entries are deleted. I think you can use start key instead.


If the server can support snapshots of= large lists (solutions like RMON2 usrHistoryTable
have been arou= nd for decades) then it can provide that feature without changing NETCONF.<= /div>
Data skew due to polling latency is a different problem then limiting = the size of data that
is processed by a client in 1 reply.
<= div>

 
/frank

Andy
 

"Netconf" <netconf-bounces@ietf.org> =D0=B4=D3=DA 2014-06-05 00:43:12:

> Andy Bierman <andy@yumaworks.com>
> =B7=A2=BC=FE=C8=CB:  "Netconf" <netconf-bounces@iet= f.org>
>
> 2014-06-05 00:43
>
> =CA=D5=BC=FE=C8=CB
>
> chong feng <fengchongllly@gmail.com>,
>
> =B3=AD=CB=CD
>
> Zhengguangying <zhengguangying@huawei.com>, Netconf
> <netconf@ietf= .org>, Yangang <yangang@huawei.com>
>
> =D6=F7=CC=E2
>
> Re: [Netconf] Netconf fragmentation-//FW: New Version Notification
> for draft-liu-netconf-fragmentation-00.txt
>
>

> On Wed, Jun 4, 2014 at 8:32 AM, chong feng <fengchongllly@gmail.c= om> wrote:
> Hi,
>    I have reviewed this new draft.
>    I understand your solution is that NETCONF server reserve break
> points and wait for client to retrieve the next response.
> I think it's not a good solution, because server may need to reserve
> many break points if there a large number of concurrent requests.
> It's too heavy for server. And, the server must be stateful if it
> support get-block capability.
>  
>
> I agree with these concerns.  Holding a snapshot of state data for
> interactive retrieval
> by the client is very expensive. 
>
> I do not agree with the premise that the client needs to know the
> key values in advance.
> An "iterator" approach allows a list resource to be retrieved in
> chunks.  This is what RESTCONF
> is going to do, and NETCONF could add a similar RPC function:
>
>    rpc get-list {
>      input {
>        leaf target {
>           type schema-instance-= identifier;
>           description "Identifies subtree to retrieve.";
>       }
>       leaf start {
>          type uint32;
>          default 0;
>          description "Number of entries to skip before starting retrieval";
>       }
>       leaf max-entries {
>         type uint32 { range "1..max"; }
>         default 25;
>         description "Maximum number of list entries to retrieve";
>       }
>     }
>     output {
>        anyxml data {
>           description "Contains the requested data";
>        }
>     }
>   }
>
>   <rpc>
>     <get-list>
>       <target>/if:interfaces/if:int= erface</target>
>     </get-list>
>   </rpc>
>
>   <rpc-reply>
>      <data>
>         <interfaces>
>            <interface&g= t;   .... first entry </interface>
>            ...
>            <interface&g= t;   .... 25th entry </interface>
>         </interfaces>
>      </data>
>   </rpc-reply>
>
>    <rpc>
>     <get-list>
>       <target>/if:interfaces/if:int= erface</target>
>       <start>25</start>
>     </get-list>
>   </rpc>
>
>   <rpc-reply>
>      <data>
>         <interfaces>
>            <interface&g= t;   .... 26th entry </interface>
>            ...
>            <interface&g= t;   .... 50th entry </interface>
>         </interfaces>
>      </data>
>   </rpc-reply>
>
> There is a problem with rapidly changing lists
> (could get repeat entries on miss some entries), but the snapshot
> approach uses too much memory, and if the list instances
> change rapidly, a stale snapshot is not very useful.
>
> Andy
>
> The other questions and comments are listed below:
> 1. Get-block capability should not change the get-config operation's
> behavior. If client use get-config operation to retrieve data,<= /tt>
> all data must be sent in one response or get-block capability should
> add a parameter to get-config operation to indicate the 
> response data will be fragmented.
> 2. A set-id can be aged? when client never send a request to
> retrieve the next fragment for a long time, I think this set-id
> should be aged,
> otherwise, server will be reserve more and more set-ids.
> 3. A set-id is unique in session level or server level?
> 4. If a session is killed or closed, other session can retrieved the
> next fragment if the client provide the correct set-id?
> /frank
>

> 2014-06-04 18:22 GMT+08:00 Liubing (Leo) <leo.liubing@huawei.com= >:
> Hi all,
>
> We've posted a new draft, which is about NETCONF data fragmentatio= n.
>
> The basic idea is, when NMS is retrieving a large size of data in
> the device, the <rpc-reply> might be very big (e.g. the routes in a
> core router).
> Currently there are mainly two methods of handling the big <rpc- > reply>: one is stream-oriented handling; the other is just request a
> portion of the data.
>
> This draft considers both the two methods are problematic in some
> situations, and proposes a new method which allows the large size
> <rpc-reply> to be fragmented in NETCONF level.
>
> Please read the draft and comment.
> Many thanks!
>
> Best regards,
> Bing
>
> -----Original Message-----
> From: in= ternet-drafts@ietf.org [mailto:internet-drafts@ietf.org= ]
> Sent: Wednesday, June 04, 2014 5:27 PM
> To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying
> Subject: New Version Notification for draft-liu-netconf-fragmentation-= 00.txt
>
>
> A new version of I-D, draft-liu-netconf-fragmentation-00.txt
> has been successfully submitted by Bing Liu and posted to the IETF repository.
>
> Name:           draft-liu-netconf-fragmentati= on
> Revision:       00
> Title:          A NETCONF Extension for Data Fragmentation
> Document date:  2014-06-04
> Group:          Individual Submission
> Pages:          12
> URL:            = http://www.ietf.org/internet-drafts/draft-liu- > netconf-fragmentation-00.txt
> Status:         https= ://datatracker.ietf.org/doc/draft-liu-netconf- > fragmentation/
> Htmlized:       = http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00
>
>
> Abstract:
>    This document introduces an extension to NETCONF (Network=
>    Configuration) protocol. The extension allows NETCONF to handle large
>    size data as fragmented RPC messages. Specifically, this document
>    defines a new <get-block> capability and relevant operations to
>    handle the fragmentations.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org
> .
>
> The IETF Secretariat
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf
 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


--001a11c20e7a5becaf04fb0c7c35-- From nobody Wed Jun 4 18:36:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD7F1A03E6 for ; Wed, 4 Jun 2014 18:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjkPwarNEpwm for ; Wed, 4 Jun 2014 18:35:56 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8B39C1A03DB for ; Wed, 4 Jun 2014 18:35:55 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id B7C391248EA0 for ; Thu, 5 Jun 2014 09:35:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s551ZeSF068240 for ; Thu, 5 Jun 2014 09:35:40 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) To: netconf@ietf.org MIME-Version: 1.0 X-KeepSent: BF695BBF:DD23BC13-48257CEE:00058BBE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Thu, 5 Jun 2014 09:35:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-05 09:35:42, Serialize complete at 2014-06-05 09:35:42 Content-Type: multipart/alternative; boundary="=_alternative 0008C2A848257CEE_=" X-MAIL: mse02.zte.com.cn s551ZeSF068240 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/aMD0dgJ6iFZM1rJ6QYpyCduddLo Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, xiao.yuqing@zte.com.cn Subject: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 01:35:59 -0000 This is a multipart message in MIME format. --=_alternative 0008C2A848257CEE_= Content-Type: text/plain; charset="US-ASCII" Hi all, I have some questions about the usage of 'operation' attribute in edit-config. 1. 'replace' attribute can only be used to remove configuration? For example, the rpc request listed below is valid? 2.How to process nested operation attribute? For example: eth0/0/0 true The sequence of process is merge interface name 'eth0/0/0' and remove mtu and merge enabled to 'true' or merge interface name 'eth0/0/0' and merge enabled to 'true' and remove mtu? In other words, NETCONF will process outer layer operation firstly and process inner layer operation later, or process operations in accordance with XML tree traversal order? 3. If other operation attribute nested in operation attribute 'remove',what should NETCONF server do? Only process remove operation? 4. Can NETCONF support the nested operation attribute equals to parent operation attribute? /frank -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 0008C2A848257CEE_= Content-Type: text/html; charset="US-ASCII" Hi all,
   I have some questions about the usage of  'operation' attribute in edit-config.
   1. 'replace' attribute can only be used to remove configuration?
      For example, the rpc request listed below is valid?
      <rpc message-id = "101">
           <edit-config>
               <target>
                  <running/>
               </target>
               <config>
                  <interfaces operation= "replace"/>
               </config>
           </edit-config>
      </rpc>


   2.How to process nested operation attribute?
     For example:
           <rpc message-id = "101">
           <edit-config>
               <target>
                  <running/>
               </target>
               <config>
                  <interfaces>
                      <interface operation= "merge">
                           <name>eth0/0/0</name>
                           <mtu operation= "remove">
                           <enabled>true</enalbled>
                      </interface>
                  </interfaces>
               </config>
           </edit-config>
      </rpc>

     The sequence of process is merge interface name 'eth0/0/0' and remove mtu and merge enabled to 'true'
                             or merge interface name 'eth0/0/0' and merge enabled to 'true' and remove mtu?
     In other words, NETCONF will process outer layer operation firstly and process inner layer operation later, or process operations in accordance with XML tree traversal order?
 
3. If other operation attribute nested in operation attribute 'remove',what should NETCONF server do? Only process remove operation?

  4. Can NETCONF support the nested operation attribute equals to parent operation attribute?
     
/frank 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 0008C2A848257CEE_=-- From nobody Thu Jun 5 00:34:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6261A009E for ; Thu, 5 Jun 2014 00:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg-nZXqhHEPY for ; Thu, 5 Jun 2014 00:34:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01FB91A006B for ; Thu, 5 Jun 2014 00:33:59 -0700 (PDT) Received: from [192.168.12.238] (31.179.210.186) by AMXPR04MB199.eurprd04.prod.outlook.com (10.242.72.19) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 07:33:50 +0000 Message-ID: <53901D5B.5080003@amartus.com> Date: Thu, 5 Jun 2014 09:33:47 +0200 From: Bartosz Michalik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Netconf Content-Type: multipart/alternative; boundary="------------060306030900080200090709" X-Originating-IP: [31.179.210.186] X-ClientProxiedBy: AM3PR01CA001.eurprd01.prod.exchangelabs.com (10.242.240.11) To AMXPR04MB199.eurprd04.prod.outlook.com (10.242.72.19) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(428001)(189002)(53754006)(504964003)(199002)(64126003)(79102001)(42186004)(77982001)(59896001)(87976001)(512934002)(81342001)(83506001)(16236675004)(4396001)(84326002)(65956001)(80022001)(65806001)(20776003)(101416001)(66066001)(64706001)(76482001)(71186001)(15202345003)(46102001)(81542001)(85852003)(83072002)(15975445006)(33656002)(21056001)(102836001)(92566001)(92726001)(74502001)(99396002)(31966008)(65816999)(74662001)(36756003)(83322001)(86362001)(50986999)(87266999)(54356999)(21314002); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR04MB199; H:[192.168.12.238]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: amartus.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=bartosz.michalik@amartus.com; X-OriginatorOrg: amartus.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/t0HfILWT6OHIXyElnlFaMBRyvZY Subject: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 07:34:03 -0000 --------------060306030900080200090709 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi all, We are implementing database-backed YANG datastore with RESTCONF API. I have some problems with interpreting the spec when it comes to data updates when leafrefs are involved. More specifically I would like to know how the leafref would behave when referred leaf got updated. Let me give you an example module toy_example { namespace "http://com/example/artist"; prefix artist; container music { list artist { key name; leaf name {type string;} leaf nick_name {type string;} ... } container prerferences { leaf best_artist { type leafref { path "../artist/nick_name"; }} } } } Lets imagine I have two artists in the database Aartist("XXX") and Bartist("YYY") - nicknames in brackets. Now i have POSTed my preferences and best artist links to "YYY". Lets imagine we update Bartist nick name to "ZZZ". What would happen with best_artist leaf ? Thank you in advance for the answers, Bartosz --------------060306030900080200090709 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi all,
We are implementing database-backed YANG datastore with RESTCONF API.
I have some problems with interpreting the spec when it comes to data updates when leafrefs are involved.
More specifically I would like to know how the leafref would behave when referred leaf got updated.
Let me give you an example

module toy_example {
  namespace "http://com/example/artist";
  prefix artist;

  container music {
   list artist {
     key name;
     leaf name {type string;}
     leaf nick_name {type string;}
     ...
   }
   container prerferences {
     leaf best_artist { type leafref { path "../artist/nick_name"; }}
   }
  }
}

Lets imagine I have two artists in the database  Aartist("XXX") and Bartist("YYY") - nicknames in brackets.
Now i have POSTed my preferences and best artist links to "YYY". Lets imagine we update Bartist nick name to "ZZZ".
What would happen with best_artist leaf ?

Thank you in advance for the answers,
Bartosz
--------------060306030900080200090709-- From nobody Thu Jun 5 00:50:16 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904EA1A009E for ; Thu, 5 Jun 2014 00:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uPDXgnOrbVy for ; Thu, 5 Jun 2014 00:50:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id E3E3B1A00AA for ; Thu, 5 Jun 2014 00:50:10 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id C5C551280CBB; Thu, 5 Jun 2014 09:49:05 +0200 (CEST) Date: Thu, 05 Jun 2014 09:50:03 +0200 (CEST) Message-Id: <20140605.095003.54892709867665329.mbj@tail-f.com> To: bartosz.michalik@amartus.com From: Martin Bjorklund In-Reply-To: <53901D5B.5080003@amartus.com> References: <53901D5B.5080003@amartus.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qGKACqE2YUyBdhUa70KyuxugnBI Cc: netconf@ietf.org Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 07:50:13 -0000 Bartosz Michalik wrote: > Hi all, > We are implementing database-backed YANG datastore with RESTCONF API. > I have some problems with interpreting the spec when it comes to data > updates when leafrefs are involved. > More specifically I would like to know how the leafref would behave > when referred leaf got updated. > Let me give you an example > > module toy_example { > namespace "http://com/example/artist"; > prefix artist; > > container music { > list artist { > key name; > leaf name {type string;} > leaf nick_name {type string;} > ... > } > container prerferences { > leaf best_artist { type leafref { path "../artist/nick_name"; }} > } > } > } > > Lets imagine I have two artists in the database Aartist("XXX") and > Bartist("YYY") - nicknames in brackets. > Now i have POSTed my preferences and best artist links to "YYY". Lets > imagine we update Bartist nick name to "ZZZ". > What would happen with best_artist leaf ? Nothing, but the resulting configuration would not be valid since the leafref points to a non-existing leaf, and thus your POST request would fail. /martin From nobody Thu Jun 5 00:57:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CF71A00AA for ; Thu, 5 Jun 2014 00:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCShL9npDfT4 for ; Thu, 5 Jun 2014 00:57:40 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C921A00A9 for ; Thu, 5 Jun 2014 00:57:40 -0700 (PDT) Received: from [192.168.12.238] (31.179.210.186) by DBXPR04MB208.eurprd04.prod.outlook.com (10.242.140.153) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 07:57:32 +0000 Message-ID: <539022EA.5030603@amartus.com> Date: Thu, 5 Jun 2014 09:57:30 +0200 From: Bartosz Michalik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Martin Bjorklund References: <53901D5B.5080003@amartus.com> <20140605.095003.54892709867665329.mbj@tail-f.com> In-Reply-To: <20140605.095003.54892709867665329.mbj@tail-f.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [31.179.210.186] X-ClientProxiedBy: AM3PR01CA001.eurprd01.prod.exchangelabs.com (10.242.240.11) To DBXPR04MB208.eurprd04.prod.outlook.com (10.242.140.153) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(6009001)(428001)(53754006)(24454002)(51704005)(189002)(199002)(33656002)(74502001)(74662001)(31966008)(46102001)(42186004)(21056001)(36756003)(64126003)(50986999)(4396001)(81342001)(99396002)(76176999)(87266999)(65816999)(15202345003)(81542001)(92566001)(50466002)(79102001)(54356999)(101416001)(77982001)(59896001)(47776003)(64706001)(20776003)(102836001)(76482001)(83506001)(65806001)(83322001)(23756003)(19580405001)(19580395003)(87976001)(15975445006)(80022001)(92726001)(86362001)(83072002)(66066001)(65956001)(85852003)(21314002); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR04MB208; H:[192.168.12.238]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: amartus.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=bartosz.michalik@amartus.com; X-OriginatorOrg: amartus.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1uLDNEOVfIy1UOtZBu8B7twVRO4 Cc: netconf@ietf.org Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 07:57:42 -0000 On 05.06.2014 09:50, Martin Bjorklund wrote: > Bartosz Michalik wrote: >> Hi all, >> We are implementing database-backed YANG datastore with RESTCONF API. >> I have some problems with interpreting the spec when it comes to data >> updates when leafrefs are involved. >> More specifically I would like to know how the leafref would behave >> when referred leaf got updated. >> Let me give you an example >> >> module toy_example { >> namespace "http://com/example/artist"; >> prefix artist; >> >> container music { >> list artist { >> key name; >> leaf name {type string;} >> leaf nick_name {type string;} >> ... >> } >> container prerferences { >> leaf best_artist { type leafref { path "../artist/nick_name"; }} >> } >> } >> } >> >> Lets imagine I have two artists in the database Aartist("XXX") and >> Bartist("YYY") - nicknames in brackets. >> Now i have POSTed my preferences and best artist links to "YYY". Lets >> imagine we update Bartist nick name to "ZZZ". >> What would happen with best_artist leaf ? > Nothing, but the resulting configuration would not be valid since the > leafref points to a non-existing leaf, and thus your POST request > would fail. > > > /martin So leafref is a "reference by value" and adds modification-lock to the leaf it refers to. Thank you for the clarification. Greetings, Bartosz From nobody Thu Jun 5 01:31:17 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E04B1A0102 for ; Thu, 5 Jun 2014 01:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4c7HTzPDy_M for ; Thu, 5 Jun 2014 01:31:05 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B8C611A00A9 for ; Thu, 5 Jun 2014 01:31:05 -0700 (PDT) Received: from mars.tail-f.com (mars.tail-f.com [192.168.1.70]) by mail.tail-f.com (Postfix) with ESMTPSA id A788F1280CB6; Thu, 5 Jun 2014 10:29:56 +0200 (CEST) Message-ID: <53902ABE.5040603@tail-f.com> Date: Thu, 05 Jun 2014 10:30:54 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bartosz Michalik References: <53901D5B.5080003@amartus.com> <20140605.095003.54892709867665329.mbj@tail-f.com> <539022EA.5030603@amartus.com> In-Reply-To: <539022EA.5030603@amartus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ty07kJY_K-peZbUSeLBf9Intv8A Cc: netconf@ietf.org Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:31:11 -0000 On 2014-06-05 09:57, Bartosz Michalik wrote: > > On 05.06.2014 09:50, Martin Bjorklund wrote: >> Bartosz Michalik wrote: >>> Hi all, >>> We are implementing database-backed YANG datastore with RESTCONF API. >>> I have some problems with interpreting the spec when it comes to data >>> updates when leafrefs are involved. >>> More specifically I would like to know how the leafref would behave >>> when referred leaf got updated. >>> Let me give you an example >>> >>> module toy_example { >>> namespace "http://com/example/artist"; >>> prefix artist; >>> >>> container music { >>> list artist { >>> key name; >>> leaf name {type string;} >>> leaf nick_name {type string;} >>> ... >>> } >>> container prerferences { >>> leaf best_artist { type leafref { path "../artist/nick_name"; }} >>> } >>> } >>> } >>> >>> Lets imagine I have two artists in the database Aartist("XXX") and >>> Bartist("YYY") - nicknames in brackets. >>> Now i have POSTed my preferences and best artist links to "YYY". Lets >>> imagine we update Bartist nick name to "ZZZ". >>> What would happen with best_artist leaf ? >> Nothing, but the resulting configuration would not be valid since the >> leafref points to a non-existing leaf, and thus your POST request >> would fail. >> >> >> /martin > So leafref is a "reference by value" and adds modification-lock to the leaf it refers to. I believe a more correct way to look at leafref is (besides the type-copy) purely as a constraint on the value space. If you update Bartist nick name to "ZZZ" *and* Aartist nick name to "YYY", the resulting configuration is still fine, even though the leafref then "refers to" a different leaf (and of course you could have both nick names be "YYY", in which case there is no way to tell which of them the leafref "refers to"). I frequently see confusion about the semantics of leafref among our "YANG newbie" customers, mostly that it is thought of as some kind of "link" rather than a constraint. Maybe the name isn't ideal (I'm not suggesting to change it though:-), and the text in RFC 6020, while it does eventually tell everything, is perhaps not ideal either. E.g. it starts out with The leafref type is used to reference a particular leaf instance in the data tree. - which, if not actually incorrect in the general case (see above), is at least IMHO leading the reader down the wrong thought path. Maybe The leafref type is used to declare a constraint on the value space of a leaf, based on a reference to a set of leaf instances in the data tree. would be better... --Per Hedeland > Thank you for the clarification. > Greetings, > Bartosz From nobody Thu Jun 5 01:39:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366381A038D; Thu, 5 Jun 2014 01:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSM3eTcxCmu4; Thu, 5 Jun 2014 01:39:26 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (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 CC1B61A0420; Thu, 5 Jun 2014 01:39:23 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1WsTCY-0008NM-RF; Thu, 05 Jun 2014 10:39:13 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh-5.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WsTCY-00060Y-MR; Thu, 05 Jun 2014 10:39:10 +0200 Message-ID: <53902CAD.6010906@bwijnen.net> Date: Thu, 05 Jun 2014 10:39:09 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: feng.chong33@zte.com.cn, Andy Bierman References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd472f316c343e4005b1faa0e99fd53c9e2 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/K97r4PKgGe3OONe9aI1NnKgILqs Cc: Zhengguangying , Netconf , Netconf , Yangang Subject: Re: [Netconf] =?utf-8?b?562U5aSNOiBSZTogIE5ldGNvbmYgZnJhZ21lbnRhdGlv?= =?utf-8?q?n-//FW=3A_New_Version_Notification_for_draft-liu-netconf-fragme?= =?utf-8?q?ntation-00=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:39:28 -0000 I am a bit concerned that we are now discussing a possible solution. BUT.... I think we should first discuss on this list: - Is the problem statement describing a real problem that we all agree with? - If it is, do we believe that our WG should work on a solution? Once we have agree on that, we can decide if we want to add this topic to our WG charter and work on it. Bert (speaking as co-chair) On 05/06/14 02:59, feng.chong33@zte.com.cn wrote: > andy, > How to process nested lists using your solution? > > For example: > list foo { > key a; > leaf a {...} > leaf b {...} > list nested-foo { > key nested-a; > leaf nested-a {...} > leaf netsted-b {...} > } > } > > If request is: > > > /foo > > > What is the response? > > And, another question: > Start-index is not reliable, if some entries are deleted. I think you can use start key instead. > > > > /frank > > "Netconf" 写于 2014-06-05 00:43:12: > > > Andy Bierman > > 发件人: "Netconf" > > > > 2014-06-05 00:43 > > > > 收件人 > > > > chong feng , > > > > 抄送 > > > > Zhengguangying , Netconf > > , Yangang > > > > 主题 > > > > Re: [Netconf] Netconf fragmentation-//FW: New Version Notification > > for draft-liu-netconf-fragmentation-00.txt > > > > > > > On Wed, Jun 4, 2014 at 8:32 AM, chong feng wrote: > > Hi, > > I have reviewed this new draft. > > I understand your solution is that NETCONF server reserve break > > points and wait for client to retrieve the next response. > > I think it's not a good solution, because server may need to reserve > > many break points if there a large number of concurrent requests. > > It's too heavy for server. And, the server must be stateful if it > > support get-block capability. > > > > > > I agree with these concerns. Holding a snapshot of state data for > > interactive retrieval > > by the client is very expensive. > > > > I do not agree with the premise that the client needs to know the > > key values in advance. > > An "iterator" approach allows a list resource to be retrieved in > > chunks. This is what RESTCONF > > is going to do, and NETCONF could add a similar RPC function: > > > > rpc get-list { > > input { > > leaf target { > > type schema-instance-identifier; > > description "Identifies subtree to retrieve."; > > } > > leaf start { > > type uint32; > > default 0; > > description "Number of entries to skip before starting retrieval"; > > } > > leaf max-entries { > > type uint32 { range "1..max"; } > > default 25; > > description "Maximum number of list entries to retrieve"; > > } > > } > > output { > > anyxml data { > > description "Contains the requested data"; > > } > > } > > } > > > > > > > > /if:interfaces/if:interface > > > > > > > > > > > > > > .... first entry > > ... > > .... 25th entry > > > > > > > > > > > > > > /if:interfaces/if:interface > > 25 > > > > > > > > > > > > > > .... 26th entry > > ... > > .... 50th entry > > > > > > > > > > There is a problem with rapidly changing lists > > (could get repeat entries on miss some entries), but the snapshot > > approach uses too much memory, and if the list instances > > change rapidly, a stale snapshot is not very useful. > > > > Andy > > > > The other questions and comments are listed below: > > 1. Get-block capability should not change the get-config operation's > > behavior. If client use get-config operation to retrieve data, > > all data must be sent in one response or get-block capability should > > add a parameter to get-config operation to indicate the > > response data will be fragmented. > > 2. A set-id can be aged? when client never send a request to > > retrieve the next fragment for a long time, I think this set-id > > should be aged, > > otherwise, server will be reserve more and more set-ids. > > 3. A set-id is unique in session level or server level? > > 4. If a session is killed or closed, other session can retrieved the > > next fragment if the client provide the correct set-id? > > /frank > > > > > 2014-06-04 18:22 GMT+08:00 Liubing (Leo) : > > Hi all, > > > > We've posted a new draft, which is about NETCONF data fragmentation. > > > > The basic idea is, when NMS is retrieving a large size of data in > > the device, the might be very big (e.g. the routes in a > > core router). > > Currently there are mainly two methods of handling the big > reply>: one is stream-oriented handling; the other is just request a > > portion of the data. > > > > This draft considers both the two methods are problematic in some > > situations, and proposes a new method which allows the large size > > to be fragmented in NETCONF level. > > > > Please read the draft and comment. > > Many thanks! > > > > Best regards, > > Bing > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, June 04, 2014 5:27 PM > > To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying > > Subject: New Version Notification for draft-liu-netconf-fragmentation-00.txt > > > > > > A new version of I-D, draft-liu-netconf-fragmentation-00.txt > > has been successfully submitted by Bing Liu and posted to the IETF repository. > > > > Name: draft-liu-netconf-fragmentation > > Revision: 00 > > Title: A NETCONF Extension for Data Fragmentation > > Document date: 2014-06-04 > > Group: Individual Submission > > Pages: 12 > > URL: http://www.ietf.org/internet-drafts/draft-liu- > > netconf-fragmentation-00.txt > > Status: https://datatracker.ietf.org/doc/draft-liu-netconf- > > fragmentation/ > > Htmlized: http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00 > > > > > > Abstract: > > This document introduces an extension to NETCONF (Network > > Configuration) protocol. The extension allows NETCONF to handle large > > size data as fragmented RPC messages. Specifically, this document > > defines a new capability and relevant operations to > > handle the fragmentations. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org > > . > > > > The IETF Secretariat > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Jun 5 01:39:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4FC1A0420 for ; Thu, 5 Jun 2014 01:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXfjFFW-adwi for ; Thu, 5 Jun 2014 01:39:27 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200A71A042A for ; Thu, 5 Jun 2014 01:39:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5C5BF115F; Thu, 5 Jun 2014 10:39:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UnOJ5i-Q-2WM; Thu, 5 Jun 2014 10:39:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Jun 2014 10:39:16 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CF4420017; Thu, 5 Jun 2014 10:39:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9fnuXfoI3hQ3; Thu, 5 Jun 2014 10:39:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64DD420013; Thu, 5 Jun 2014 10:39:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 47A8A2D51EFF; Thu, 5 Jun 2014 10:39:16 +0200 (CEST) Date: Thu, 5 Jun 2014 10:39:16 +0200 From: Juergen Schoenwaelder To: Per Hedeland Message-ID: <20140605083916.GB10945@elstar.local> Mail-Followup-To: Per Hedeland , Bartosz Michalik , netconf@ietf.org References: <53901D5B.5080003@amartus.com> <20140605.095003.54892709867665329.mbj@tail-f.com> <539022EA.5030603@amartus.com> <53902ABE.5040603@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53902ABE.5040603@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/MmmAQfE0q5DiJn0DiSVpCnZwxVQ Cc: netconf@ietf.org Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:39:28 -0000 On Thu, Jun 05, 2014 at 10:30:54AM +0200, Per Hedeland wrote: > > I frequently see confusion about the semantics of leafref among our > "YANG newbie" customers, mostly that it is thought of as some kind of > "link" rather than a constraint. Maybe the name isn't ideal (I'm not > suggesting to change it though:-), and the text in RFC 6020, while it > does eventually tell everything, is perhaps not ideal either. E.g. it > starts out with > > The leafref type is used to reference a particular leaf instance in > the data tree. > > - which, if not actually incorrect in the general case (see above), is > at least IMHO leading the reader down the wrong thought path. Maybe > > The leafref type is used to declare a constraint on the value space of > a leaf, based on a reference to a set of leaf instances in the data > tree. > > would be better... I agree that the first sentence in 9.9, in particular the phrase "reference a particular leaf instance", is likely confusing. If others feel the same, perhaps the right thing is to open an erratum so we can track this and finally fix it in YANG 1.1. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jun 5 01:47:35 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E941A0270 for ; Thu, 5 Jun 2014 01:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aze0VFLQmzy4 for ; Thu, 5 Jun 2014 01:47:32 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3CF1A0102 for ; Thu, 5 Jun 2014 01:47:24 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s558lEE0032329; Thu, 5 Jun 2014 10:47:14 +0200 Message-ID: <53902E91.5070102@mg-soft.com> Date: Thu, 05 Jun 2014 10:47:13 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Per Hedeland , Bartosz Michalik , netconf@ietf.org References: <53901D5B.5080003@amartus.com> <20140605.095003.54892709867665329.mbj@tail-f.com> <539022EA.5030603@amartus.com> <53902ABE.5040603@tail-f.com> <20140605083916.GB10945@elstar.local> In-Reply-To: <20140605083916.GB10945@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ygISBEHh8yYAlSOwYQuttCNDdOk Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:47:34 -0000 Dne 5.6.2014 10:39, pie Juergen Schoenwaelder: > On Thu, Jun 05, 2014 at 10:30:54AM +0200, Per Hedeland wrote: >> I frequently see confusion about the semantics of leafref among our >> "YANG newbie" customers, mostly that it is thought of as some kind of >> "link" rather than a constraint. Maybe the name isn't ideal (I'm not >> suggesting to change it though:-), and the text in RFC 6020, while it >> does eventually tell everything, is perhaps not ideal either. E.g. it >> starts out with >> >> The leafref type is used to reference a particular leaf instance in >> the data tree. >> >> - which, if not actually incorrect in the general case (see above), is >> at least IMHO leading the reader down the wrong thought path. Maybe >> >> The leafref type is used to declare a constraint on the value space of >> a leaf, based on a reference to a set of leaf instances in the data >> tree. >> >> would be better... > I agree that the first sentence in 9.9, in particular the phrase > "reference a particular leaf instance", is likely confusing. If others > feel the same, perhaps the right thing is to open an erratum so we can > track this and finally fix it in YANG 1.1. +1 Jernej > > /js > From nobody Thu Jun 5 01:49:10 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D416B1A042E for ; Thu, 5 Jun 2014 01:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1lp5y7eZch3 for ; Thu, 5 Jun 2014 01:49:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2DD1A0102 for ; Thu, 5 Jun 2014 01:49:07 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 3EADBED05C7; Thu, 5 Jun 2014 10:48:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1401958137; bh=+zKU1iwF2c493ezsjSyPRsb1rXCwJpsv+5zMRnUmv9Y=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IdtwV+p4ix1b+P0NEZYDEzxUfVpbbOSkWgL3GWdasZE/VQyIA8DhxsH9Oj4YcbMxn l4565e77Yo4bhik/GX8AijxZbEkbDkyIadLHCfPMIj12LuiJR4RMHOtiAAbrD43tnR OwLkpqITHvnXDgMWtb+HqPuYbybxx4lO+oZ6K2iE= Message-ID: <53902EAB.4070905@cesnet.cz> Date: Thu, 05 Jun 2014 10:47:39 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Per Hedeland , Bartosz Michalik , netconf@ietf.org References: <53901D5B.5080003@amartus.com> <20140605.095003.54892709867665329.mbj@tail-f.com> <539022EA.5030603@amartus.com> <53902ABE.5040603@tail-f.com> <20140605083916.GB10945@elstar.local> In-Reply-To: <20140605083916.GB10945@elstar.local> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/AjGCK7h6-8U99SPdtXCAgbh_gds Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:49:09 -0000 Dne 5.6.2014 10:39, Juergen Schoenwaelder napsal(a): > On Thu, Jun 05, 2014 at 10:30:54AM +0200, Per Hedeland wrote: >> I frequently see confusion about the semantics of leafref among our >> "YANG newbie" customers, mostly that it is thought of as some kind of >> "link" rather than a constraint. Maybe the name isn't ideal (I'm not >> suggesting to change it though:-), and the text in RFC 6020, while it >> does eventually tell everything, is perhaps not ideal either. E.g. it >> starts out with >> >> The leafref type is used to reference a particular leaf instance in >> the data tree. >> >> - which, if not actually incorrect in the general case (see above), is >> at least IMHO leading the reader down the wrong thought path. Maybe >> >> The leafref type is used to declare a constraint on the value space of >> a leaf, based on a reference to a set of leaf instances in the data >> tree. >> >> would be better... > I agree that the first sentence in 9.9, in particular the phrase > "reference a particular leaf instance", is likely confusing. If others > feel the same, perhaps the right thing is to open an erratum so we can > track this and finally fix it in YANG 1.1. > > /js > +1 Radek From nobody Thu Jun 5 01:49:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DF41A0102 for ; Thu, 5 Jun 2014 01:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmJ1MSHOAuoU for ; Thu, 5 Jun 2014 01:49:43 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0077.outbound.protection.outlook.com [213.199.154.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56BC31A0431 for ; Thu, 5 Jun 2014 01:49:42 -0700 (PDT) Received: from DB3PRD0210HT002.eurprd02.prod.outlook.com (157.56.253.69) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 08:49:34 +0000 Message-ID: <015b01cf809a$a9cae8c0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Andy Bierman References: <538F178E.6060400@cisco.com> Date: Thu, 5 Jun 2014 09:46:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-ClientProxiedBy: AM3PR07CA0048.eurprd07.prod.outlook.com (10.141.45.176) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(51704005)(377454003)(13464003)(42186004)(47776003)(20776003)(83322001)(84392001)(1941001)(93886002)(83072002)(89996001)(76482001)(86362001)(93916002)(85852003)(92566001)(19580405001)(88136002)(76176999)(87286001)(19580395003)(81686999)(81816999)(92726001)(50986999)(14496001)(87976001)(46102001)(64706001)(33646001)(50226001)(44736004)(23756003)(81342001)(4396001)(21056001)(80022001)(50466002)(77156001)(66066001)(102836001)(99396002)(62966002)(77982001)(62236002)(81542001)(61296002)(79102001)(44716002)(101416001)(74662001)(74502001)(104166001)(31966008)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB049; H:DB3PRD0210HT002.eurprd02.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2CtwQ0plPrTr249_N4vCWEwVLkQ Cc: Boris Pilka , Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:49:48 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Andy Bierman" Cc: "Boris Pilka" ; "Netconf" Sent: Wednesday, June 04, 2014 7:31 PM > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. > > It says "NETCONF XML". > Does this imply that a SYSLOG text stream also needs to be wrapped in XML > and sent as a element on the NETCONF stream? I hope not. My interpretation is that the NETCONF stream contains all notifications defined by all YANG modules advertised by the device. Only problem is the RFC5277 doesn't mention YANG anywhere... No reason why it should! NETCONF came first, and RFC4741 makes no mention of any modelling language, so there is no reason for RFC5277 to do so either. Recall that YANG is an afterthought, formally introduced only in RFC6241. XML is required, YANG, I hope, not. Tom Petch That reading would exclude SYSLOG messages, thankfully. > Probably needs clarification. ;-) Right, e.g., what is "NETCONF XML" ? From nobody Thu Jun 5 01:55:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341881A0102 for ; Thu, 5 Jun 2014 01:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aDdfrBmvIpU for ; Thu, 5 Jun 2014 01:55:21 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66391A042F for ; Thu, 5 Jun 2014 01:55:20 -0700 (PDT) Received: from [192.168.12.238] (31.179.210.186) by AMXPR04MB199.eurprd04.prod.outlook.com (10.242.72.19) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 08:55:12 +0000 Message-ID: <5390306F.4000100@amartus.com> Date: Thu, 5 Jun 2014 10:55:11 +0200 From: Bartosz Michalik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Per Hedeland , References: <53901D5B.5080003@amartus.com> <20140605.095003.54892709867665329.mbj@tail-f.com> <539022EA.5030603@amartus.com> <53902ABE.5040603@tail-f.com> <20140605083916.GB10945@elstar.local> In-Reply-To: <20140605083916.GB10945@elstar.local> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [31.179.210.186] X-ClientProxiedBy: AM3PR01CA004.eurprd01.prod.exchangelabs.com (10.242.240.14) To AMXPR04MB199.eurprd04.prod.outlook.com (10.242.72.19) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(6009001)(428001)(24454002)(51704005)(199002)(189002)(21056001)(92726001)(102836001)(92566001)(83072002)(85852003)(81542001)(33656002)(50466002)(93886002)(86362001)(83322001)(50986999)(87266999)(54356999)(76176999)(65816999)(31966008)(74662001)(74502001)(99396002)(36756003)(4396001)(83506001)(81342001)(64706001)(76482001)(20776003)(47776003)(65956001)(80022001)(65806001)(66066001)(101416001)(42186004)(59896001)(77982001)(64126003)(79102001)(87976001)(46102001)(23756003); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR04MB199; H:[192.168.12.238]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: amartus.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=bartosz.michalik@amartus.com; X-OriginatorOrg: amartus.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Rd8dgd7Rz2Zu77b95OotYlxQQC8 Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:55:23 -0000 On 05.06.2014 10:39, Juergen Schoenwaelder wrote: > I agree that the first sentence in 9.9, in particular the phrase > "reference a particular leaf instance", is likely confusing. If others > feel the same, perhaps the right thing is to open an erratum so we can > track this and finally fix it in YANG 1.1. > > /js > +1 Bartosz From nobody Thu Jun 5 02:00:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3FF1A0407 for ; Thu, 5 Jun 2014 02:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYQvkn_sgLzO for ; Thu, 5 Jun 2014 02:00:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 129B51A01C0 for ; Thu, 5 Jun 2014 02:00:33 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id EF0381280CB6; Thu, 5 Jun 2014 10:59:27 +0200 (CEST) Date: Thu, 05 Jun 2014 11:00:26 +0200 (CEST) Message-Id: <20140605.110026.809546159633050650.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140605083916.GB10945@elstar.local> References: <539022EA.5030603@amartus.com> <53902ABE.5040603@tail-f.com> <20140605083916.GB10945@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Pe7XTWLdvluoVedypm8zChhmqhw Cc: netconf@ietf.org Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:00:34 -0000 Juergen Schoenwaelder wrote: > On Thu, Jun 05, 2014 at 10:30:54AM +0200, Per Hedeland wrote: > > > > I frequently see confusion about the semantics of leafref among our > > "YANG newbie" customers, mostly that it is thought of as some kind of > > "link" rather than a constraint. Maybe the name isn't ideal (I'm not > > suggesting to change it though:-), and the text in RFC 6020, while it > > does eventually tell everything, is perhaps not ideal either. E.g. it > > starts out with > > > > The leafref type is used to reference a particular leaf instance in > > the data tree. > > > > - which, if not actually incorrect in the general case (see above), is > > at least IMHO leading the reader down the wrong thought path. Maybe > > > > The leafref type is used to declare a constraint on the value space of > > a leaf, based on a reference to a set of leaf instances in the data > > tree. > > > > would be better... > > I agree that the first sentence in 9.9, in particular the phrase > "reference a particular leaf instance", is likely confusing. If others > feel the same, perhaps the right thing is to open an erratum so we can > track this and finally fix it in YANG 1.1. +1 for fix in 1.1, but do we really need to open an errata? /martin From nobody Thu Jun 5 02:12:09 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34311A03BE; Thu, 5 Jun 2014 02:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.6 X-Spam-Level: X-Spam-Status: No, score=-96.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlvXJm6YG8wF; Thu, 5 Jun 2014 02:12:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 145191A0365; Thu, 5 Jun 2014 02:11:59 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id B221012878EC; Thu, 5 Jun 2014 17:11:38 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id B0B1B74020E; Thu, 5 Jun 2014 17:11:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s559Bdsq064578; Thu, 5 Jun 2014 17:11:39 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <53902CAD.6010906@bwijnen.net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <53902CAD.6010906@bwijnen.net> To: "Bert Wijnen (IETF)" MIME-Version: 1.0 X-KeepSent: FD8D362B:D44EF15B-48257CEE:0031EDD5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Thu, 5 Jun 2014 17:11:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-05 17:11:41, Serialize complete at 2014-06-05 17:11:41 Content-Type: multipart/alternative; boundary="=_alternative 003281CA48257CEE_=" X-MAIL: mse01.zte.com.cn s559Bdsq064578 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6oEmYTYcPIKOY06lq4Fx8JTQT9M Cc: Zhengguangying , Netconf , Yangang , Netconf Subject: Re: [Netconf] =?gb2312?b?tPC4tDogUmU6ICBOZXRjb25mIGZyYWdtZW50YXRpb24t?= =?gb2312?b?Ly9GVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUt?= =?gb2312?b?bmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA==?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:12:07 -0000 This is a multipart message in MIME format. --=_alternative 003281CA48257CEE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 L2ZyYW5rDQoNCiJCZXJ0IFdpam5lbiAoSUVURikiIDxiZXJ0aWV0ZkBid2lqbmVuLm5ldD4g0LTT 2iAyMDE0LTA2LTA1IDE2OjM5OjA5Og0KDQo+ICJCZXJ0IFdpam5lbiAoSUVURikiIDxiZXJ0aWV0 ZkBid2lqbmVuLm5ldD4gDQo+IDIwMTQtMDYtMDUgMTY6MzkNCj4gDQo+IMrVvP7Iyw0KPiANCj4g ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29t PiwgDQo+IA0KPiCzrcvNDQo+IA0KPiBaaGVuZ2d1YW5neWluZyA8emhlbmdndWFuZ3lpbmdAaHVh d2VpLmNvbT4sIE5ldGNvbmYgPG5ldGNvbmYtDQo+IGJvdW5jZXNAaWV0Zi5vcmc+LCBOZXRjb25m IDxuZXRjb25mQGlldGYub3JnPiwgWWFuZ2FuZyANCjx5YW5nYW5nQGh1YXdlaS5jb20+DQo+IA0K PiDW98ziDQo+IA0KPiBSZTogW05ldGNvbmZdILTwuLQ6IFJlOiAgTmV0Y29uZiBmcmFnbWVudGF0 aW9uLS8vRlc6IE5ldyBWZXJzaW9uIA0KPiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1uZXRj b25mLWZyYWdtZW50YXRpb24tMDAudHh0DQo+IA0KPiBJIGFtIGEgYml0IGNvbmNlcm5lZCB0aGF0 IHdlIGFyZSBub3cgZGlzY3Vzc2luZyBhIHBvc3NpYmxlIHNvbHV0aW9uLg0KPiANCj4gQlVULi4u LiBJIHRoaW5rIHdlIHNob3VsZCBmaXJzdCBkaXNjdXNzIG9uIHRoaXMgbGlzdDoNCj4gDQo+IC0g SXMgdGhlIHByb2JsZW0gc3RhdGVtZW50IGRlc2NyaWJpbmcgYSByZWFsIHByb2JsZW0gdGhhdCB3 ZSBhbGwgYWdyZWUgDQp3aXRoPw0KSSBhZ3JlZS4gQnV0IEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGlz IHNvbHV0aW9uLiBORVRDT05GIHNlcnZlciBzaG91bGQgYmUgDQpzdGF0ZWxlc3MsIA0Kb25lIHJl cXVlc3Qgc2hvdWxkIG9ubHkgaGF2ZSBvbmUgcmVzcG9uc2UuDQo+IA0KPiAtIElmIGl0IGlzLCBk byB3ZSBiZWxpZXZlIHRoYXQgb3VyIFdHIHNob3VsZCB3b3JrIG9uIGEgc29sdXRpb24/DQpJIHRo aW5rIFdHIHNob3VsZCB3b3JrIG9uIGEgc29sdXRpb24uIFdoZW4gd2UgcmVhbGl6ZWQgTkVUQ09O Riwgd2UgYWxzbyANCmhhdmUgZW5jb3VudGVyZWQgdGhpcyBwcm9ibGVtLg0KPiANCj4gT25jZSB3 ZSBoYXZlIGFncmVlIG9uIHRoYXQsIHdlIGNhbiBkZWNpZGUgaWYgd2Ugd2FudCB0byBhZGQgdGhp cyB0b3BpYw0KPiB0byBvdXIgV0cgY2hhcnRlciBhbmQgd29yayBvbiBpdC4NCj4gDQo+IEJlcnQg KHNwZWFraW5nIGFzIGNvLWNoYWlyKQ0KPiANCj4gT24gMDUvMDYvMTQgMDI6NTksIGZlbmcuY2hv bmczM0B6dGUuY29tLmNuIHdyb3RlOg0KPiA+IGFuZHksDQo+ID4gICAgIEhvdyB0byBwcm9jZXNz IG5lc3RlZCBsaXN0cyB1c2luZyB5b3VyIHNvbHV0aW9uPw0KPiA+DQo+ID4gRm9yIGV4YW1wbGU6 DQo+ID4gICAgIGxpc3QgZm9vIHsNCj4gPiAgICAgICAgIGtleSBhOw0KPiA+ICAgICAgICAgbGVh ZiBhIHsuLi59DQo+ID4gICAgICAgICBsZWFmIGIgey4uLn0NCj4gPiAgICAgICAgIGxpc3QgbmVz dGVkLWZvbyB7DQo+ID4ga2V5IG5lc3RlZC1hOw0KPiA+IGxlYWYgbmVzdGVkLWEgey4uLn0NCj4g PiBsZWFmIG5ldHN0ZWQtYiB7Li4ufQ0KPiA+ICAgICAgICAgfQ0KPiA+ICAgICB9DQo+ID4NCj4g PiAgICBJZiByZXF1ZXN0IGlzOg0KPiA+IDxycGM+DQo+ID4gICAgICAgPGdldC1saXN0Pg0KPiA+ ICAgICAgICAgPHRhcmdldD4vZm9vPC90YXJnZXQ+DQo+ID4gICAgICAgPC9nZXQtbGlzdD4NCj4g PiAgICAgPC9ycGM+DQo+ID4gICAgV2hhdCBpcyB0aGUgcmVzcG9uc2U/DQo+ID4NCj4gPiBBbmQs IGFub3RoZXIgcXVlc3Rpb246DQo+ID4gU3RhcnQtaW5kZXggaXMgbm90IHJlbGlhYmxlLCBpZiBz b21lIGVudHJpZXMgYXJlIGRlbGV0ZWQuIEkgdGhpbmsgDQo+IHlvdSBjYW4gdXNlIHN0YXJ0IGtl eSBpbnN0ZWFkLg0KPiA+DQo+ID4NCj4gPg0KPiA+IC9mcmFuaw0KPiA+DQo+ID4gIk5ldGNvbmYi IDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+INC009ogMjAxNC0wNi0wNSAwMDo0MzoxMjoNCj4g Pg0KPiA+ICA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0KPiA+ICA+ILeivP7I yzogICJOZXRjb25mIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPg0KPiA+ICA+DQo+ID4gID4g MjAxNC0wNi0wNSAwMDo0Mw0KPiA+ICA+DQo+ID4gID4gytW8/sjLDQo+ID4gID4NCj4gPiAgPiBj aG9uZyBmZW5nIDxmZW5nY2hvbmdsbGx5QGdtYWlsLmNvbT4sDQo+ID4gID4NCj4gPiAgPiCzrcvN DQo+ID4gID4NCj4gPiAgPiBaaGVuZ2d1YW5neWluZyA8emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNv bT4sIE5ldGNvbmYNCj4gPiAgPiA8bmV0Y29uZkBpZXRmLm9yZz4sIFlhbmdhbmcgPHlhbmdhbmdA aHVhd2VpLmNvbT4NCj4gPiAgPg0KPiA+ICA+INb3zOINCj4gPiAgPg0KPiA+ICA+IFJlOiBbTmV0 Y29uZl0gTmV0Y29uZiBmcmFnbWVudGF0aW9uLS8vRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv bg0KPiA+ICA+IGZvciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA0KPiA+ ICA+DQo+ID4gID4NCj4gPg0KPiA+ICA+IE9uIFdlZCwgSnVuIDQsIDIwMTQgYXQgODozMiBBTSwg Y2hvbmcgZmVuZyANCj4gPGZlbmdjaG9uZ2xsbHlAZ21haWwuY29tPiB3cm90ZToNCj4gPiAgPiBI aSwNCj4gPiAgPiAgICBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBuZXcgZHJhZnQuDQo+ID4gID4gICAg SSB1bmRlcnN0YW5kIHlvdXIgc29sdXRpb24gaXMgdGhhdCBORVRDT05GIHNlcnZlciByZXNlcnZl IGJyZWFrDQo+ID4gID4gcG9pbnRzIGFuZCB3YWl0IGZvciBjbGllbnQgdG8gcmV0cmlldmUgdGhl IG5leHQgcmVzcG9uc2UuDQo+ID4gID4gSSB0aGluayBpdCdzIG5vdCBhIGdvb2Qgc29sdXRpb24s IGJlY2F1c2Ugc2VydmVyIG1heSBuZWVkIHRvIA0KcmVzZXJ2ZQ0KPiA+ICA+IG1hbnkgYnJlYWsg cG9pbnRzIGlmIHRoZXJlIGEgbGFyZ2UgbnVtYmVyIG9mIGNvbmN1cnJlbnQgcmVxdWVzdHMuDQo+ ID4gID4gSXQncyB0b28gaGVhdnkgZm9yIHNlcnZlci4gQW5kLCB0aGUgc2VydmVyIG11c3QgYmUg c3RhdGVmdWwgaWYgaXQNCj4gPiAgPiBzdXBwb3J0IGdldC1ibG9jayBjYXBhYmlsaXR5Lg0KPiA+ ICA+DQo+ID4gID4NCj4gPiAgPiBJIGFncmVlIHdpdGggdGhlc2UgY29uY2VybnMuICBIb2xkaW5n IGEgc25hcHNob3Qgb2Ygc3RhdGUgZGF0YSBmb3INCj4gPiAgPiBpbnRlcmFjdGl2ZSByZXRyaWV2 YWwNCj4gPiAgPiBieSB0aGUgY2xpZW50IGlzIHZlcnkgZXhwZW5zaXZlLg0KPiA+ICA+DQo+ID4g ID4gSSBkbyBub3QgYWdyZWUgd2l0aCB0aGUgcHJlbWlzZSB0aGF0IHRoZSBjbGllbnQgbmVlZHMg dG8ga25vdyB0aGUNCj4gPiAgPiBrZXkgdmFsdWVzIGluIGFkdmFuY2UuDQo+ID4gID4gQW4gIml0 ZXJhdG9yIiBhcHByb2FjaCBhbGxvd3MgYSBsaXN0IHJlc291cmNlIHRvIGJlIHJldHJpZXZlZCBp bg0KPiA+ICA+IGNodW5rcy4gIFRoaXMgaXMgd2hhdCBSRVNUQ09ORg0KPiA+ICA+IGlzIGdvaW5n IHRvIGRvLCBhbmQgTkVUQ09ORiBjb3VsZCBhZGQgYSBzaW1pbGFyIFJQQyBmdW5jdGlvbjoNCj4g PiAgPg0KPiA+ICA+ICAgIHJwYyBnZXQtbGlzdCB7DQo+ID4gID4gICAgICBpbnB1dCB7DQo+ID4g ID4gICAgICAgIGxlYWYgdGFyZ2V0IHsNCj4gPiAgPiAgICAgICAgICAgdHlwZSBzY2hlbWEtaW5z dGFuY2UtaWRlbnRpZmllcjsNCj4gPiAgPiAgICAgICAgICAgZGVzY3JpcHRpb24gIklkZW50aWZp ZXMgc3VidHJlZSB0byByZXRyaWV2ZS4iOw0KPiA+ICA+ICAgICAgIH0NCj4gPiAgPiAgICAgICBs ZWFmIHN0YXJ0IHsNCj4gPiAgPiAgICAgICAgICB0eXBlIHVpbnQzMjsNCj4gPiAgPiAgICAgICAg ICBkZWZhdWx0IDA7DQo+ID4gID4gICAgICAgICAgZGVzY3JpcHRpb24gIk51bWJlciBvZiBlbnRy aWVzIHRvIHNraXAgYmVmb3JlIHN0YXJ0aW5nDQo+IHJldHJpZXZhbCI7DQo+ID4gID4gICAgICAg fQ0KPiA+ICA+ICAgICAgIGxlYWYgbWF4LWVudHJpZXMgew0KPiA+ICA+ICAgICAgICAgdHlwZSB1 aW50MzIgeyByYW5nZSAiMS4ubWF4IjsgfQ0KPiA+ICA+ICAgICAgICAgZGVmYXVsdCAyNTsNCj4g PiAgPiAgICAgICAgIGRlc2NyaXB0aW9uICJNYXhpbXVtIG51bWJlciBvZiBsaXN0IGVudHJpZXMg dG8gcmV0cmlldmUiOw0KPiA+ICA+ICAgICAgIH0NCj4gPiAgPiAgICAgfQ0KPiA+ICA+ICAgICBv dXRwdXQgew0KPiA+ICA+ICAgICAgICBhbnl4bWwgZGF0YSB7DQo+ID4gID4gICAgICAgICAgIGRl c2NyaXB0aW9uICJDb250YWlucyB0aGUgcmVxdWVzdGVkIGRhdGEiOw0KPiA+ICA+ICAgICAgICB9 DQo+ID4gID4gICAgIH0NCj4gPiAgPiAgIH0NCj4gPiAgPg0KPiA+ICA+ICAgPHJwYz4NCj4gPiAg PiAgICAgPGdldC1saXN0Pg0KPiA+ICA+ICAgICAgIDx0YXJnZXQ+L2lmOmludGVyZmFjZXMvaWY6 aW50ZXJmYWNlPC90YXJnZXQ+DQo+ID4gID4gICAgIDwvZ2V0LWxpc3Q+DQo+ID4gID4gICA8L3Jw Yz4NCj4gPiAgPg0KPiA+ICA+ICAgPHJwYy1yZXBseT4NCj4gPiAgPiAgICAgIDxkYXRhPg0KPiA+ ICA+ICAgICAgICAgPGludGVyZmFjZXM+DQo+ID4gID4gICAgICAgICAgICA8aW50ZXJmYWNlPiAg IC4uLi4gZmlyc3QgZW50cnkgPC9pbnRlcmZhY2U+DQo+ID4gID4gICAgICAgICAgICAuLi4NCj4g PiAgPiAgICAgICAgICAgIDxpbnRlcmZhY2U+ICAgLi4uLiAyNXRoIGVudHJ5IDwvaW50ZXJmYWNl Pg0KPiA+ICA+ICAgICAgICAgPC9pbnRlcmZhY2VzPg0KPiA+ICA+ICAgICAgPC9kYXRhPg0KPiA+ ICA+ICAgPC9ycGMtcmVwbHk+DQo+ID4gID4NCj4gPiAgPiAgICA8cnBjPg0KPiA+ICA+ICAgICA8 Z2V0LWxpc3Q+DQo+ID4gID4gICAgICAgPHRhcmdldD4vaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZh Y2U8L3RhcmdldD4NCj4gPiAgPiAgICAgICA8c3RhcnQ+MjU8L3N0YXJ0Pg0KPiA+ICA+ICAgICA8 L2dldC1saXN0Pg0KPiA+ICA+ICAgPC9ycGM+DQo+ID4gID4NCj4gPiAgPiAgIDxycGMtcmVwbHk+ DQo+ID4gID4gICAgICA8ZGF0YT4NCj4gPiAgPiAgICAgICAgIDxpbnRlcmZhY2VzPg0KPiA+ICA+ ICAgICAgICAgICAgPGludGVyZmFjZT4gICAuLi4uIDI2dGggZW50cnkgPC9pbnRlcmZhY2U+DQo+ ID4gID4gICAgICAgICAgICAuLi4NCj4gPiAgPiAgICAgICAgICAgIDxpbnRlcmZhY2U+ICAgLi4u LiA1MHRoIGVudHJ5IDwvaW50ZXJmYWNlPg0KPiA+ICA+ICAgICAgICAgPC9pbnRlcmZhY2VzPg0K PiA+ICA+ICAgICAgPC9kYXRhPg0KPiA+ICA+ICAgPC9ycGMtcmVwbHk+DQo+ID4gID4NCj4gPiAg PiBUaGVyZSBpcyBhIHByb2JsZW0gd2l0aCByYXBpZGx5IGNoYW5naW5nIGxpc3RzDQo+ID4gID4g KGNvdWxkIGdldCByZXBlYXQgZW50cmllcyBvbiBtaXNzIHNvbWUgZW50cmllcyksIGJ1dCB0aGUg c25hcHNob3QNCj4gPiAgPiBhcHByb2FjaCB1c2VzIHRvbyBtdWNoIG1lbW9yeSwgYW5kIGlmIHRo ZSBsaXN0IGluc3RhbmNlcw0KPiA+ICA+IGNoYW5nZSByYXBpZGx5LCBhIHN0YWxlIHNuYXBzaG90 IGlzIG5vdCB2ZXJ5IHVzZWZ1bC4NCj4gPiAgPg0KPiA+ICA+IEFuZHkNCj4gPiAgPg0KPiA+ICA+ IFRoZSBvdGhlciBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSBsaXN0ZWQgYmVsb3c6DQo+ID4g ID4gMS4gR2V0LWJsb2NrIGNhcGFiaWxpdHkgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIGdldC1jb25m aWcgDQpvcGVyYXRpb24ncw0KPiA+ICA+IGJlaGF2aW9yLiBJZiBjbGllbnQgdXNlIGdldC1jb25m aWcgb3BlcmF0aW9uIHRvIHJldHJpZXZlIGRhdGEsDQo+ID4gID4gYWxsIGRhdGEgbXVzdCBiZSBz ZW50IGluIG9uZSByZXNwb25zZSBvciBnZXQtYmxvY2sgY2FwYWJpbGl0eSANCnNob3VsZA0KPiA+ ICA+IGFkZCBhIHBhcmFtZXRlciB0byBnZXQtY29uZmlnIG9wZXJhdGlvbiB0byBpbmRpY2F0ZSB0 aGUNCj4gPiAgPiByZXNwb25zZSBkYXRhIHdpbGwgYmUgZnJhZ21lbnRlZC4NCj4gPiAgPiAyLiBB IHNldC1pZCBjYW4gYmUgYWdlZD8gd2hlbiBjbGllbnQgbmV2ZXIgc2VuZCBhIHJlcXVlc3QgdG8N Cj4gPiAgPiByZXRyaWV2ZSB0aGUgbmV4dCBmcmFnbWVudCBmb3IgYSBsb25nIHRpbWUsIEkgdGhp bmsgdGhpcyBzZXQtaWQNCj4gPiAgPiBzaG91bGQgYmUgYWdlZCwNCj4gPiAgPiBvdGhlcndpc2Us IHNlcnZlciB3aWxsIGJlIHJlc2VydmUgbW9yZSBhbmQgbW9yZSBzZXQtaWRzLg0KPiA+ICA+IDMu IEEgc2V0LWlkIGlzIHVuaXF1ZSBpbiBzZXNzaW9uIGxldmVsIG9yIHNlcnZlciBsZXZlbD8NCj4g PiAgPiA0LiBJZiBhIHNlc3Npb24gaXMga2lsbGVkIG9yIGNsb3NlZCwgb3RoZXIgc2Vzc2lvbiBj YW4gcmV0cmlldmVkIA0KdGhlDQo+ID4gID4gbmV4dCBmcmFnbWVudCBpZiB0aGUgY2xpZW50IHBy b3ZpZGUgdGhlIGNvcnJlY3Qgc2V0LWlkPw0KPiA+ICA+IC9mcmFuaw0KPiA+ICA+DQo+ID4NCj4g PiAgPiAyMDE0LTA2LTA0IDE4OjIyIEdNVCswODowMCBMaXViaW5nIChMZW8pIDxsZW8ubGl1Ymlu Z0BodWF3ZWkuY29tPjoNCj4gPiAgPiBIaSBhbGwsDQo+ID4gID4NCj4gPiAgPiBXZSd2ZSBwb3N0 ZWQgYSBuZXcgZHJhZnQsIHdoaWNoIGlzIGFib3V0IE5FVENPTkYgZGF0YSANCmZyYWdtZW50YXRp b24uDQo+ID4gID4NCj4gPiAgPiBUaGUgYmFzaWMgaWRlYSBpcywgd2hlbiBOTVMgaXMgcmV0cmll dmluZyBhIGxhcmdlIHNpemUgb2YgZGF0YSBpbg0KPiA+ICA+IHRoZSBkZXZpY2UsIHRoZSA8cnBj LXJlcGx5PiBtaWdodCBiZSB2ZXJ5IGJpZyAoZS5nLiB0aGUgcm91dGVzIGluIGENCj4gPiAgPiBj b3JlIHJvdXRlcikuDQo+ID4gID4gQ3VycmVudGx5IHRoZXJlIGFyZSBtYWlubHkgdHdvIG1ldGhv ZHMgb2YgaGFuZGxpbmcgdGhlIGJpZyA8cnBjLQ0KPiA+ICA+IHJlcGx5Pjogb25lIGlzIHN0cmVh bS1vcmllbnRlZCBoYW5kbGluZzsgdGhlIG90aGVyIGlzIGp1c3QgcmVxdWVzdCANCmENCj4gPiAg PiBwb3J0aW9uIG9mIHRoZSBkYXRhLg0KPiA+ICA+DQo+ID4gID4gVGhpcyBkcmFmdCBjb25zaWRl cnMgYm90aCB0aGUgdHdvIG1ldGhvZHMgYXJlIHByb2JsZW1hdGljIGluIHNvbWUNCj4gPiAgPiBz aXR1YXRpb25zLCBhbmQgcHJvcG9zZXMgYSBuZXcgbWV0aG9kIHdoaWNoIGFsbG93cyB0aGUgbGFy Z2Ugc2l6ZQ0KPiA+ICA+IDxycGMtcmVwbHk+IHRvIGJlIGZyYWdtZW50ZWQgaW4gTkVUQ09ORiBs ZXZlbC4NCj4gPiAgPg0KPiA+ICA+IFBsZWFzZSByZWFkIHRoZSBkcmFmdCBhbmQgY29tbWVudC4N Cj4gPiAgPiBNYW55IHRoYW5rcyENCj4gPiAgPg0KPiA+ICA+IEJlc3QgcmVnYXJkcywNCj4gPiAg PiBCaW5nDQo+ID4gID4NCj4gPiAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ICA+ IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10NCj4gPiAgPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQgNToyNyBQTQ0K PiA+ICA+IFRvOiBMaXViaW5nIChMZW8pOyBMaXViaW5nIChMZW8pOyBaaGVuZ2d1YW5neWluZzsg WmhlbmdndWFuZ3lpbmcNCj4gPiAgPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWxpdS1uZXRjb25mLQ0KPiBmcmFnbWVudGF0aW9uLTAwLnR4dA0KPiA+ICA+DQo+ ID4gID4NCj4gPiAgPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LW5ldGNvbmYtZnJh Z21lbnRhdGlvbi0wMC50eHQNCj4gPiAgPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEJpbmcgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlIA0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4g ID4NCj4gPiAgPiBOYW1lOiAgICAgICAgICAgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlv bg0KPiA+ICA+IFJldmlzaW9uOiAgICAgICAwMA0KPiA+ICA+IFRpdGxlOiAgICAgICAgICBBIE5F VENPTkYgRXh0ZW5zaW9uIGZvciBEYXRhIEZyYWdtZW50YXRpb24NCj4gPiAgPiBEb2N1bWVudCBk YXRlOiAgMjAxNC0wNi0wNA0KPiA+ICA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCj4gPiAgPiBQYWdlczogICAgICAgICAgMTINCj4gPiAgPiBVUkw6IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS0NCj4gPiAgPiBuZXRjb25mLWZyYWdt ZW50YXRpb24tMDAudHh0DQo+ID4gID4gU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1saXUtbmV0Y29uZi0NCj4gPiAgPiBmcmFnbWVudGF0aW9uLw0KPiA+ICA+ IEh0bWxpemVkOiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1uZXRjb25m LWZyYWdtZW50YXRpb24tMDANCj4gPiAgPg0KPiA+ICA+DQo+ID4gID4gQWJzdHJhY3Q6DQo+ID4g ID4gICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGFuIGV4dGVuc2lvbiB0byBORVRDT05GIChO ZXR3b3JrDQo+ID4gID4gICAgQ29uZmlndXJhdGlvbikgcHJvdG9jb2wuIFRoZSBleHRlbnNpb24g YWxsb3dzIE5FVENPTkYgdG8gaGFuZGxlIA0KbGFyZ2UNCj4gPiAgPiAgICBzaXplIGRhdGEgYXMg ZnJhZ21lbnRlZCBSUEMgbWVzc2FnZXMuIFNwZWNpZmljYWxseSwgdGhpcyANCmRvY3VtZW50DQo+ ID4gID4gICAgZGVmaW5lcyBhIG5ldyA8Z2V0LWJsb2NrPiBjYXBhYmlsaXR5IGFuZCByZWxldmFu dCBvcGVyYXRpb25zIHRvDQo+ID4gID4gICAgaGFuZGxlIHRoZSBmcmFnbWVudGF0aW9ucy4NCj4g PiAgPg0KPiA+ICA+DQo+ID4gID4NCj4gPiAgPg0KPiA+ICA+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4gID4gc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0DQo+IHRvb2xzLmlldGYub3JnDQo+ID4gID4gLg0KPiA+ICA+DQo+ID4gID4gVGhlIElFVEYg U2VjcmV0YXJpYXQNCj4gPiAgPg0KPiA+ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiAgPiBO ZXRjb25mQGlldGYub3JnDQo+ID4gID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRjb25mDQo+ID4gID4NCj4gPiAgPg0KPiA+ICA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QN Cj4gPiAgPiBOZXRjb25mQGlldGYub3JnDQo+ID4gID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4NCj4gPiAgPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ ID4gID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+ICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KPiBtYWls IChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQg YW5kIA0KPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVz ZSBvZiB0aGUgYWRkcmVzc2VlDQo+IChzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJl Y2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBv ciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgDQo+IGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgDQo+IHRo aXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0 ZWx5Lg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCj4gbWFpbCAoYW5k IGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCAN Cj4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg dGhlIGFkZHJlc3NlZQ0KPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGll bnQsIGFueSBkaXNjbG9zdXJlLCANCj4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3Ro ZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiBpbmZvcm1hdGlvbiBjb250YWluZWQg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiB0aGlzIG1h aWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiBOZXRjb25mQGll dGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m DQo+ID4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQg aGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRp c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1l ZGlhdGVseS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVk IGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVk IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBu b3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBk aXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1t ZWRpYXRlbHkuDQo= --=_alternative 003281CA48257CEE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O0JlcnQgV2lqbmVuIChJRVRGKSZxdW90OyAmbHQ7YmVydGll dGZAYndpam5lbi5uZXQmZ3Q7DQrQtNPaIDIwMTQtMDYtMDUgMTY6Mzk6MDk6PGJyPg0KPGJyPg0K Jmd0OyAmcXVvdDtCZXJ0IFdpam5lbiAoSUVURikmcXVvdDsgJmx0O2JlcnRpZXRmQGJ3aWpuZW4u bmV0Jmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMjAxNC0wNi0w NSAxNjozOTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7 IMrVvP7IyzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7 IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtz LmNvbSZndDssDQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K Jmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZn dDsgWmhlbmdndWFuZ3lpbmcgJmx0O3poZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb20mZ3Q7LCBOZXRj b25mICZsdDtuZXRjb25mLTxicj4NCiZndDsgYm91bmNlc0BpZXRmLm9yZyZndDssIE5ldGNvbmYg Jmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCBZYW5nYW5nICZsdDt5YW5nYW5nQGh1YXdlaS5jb20m Z3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM 4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJlOiBb TmV0Y29uZl0gtPC4tDogUmU6ICZuYnNwO05ldGNvbmYgZnJhZ21lbnRhdGlvbi0vL0ZXOiBOZXcg VmVyc2lvbg0KPGJyPg0KJmd0OyBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1uZXRjb25mLWZy YWdtZW50YXRpb24tMDAudHh0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IDxicj4NCiZndDsgSSBhbSBhIGJpdCBjb25jZXJuZWQgdGhhdCB3ZSBhcmUgbm93IGRpc2N1c3Np bmcgYSBwb3NzaWJsZSBzb2x1dGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgQlVULi4uLiBJIHRo aW5rIHdlIHNob3VsZCBmaXJzdCBkaXNjdXNzIG9uIHRoaXMgbGlzdDo8YnI+DQomZ3Q7IDxicj4N CiZndDsgLSBJcyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZGVzY3JpYmluZyBhIHJlYWwgcHJvYmxl bSB0aGF0IHdlIGFsbCBhZ3JlZQ0Kd2l0aD88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPkkgYWdyZWUuIEJ1dCBJIGRvbid0IGFncmVlIHdpdGggdGhpcyBzb2x1dGlvbi4gTkVUQ09O Rg0Kc2VydmVyIHNob3VsZCBiZSBzdGF0ZWxlc3MsIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+b25lIHJlcXVlc3Qgc2hvdWxkIG9ubHkgaGF2ZSBvbmUgcmVzcG9uc2UuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IC0gSWYgaXQgaXMsIGRvIHdlIGJlbGlldmUgdGhhdCBvdXIgV0cgc2hv dWxkIHdvcmsgb24gYSBzb2x1dGlvbj88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PkkgdGhpbmsgV0cgc2hvdWxkIHdvcmsgb24gYSBzb2x1dGlvbi4gV2hlbiB3ZSByZWFsaXplZA0K TkVUQ09ORiwgd2UgYWxzbyBoYXZlIGVuY291bnRlcmVkIHRoaXMgcHJvYmxlbS48YnI+DQomZ3Q7 IDxicj4NCiZndDsgT25jZSB3ZSBoYXZlIGFncmVlIG9uIHRoYXQsIHdlIGNhbiBkZWNpZGUgaWYg d2Ugd2FudCB0byBhZGQgdGhpcyB0b3BpYzxicj4NCiZndDsgdG8gb3VyIFdHIGNoYXJ0ZXIgYW5k IHdvcmsgb24gaXQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlcnQgKHNwZWFraW5nIGFzIGNvLWNo YWlyKTxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiAwNS8wNi8xNCAwMjo1OSwgZmVuZy5jaG9uZzMz QHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IGFuZHksPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDsgSG93IHRvIHByb2Nlc3MgbmVzdGVkIGxpc3RzIHVzaW5nIHlvdXIgc29sdXRp b24/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEZvciBleGFtcGxlOjxicj4NCiZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7IGxpc3QgZm9vIHs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGtleSBhOzxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgbGVhZiBhIHsuLi59PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBsZWFmIGIgey4uLn08YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGxpc3QgbmVzdGVkLWZvbyB7PGJyPg0KJmd0OyAmZ3Q7IGtleSBuZXN0ZWQtYTs8YnI+ DQomZ3Q7ICZndDsgbGVhZiBuZXN0ZWQtYSB7Li4ufTxicj4NCiZndDsgJmd0OyBsZWFmIG5ldHN0 ZWQtYiB7Li4ufTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwO0lmIHJlcXVlc3QgaXM6PGJyPg0KJmd0OyAmZ3Q7ICZsdDtycGMmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtnZXQtbGlzdCZndDs8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt0YXJnZXQmZ3Q7L2Zv byZsdDsvdGFyZ2V0Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7 L2dldC1saXN0Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZsdDsvcnBjJmd0Ozxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7V2hhdCBpcyB0aGUgcmVzcG9uc2U/PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFuZCwgYW5vdGhlciBxdWVzdGlvbjo8YnI+DQomZ3Q7ICZn dDsgU3RhcnQtaW5kZXggaXMgbm90IHJlbGlhYmxlLCBpZiBzb21lIGVudHJpZXMgYXJlIGRlbGV0 ZWQuIEkgdGhpbmsNCjxicj4NCiZndDsgeW91IGNhbiB1c2Ugc3RhcnQga2V5IGluc3RlYWQuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IC9mcmFuazxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmcXVvdDtOZXRjb25mJnF1b3Q7 ICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7INC009ogMjAxNC0wNi0wNQ0KMDA6NDM6 MTI6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgQW5keSBCaWVybWFu ICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgt6K8 /sjLOiAmbmJzcDsmcXVvdDtOZXRjb25mJnF1b3Q7ICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0 OyAyMDE0LTA2LTA1IDAwOjQzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7Jmd0OyDK1bz+yMs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsg Jmd0OyAmbmJzcDsmZ3Q7IGNob25nIGZlbmcgJmx0O2ZlbmdjaG9uZ2xsbHlAZ21haWwuY29tJmd0 Oyw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ILOt y808YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IFpo ZW5nZ3Vhbmd5aW5nICZsdDt6aGVuZ2d1YW5neWluZ0BodWF3ZWkuY29tJmd0OywNCk5ldGNvbmY8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDssIFlhbmdh bmcgJmx0O3lhbmdhbmdAaHVhd2VpLmNvbSZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxi cj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7INb3zOI8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxi cj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IFJlOiBbTmV0Y29uZl0gTmV0Y29uZiBmcmFnbWVudGF0 aW9uLS8vRlc6IE5ldyBWZXJzaW9uDQpOb3RpZmljYXRpb248YnI+DQomZ3Q7ICZndDsgJm5ic3A7 Jmd0OyBmb3IgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQ8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgT24gV2VkLCBKdW4gNCwgMjAxNCBhdCA4OjMyIEFN LCBjaG9uZyBmZW5nIDxicj4NCiZndDsgJmx0O2ZlbmdjaG9uZ2xsbHlAZ21haWwuY29tJmd0OyB3 cm90ZTo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBIaSw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 Jmd0OyAmbmJzcDsgJm5ic3A7SSBoYXZlIHJldmlld2VkIHRoaXMgbmV3IGRyYWZ0Ljxicj4NCiZn dDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDtJIHVuZGVyc3RhbmQgeW91ciBzb2x1dGlv biBpcyB0aGF0IE5FVENPTkYNCnNlcnZlciByZXNlcnZlIGJyZWFrPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyZndDsgcG9pbnRzIGFuZCB3YWl0IGZvciBjbGllbnQgdG8gcmV0cmlldmUgdGhlIG5leHQg cmVzcG9uc2UuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgSSB0aGluayBpdCdzIG5vdCBhIGdv b2Qgc29sdXRpb24sIGJlY2F1c2Ugc2VydmVyIG1heQ0KbmVlZCB0byByZXNlcnZlPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyZndDsgbWFueSBicmVhayBwb2ludHMgaWYgdGhlcmUgYSBsYXJnZSBudW1i ZXIgb2YgY29uY3VycmVudA0KcmVxdWVzdHMuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgSXQn cyB0b28gaGVhdnkgZm9yIHNlcnZlci4gQW5kLCB0aGUgc2VydmVyIG11c3QgYmUNCnN0YXRlZnVs IGlmIGl0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgc3VwcG9ydCBnZXQtYmxvY2sgY2FwYWJp bGl0eS48YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgSSBhZ3JlZSB3aXRoIHRoZXNlIGNvbmNlcm5zLiAm bmJzcDtIb2xkaW5nIGEgc25hcHNob3QNCm9mIHN0YXRlIGRhdGEgZm9yPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyZndDsgaW50ZXJhY3RpdmUgcmV0cmlldmFsPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZn dDsgYnkgdGhlIGNsaWVudCBpcyB2ZXJ5IGV4cGVuc2l2ZS48YnI+DQomZ3Q7ICZndDsgJm5ic3A7 Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IEkgZG8gbm90IGFncmVlIHdpdGggdGhlIHBy ZW1pc2UgdGhhdCB0aGUgY2xpZW50IG5lZWRzDQp0byBrbm93IHRoZTxicj4NCiZndDsgJmd0OyAm bmJzcDsmZ3Q7IGtleSB2YWx1ZXMgaW4gYWR2YW5jZS48YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0 OyBBbiAmcXVvdDtpdGVyYXRvciZxdW90OyBhcHByb2FjaCBhbGxvd3MgYSBsaXN0IHJlc291cmNl DQp0byBiZSByZXRyaWV2ZWQgaW48YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBjaHVua3MuICZu YnNwO1RoaXMgaXMgd2hhdCBSRVNUQ09ORjxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IGlzIGdv aW5nIHRvIGRvLCBhbmQgTkVUQ09ORiBjb3VsZCBhZGQgYSBzaW1pbGFyIFJQQw0KZnVuY3Rpb246 PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJz cDsgJm5ic3A7cnBjIGdldC1saXN0IHs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2lucHV0IHs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtsZWFmIHRhcmdldCB7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0eXBlIHNjaGVtYS1pbnN0YW5jZS1p ZGVudGlmaWVyOzxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7SWRlbnRpZmllcw0Kc3VidHJlZSB0byBy ZXRyaWV2ZS4mcXVvdDs7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfTxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxl YWYgc3RhcnQgezxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt0eXBlIHVpbnQzMjs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVmYXVsdCAwOzxicj4NCiZndDsgJmd0OyAm bmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNjcmlwdGlvbiAm cXVvdDtOdW1iZXINCm9mIGVudHJpZXMgdG8gc2tpcCBiZWZvcmUgc3RhcnRpbmc8YnI+DQomZ3Q7 IHJldHJpZXZhbCZxdW90Ozs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg bGVhZiBtYXgtZW50cmllcyB7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHR5cGUgdWludDMyIHsgcmFuZ2UgJnF1b3Q7MS4ubWF4JnF1b3Q7Ow0K fTxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBk ZWZhdWx0IDI1Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtNYXhpbXVtDQpudW1iZXIgb2YgbGlzdCBlbnRyaWVz IHRvIHJldHJpZXZlJnF1b3Q7Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7IH08YnI+ DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7IG91dHB1dCB7PGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW55eG1sIGRhdGEgezxi cj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgZGVzY3JpcHRpb24gJnF1b3Q7Q29udGFpbnMNCnRoZSByZXF1ZXN0ZWQgZGF0YSZxdW90Ozs8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyZndDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0 OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbHQ7cnBjJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7 ICZuYnNwOyAmbmJzcDsgJmx0O2dldC1saXN0Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt0YXJnZXQmZ3Q7L2lmOmludGVyZmFjZXMvaWY6aW50 ZXJmYWNlJmx0Oy90YXJnZXQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZu YnNwOyAmbHQ7L2dldC1saXN0Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAm bHQ7L3JwYyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJz cDsmZ3Q7ICZuYnNwOyAmbHQ7cnBjLXJlcGx5Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2RhdGEmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtpbnRlcmZhY2VzJmd0Ozxicj4NCiZn dDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0O2ludGVyZmFjZSZndDsNCiZuYnNwOyAuLi4uIGZpcnN0IGVudHJ5ICZsdDsvaW50ZXJm YWNlJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Li4uPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aW50ZXJmYWNlJmd0Ow0KJm5ic3A7 IC4uLi4gMjV0aCBlbnRyeSAmbHQ7L2ludGVyZmFjZSZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9pbnRlcmZhY2VzJmd0Ozxicj4N CiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9kYXRhJmd0Ozxi cj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbHQ7L3JwYy1yZXBseSZndDs8YnI+DQom Z3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJz cDsmbHQ7cnBjJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJmx0 O2dldC1saXN0Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDt0YXJnZXQmZ3Q7L2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlJmx0Oy90YXJnZXQm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3N0 YXJ0Jmd0OzI1Jmx0Oy9zdGFydCZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsg Jm5ic3A7ICZsdDsvZ2V0LWxpc3QmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7 ICZsdDsvcnBjJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyZndDsgJm5ic3A7ICZsdDtycGMtcmVwbHkmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZGF0YSZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2ludGVyZmFjZXMmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7aW50ZXJmYWNlJmd0Ow0KJm5ic3A7IC4uLi4gMjZ0aCBlbnRyeSAmbHQ7L2ludGVy ZmFjZSZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOy4uLjxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ludGVyZmFjZSZndDsNCiZuYnNw OyAuLi4uIDUwdGggZW50cnkgJmx0Oy9pbnRlcmZhY2UmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvaW50ZXJmYWNlcyZndDs8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZGF0YSZndDs8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJmx0Oy9ycGMtcmVwbHkmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBUaGVyZSBpcyBh IHByb2JsZW0gd2l0aCByYXBpZGx5IGNoYW5naW5nIGxpc3RzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyZndDsgKGNvdWxkIGdldCByZXBlYXQgZW50cmllcyBvbiBtaXNzIHNvbWUgZW50cmllcyksIGJ1 dA0KdGhlIHNuYXBzaG90PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgYXBwcm9hY2ggdXNlcyB0 b28gbXVjaCBtZW1vcnksIGFuZCBpZiB0aGUgbGlzdCBpbnN0YW5jZXM8YnI+DQomZ3Q7ICZndDsg Jm5ic3A7Jmd0OyBjaGFuZ2UgcmFwaWRseSwgYSBzdGFsZSBzbmFwc2hvdCBpcyBub3QgdmVyeSB1 c2VmdWwuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0 OyBBbmR5PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0 OyBUaGUgb3RoZXIgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBhcmUgbGlzdGVkIGJlbG93Ojxicj4N CiZndDsgJmd0OyAmbmJzcDsmZ3Q7IDEuIEdldC1ibG9jayBjYXBhYmlsaXR5IHNob3VsZCBub3Qg Y2hhbmdlIHRoZSBnZXQtY29uZmlnDQpvcGVyYXRpb24nczxicj4NCiZndDsgJmd0OyAmbmJzcDsm Z3Q7IGJlaGF2aW9yLiBJZiBjbGllbnQgdXNlIGdldC1jb25maWcgb3BlcmF0aW9uIHRvIHJldHJp ZXZlDQpkYXRhLDxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IGFsbCBkYXRhIG11c3QgYmUgc2Vu dCBpbiBvbmUgcmVzcG9uc2Ugb3IgZ2V0LWJsb2NrDQpjYXBhYmlsaXR5IHNob3VsZDxicj4NCiZn dDsgJmd0OyAmbmJzcDsmZ3Q7IGFkZCBhIHBhcmFtZXRlciB0byBnZXQtY29uZmlnIG9wZXJhdGlv biB0byBpbmRpY2F0ZQ0KdGhlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgcmVzcG9uc2UgZGF0 YSB3aWxsIGJlIGZyYWdtZW50ZWQuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgMi4gQSBzZXQt aWQgY2FuIGJlIGFnZWQ/IHdoZW4gY2xpZW50IG5ldmVyIHNlbmQgYQ0KcmVxdWVzdCB0bzxicj4N CiZndDsgJmd0OyAmbmJzcDsmZ3Q7IHJldHJpZXZlIHRoZSBuZXh0IGZyYWdtZW50IGZvciBhIGxv bmcgdGltZSwgSSB0aGluaw0KdGhpcyBzZXQtaWQ8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBz aG91bGQgYmUgYWdlZCw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBvdGhlcndpc2UsIHNlcnZl ciB3aWxsIGJlIHJlc2VydmUgbW9yZSBhbmQgbW9yZSBzZXQtaWRzLjxicj4NCiZndDsgJmd0OyAm bmJzcDsmZ3Q7IDMuIEEgc2V0LWlkIGlzIHVuaXF1ZSBpbiBzZXNzaW9uIGxldmVsIG9yIHNlcnZl ciBsZXZlbD88YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyA0LiBJZiBhIHNlc3Npb24gaXMga2ls bGVkIG9yIGNsb3NlZCwgb3RoZXIgc2Vzc2lvbg0KY2FuIHJldHJpZXZlZCB0aGU8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7Jmd0OyBuZXh0IGZyYWdtZW50IGlmIHRoZSBjbGllbnQgcHJvdmlkZSB0aGUg Y29ycmVjdCBzZXQtaWQ/PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgL2ZyYW5rPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0 OyAyMDE0LTA2LTA0IDE4OjIyIEdNVCswODowMCBMaXViaW5nIChMZW8pICZsdDtsZW8ubGl1Ymlu Z0BodWF3ZWkuY29tJmd0Ozo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBIaSBhbGwsPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBXZSd2ZSBwb3N0 ZWQgYSBuZXcgZHJhZnQsIHdoaWNoIGlzIGFib3V0IE5FVENPTkYgZGF0YQ0KZnJhZ21lbnRhdGlv bi48YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IFRo ZSBiYXNpYyBpZGVhIGlzLCB3aGVuIE5NUyBpcyByZXRyaWV2aW5nIGEgbGFyZ2UNCnNpemUgb2Yg ZGF0YSBpbjxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IHRoZSBkZXZpY2UsIHRoZSAmbHQ7cnBj LXJlcGx5Jmd0OyBtaWdodCBiZSB2ZXJ5IGJpZw0KKGUuZy4gdGhlIHJvdXRlcyBpbiBhPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyZndDsgY29yZSByb3V0ZXIpLjxicj4NCiZndDsgJmd0OyAmbmJzcDsm Z3Q7IEN1cnJlbnRseSB0aGVyZSBhcmUgbWFpbmx5IHR3byBtZXRob2RzIG9mIGhhbmRsaW5nDQp0 aGUgYmlnICZsdDtycGMtPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgcmVwbHkmZ3Q7OiBvbmUg aXMgc3RyZWFtLW9yaWVudGVkIGhhbmRsaW5nOyB0aGUgb3RoZXINCmlzIGp1c3QgcmVxdWVzdCBh PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgcG9ydGlvbiBvZiB0aGUgZGF0YS48YnI+DQomZ3Q7 ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IFRoaXMgZHJhZnQgY29u c2lkZXJzIGJvdGggdGhlIHR3byBtZXRob2RzIGFyZSBwcm9ibGVtYXRpYw0KaW4gc29tZTxicj4N CiZndDsgJmd0OyAmbmJzcDsmZ3Q7IHNpdHVhdGlvbnMsIGFuZCBwcm9wb3NlcyBhIG5ldyBtZXRo b2Qgd2hpY2ggYWxsb3dzDQp0aGUgbGFyZ2Ugc2l6ZTxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7 ICZsdDtycGMtcmVwbHkmZ3Q7IHRvIGJlIGZyYWdtZW50ZWQgaW4gTkVUQ09ORiBsZXZlbC48YnI+ DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IFBsZWFzZSBy ZWFkIHRoZSBkcmFmdCBhbmQgY29tbWVudC48YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBNYW55 IHRoYW5rcyE8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsm Z3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBCaW5nPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IEZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbPC9mb250PjwvdHQ+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyI+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+XTxicj4NCiZndDsgJmd0OyAmbmJz cDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCA1OjI3IFBNPGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyZndDsgVG86IExpdWJpbmcgKExlbyk7IExpdWJpbmcgKExlbyk7IFpoZW5nZ3Vh bmd5aW5nOw0KWmhlbmdndWFuZ3lpbmc8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1uZXRjb25mLTxicj4NCiZn dDsgZnJhZ21lbnRhdGlvbi0wMC50eHQ8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZn dDsgJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0PGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5n IExpdSBhbmQgcG9zdGVkDQp0byB0aGUgPGJyPg0KJmd0OyBJRVRGIHJlcG9zaXRvcnkuPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBOYW1lOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50 YXRpb248YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAm bmJzcDsgMDA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBUaXRsZTogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0EgTkVUQ09ORg0KRXh0ZW5zaW9uIGZvciBEYXRhIEZyYWdtZW50 YXRpb248YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBEb2N1bWVudCBkYXRlOiAmbmJzcDsyMDE0 LTA2LTA0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgR3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsDQpTdWJtaXNzaW9uPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyZndDsgUGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxMjxicj4N CiZndDsgJmd0OyAmbmJzcDsmZ3Q7IFVSTDogPC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LSI+PHR0Pjxmb250IHNpemU9Mj5o dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtPC9mb250PjwvdHQ+ PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgbmV0Y29uZi1m cmFnbWVudGF0aW9uLTAwLnR4dDxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IFN0YXR1czogPC9m b250PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bGl1LW5ldGNvbmYtIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWxpdS1uZXRjb25mLTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0y Pjxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IGZyYWdtZW50YXRpb24vPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyZndDsgSHRtbGl6ZWQ6IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDAiPjx0dD48Zm9u dCBzaXplPTI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LW5ldGNvbmYtZnJh Z21lbnRhdGlvbi0wMDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsg Jmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsg Jm5ic3A7Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5i c3A7VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGFuIGV4dGVuc2lvbg0KdG8gTkVUQ09ORiAoTmV0 d29yazxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDtDb25maWd1cmF0aW9u KSBwcm90b2NvbC4gVGhlIGV4dGVuc2lvbg0KYWxsb3dzIE5FVENPTkYgdG8gaGFuZGxlIGxhcmdl PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwO3NpemUgZGF0YSBhcyBmcmFn bWVudGVkIFJQQyBtZXNzYWdlcy4NClNwZWNpZmljYWxseSwgdGhpcyBkb2N1bWVudDxicj4NCiZn dDsgJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDtkZWZpbmVzIGEgbmV3ICZsdDtnZXQtYmxv Y2smZ3Q7IGNhcGFiaWxpdHkNCmFuZCByZWxldmFudCBvcGVyYXRpb25zIHRvPGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwO2hhbmRsZSB0aGUgZnJhZ21lbnRhdGlvbnMuPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZn dDsgJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7Jmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbQ0KdGhlIHRpbWUgb2Y8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZQ0KYXZhaWxhYmxlIGF0 PGJyPg0KJmd0OyB0b29scy5pZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IC48YnI+ DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IFRoZSBJRVRG IFNlY3JldGFyaWF0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5i c3A7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyZndDsgTmV0Y29uZkBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7 IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0 OyAmbmJzcDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7ICZndDsgJm5ic3A7Jmd0OyBOZXRjb25mQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmY+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmY8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IE5l dGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZndDsgTmV0Y29uZkBpZXRm Lm9yZzxicj4NCiZndDsgJmd0OyAmbmJzcDsmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPjx0dD48Zm9udCBzaXplPTI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9mb250PjwvdHQ+ PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4NCnRoaXM8YnI+DQomZ3Q7IG1haWwgKGFuZCBh bnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgPGJy Pg0KJmd0OyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVz ZSBvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFu IGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIDxicj4NCiZndDsgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIDxi cj4NCiZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZu YnNwO0lmIHlvdSBoYXZlIHJlY2VpdmVkDQo8YnI+DQomZ3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwg cGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCiZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluDQp0aGlzPGJyPg0KJmd0OyBtYWlsIChhbmQgYW55IGF0 dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIDxicj4NCiZn dDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg dGhlIGFkZHJlc3NlZTxicj4NCiZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRl bmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCA8YnI+DQomZ3Q7IHJlcHJvZHVjdGlvbiwg ZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSA8YnI+DQom Z3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAmbmJzcDtJ ZiB5b3UgaGF2ZSByZWNlaXZlZA0KPGJyPg0KJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 ICZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgTmV0Y29uZkBpZXRmLm9y Zzxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCiZndDsgJmd0Ozxicj4NCjwvZm9udD48L3R0Pg0KDQo8YnI+PHByZT48Zm9u dCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFu c21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBp bnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlv dSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVj dGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5 IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0KDQo8YnI+PHByZT48Zm9udCBj b2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21p dHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVz IGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 003281CA48257CEE_=-- From nobody Thu Jun 5 02:14:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2FE1A042F for ; Thu, 5 Jun 2014 02:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRMpIU-omlK6 for ; Thu, 5 Jun 2014 02:14:30 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA5F1A03BE for ; Thu, 5 Jun 2014 02:14:29 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 21219ED05C7; Thu, 5 Jun 2014 11:14:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1401959662; bh=eeMfoVRgGylC/QOz2TZh0yZaCyXmMTcyfHo6GxCqe/g=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=Tz6PKnx75x6mMGPuiKKwpRNDakjIFEzE4+r2ZrBkAhrxjV48xh6dBp1TuFGNgixTa A9N+mU2gPd/fxbb6H5IBWafSQgk4+HSjepyDmi6OjounAd+BHyeG+H7QOOF6pMaYmX uBD2ntEmjwFDfLJnjEITGR1vXrlL92pBIVOXeesM= Message-ID: <539034A1.4000500@cesnet.cz> Date: Thu, 05 Jun 2014 11:13:05 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kent Watsen , Andy Bierman References: <538F178E.6060400@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------010206020301000108080403" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/U7-0VgKw_LIYvZWY9HhzSMX2OUo Cc: Boris Pilka , Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:14:31 -0000 This is a multi-part message in MIME format. --------------010206020301000108080403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Dne 4.6.2014 20:31, Kent Watsen napsal(a): > > This stream contains all NETCONF XML event notifications supported by > > the NETCONF server. > > > > It says "NETCONF XML". > > Does this imply that a SYSLOG text stream also needs to be wrapped in XML > > and sent as a element on the NETCONF stream? I hope not. > > My interpretation is that the NETCONF stream contains all > notifications defined by all YANG modules advertised by the device. > Only problem is the RFC5277 doesn't mention YANG anywhere... I understand the text the same way and libnetconf implements it this way. RFC says "all NETCONF XML event notifications supported by the NETCONF server", not "all standard event notifications". Radek > > That reading would exclude SYSLOG messages, thankfully. > > > > Probably needs clarification. ;-) > > Right, e.g., what is "NETCONF XML" ? > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Radek Krejci mobile : +420 732 212 714 office : +420 234 680 256 e-mail : rkrejci@cesnet.cz LinkedIn: http://www.linkedin.com/in/radekkrejci CESNET Association of Legal Entities 160 00 Praha 6, Zikova 4 Czech Republic --------------010206020301000108080403 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dne 4.6.2014 20:31, Kent Watsen napsal(a):
>    This stream contains all NETCONF XML event notifications supported by
>    the NETCONF server.  
>
> It says "NETCONF XML".
> Does this imply that a SYSLOG text stream also needs to be wrapped in XML
> and sent as a <notification> element on the NETCONF stream?  I hope not.

My interpretation is that the NETCONF stream contains all notifications defined by all YANG modules advertised by the device.    Only problem is the RFC5277 doesn't mention YANG anywhere...

I understand the text the same way and libnetconf implements it this way. RFC says "all NETCONF XML event notifications supported by the NETCONF server", not "all standard event notifications".

Radek


That reading would exclude SYSLOG messages, thankfully.


> Probably needs clarification. ;-)

Right, e.g., what is "NETCONF XML" ?
 




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


-- 
Radek Krejci
mobile  : +420 732 212 714
office  : +420 234 680 256
e-mail  : rkrejci@cesnet.cz
LinkedIn: http://www.linkedin.com/in/radekkrejci

CESNET
Association of Legal Entities
160 00 Praha 6, Zikova 4
Czech Republic
--------------010206020301000108080403-- From nobody Thu Jun 5 02:18:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2FD1A0422 for ; Thu, 5 Jun 2014 02:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un7iQgOjAuUD for ; Thu, 5 Jun 2014 02:18:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DC8A41A010C for ; Thu, 5 Jun 2014 02:18:33 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id CBBD21280CB6; Thu, 5 Jun 2014 11:17:28 +0200 (CEST) Date: Thu, 05 Jun 2014 11:18:27 +0200 (CEST) Message-Id: <20140605.111827.2005613958668274653.mbj@tail-f.com> To: rkrejci@cesnet.cz From: Martin Bjorklund In-Reply-To: <539034A1.4000500@cesnet.cz> References: <539034A1.4000500@cesnet.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/VufZFQ8eUsdpIYjGBsU5xH-NR_0 Cc: bpilka@cisco.com, netconf@ietf.org Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:18:36 -0000 UmFkZWsgS3JlasSNw60gPHJrcmVqY2lAY2VzbmV0LmN6PiB3cm90ZToNCj4gDQo+IERuZSA0LjYu MjAxNCAyMDozMSwgS2VudCBXYXRzZW4gbmFwc2FsKGEpOg0KPiA+ID4gICAgVGhpcyBzdHJlYW0g Y29udGFpbnMgYWxsIE5FVENPTkYgWE1MIGV2ZW50IG5vdGlmaWNhdGlvbnMgc3VwcG9ydGVkIGJ5 DQo+ID4gPiAgICB0aGUgTkVUQ09ORiBzZXJ2ZXIuICANCj4gPiA+DQo+ID4gPiBJdCBzYXlzICJO RVRDT05GIFhNTCIuDQo+ID4gPiBEb2VzIHRoaXMgaW1wbHkgdGhhdCBhIFNZU0xPRyB0ZXh0IHN0 cmVhbSBhbHNvIG5lZWRzIHRvIGJlIHdyYXBwZWQgaW4gWE1MDQo+ID4gPiBhbmQgc2VudCBhcyBh IDxub3RpZmljYXRpb24+IGVsZW1lbnQgb24gdGhlIE5FVENPTkYgc3RyZWFtPyAgSSBob3BlIG5v dC4NCj4gPg0KPiA+IE15IGludGVycHJldGF0aW9uIGlzIHRoYXQgdGhlIE5FVENPTkYgc3RyZWFt IGNvbnRhaW5zIGFsbA0KPiA+IG5vdGlmaWNhdGlvbnMgZGVmaW5lZCBieSBhbGwgWUFORyBtb2R1 bGVzIGFkdmVydGlzZWQgYnkgdGhlIGRldmljZS4gIA0KPiA+ICBPbmx5IHByb2JsZW0gaXMgdGhl IFJGQzUyNzcgZG9lc24ndCBtZW50aW9uIFlBTkcgYW55d2hlcmUuLi4NCj4gDQo+IEkgdW5kZXJz dGFuZCB0aGUgdGV4dCB0aGUgc2FtZSB3YXkgYW5kIGxpYm5ldGNvbmYgaW1wbGVtZW50cyBpdCB0 aGlzDQo+IHdheS4gUkZDIHNheXMgImFsbCBORVRDT05GIFhNTCBldmVudCBub3RpZmljYXRpb25z IHN1cHBvcnRlZCBieSB0aGUNCj4gTkVUQ09ORiBzZXJ2ZXIiLCBub3QgImFsbCBzdGFuZGFyZCBl dmVudCBub3RpZmljYXRpb25zIi4NCg0KQnV0IHRoaXMgaW5kaWNhdGVzIHRoYXQgKmFsbCogbm90 aWZpY2F0aW9ucyBhcmUgYWx3YXlzIHNlbnQgb3ZlciB0aGUNCidORVRDT05GJyBzdHJlYW0uICBJ LmUuLCB5b3UgY2Fubm90IGhhdmUgYSBub3RpZmljYXRpb24gc2VudCBvbiBzb21lDQpzdHJlYW0s IGJ1dCBub3Qgb24gJ05FVENPTkYnLg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgd2FzIHRoZSBpbnRl bnRpb24gd2l0aCB0aGUgJ05FVENPTkYnIHN0cmVhbS4NCg0KDQoNCi9tYXJ0aW4NCg0KDQoNCg0K PiANCj4gUmFkZWsNCj4gDQo+ID4NCj4gPiBUaGF0IHJlYWRpbmcgd291bGQgZXhjbHVkZSBTWVNM T0cgbWVzc2FnZXMsIHRoYW5rZnVsbHkuDQo+ID4NCj4gPg0KPiA+ID4gUHJvYmFibHkgbmVlZHMg Y2xhcmlmaWNhdGlvbi4gOy0pDQo+ID4NCj4gPiBSaWdodCwgZS5nLiwgd2hhdCBpcyAiTkVUQ09O RiBYTUwiID8NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiBO ZXRjb25mQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQo+IA0KPiAtLSANCj4gUmFkZWsgS3JlamNpDQo+IG1vYmlsZSAgOiArNDIwIDcz MiAyMTIgNzE0DQo+IG9mZmljZSAgOiArNDIwIDIzNCA2ODAgMjU2DQo+IGUtbWFpbCAgOiBya3Jl amNpQGNlc25ldC5jeg0KPiBMaW5rZWRJbjogaHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vcmFk ZWtrcmVqY2kNCj4gDQo+IENFU05FVA0KPiBBc3NvY2lhdGlvbiBvZiBMZWdhbCBFbnRpdGllcw0K PiAxNjAgMDAgUHJhaGEgNiwgWmlrb3ZhIDQNCj4gQ3plY2ggUmVwdWJsaWMNCj4gDQo= From nobody Thu Jun 5 02:24:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829391A0431 for ; Thu, 5 Jun 2014 02:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ-A0Q_7NXv2 for ; Thu, 5 Jun 2014 02:24:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD401A0430 for ; Thu, 5 Jun 2014 02:24:19 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2A84F140141; Thu, 5 Jun 2014 11:24:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401960251; bh=UckmVmeWEB/kL39Pkjj+CGxcOABTAHRHdrxQ85djtC4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gETf1xxbr+OOWs+2y1n5RGIr0rxw9wh8+AMPQpk4xsbXG7G1SLLAtTekpG10279eK 5kvgmFyYLpEJJd2yW1M2W4uvG6wKg9T0EK+5MYvSQ0bPqcZGyrOIeKJGEgo5KnWIIf QdESDY3DP31YV5+vFzvSHubq07haov82vimyyey8= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ladislav Lhotka In-Reply-To: <539034A1.4000500@cesnet.cz> Date: Thu, 5 Jun 2014 11:24:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <538F178E.6060400@cisco.com> <539034A1.4000500@cesnet.cz> To: =?utf-8?Q?Radek_Krej=C4=8D=C3=AD?= X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FMNbOxAjJIW02sQgMmWRVZZBItI Cc: Boris Pilka , Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:24:20 -0000 On 05 Jun 2014, at 11:13, Radek Krej=C4=8D=C3=AD = wrote: >=20 > Dne 4.6.2014 20:31, Kent Watsen napsal(a): >> > This stream contains all NETCONF XML event notifications = supported by >> > the NETCONF server. =20 >> > >> > It says "NETCONF XML". >> > Does this imply that a SYSLOG text stream also needs to be wrapped = in XML >> > and sent as a element on the NETCONF stream? I hope = not. >>=20 >> My interpretation is that the NETCONF stream contains all = notifications defined by all YANG modules advertised by the device. = Only problem is the RFC5277 doesn't mention YANG anywhere... >=20 > I understand the text the same way and libnetconf implements it this = way. RFC says "all NETCONF XML event notifications supported by the = NETCONF server", not "all standard event notifications=E2=80=9D. I wonder, isn=E2=80=99t it another conformance-related issue? A simple = server may implement a YANG module but not its notifications, perhaps = because it doesn=E2=80=99t implement notifications in the first place. = Then, a server implementing only the NETCONF stream might send all = notifications in it but another server may use a more fine-grained = approach. So probably there should be a way for the server to declare to the = client how notifications are organised. Lada=20 >=20 > Radek >=20 >>=20 >> That reading would exclude SYSLOG messages, thankfully. >>=20 >>=20 >> > Probably needs clarification. ;-) >>=20 >> Right, e.g., what is "NETCONF XML" ? >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >>=20 >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Radek Krejci > mobile : +420 732 212 714 > office : +420 234 680 256 > e-mail :=20 > rkrejci@cesnet.cz >=20 > LinkedIn:=20 > http://www.linkedin.com/in/radekkrejci >=20 >=20 > CESNET > Association of Legal Entities > 160 00 Praha 6, Zikova 4 > Czech Republic >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 5 02:28:47 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE6A1A0365 for ; Thu, 5 Jun 2014 02:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e7RtZYgONFM for ; Thu, 5 Jun 2014 02:28:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970301A03C8 for ; Thu, 5 Jun 2014 02:28:44 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id A2925ED05C7; Thu, 5 Jun 2014 11:28:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1401960516; bh=hS7wSZYCWaE8WryGHhCba6igIeLW/5APA4pHmaPe6hE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pzd42+ihcLWEypZm8PG3SJHmpJexguM6/IBpI2/Av5A/SRuHSLMXQ6VjpnsRaPaAY kMi1RhxbLKmUnqYsgqSmrKrQLQKnZR3ONns36gaxPHOhrP5rAXIjCEpVJMdDXtnHzX fLOWEa3K9efXYIj+5wNR/UIvtu7ecmU9TVtaDvFc= Message-ID: <539037F7.2020302@cesnet.cz> Date: Thu, 05 Jun 2014 11:27:19 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Martin Bjorklund References: <539034A1.4000500@cesnet.cz> <20140605.111827.2005613958668274653.mbj@tail-f.com> In-Reply-To: <20140605.111827.2005613958668274653.mbj@tail-f.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XfgBtGEJYy7paMACNshf5CJhiI0 Cc: bpilka@cisco.com, netconf@ietf.org Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:28:46 -0000 Dne 5.6.2014 11:18, Martin Bjorklund napsal(a): > Radek Krejčí wrote: >> Dne 4.6.2014 20:31, Kent Watsen napsal(a): >>>> This stream contains all NETCONF XML event notifications supported by >>>> the NETCONF server. >>>> >>>> It says "NETCONF XML". >>>> Does this imply that a SYSLOG text stream also needs to be wrapped in XML >>>> and sent as a element on the NETCONF stream? I hope not. >>> My interpretation is that the NETCONF stream contains all >>> notifications defined by all YANG modules advertised by the device. >>> Only problem is the RFC5277 doesn't mention YANG anywhere... >> I understand the text the same way and libnetconf implements it this >> way. RFC says "all NETCONF XML event notifications supported by the >> NETCONF server", not "all standard event notifications". > But this indicates that *all* notifications are always sent over the > 'NETCONF' stream. I.e., you cannot have a notification sent on some > stream, but not on 'NETCONF'. > > I don't think this was the intention with the 'NETCONF' stream. > > > > /martin > ok, but what was the intention? Because I don't get the other interpretation from the text :) Radek > > >> Radek >> >>> That reading would exclude SYSLOG messages, thankfully. >>> >>> >>>> Probably needs clarification. ;-) >>> Right, e.g., what is "NETCONF XML" ? >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> -- >> Radek Krejci >> mobile : +420 732 212 714 >> office : +420 234 680 256 >> e-mail : rkrejci@cesnet.cz >> LinkedIn: http://www.linkedin.com/in/radekkrejci >> >> CESNET >> Association of Legal Entities >> 160 00 Praha 6, Zikova 4 >> Czech Republic >> From nobody Thu Jun 5 02:41:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3341A011F; Thu, 5 Jun 2014 02:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.6 X-Spam-Level: X-Spam-Status: No, score=-96.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVLaz_PQQ_NY; Thu, 5 Jun 2014 02:41:15 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D7A351A041D; Thu, 5 Jun 2014 02:41:14 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4FDC91287F35; Thu, 5 Jun 2014 17:40:54 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 3EC87740ACB; Thu, 5 Jun 2014 17:40:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s559e9bC080360; Thu, 5 Jun 2014 17:40:09 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: References: To: feng.chong33@zte.com.cn MIME-Version: 1.0 X-KeepSent: F2871859:174684B5-48257CEE:0034F494; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Thu, 5 Jun 2014 17:40:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-05 17:40:11, Serialize complete at 2014-06-05 17:40:11 Content-Type: multipart/alternative; boundary="=_alternative 00351DD748257CEE_=" X-MAIL: mse01.zte.com.cn s559e9bC080360 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/CN6JA21c8ZiUVHa_MucOCRNquf8 Cc: ye.xu1@zte.com.cn, Netconf , dou.wei1@zte.com.cn, netconf@ietf.org, xiao.yuqing@zte.com.cn Subject: [Netconf] =?gb2312?b?tPC4tDogV0FSTklORzogTWVzc2FnZSBtYXkgY29udGFp?= =?gb2312?b?biBtYWxpY2lvdXMgY29udGVudCBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUg?= =?gb2312?b?dXNhZ2Ugb2YgJ29wZXJhdGlvbicgYXR0cmlidXRlaW4gZWRpdC1jb25maWc=?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:41:21 -0000 This is a multipart message in MIME format. --=_alternative 00351DD748257CEE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Tm9ib2R5IGhhcyBpbnRlcmVzdCBvbiB0aGlzIHF1ZXN0aW9uPyA6KQ0KL2ZyYW5rDQoNCiJOZXRj b25mIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiDQtNPaIDIwMTQtMDYtMDUgMDk6MzU6NDE6 DQoNCj4gZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24gDQo+ILeivP7IyzogICJOZXRjb25mIiA8bmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnPg0KPiANCj4gMjAxNC0wNi0wNSAwOTozNQ0KPiANCj4gytW8 /sjLDQo+IA0KPiBuZXRjb25mQGlldGYub3JnLCANCj4gDQo+ILOty80NCj4gDQo+IHllLnh1MUB6 dGUuY29tLmNuLCBkb3Uud2VpMUB6dGUuY29tLmNuLCB4aWFvLnl1cWluZ0B6dGUuY29tLmNuDQo+ IA0KPiDW98ziDQo+IA0KPiBXQVJOSU5HOiBNZXNzYWdlIG1heSBjb250YWluIG1hbGljaW91cyBj b250ZW50W05ldGNvbmZdIFNvbWUgDQo+IHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29w ZXJhdGlvbicgYXR0cmlidXRlaW4gZWRpdC1jb25maWcNCj4gDQo+IEhpIGFsbCwgDQo+ICAgIEkg aGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgICdvcGVyYXRpb24nIGF0dHJp YnV0ZSANCj4gaW4gZWRpdC1jb25maWcuIA0KPiAgICAxLiAncmVwbGFjZScgYXR0cmlidXRlIGNh biBvbmx5IGJlIHVzZWQgdG8gcmVtb3ZlIGNvbmZpZ3VyYXRpb24/IA0KPiAgICAgICBGb3IgZXhh bXBsZSwgdGhlIHJwYyByZXF1ZXN0IGxpc3RlZCBiZWxvdyBpcyB2YWxpZD8gDQo+ICAgICAgIDxy cGMgbWVzc2FnZS1pZCA9ICIxMDEiPiANCj4gICAgICAgICAgICA8ZWRpdC1jb25maWc+IA0KPiAg ICAgICAgICAgICAgICA8dGFyZ2V0PiANCj4gICAgICAgICAgICAgICAgICAgPHJ1bm5pbmcvPiAN Cj4gICAgICAgICAgICAgICAgPC90YXJnZXQ+IA0KPiAgICAgICAgICAgICAgICA8Y29uZmlnPiAN Cj4gICAgICAgICAgICAgICAgICAgPGludGVyZmFjZXMgb3BlcmF0aW9uPSAicmVwbGFjZSIvPiAN Cj4gICAgICAgICAgICAgICAgPC9jb25maWc+IA0KPiAgICAgICAgICAgIDwvZWRpdC1jb25maWc+ IA0KPiAgICAgICA8L3JwYz4gDQo+IA0KPiANCj4gICAgMi5Ib3cgdG8gcHJvY2VzcyBuZXN0ZWQg b3BlcmF0aW9uIGF0dHJpYnV0ZT8gDQo+ICAgICAgRm9yIGV4YW1wbGU6IA0KPiAgICAgICAgICAg IDxycGMgbWVzc2FnZS1pZCA9ICIxMDEiPiANCj4gICAgICAgICAgICA8ZWRpdC1jb25maWc+IA0K PiAgICAgICAgICAgICAgICA8dGFyZ2V0PiANCj4gICAgICAgICAgICAgICAgICAgPHJ1bm5pbmcv PiANCj4gICAgICAgICAgICAgICAgPC90YXJnZXQ+IA0KPiAgICAgICAgICAgICAgICA8Y29uZmln PiANCj4gICAgICAgICAgICAgICAgICAgPGludGVyZmFjZXM+IA0KPiAgICAgICAgICAgICAgICAg ICAgICAgPGludGVyZmFjZSBvcGVyYXRpb249ICJtZXJnZSI+IA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8bmFtZT5ldGgwLzAvMDwvbmFtZT4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxtdHUgb3BlcmF0aW9uPSAicmVtb3ZlIj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxlbmFibGVkPnRydWU8L2VuYWxibGVkPiANCj4gICAgICAgICAgICAgICAgICAgICAg IDwvaW50ZXJmYWNlPiANCj4gICAgICAgICAgICAgICAgICAgPC9pbnRlcmZhY2VzPiANCj4gICAg ICAgICAgICAgICAgPC9jb25maWc+IA0KPiAgICAgICAgICAgIDwvZWRpdC1jb25maWc+IA0KPiAg ICAgICA8L3JwYz4gDQo+IA0KPiAgICAgIFRoZSBzZXF1ZW5jZSBvZiBwcm9jZXNzIGlzIG1lcmdl IGludGVyZmFjZSBuYW1lICdldGgwLzAvMCcgYW5kIA0KPiByZW1vdmUgbXR1IGFuZCBtZXJnZSBl bmFibGVkIHRvICd0cnVlJyANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvciBtZXJn ZSBpbnRlcmZhY2UgbmFtZSAnZXRoMC8wLzAnIGFuZCANCj4gbWVyZ2UgZW5hYmxlZCB0byAndHJ1 ZScgYW5kIHJlbW92ZSBtdHU/IA0KPiAgICAgIEluIG90aGVyIHdvcmRzLCBORVRDT05GIHdpbGwg cHJvY2VzcyBvdXRlciBsYXllciBvcGVyYXRpb24gDQo+IGZpcnN0bHkgYW5kIHByb2Nlc3MgaW5u ZXIgbGF5ZXIgb3BlcmF0aW9uIGxhdGVyLCBvciBwcm9jZXNzIA0KPiBvcGVyYXRpb25zIGluIGFj Y29yZGFuY2Ugd2l0aCBYTUwgdHJlZSB0cmF2ZXJzYWwgb3JkZXI/IA0KPiANCj4gMy4gSWYgb3Ro ZXIgb3BlcmF0aW9uIGF0dHJpYnV0ZSBuZXN0ZWQgaW4gb3BlcmF0aW9uIGF0dHJpYnV0ZSANCj4g J3JlbW92ZScsd2hhdCBzaG91bGQgTkVUQ09ORiBzZXJ2ZXIgZG8/IE9ubHkgcHJvY2VzcyByZW1v dmUgb3BlcmF0aW9uPyANCj4gDQo+ICAgNC4gQ2FuIE5FVENPTkYgc3VwcG9ydCB0aGUgbmVzdGVk IG9wZXJhdGlvbiBhdHRyaWJ1dGUgZXF1YWxzIHRvIA0KPiBwYXJlbnQgb3BlcmF0aW9uIGF0dHJp YnV0ZT8gDQo+IA0KPiAvZnJhbmsgDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgDQo+IG1haWwgKGFuZCBh bnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgDQo+ IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBhZGRyZXNzZWUNCj4gKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50 LCBhbnkgZGlzY2xvc3VyZSwgDQo+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVy IGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gaW5mb3JtYXRpb24gY29udGFpbmVkIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCANCj4gdGhpcyBtYWls IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+ IA0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5k IGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBj b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUg YWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkg ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5h dGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2Ug ZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFu ZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQg Y29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55 IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWlu YXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNl IGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 00351DD748257CEE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk5vYm9keSBoYXMgaW50ZXJlc3Qgb24gdGhp cyBxdWVzdGlvbj8gOik8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O05ldGNvbmYm cXVvdDsgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDsNCtC009ogMjAxNC0wNi0wNSAw OTozNTo0MTo8YnI+DQo8YnI+DQomZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuIDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyC3orz+yMs6ICZuYnNwOyZxdW90O05ldGNv bmYmcXVvdDsgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQomZ3Q7IDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyMDE0LTA2LTA1IDA5OjM1PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgbmV0Y29uZkBpZXRm Lm9yZywgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg s63LzTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IHll Lnh1MUB6dGUuY29tLmNuLCBkb3Uud2VpMUB6dGUuY29tLmNuLCB4aWFvLnl1cWluZ0B6dGUuY29t LmNuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM 4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFdBUk5J Tkc6IE1lc3NhZ2UgbWF5IGNvbnRhaW4gbWFsaWNpb3VzIGNvbnRlbnRbTmV0Y29uZl0gU29tZSA8 YnI+DQomZ3Q7IHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgYXR0cmli dXRlaW4gZWRpdC1jb25maWc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyBIaSBhbGwsIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0kgaGF2ZSBzb21lIHF1 ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJm5ic3A7J29wZXJhdGlvbicNCmF0dHJpYnV0ZSA8 YnI+DQomZ3Q7IGluIGVkaXQtY29uZmlnLiA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsxLiAncmVw bGFjZScgYXR0cmlidXRlIGNhbiBvbmx5IGJlIHVzZWQgdG8gcmVtb3ZlIGNvbmZpZ3VyYXRpb24/ DQo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZvciBleGFtcGxlLCB0aGUgcnBjIHJl cXVlc3QgbGlzdGVkIGJlbG93IGlzDQp2YWxpZD8gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbHQ7cnBjIG1lc3NhZ2UtaWQgPSAmcXVvdDsxMDEmcXVvdDsmZ3Q7IDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZWRpdC1jb25maWcm Z3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDt0YXJnZXQmZ3Q7DQo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtydW5uaW5n LyZndDsNCjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZsdDsvdGFyZ2V0Jmd0Ow0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2NvbmZpZyZndDsN Cjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJmx0O2ludGVyZmFjZXMNCm9wZXJhdGlvbj0gJnF1b3Q7cmVwbGFj ZSZxdW90Oy8mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvY29uZmlnJmd0Ow0KPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZWRpdC1jb25maWcmZ3Q7IDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9ycGMmZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsyLkhvdyB0byBwcm9jZXNzIG5lc3RlZCBv cGVyYXRpb24gYXR0cmlidXRlPyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Rm9yIGV4 YW1wbGU6IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7cnBjIG1lc3NhZ2UtaWQgPSAmcXVvdDsxMDEmcXVvdDsmZ3Q7DQo8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2VkaXQtY29uZmlnJmd0 OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7dGFyZ2V0Jmd0Ow0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7cnVubmluZy8m Z3Q7DQo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7L3RhcmdldCZndDsNCjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtjb25maWcmZ3Q7DQo8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDtpbnRlcmZhY2VzJmd0Ow0KPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbHQ7aW50ZXJmYWNlIG9wZXJhdGlvbj0gJnF1b3Q7bWVyZ2UmcXVvdDsmZ3Q7 IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7 bmFtZSZndDtldGgwLzAvMCZsdDsvbmFtZSZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDttdHUgb3BlcmF0aW9uPSAmcXVvdDtyZW1vdmUm cXVvdDsmZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7ZW5hYmxlZCZndDt0cnVlJmx0Oy9lbmFsYmxlZCZndDsgPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbHQ7L2ludGVyZmFjZSZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7 L2ludGVyZmFjZXMmZ3Q7DQo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2NvbmZpZyZndDsNCjxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2VkaXQtY29uZmlnJmd0 OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvcnBjJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgc2VxdWVuY2Ugb2YgcHJvY2VzcyBp cyBtZXJnZSBpbnRlcmZhY2UgbmFtZQ0KJ2V0aDAvMC8wJyBhbmQgPGJyPg0KJmd0OyByZW1vdmUg bXR1IGFuZCBtZXJnZSBlbmFibGVkIHRvICd0cnVlJyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29yIG1lcmdlIGludGVyZmFjZSBuYW1l ICdldGgwLzAvMCcgYW5kDQo8YnI+DQomZ3Q7IG1lcmdlIGVuYWJsZWQgdG8gJ3RydWUnIGFuZCBy ZW1vdmUgbXR1PyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW4gb3RoZXIgd29yZHMs IE5FVENPTkYgd2lsbCBwcm9jZXNzIG91dGVyIGxheWVyDQpvcGVyYXRpb24gPGJyPg0KJmd0OyBm aXJzdGx5IGFuZCBwcm9jZXNzIGlubmVyIGxheWVyIG9wZXJhdGlvbiBsYXRlciwgb3IgcHJvY2Vz cyA8YnI+DQomZ3Q7IG9wZXJhdGlvbnMgaW4gYWNjb3JkYW5jZSB3aXRoIFhNTCB0cmVlIHRyYXZl cnNhbCBvcmRlcj8gPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAzLiBJZiBvdGhlciBvcGVy YXRpb24gYXR0cmlidXRlIG5lc3RlZCBpbiBvcGVyYXRpb24gYXR0cmlidXRlIDxicj4NCiZndDsg J3JlbW92ZScsd2hhdCBzaG91bGQgTkVUQ09ORiBzZXJ2ZXIgZG8/IE9ubHkgcHJvY2VzcyByZW1v dmUgb3BlcmF0aW9uPw0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyA0LiBDYW4gTkVUQ09O RiBzdXBwb3J0IHRoZSBuZXN0ZWQgb3BlcmF0aW9uIGF0dHJpYnV0ZSBlcXVhbHMNCnRvIDxicj4N CiZndDsgcGFyZW50IG9wZXJhdGlvbiBhdHRyaWJ1dGU/IDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgPGJyPg0KJmd0OyAvZnJhbmsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KPGJyPg0KJmd0OyBtYWls IChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQg YW5kIDxicj4NCiZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1 c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZTxicj4NCiZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJl IG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCA8YnI+DQomZ3Q7IHJl cHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9m IHRoZSA8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiAmbmJzcDtJZiB5b3UgaGF2ZSByZWNlaXZlZA0KPGJyPg0KJmd0OyB0aGlzIG1haWwgaW4g ZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQom Z3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgTmV0Y29u ZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IE5ldGNvbmZAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9u dD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250Pjwv dHQ+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5k IGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBj b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUg YWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkg ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5h dGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2Ug ZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+ DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFu eSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25m aWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRk cmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlz Y2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlv biBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVs ZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 00351DD748257CEE_=-- From nobody Thu Jun 5 02:45:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CF11A03C8 for ; Thu, 5 Jun 2014 02:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.851 X-Spam-Level: X-Spam-Status: No, score=-14.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsUKcUSjJ8R7 for ; Thu, 5 Jun 2014 02:45:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF511A041D for ; Thu, 5 Jun 2014 02:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4390; q=dns/txt; s=iport; t=1401961497; x=1403171097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QjV9m+D/QNqv0Y2y1hTqVi1EICiAwBUA2EVQCKTGFhA=; b=P0Ly0iXHqBUAkus6Vj7Tk5W6qeh3XodIB3oAAczQS0SValUCXuIMJTZy 9pCrUxDzwy4qOkzeKVS0/eJmGxnDhQVzRoI11xzLQ8Kxd9zjuFWdHNKEo aOqXIySu4hkCwC0jg8OveMG8jxPhS6cZrhDsMzUKG8O/xu+RKilVuzAdV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAAI7kFOtJA2H/2dsb2JhbABZgwdSWIJsuFaGaFEBGXMWdIIlAQEBAwEBAQEgEToJAgwCAgIBBgIRBAEBAwIGHQMCAgIUEQsUAQgIAgQBDQUIiDIIDZEAnCCmHRcEgSaLAoF1FhsHBoJvNoEVBK1MgXiBQIIv X-IronPort-AV: E=Sophos;i="4.98,980,1392163200"; d="scan'208";a="330777047" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 05 Jun 2014 09:44:56 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s559iu4q028265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 09:44:56 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.151]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 5 Jun 2014 04:44:55 -0500 From: "Matus Fabian -X (matfabia - Pantheon Technologies SRO at Cisco)" To: Ladislav Lhotka , =?utf-8?B?UmFkZWsgS3JlasSNw60=?= Thread-Topic: [Netconf] Should Default Event Stream contain really all the notifications ? Thread-Index: AQHPf/WI/dcoOgGtbEW0EgNDM4mK05thdZaAgAAVhoCAAAXYAIAACUQAgAD2ZoCAAAMagP//r17A Date: Thu, 5 Jun 2014 09:44:54 +0000 Message-ID: <235736C59B081941AD5490A89823819B1D34CA4A@xmb-rcd-x11.cisco.com> References: <538F178E.6060400@cisco.com> <539034A1.4000500@cesnet.cz> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.107.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Z1iEOyHKkerftkYRTl9NatY32I8 Cc: "Boris Pilka -X \(bpilka - Pantheon Technologies SRO at Cisco\)" , Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:45:05 -0000 SGksDQoNCklmIHdlIGV4dGVuZCBzdHJlYW0gbGlzdCBkYXRhIHdoaWNoIGlzIGRlc2NyaWJlZCBp biBSRkMtNjI3NyAocmVwbHkgb2YgZ2V0IG9wZXJhdGlvbiBmb3IgdGhlIGxpc3Qgb2YgYXZhaWxh YmxlIGV2ZW50IHN0cmVhbXMpIGNsaWVudCB3aWxsIGJlIGFibGUgdG8gc2VlIG5vdGlmaWNhdGlv biBhc3NvY2lhdGVkIHdpdGggIHN0cmVhbS4NCkkgc3VnZ2VzdCBhZGQgZm9sbG93aW5nIGludG8g L25ldGNvbmYvc3RyZWFtcy9zdHJlYW0NCg0KICBsaXN0IG1vZHVsZSB7DQogICAgZGVzY3JpcHRp b24gIkxpc3Qgb2YgbW9kdWxlcyBhbmQgbm90aWZpY2F0aW9ucyBhc3NvY2lhdGVkIHdpdGggdGhp cyBzdHJlYW0uIjsNCiAgICBrZXkgbW9kdWxlLW5hbWU7DQogICAgbGVhZiBtb2R1bGUtbmFtZSB7 DQogICAgICB0eXBlIHN0cmluZzsNCiAgICAgIGRlc2NyaXB0aW9uICJOYW1lIG9mIHRoZSBtb2R1 bGUuIjsNCiAgICB9DQogICAgbGVhZi1saXN0IG5vdGlmaWNhdGlvbiB7DQogICAgICB0eXBlIHN0 cmluZzsNCiAgICAgIGRlc2NyaXB0aW9uICJOYW1lIG9mIHRoZSBub3RpZmljYXRpb24uIjsNCiAg ICB9DQoNClJlZ2FyZHMsDQpNYXR1cw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IExhZGlzbGF2IExob3RrYQ0KU2VudDogVGh1cnNkYXksIEp1bmUgMDUsIDIwMTQgMTE6MjQgQU0N ClRvOiBSYWRlayBLcmVqxI3DrQ0KQ2M6IEJvcmlzIFBpbGthIC1YIChicGlsa2EgLSBQYW50aGVv biBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKTsgTmV0Y29uZg0KU3ViamVjdDogUmU6IFtOZXRj b25mXSBTaG91bGQgRGVmYXVsdCBFdmVudCBTdHJlYW0gY29udGFpbiByZWFsbHkgYWxsIHRoZSBu b3RpZmljYXRpb25zID8NCg0KDQpPbiAwNSBKdW4gMjAxNCwgYXQgMTE6MTMsIFJhZGVrIEtyZWrE jcOtIDxya3JlamNpQGNlc25ldC5jej4gd3JvdGU6DQoNCj4gDQo+IERuZSA0LjYuMjAxNCAyMDoz MSwgS2VudCBXYXRzZW4gbmFwc2FsKGEpOg0KPj4gPiAgICBUaGlzIHN0cmVhbSBjb250YWlucyBh bGwgTkVUQ09ORiBYTUwgZXZlbnQgbm90aWZpY2F0aW9ucyBzdXBwb3J0ZWQgYnkNCj4+ID4gICAg dGhlIE5FVENPTkYgc2VydmVyLiAgDQo+PiA+DQo+PiA+IEl0IHNheXMgIk5FVENPTkYgWE1MIi4N Cj4+ID4gRG9lcyB0aGlzIGltcGx5IHRoYXQgYSBTWVNMT0cgdGV4dCBzdHJlYW0gYWxzbyBuZWVk cyB0byBiZSB3cmFwcGVkIA0KPj4gPiBpbiBYTUwgYW5kIHNlbnQgYXMgYSA8bm90aWZpY2F0aW9u PiBlbGVtZW50IG9uIHRoZSBORVRDT05GIHN0cmVhbT8gIEkgaG9wZSBub3QuDQo+PiANCj4+IE15 IGludGVycHJldGF0aW9uIGlzIHRoYXQgdGhlIE5FVENPTkYgc3RyZWFtIGNvbnRhaW5zIGFsbCBu b3RpZmljYXRpb25zIGRlZmluZWQgYnkgYWxsIFlBTkcgbW9kdWxlcyBhZHZlcnRpc2VkIGJ5IHRo ZSBkZXZpY2UuICAgIE9ubHkgcHJvYmxlbSBpcyB0aGUgUkZDNTI3NyBkb2Vzbid0IG1lbnRpb24g WUFORyBhbnl3aGVyZS4uLg0KPiANCj4gSSB1bmRlcnN0YW5kIHRoZSB0ZXh0IHRoZSBzYW1lIHdh eSBhbmQgbGlibmV0Y29uZiBpbXBsZW1lbnRzIGl0IHRoaXMgd2F5LiBSRkMgc2F5cyAiYWxsIE5F VENPTkYgWE1MIGV2ZW50IG5vdGlmaWNhdGlvbnMgc3VwcG9ydGVkIGJ5IHRoZSBORVRDT05GIHNl cnZlciIsIG5vdCAiYWxsIHN0YW5kYXJkIGV2ZW50IG5vdGlmaWNhdGlvbnPigJ0uDQoNCkkgd29u ZGVyLCBpc27igJl0IGl0IGFub3RoZXIgY29uZm9ybWFuY2UtcmVsYXRlZCBpc3N1ZT8gQSBzaW1w bGUgc2VydmVyIG1heSBpbXBsZW1lbnQgYSBZQU5HIG1vZHVsZSBidXQgbm90IGl0cyBub3RpZmlj YXRpb25zLCBwZXJoYXBzIGJlY2F1c2UgaXQgZG9lc27igJl0IGltcGxlbWVudCBub3RpZmljYXRp b25zIGluIHRoZSBmaXJzdCBwbGFjZS4gVGhlbiwgYSBzZXJ2ZXIgaW1wbGVtZW50aW5nIG9ubHkg dGhlIE5FVENPTkYgc3RyZWFtIG1pZ2h0IHNlbmQgYWxsIG5vdGlmaWNhdGlvbnMgaW4gaXQgYnV0 IGFub3RoZXIgc2VydmVyIG1heSB1c2UgYSBtb3JlIGZpbmUtZ3JhaW5lZCBhcHByb2FjaC4NCg0K U28gcHJvYmFibHkgdGhlcmUgc2hvdWxkIGJlIGEgd2F5IGZvciB0aGUgc2VydmVyIHRvIGRlY2xh cmUgdG8gdGhlIGNsaWVudCBob3cgbm90aWZpY2F0aW9ucyBhcmUgb3JnYW5pc2VkLg0KDQpMYWRh IA0KDQo+IA0KPiBSYWRlaw0KPiANCj4+IA0KPj4gVGhhdCByZWFkaW5nIHdvdWxkIGV4Y2x1ZGUg U1lTTE9HIG1lc3NhZ2VzLCB0aGFua2Z1bGx5Lg0KPj4gDQo+PiANCj4+ID4gUHJvYmFibHkgbmVl ZHMgY2xhcmlmaWNhdGlvbi4gOy0pDQo+PiANCj4+IFJpZ2h0LCBlLmcuLCB3aGF0IGlzICJORVRD T05GIFhNTCIgPw0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4+IA0K Pj4gTmV0Y29uZkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRjb25mDQo+IA0KPiAtLQ0KPiBSYWRlayBLcmVqY2kNCj4gbW9iaWxlICA6ICs0MjAg NzMyIDIxMiA3MTQNCj4gb2ZmaWNlICA6ICs0MjAgMjM0IDY4MCAyNTYNCj4gZS1tYWlsICA6IA0K PiBya3JlamNpQGNlc25ldC5jeg0KPiANCj4gTGlua2VkSW46IA0KPiBodHRwOi8vd3d3Lmxpbmtl ZGluLmNvbS9pbi9yYWRla2tyZWpjaQ0KPiANCj4gDQo+IENFU05FVA0KPiBBc3NvY2lhdGlvbiBv ZiBMZWdhbCBFbnRpdGllcw0KPiAxNjAgMDAgUHJhaGEgNiwgWmlrb3ZhIDQNCj4gQ3plY2ggUmVw dWJsaWMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCi0tDQpMYWRpc2xhdiBM aG90a2EsIENaLk5JQyBMYWJzDQpQR1AgS2V5IElEOiBFNzRFOEMwQw0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5n IGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZg0K From nobody Thu Jun 5 02:59:23 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF901A0151 for ; Thu, 5 Jun 2014 02:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS9B-9jdvEbN for ; Thu, 5 Jun 2014 02:59:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9911A0132 for ; Thu, 5 Jun 2014 02:59:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHW19219; Thu, 05 Jun 2014 09:59:07 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 10:58:16 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 10:59:05 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 5 Jun 2014 17:58:56 +0800 From: "Liubing (Leo)" To: chong feng Thread-Topic: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt Thread-Index: AQHPf97ZguH8jW6EdUWevnlZT6o6DptgjqiAgAEk+lA= Date: Thu, 5 Jun 2014 09:58:56 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3ABnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qGMfh3yeUBBuMQJZh_J6yuWwhkI Cc: Zhengguangying , Yangshouchuan , Netconf , Yangang Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:59:18 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3ABnkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hvbmcsDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiBQbGVhc2Ug c2VlIHJlcGxpZXMgaW5saW5lLg0KDQpGcm9tOiBjaG9uZyBmZW5nIFttYWlsdG86ZmVuZ2Nob25n bGxseUBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQgMTE6MzMgUE0N ClRvOiBMaXViaW5nIChMZW8pDQpDYzogTmV0Y29uZjsgWmhlbmdndWFuZ3lpbmc7IFlhbmdhbmcN ClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gTmV0Y29uZiBmcmFnbWVudGF0aW9uLS8vRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0w MC50eHQNCg0KSGksDQogICBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBuZXcgZHJhZnQuDQogICBJIHVu ZGVyc3RhbmQgeW91ciBzb2x1dGlvbiBpcyB0aGF0IE5FVENPTkYgc2VydmVyIHJlc2VydmUgYnJl YWsgcG9pbnRzIGFuZCB3YWl0IGZvciBjbGllbnQgdG8gcmV0cmlldmUgdGhlIG5leHQgcmVzcG9u c2UuDQpJIHRoaW5rIGl0J3Mgbm90IGEgZ29vZCBzb2x1dGlvbiwgYmVjYXVzZSBzZXJ2ZXIgbWF5 IG5lZWQgdG8gcmVzZXJ2ZSBtYW55IGJyZWFrIHBvaW50cyBpZiB0aGVyZSBhIGxhcmdlIG51bWJl ciBvZiBjb25jdXJyZW50IHJlcXVlc3RzLg0KSXQncyB0b28gaGVhdnkgZm9yIHNlcnZlci4gQW5k LCB0aGUgc2VydmVyIG11c3QgYmUgc3RhdGVmdWwgaWYgaXQgc3VwcG9ydCBnZXQtYmxvY2sgY2Fw YWJpbGl0eS4NCltCaW5nXSBUaGUgYnJlYWsgcG9pbnQgZGVzaWduIGlzIG1haW5seSBmb3IgdGhl IGlzc3VlIG9mIHRlcm1pbmF0aW5nIHRoZSByZXRyaWV2aW5nIG9wZXJhdGlvbiBpbnN0YW50bHku IFNvIGJlZm9yZSB0aGlua2luZyBvZiB0aGUgZGVzaWduIGFzIHRvbyBoZWF2eSBvciB3aGF0LCBt YXkgSSBhc2sgZG8geW91IGFncmVlIGl0IGlzIGEgcmVxdWlyZW1lbnQgbmVlZCB0byBiZSBzb2x2 ZWQ/DQoNClRoZW4gZm9yIHRoZSDigJx0b28gaGVhdnnigJ0gY29uc2lkZXJhdGlvbiwgSSBkb27i gJl0IHRoaW5rIDxnZXQtYmxvY2s+IHdvdWxkIGJlIHdpZGUgdXNlZCBhbW9uZyBvcGVyYXRpb25z LCBvbmx5IGlmIHRoZSByZXRyaWV2aW5nIGRhdGEgaXMgdG9vIGJpZy4gU28gYmFzaWNhbGx5IEkg ZG9u4oCZdCB0aGluayB0aGVyZSB3b3VsZCBiZSBhIGxhcmdlIG51bWJlciBvZiBjb25jdXJyZW50 IHJlcXVlc3RzLg0KDQpUaGUgb3RoZXIgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBhcmUgbGlzdGVk IGJlbG93Og0KMS4gR2V0LWJsb2NrIGNhcGFiaWxpdHkgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIGdl dC1jb25maWcgb3BlcmF0aW9uJ3MgYmVoYXZpb3IuIElmIGNsaWVudCB1c2UgZ2V0LWNvbmZpZyBv cGVyYXRpb24gdG8gcmV0cmlldmUgZGF0YSwNCmFsbCBkYXRhIG11c3QgYmUgc2VudCBpbiBvbmUg cmVzcG9uc2Ugb3IgZ2V0LWJsb2NrIGNhcGFiaWxpdHkgc2hvdWxkIGFkZCBhIHBhcmFtZXRlciB0 byBnZXQtY29uZmlnIG9wZXJhdGlvbiB0byBpbmRpY2F0ZSB0aGUNCnJlc3BvbnNlIGRhdGEgd2ls bCBiZSBmcmFnbWVudGVkLg0KW0JpbmddIFllcywgZ2V0LWJsb2NrIGNhcGFiaWxpdHkgaXMgaW4g dXNlIG9ubHkgaWYgYm90aCBvZiB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgc3VwcG9ydCB0aGUgY2Fw YWJpbGl0eS4gQW5kIGluIGN1cnJlbnQgZGVzaWduLCA8Z2V0LWJsb2NrPiBpcyBkZWZpbmVkIGFz IGEgbmV3IG9wZXJhdGlvbiBhbG9uZyB3aXRoIDxnZXQtY29uZmlnPi4NCklmIEkgdW5kZXJzdGFu ZCBjb3JyZWN0bHksIHlvdSBoYWQgdGhlIGFzc3VtcHRpb24gdGhhdCBpdCBpcyB0aGUgc2VydmVy IHdobyB0cmlnZ2VycyB0aGUgPGdldC1ibG9jaz4gb3BlcmF0aW9uIGluIGEgcmVzcG9uc2UgdG8g PGdldC1jb25maWc+PyBJZiBzbywgSSB0aGluayBpdCBpcyBhIGdvb2QgcG9pbnQgdGhhdCB3ZSBz aG91bGQgY29uc2lkZXIuDQoNCjIuIEEgc2V0LWlkIGNhbiBiZSBhZ2VkPyB3aGVuIGNsaWVudCBu ZXZlciBzZW5kIGEgcmVxdWVzdCB0byByZXRyaWV2ZSB0aGUgbmV4dCBmcmFnbWVudCBmb3IgYSBs b25nIHRpbWUsIEkgdGhpbmsgdGhpcyBzZXQtaWQgc2hvdWxkIGJlIGFnZWQsDQpvdGhlcndpc2Us IHNlcnZlciB3aWxsIGJlIHJlc2VydmUgbW9yZSBhbmQgbW9yZSBzZXQtaWRzLg0KMy4gQSBzZXQt aWQgaXMgdW5pcXVlIGluIHNlc3Npb24gbGV2ZWwgb3Igc2VydmVyIGxldmVsPw0KNC4gSWYgYSBz ZXNzaW9uIGlzIGtpbGxlZCBvciBjbG9zZWQsIG90aGVyIHNlc3Npb24gY2FuIHJldHJpZXZlZCB0 aGUgbmV4dCBmcmFnbWVudCBpZiB0aGUgY2xpZW50IHByb3ZpZGUgdGhlIGNvcnJlY3Qgc2V0LWlk Pw0KW0JpbmddIFNldC1pZCBpcyB1c2VkIGZvciBkaXN0aW5ndWlzaGluZyBmcmFnbWVudHMgaW4g YSBzcGVjaWZpYyBzZXNzaW9uLiBTbyB3aGVuIHRoZSBzZXNzaW9uIGlzIGtpbGxlZCwgdGhlIHNl dC1pZHMgYXJlIGludmFsaWQgYXMgd2VsbC4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQovZnJh bmsNCg0KMjAxNC0wNi0wNCAxODoyMiBHTVQrMDg6MDAgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJp bmdAaHVhd2VpLmNvbTxtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4+Og0KSGkgYWxsLA0K DQpXZSd2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQsIHdoaWNoIGlzIGFib3V0IE5FVENPTkYgZGF0YSBm cmFnbWVudGF0aW9uLg0KDQpUaGUgYmFzaWMgaWRlYSBpcywgd2hlbiBOTVMgaXMgcmV0cmlldmlu ZyBhIGxhcmdlIHNpemUgb2YgZGF0YSBpbiB0aGUgZGV2aWNlLCB0aGUgPHJwYy1yZXBseT4gbWln aHQgYmUgdmVyeSBiaWcgKGUuZy4gdGhlIHJvdXRlcyBpbiBhIGNvcmUgcm91dGVyKS4NCkN1cnJl bnRseSB0aGVyZSBhcmUgbWFpbmx5IHR3byBtZXRob2RzIG9mIGhhbmRsaW5nIHRoZSBiaWcgPHJw Yy1yZXBseT46IG9uZSBpcyBzdHJlYW0tb3JpZW50ZWQgaGFuZGxpbmc7IHRoZSBvdGhlciBpcyBq dXN0IHJlcXVlc3QgYSBwb3J0aW9uIG9mIHRoZSBkYXRhLg0KDQpUaGlzIGRyYWZ0IGNvbnNpZGVy cyBib3RoIHRoZSB0d28gbWV0aG9kcyBhcmUgcHJvYmxlbWF0aWMgaW4gc29tZSBzaXR1YXRpb25z LCBhbmQgcHJvcG9zZXMgYSBuZXcgbWV0aG9kIHdoaWNoIGFsbG93cyB0aGUgbGFyZ2Ugc2l6ZSA8 cnBjLXJlcGx5PiB0byBiZSBmcmFnbWVudGVkIGluIE5FVENPTkYgbGV2ZWwuDQoNClBsZWFzZSBy ZWFkIHRoZSBkcmFmdCBhbmQgY29tbWVudC4NCk1hbnkgdGhhbmtzIQ0KDQpCZXN0IHJlZ2FyZHMs DQpCaW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz5dDQpT ZW50OiBXZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQgNToyNyBQTQ0KVG86IExpdWJpbmcgKExlbyk7 IExpdWJpbmcgKExlbyk7IFpoZW5nZ3Vhbmd5aW5nOyBaaGVuZ2d1YW5neWluZw0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0 aW9uLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saXUtbmV0Y29uZi1m cmFnbWVudGF0aW9uLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBC aW5nIExpdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAg ICAgICBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uDQpSZXZpc2lvbjogICAgICAgMDAN ClRpdGxlOiAgICAgICAgICBBIE5FVENPTkYgRXh0ZW5zaW9uIGZvciBEYXRhIEZyYWdtZW50YXRp b24NCkRvY3VtZW50IGRhdGU6ICAyMDE0LTA2LTA0DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMTINClVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0 aW9uLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24vDQpIdG1saXplZDogICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0w MA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGFuIGV4dGVuc2lv biB0byBORVRDT05GIChOZXR3b3JrDQogICBDb25maWd1cmF0aW9uKSBwcm90b2NvbC4gVGhlIGV4 dGVuc2lvbiBhbGxvd3MgTkVUQ09ORiB0byBoYW5kbGUgbGFyZ2UNCiAgIHNpemUgZGF0YSBhcyBm cmFnbWVudGVkIFJQQyBtZXNzYWdlcy4gU3BlY2lmaWNhbGx5LCB0aGlzIGRvY3VtZW50DQogICBk ZWZpbmVzIGEgbmV3IDxnZXQtYmxvY2s+IGNhcGFiaWxpdHkgYW5kIHJlbGV2YW50IG9wZXJhdGlv bnMgdG8NCiAgIGhhbmRsZSB0aGUgZnJhZ21lbnRhdGlvbnMuDQoNCg0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNv bmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYNCg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3ABnkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG 5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrm ibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQ2hvbmcsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1l bnRzLiBQbGVhc2Ugc2VlIHJlcGxpZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBjaG9uZyBmZW5nIFttYWlsdG86ZmVuZ2Nob25nbGxseUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDA0LCAyMDE0IDExOjMzIFBNPGJyPg0KPGI+VG86PC9i PiBMaXViaW5nIChMZW8pPGJyPg0KPGI+Q2M6PC9iPiBOZXRjb25mOyBaaGVuZ2d1YW5neWluZzsg WWFuZ2FuZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIE5ldGNvbmYgZnJhZ21l bnRhdGlvbi0vL0ZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1uZXRj b25mLWZyYWdtZW50YXRpb24tMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO0kgaGF2ZSByZXZpZXdlZCB0 aGlzIG5ldyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO0kgdW5kZXJz dGFuZCB5b3VyIHNvbHV0aW9uIGlzIHRoYXQgTkVUQ09ORiBzZXJ2ZXIgcmVzZXJ2ZSBicmVhayBw b2ludHMgYW5kIHdhaXQgZm9yIGNsaWVudCB0byByPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5l dHJpZXZlIHRoZSBuZXh0IHJlc3BvbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj5JIHRoaW5rIGl0J3Mgbm90IGEgZ29vZCBzb2x1dGlvbiwgYmVjYXVz ZSBzZXJ2ZXIgbWF5IG5lZWQgdG8gcmVzZXJ2ZSBtYW55IGJyZWFrIHBvaW50cyBpZiB0aGVyZSBh IGxhcmdlIG51bWJlciBvZiBjb25jdXJyZW50IHJlcXVlc3RzLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SXQncyB0b28g aGVhdnkgZm9yIHNlcnZlci4gQW5kLCB0aGUgc2VydmVyIG11c3QgYmUgc3RhdGVmdWwgaWYgaXQg c3VwcG9ydCBnZXQtYmxvY2sgY2FwYWJpbGl0eS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W0JpbmddIFRoZSBicmVhayBwb2ludCBkZXNpZ24gaXMgbWFpbmx5IGZvciB0aGUgaXNzdWUgb2Yg dGVybWluYXRpbmcgdGhlIHJldHJpZXZpbmcgb3BlcmF0aW9uIGluc3RhbnRseS4gU28gYmVmb3Jl IHRoaW5raW5nIG9mIHRoZSBkZXNpZ24gYXMgdG9vDQogaGVhdnkgb3Igd2hhdCwgbWF5IEkgYXNr IGRvIHlvdSBhZ3JlZSBpdCBpcyBhIHJlcXVpcmVtZW50IG5lZWQgdG8gYmUgc29sdmVkPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVuIGZvciB0aGUg4oCcdG9vIGhlYXZ5 4oCdIGNvbnNpZGVyYXRpb24sIEkgZG9u4oCZdCB0aGluayAmbHQ7Z2V0LWJsb2NrJmd0OyB3b3Vs ZCBiZSB3aWRlIHVzZWQgYW1vbmcgb3BlcmF0aW9ucywgb25seSBpZiB0aGUgcmV0cmlldmluZyBk YXRhIGlzIHRvbyBiaWcuDQogU28gYmFzaWNhbGx5IEkgZG9u4oCZdCB0aGluayB0aGVyZSB3b3Vs ZCBiZSBhIGxhcmdlIG51bWJlciBvZiBjb25jdXJyZW50IHJlcXVlc3RzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhlIG90aGVyIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIGxpc3RlZCBiZWxvdzo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjEuIEdldC1ibG9jayBjYXBhYmlsaXR5IHNob3VsZCBub3QgY2hhbmdlIHRoZSBn ZXQtY29uZmlnIG9wZXJhdGlvbidzIGJlaGF2aW9yLiBJZiBjbGllbnQgdXNlIGdldC1jb25maWcg b3BlcmF0aW9uIHRvIHJldHJpZXZlIGRhdGEsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5hbGwgZGF0YSBtdXN0IGJlIHNl bnQgaW4gb25lIHJlc3BvbnNlIG9yIGdldC1ibG9jayBjYXBhYmlsaXR5IHNob3VsZCBhZGQgYSBw YXJhbWV0ZXIgdG8gZ2V0LWNvbmZpZyBvcGVyYXRpb24gdG8gaW5kaWNhdGUgdGhlJm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj5yZXNwb25zZSBkYXRhIHdpbGwgYmUgZnJhZ21lbnRlZC48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0Jp bmddIFllcywgZ2V0LWJsb2NrIGNhcGFiaWxpdHkgaXMgaW4gdXNlIG9ubHkgaWYgYm90aCBvZiB0 aGUgY2xpZW50IGFuZCBzZXJ2ZXIgc3VwcG9ydCB0aGUgY2FwYWJpbGl0eS4gQW5kIGluIGN1cnJl bnQgZGVzaWduLCAmbHQ7Z2V0LWJsb2NrJmd0OyBpcw0KIGRlZmluZWQgYXMgYSBuZXcgb3BlcmF0 aW9uIGFsb25nIHdpdGggJmx0O2dldC1jb25maWcmZ3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IGhhZCB0 aGUgYXNzdW1wdGlvbiB0aGF0IGl0IGlzIHRoZSBzZXJ2ZXIgd2hvIHRyaWdnZXJzIHRoZSAmbHQ7 Z2V0LWJsb2NrJmd0OyBvcGVyYXRpb24gaW4gYSByZXNwb25zZSB0byAmbHQ7Z2V0LWNvbmZpZyZn dDs/IElmDQogc28sIEkgdGhpbmsgaXQgaXMgYSBnb29kIHBvaW50IHRoYXQgd2Ugc2hvdWxkIGNv bnNpZGVyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjIuIEEgc2V0LWlkIGNh biBiZSBhZ2VkPyB3aGVuIGNsaWVudCBuZXZlciBzZW5kIGEgcmVxdWVzdCB0byByZXRyaWV2ZSB0 aGUgbmV4dCBmcmFnbWVudCBmb3IgYSBsb25nIHRpbWUsIEkgdGhpbmsgdGhpcyBzZXQtaWQgc2hv dWxkIGJlIGFnZWQsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5vdGhlcndpc2UsIHNlcnZlciB3aWxsIGJlIHJlc2VydmUg bW9yZSBhbmQgbW9yZSBzZXQtaWRzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+My4gQSBzZXQtaWQgaXMgdW5pcXVlIGlu IHNlc3Npb24gbGV2ZWwgb3Igc2VydmVyIGxldmVsPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+NC4gSWYgYSBzZXNzaW9u IGlzIGtpbGxlZCBvciBjbG9zZWQsIG90aGVyIHNlc3Npb24gY2FuIHJldHJpZXZlZCB0aGUgbmV4 dCBmcmFnbWVudCBpZiB0aGUgY2xpZW50IHByb3ZpZGUgdGhlIGNvcnJlY3Qgc2V0LWlkPzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5bQmluZ10gU2V0LWlkIGlzIHVzZWQgZm9yIGRpc3Rpbmd1aXNoaW5nIGZyYWdtZW50 cyBpbiBhIHNwZWNpZmljIHNlc3Npb24uIFNvIHdoZW4gdGhlIHNlc3Npb24gaXMga2lsbGVkLCB0 aGUgc2V0LWlkcyBhcmUgaW52YWxpZCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5CaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4vZnJhbms8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4yMDE0LTA2LTA0 IDE4OjIyIEdNVCYjNDM7MDg6MDAgTGl1YmluZyAoTGVvKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxl by5saXViaW5nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5sZW8ubGl1YmluZ0BodWF3ZWku Y29tPC9hPiZndDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFsbCw8YnI+DQo8YnI+DQpXZSd2ZSBwb3N0ZWQgYSBuZXcg ZHJhZnQsIHdoaWNoIGlzIGFib3V0IE5FVENPTkYgZGF0YSBmcmFnbWVudGF0aW9uLjxicj4NCjxi cj4NClRoZSBiYXNpYyBpZGVhIGlzLCB3aGVuIE5NUyBpcyByZXRyaWV2aW5nIGEgbGFyZ2Ugc2l6 ZSBvZiBkYXRhIGluIHRoZSBkZXZpY2UsIHRoZSAmbHQ7cnBjLXJlcGx5Jmd0OyBtaWdodCBiZSB2 ZXJ5IGJpZyAoZS5nLiB0aGUgcm91dGVzIGluIGEgY29yZSByb3V0ZXIpLjxicj4NCkN1cnJlbnRs eSB0aGVyZSBhcmUgbWFpbmx5IHR3byBtZXRob2RzIG9mIGhhbmRsaW5nIHRoZSBiaWcgJmx0O3Jw Yy1yZXBseSZndDs6IG9uZSBpcyBzdHJlYW0tb3JpZW50ZWQgaGFuZGxpbmc7IHRoZSBvdGhlciBp cyBqdXN0IHJlcXVlc3QgYSBwb3J0aW9uIG9mIHRoZSBkYXRhLjxicj4NCjxicj4NClRoaXMgZHJh ZnQgY29uc2lkZXJzIGJvdGggdGhlIHR3byBtZXRob2RzIGFyZSBwcm9ibGVtYXRpYyBpbiBzb21l IHNpdHVhdGlvbnMsIGFuZCBwcm9wb3NlcyBhIG5ldyBtZXRob2Qgd2hpY2ggYWxsb3dzIHRoZSBs YXJnZSBzaXplICZsdDtycGMtcmVwbHkmZ3Q7IHRvIGJlIGZyYWdtZW50ZWQgaW4gTkVUQ09ORiBs ZXZlbC48YnI+DQo8YnI+DQpQbGVhc2UgcmVhZCB0aGUgZHJhZnQgYW5kIGNvbW1lbnQuPGJyPg0K TWFueSB0aGFua3MhPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCkJpbmc8YnI+DQo8YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gW21h aWx0bzo8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8L2E+XTxicj4NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCA1 OjI3IFBNPGJyPg0KVG86IExpdWJpbmcgKExlbyk7IExpdWJpbmcgKExlbyk7IFpoZW5nZ3Vhbmd5 aW5nOyBaaGVuZ2d1YW5neWluZzxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQ8YnI+DQo8YnI+DQo8 YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlv bi0wMC50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJpbmcgTGl1 IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50 YXRpb248YnI+DQpSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgMDA8YnI+DQpUaXRsZTog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0EgTkVUQ09ORiBFeHRlbnNpb24gZm9y IERhdGEgRnJhZ21lbnRhdGlvbjxicj4NCkRvY3VtZW50IGRhdGU6ICZuYnNwOzIwMTQtMDYtMDQ8 YnI+DQpHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luZGl2aWR1YWwg U3VibWlzc2lvbjxicj4NClBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 MTI8YnI+DQpVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LW5ldGNv bmYtZnJhZ21lbnRhdGlvbi0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4 dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVu dGF0aW9uLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi88L2E+PGJyPg0KSHRtbGl6ZWQ6ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDA8 L2E+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9j dW1lbnQgaW50cm9kdWNlcyBhbiBleHRlbnNpb24gdG8gTkVUQ09ORiAoTmV0d29yazxicj4NCiZu YnNwOyAmbmJzcDtDb25maWd1cmF0aW9uKSBwcm90b2NvbC4gVGhlIGV4dGVuc2lvbiBhbGxvd3Mg TkVUQ09ORiB0byBoYW5kbGUgbGFyZ2U8YnI+DQombmJzcDsgJm5ic3A7c2l6ZSBkYXRhIGFzIGZy YWdtZW50ZWQgUlBDIG1lc3NhZ2VzLiBTcGVjaWZpY2FsbHksIHRoaXMgZG9jdW1lbnQ8YnI+DQom bmJzcDsgJm5ic3A7ZGVmaW5lcyBhIG5ldyAmbHQ7Z2V0LWJsb2NrJmd0OyBjYXBhYmlsaXR5IGFu ZCByZWxldmFudCBvcGVyYXRpb25zIHRvPGJyPg0KJm5ic3A7ICZuYnNwO2hhbmRsZSB0aGUgZnJh Z21lbnRhdGlvbnMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5p ZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNv bmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5l dGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3ABnkgeml506mbxchi_-- From nobody Thu Jun 5 03:04:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAA91A015F; Thu, 5 Jun 2014 03:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVVV2Apf59Q0; Thu, 5 Jun 2014 03:04:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326FA1A014D; Thu, 5 Jun 2014 03:04:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX00148; Thu, 05 Jun 2014 10:04:10 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 11:03:19 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 11:04:08 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 5 Jun 2014 18:03:59 +0800 From: "Liubing (Leo)" To: "Bert Wijnen (IETF)" , "feng.chong33@zte.com.cn" , Andy Bierman Thread-Topic: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt Thread-Index: AQHPgKV385u97nDos02KbT6GeJYwqg== Date: Thu, 5 Jun 2014 10:03:58 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3CC@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <53902CAD.6010906@bwijnen.net> In-Reply-To: <53902CAD.6010906@bwijnen.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/A5CBvsqF3rpj5m60jgjkB5-d4YU Cc: Zhengguangying , Netconf , Netconf , Yangang Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 10:04:22 -0000 SGkgQmVydCwNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4NCkkgZnVsbHkg YWdyZWUgd2Ugc2hvdWxkIGZvY3VzaW5nIG9uIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBjb25zaWRl cmluZyBpdCBpcyBhIC0wMCB2ZXJzaW9uIGRyYWZ0Lg0KDQpGb3IgdGhlIHNvbHV0aW9ucywgd2Un cmUgb3BlbiB0byBkaXNjdXNzIHRoZSBhbHRlcm5hdGl2ZXMuDQoNCkJlc3QgcmVnYXJkcywNCkJp bmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOZXRjb25mIFttYWls dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVydCBXaWpuZW4NCj4g KElFVEYpDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDA1LCAyMDE0IDQ6MzkgUE0NCj4gVG86IGZl bmcuY2hvbmczM0B6dGUuY29tLmNuOyBBbmR5IEJpZXJtYW4NCj4gQ2M6IFpoZW5nZ3Vhbmd5aW5n OyBOZXRjb25mOyBOZXRjb25mOyBZYW5nYW5nDQo+IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0g562U 5aSNOiBSZTogTmV0Y29uZiBmcmFnbWVudGF0aW9uLS8vRlc6IE5ldyBWZXJzaW9uDQo+IE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQNCj4gDQo+ IEkgYW0gYSBiaXQgY29uY2VybmVkIHRoYXQgd2UgYXJlIG5vdyBkaXNjdXNzaW5nIGEgcG9zc2li bGUgc29sdXRpb24uDQo+IA0KPiBCVVQuLi4uIEkgdGhpbmsgd2Ugc2hvdWxkIGZpcnN0IGRpc2N1 c3Mgb24gdGhpcyBsaXN0Og0KPiANCj4gLSBJcyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZGVzY3Jp YmluZyBhIHJlYWwgcHJvYmxlbSB0aGF0IHdlIGFsbCBhZ3JlZSB3aXRoPw0KPiANCj4gLSBJZiBp dCBpcywgZG8gd2UgYmVsaWV2ZSB0aGF0IG91ciBXRyBzaG91bGQgd29yayBvbiBhIHNvbHV0aW9u Pw0KPiANCj4gT25jZSB3ZSBoYXZlIGFncmVlIG9uIHRoYXQsIHdlIGNhbiBkZWNpZGUgaWYgd2Ug d2FudCB0byBhZGQgdGhpcyB0b3BpYyB0bw0KPiBvdXIgV0cgY2hhcnRlciBhbmQgd29yayBvbiBp dC4NCj4gDQo+IEJlcnQgKHNwZWFraW5nIGFzIGNvLWNoYWlyKQ0KPiANCj4gT24gMDUvMDYvMTQg MDI6NTksIGZlbmcuY2hvbmczM0B6dGUuY29tLmNuIHdyb3RlOg0KPiA+IGFuZHksDQo+ID4gICAg IEhvdyB0byBwcm9jZXNzIG5lc3RlZCBsaXN0cyB1c2luZyB5b3VyIHNvbHV0aW9uPw0KPiA+DQo+ ID4gRm9yIGV4YW1wbGU6DQo+ID4gICAgIGxpc3QgZm9vIHsNCj4gPiAgICAgICAgIGtleSBhOw0K PiA+ICAgICAgICAgbGVhZiBhIHsuLi59DQo+ID4gICAgICAgICBsZWFmIGIgey4uLn0NCj4gPiAg ICAgICAgIGxpc3QgbmVzdGVkLWZvbyB7DQo+ID4ga2V5IG5lc3RlZC1hOw0KPiA+IGxlYWYgbmVz dGVkLWEgey4uLn0NCj4gPiBsZWFmIG5ldHN0ZWQtYiB7Li4ufQ0KPiA+ICAgICAgICAgfQ0KPiA+ ICAgICB9DQo+ID4NCj4gPiAgICBJZiByZXF1ZXN0IGlzOg0KPiA+IDxycGM+DQo+ID4gICAgICAg PGdldC1saXN0Pg0KPiA+ICAgICAgICAgPHRhcmdldD4vZm9vPC90YXJnZXQ+DQo+ID4gICAgICAg PC9nZXQtbGlzdD4NCj4gPiAgICAgPC9ycGM+DQo+ID4gICAgV2hhdCBpcyB0aGUgcmVzcG9uc2U/ DQo+ID4NCj4gPiBBbmQsIGFub3RoZXIgcXVlc3Rpb246DQo+ID4gU3RhcnQtaW5kZXggaXMgbm90 IHJlbGlhYmxlLCBpZiBzb21lIGVudHJpZXMgYXJlIGRlbGV0ZWQuIEkgdGhpbmsgeW91IGNhbiB1 c2UNCj4gc3RhcnQga2V5IGluc3RlYWQuDQo+ID4NCj4gPg0KPiA+DQo+ID4gL2ZyYW5rDQo+ID4N Cj4gPiAiTmV0Y29uZiIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4g5YaZ5LqOIDIwMTQtMDYt MDUgMDA6NDM6MTI6DQo+ID4NCj4gPiAgPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNv bT4NCj4gPiAgPiDlj5Hku7bkuro6ICAiTmV0Y29uZiIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9y Zz4gID4gID4gMjAxNC0wNi0wNQ0KPiAwMDo0Mw0KPiA+ID4gID4g5pS25Lu25Lq6DQo+ID4gID4N Cj4gPiAgPiBjaG9uZyBmZW5nIDxmZW5nY2hvbmdsbGx5QGdtYWlsLmNvbT4sICA+ICA+IOaKhOmA gQ0KPiA+ICA+DQo+ID4gID4gWmhlbmdndWFuZ3lpbmcgPHpoZW5nZ3Vhbmd5aW5nQGh1YXdlaS5j b20+LCBOZXRjb25mICA+DQo+ID4gPG5ldGNvbmZAaWV0Zi5vcmc+LCBZYW5nYW5nIDx5YW5nYW5n QGh1YXdlaS5jb20+ICA+ICA+IOS4u+mimA0KPiA+ICA+DQo+ID4gID4gUmU6IFtOZXRjb25mXSBO ZXRjb25mIGZyYWdtZW50YXRpb24tLy9GVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uDQo+ID4g PiBmb3IgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQNCj4gPiAgPg0KPiA+ ICA+DQo+ID4NCj4gPiAgPiBPbiBXZWQsIEp1biA0LCAyMDE0IGF0IDg6MzIgQU0sIGNob25nIGZl bmcNCj4gPGZlbmdjaG9uZ2xsbHlAZ21haWwuY29tPiB3cm90ZToNCj4gPiAgPiBIaSwNCj4gPiAg PiAgICBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBuZXcgZHJhZnQuDQo+ID4gID4gICAgSSB1bmRlcnN0 YW5kIHlvdXIgc29sdXRpb24gaXMgdGhhdCBORVRDT05GIHNlcnZlciByZXNlcnZlIGJyZWFrDQo+ ID4gID4gcG9pbnRzIGFuZCB3YWl0IGZvciBjbGllbnQgdG8gcmV0cmlldmUgdGhlIG5leHQgcmVz cG9uc2UuDQo+ID4gID4gSSB0aGluayBpdCdzIG5vdCBhIGdvb2Qgc29sdXRpb24sIGJlY2F1c2Ug c2VydmVyIG1heSBuZWVkIHRvDQo+ID4gcmVzZXJ2ZSAgPiBtYW55IGJyZWFrIHBvaW50cyBpZiB0 aGVyZSBhIGxhcmdlIG51bWJlciBvZiBjb25jdXJyZW50DQo+IHJlcXVlc3RzLg0KPiA+ICA+IEl0 J3MgdG9vIGhlYXZ5IGZvciBzZXJ2ZXIuIEFuZCwgdGhlIHNlcnZlciBtdXN0IGJlIHN0YXRlZnVs IGlmIGl0DQo+ID4gPiBzdXBwb3J0IGdldC1ibG9jayBjYXBhYmlsaXR5Lg0KPiA+ICA+DQo+ID4g ID4NCj4gPiAgPiBJIGFncmVlIHdpdGggdGhlc2UgY29uY2VybnMuICBIb2xkaW5nIGEgc25hcHNo b3Qgb2Ygc3RhdGUgZGF0YSBmb3INCj4gPiA+IGludGVyYWN0aXZlIHJldHJpZXZhbCAgPiBieSB0 aGUgY2xpZW50IGlzIHZlcnkgZXhwZW5zaXZlLg0KPiA+ICA+DQo+ID4gID4gSSBkbyBub3QgYWdy ZWUgd2l0aCB0aGUgcHJlbWlzZSB0aGF0IHRoZSBjbGllbnQgbmVlZHMgdG8ga25vdyB0aGUNCj4g PiA+IGtleSB2YWx1ZXMgaW4gYWR2YW5jZS4NCj4gPiAgPiBBbiAiaXRlcmF0b3IiIGFwcHJvYWNo IGFsbG93cyBhIGxpc3QgcmVzb3VyY2UgdG8gYmUgcmV0cmlldmVkIGluICA+DQo+ID4gY2h1bmtz LiAgVGhpcyBpcyB3aGF0IFJFU1RDT05GICA+IGlzIGdvaW5nIHRvIGRvLCBhbmQgTkVUQ09ORiBj b3VsZA0KPiA+IGFkZCBhIHNpbWlsYXIgUlBDIGZ1bmN0aW9uOg0KPiA+ICA+DQo+ID4gID4gICAg cnBjIGdldC1saXN0IHsNCj4gPiAgPiAgICAgIGlucHV0IHsNCj4gPiAgPiAgICAgICAgbGVhZiB0 YXJnZXQgew0KPiA+ICA+ICAgICAgICAgICB0eXBlIHNjaGVtYS1pbnN0YW5jZS1pZGVudGlmaWVy Ow0KPiA+ICA+ICAgICAgICAgICBkZXNjcmlwdGlvbiAiSWRlbnRpZmllcyBzdWJ0cmVlIHRvIHJl dHJpZXZlLiI7DQo+ID4gID4gICAgICAgfQ0KPiA+ICA+ICAgICAgIGxlYWYgc3RhcnQgew0KPiA+ ICA+ICAgICAgICAgIHR5cGUgdWludDMyOw0KPiA+ICA+ICAgICAgICAgIGRlZmF1bHQgMDsNCj4g PiAgPiAgICAgICAgICBkZXNjcmlwdGlvbiAiTnVtYmVyIG9mIGVudHJpZXMgdG8gc2tpcCBiZWZv cmUgc3RhcnRpbmcNCj4gcmV0cmlldmFsIjsNCj4gPiAgPiAgICAgICB9DQo+ID4gID4gICAgICAg bGVhZiBtYXgtZW50cmllcyB7DQo+ID4gID4gICAgICAgICB0eXBlIHVpbnQzMiB7IHJhbmdlICIx Li5tYXgiOyB9DQo+ID4gID4gICAgICAgICBkZWZhdWx0IDI1Ow0KPiA+ICA+ICAgICAgICAgZGVz Y3JpcHRpb24gIk1heGltdW0gbnVtYmVyIG9mIGxpc3QgZW50cmllcyB0byByZXRyaWV2ZSI7DQo+ ID4gID4gICAgICAgfQ0KPiA+ICA+ICAgICB9DQo+ID4gID4gICAgIG91dHB1dCB7DQo+ID4gID4g ICAgICAgIGFueXhtbCBkYXRhIHsNCj4gPiAgPiAgICAgICAgICAgZGVzY3JpcHRpb24gIkNvbnRh aW5zIHRoZSByZXF1ZXN0ZWQgZGF0YSI7DQo+ID4gID4gICAgICAgIH0NCj4gPiAgPiAgICAgfQ0K PiA+ICA+ICAgfQ0KPiA+ICA+DQo+ID4gID4gICA8cnBjPg0KPiA+ICA+ICAgICA8Z2V0LWxpc3Q+ DQo+ID4gID4gICAgICAgPHRhcmdldD4vaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U8L3Rhcmdl dD4NCj4gPiAgPiAgICAgPC9nZXQtbGlzdD4NCj4gPiAgPiAgIDwvcnBjPg0KPiA+ICA+DQo+ID4g ID4gICA8cnBjLXJlcGx5Pg0KPiA+ICA+ICAgICAgPGRhdGE+DQo+ID4gID4gICAgICAgICA8aW50 ZXJmYWNlcz4NCj4gPiAgPiAgICAgICAgICAgIDxpbnRlcmZhY2U+ICAgLi4uLiBmaXJzdCBlbnRy eSA8L2ludGVyZmFjZT4NCj4gPiAgPiAgICAgICAgICAgIC4uLg0KPiA+ICA+ICAgICAgICAgICAg PGludGVyZmFjZT4gICAuLi4uIDI1dGggZW50cnkgPC9pbnRlcmZhY2U+DQo+ID4gID4gICAgICAg ICA8L2ludGVyZmFjZXM+DQo+ID4gID4gICAgICA8L2RhdGE+DQo+ID4gID4gICA8L3JwYy1yZXBs eT4NCj4gPiAgPg0KPiA+ICA+ICAgIDxycGM+DQo+ID4gID4gICAgIDxnZXQtbGlzdD4NCj4gPiAg PiAgICAgICA8dGFyZ2V0Pi9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZTwvdGFyZ2V0Pg0KPiA+ ICA+ICAgICAgIDxzdGFydD4yNTwvc3RhcnQ+DQo+ID4gID4gICAgIDwvZ2V0LWxpc3Q+DQo+ID4g ID4gICA8L3JwYz4NCj4gPiAgPg0KPiA+ICA+ICAgPHJwYy1yZXBseT4NCj4gPiAgPiAgICAgIDxk YXRhPg0KPiA+ICA+ICAgICAgICAgPGludGVyZmFjZXM+DQo+ID4gID4gICAgICAgICAgICA8aW50 ZXJmYWNlPiAgIC4uLi4gMjZ0aCBlbnRyeSA8L2ludGVyZmFjZT4NCj4gPiAgPiAgICAgICAgICAg IC4uLg0KPiA+ICA+ICAgICAgICAgICAgPGludGVyZmFjZT4gICAuLi4uIDUwdGggZW50cnkgPC9p bnRlcmZhY2U+DQo+ID4gID4gICAgICAgICA8L2ludGVyZmFjZXM+DQo+ID4gID4gICAgICA8L2Rh dGE+DQo+ID4gID4gICA8L3JwYy1yZXBseT4NCj4gPiAgPg0KPiA+ICA+IFRoZXJlIGlzIGEgcHJv YmxlbSB3aXRoIHJhcGlkbHkgY2hhbmdpbmcgbGlzdHMgID4gKGNvdWxkIGdldCByZXBlYXQNCj4g PiBlbnRyaWVzIG9uIG1pc3Mgc29tZSBlbnRyaWVzKSwgYnV0IHRoZSBzbmFwc2hvdCAgPiBhcHBy b2FjaCB1c2VzIHRvbw0KPiA+IG11Y2ggbWVtb3J5LCBhbmQgaWYgdGhlIGxpc3QgaW5zdGFuY2Vz ICA+IGNoYW5nZSByYXBpZGx5LCBhIHN0YWxlDQo+ID4gc25hcHNob3QgaXMgbm90IHZlcnkgdXNl ZnVsLg0KPiA+ICA+DQo+ID4gID4gQW5keQ0KPiA+ICA+DQo+ID4gID4gVGhlIG90aGVyIHF1ZXN0 aW9ucyBhbmQgY29tbWVudHMgYXJlIGxpc3RlZCBiZWxvdzoNCj4gPiAgPiAxLiBHZXQtYmxvY2sg Y2FwYWJpbGl0eSBzaG91bGQgbm90IGNoYW5nZSB0aGUgZ2V0LWNvbmZpZw0KPiA+IG9wZXJhdGlv bidzICA+IGJlaGF2aW9yLiBJZiBjbGllbnQgdXNlIGdldC1jb25maWcgb3BlcmF0aW9uIHRvDQo+ ID4gcmV0cmlldmUgZGF0YSwgID4gYWxsIGRhdGEgbXVzdCBiZSBzZW50IGluIG9uZSByZXNwb25z ZSBvciBnZXQtYmxvY2sNCj4gPiBjYXBhYmlsaXR5IHNob3VsZCAgPiBhZGQgYSBwYXJhbWV0ZXIg dG8gZ2V0LWNvbmZpZyBvcGVyYXRpb24gdG8NCj4gPiBpbmRpY2F0ZSB0aGUgID4gcmVzcG9uc2Ug ZGF0YSB3aWxsIGJlIGZyYWdtZW50ZWQuDQo+ID4gID4gMi4gQSBzZXQtaWQgY2FuIGJlIGFnZWQ/ IHdoZW4gY2xpZW50IG5ldmVyIHNlbmQgYSByZXF1ZXN0IHRvICA+DQo+ID4gcmV0cmlldmUgdGhl IG5leHQgZnJhZ21lbnQgZm9yIGEgbG9uZyB0aW1lLCBJIHRoaW5rIHRoaXMgc2V0LWlkICA+DQo+ ID4gc2hvdWxkIGJlIGFnZWQsICA+IG90aGVyd2lzZSwgc2VydmVyIHdpbGwgYmUgcmVzZXJ2ZSBt b3JlIGFuZCBtb3JlDQo+ID4gc2V0LWlkcy4NCj4gPiAgPiAzLiBBIHNldC1pZCBpcyB1bmlxdWUg aW4gc2Vzc2lvbiBsZXZlbCBvciBzZXJ2ZXIgbGV2ZWw/DQo+ID4gID4gNC4gSWYgYSBzZXNzaW9u IGlzIGtpbGxlZCBvciBjbG9zZWQsIG90aGVyIHNlc3Npb24gY2FuIHJldHJpZXZlZA0KPiA+IHRo ZSAgPiBuZXh0IGZyYWdtZW50IGlmIHRoZSBjbGllbnQgcHJvdmlkZSB0aGUgY29ycmVjdCBzZXQt aWQ/DQo+ID4gID4gL2ZyYW5rDQo+ID4gID4NCj4gPg0KPiA+ICA+IDIwMTQtMDYtMDQgMTg6MjIg R01UKzA4OjAwIExpdWJpbmcgKExlbykNCj4gPGxlby5saXViaW5nQGh1YXdlaS5jb20+Og0KPiA+ ICA+IEhpIGFsbCwNCj4gPiAgPg0KPiA+ICA+IFdlJ3ZlIHBvc3RlZCBhIG5ldyBkcmFmdCwgd2hp Y2ggaXMgYWJvdXQgTkVUQ09ORiBkYXRhDQo+IGZyYWdtZW50YXRpb24uDQo+ID4gID4NCj4gPiAg PiBUaGUgYmFzaWMgaWRlYSBpcywgd2hlbiBOTVMgaXMgcmV0cmlldmluZyBhIGxhcmdlIHNpemUg b2YgZGF0YSBpbg0KPiA+ID4gdGhlIGRldmljZSwgdGhlIDxycGMtcmVwbHk+IG1pZ2h0IGJlIHZl cnkgYmlnIChlLmcuIHRoZSByb3V0ZXMgaW4gYQ0KPiA+ID4gY29yZSByb3V0ZXIpLg0KPiA+ICA+ IEN1cnJlbnRseSB0aGVyZSBhcmUgbWFpbmx5IHR3byBtZXRob2RzIG9mIGhhbmRsaW5nIHRoZSBi aWcgPHJwYy0gID4NCj4gPiByZXBseT46IG9uZSBpcyBzdHJlYW0tb3JpZW50ZWQgaGFuZGxpbmc7 IHRoZSBvdGhlciBpcyBqdXN0IHJlcXVlc3QgYQ0KPiA+ID4gcG9ydGlvbiBvZiB0aGUgZGF0YS4N Cj4gPiAgPg0KPiA+ICA+IFRoaXMgZHJhZnQgY29uc2lkZXJzIGJvdGggdGhlIHR3byBtZXRob2Rz IGFyZSBwcm9ibGVtYXRpYyBpbiBzb21lDQo+ID4gPiBzaXR1YXRpb25zLCBhbmQgcHJvcG9zZXMg YSBuZXcgbWV0aG9kIHdoaWNoIGFsbG93cyB0aGUgbGFyZ2Ugc2l6ZSAgPg0KPiA+IDxycGMtcmVw bHk+IHRvIGJlIGZyYWdtZW50ZWQgaW4gTkVUQ09ORiBsZXZlbC4NCj4gPiAgPg0KPiA+ICA+IFBs ZWFzZSByZWFkIHRoZSBkcmFmdCBhbmQgY29tbWVudC4NCj4gPiAgPiBNYW55IHRoYW5rcyENCj4g PiAgPg0KPiA+ICA+IEJlc3QgcmVnYXJkcywNCj4gPiAgPiBCaW5nDQo+ID4gID4NCj4gPiAgPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ICA+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gID4NCj4gPiBTZW50OiBX ZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQgNToyNyBQTSAgPiBUbzogTGl1YmluZyAoTGVvKTsgTGl1 YmluZw0KPiA+IChMZW8pOyBaaGVuZ2d1YW5neWluZzsgWmhlbmdndWFuZ3lpbmcgID4gU3ViamVj dDogTmV3IFZlcnNpb24NCj4gPiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1uZXRjb25mLWZy YWdtZW50YXRpb24tMDAudHh0DQo+ID4gID4NCj4gPiAgPg0KPiA+ICA+IEEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA0KPiA+ICA+IGhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmluZyBMaXUgYW5kIHBvc3RlZCB0byB0 aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiA+ICA+DQo+ID4gID4gTmFtZTogICAgICAgICAgIGRy YWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24NCj4gPiAgPiBSZXZpc2lvbjogICAgICAgMDAN Cj4gPiAgPiBUaXRsZTogICAgICAgICAgQSBORVRDT05GIEV4dGVuc2lvbiBmb3IgRGF0YSBGcmFn bWVudGF0aW9uDQo+ID4gID4gRG9jdW1lbnQgZGF0ZTogIDIwMTQtMDYtMDQNCj4gPiAgPiBHcm91 cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gID4gUGFnZXM6ICAgICAgICAg IDEyDQo+ID4gID4gVVJMOiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1saXUtDQo+ID4gID4gbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA0KPiA+ICA+IFN0YXR1 czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LW5ldGNvbmYtDQo+ ID4gID4gZnJhZ21lbnRhdGlvbi8NCj4gPiAgPiBIdG1saXplZDoNCj4gPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwDQo+ID4gID4N Cj4gPiAgPg0KPiA+ICA+IEFic3RyYWN0Og0KPiA+ICA+ICAgIFRoaXMgZG9jdW1lbnQgaW50cm9k dWNlcyBhbiBleHRlbnNpb24gdG8gTkVUQ09ORiAoTmV0d29yaw0KPiA+ICA+ICAgIENvbmZpZ3Vy YXRpb24pIHByb3RvY29sLiBUaGUgZXh0ZW5zaW9uIGFsbG93cyBORVRDT05GIHRvIGhhbmRsZQ0K PiBsYXJnZQ0KPiA+ICA+ICAgIHNpemUgZGF0YSBhcyBmcmFnbWVudGVkIFJQQyBtZXNzYWdlcy4g U3BlY2lmaWNhbGx5LCB0aGlzIGRvY3VtZW50DQo+ID4gID4gICAgZGVmaW5lcyBhIG5ldyA8Z2V0 LWJsb2NrPiBjYXBhYmlsaXR5IGFuZCByZWxldmFudCBvcGVyYXRpb25zIHRvDQo+ID4gID4gICAg aGFuZGxlIHRoZSBmcmFnbWVudGF0aW9ucy4NCj4gPiAgPg0KPiA+ICA+DQo+ID4gID4NCj4gPiAg Pg0KPiA+ICA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPiB0b29scy5pZXRmLm9yZyAgPiAu DQo+ID4gID4NCj4gPiAgPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+ICA+DQo+ID4gID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiAgPiBOZXRj b25mIG1haWxpbmcgbGlzdA0KPiA+ICA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiAgPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPiAgPg0KPiA+ICA+DQo+ ID4gID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiAgPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ICA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiAg PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPg0KPiA+ ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiAgPiBOZXRjb25mQGlldGYub3JnDQo+ID4gID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4NCj4gPg0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCj4gKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRl ZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZA0KPiBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IGFuDQo+IGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVj dGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyDQo+IGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmDQo+IHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQg bm90aWZ5IHVzDQo+IGltbWVkaWF0ZWx5Lg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbA0KPiAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRo KSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kDQo+IGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4N Cj4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0 cmlidXRpb24gb3Igb3RoZXINCj4gZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYNCj4geW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMN Cj4gaW1tZWRpYXRlbHkuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0 DQo+ID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZg0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiBOZXRjb25mQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Thu Jun 5 03:17:18 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3681A03C8 for ; Thu, 5 Jun 2014 03:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnkQq7_gDlg3 for ; Thu, 5 Jun 2014 03:17:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFA31A0240 for ; Thu, 5 Jun 2014 03:17:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1B7C3117C; Thu, 5 Jun 2014 12:17:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ta5QiJqXiHBq; Thu, 5 Jun 2014 12:16:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Jun 2014 12:17:07 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06A1820017; Thu, 5 Jun 2014 12:17:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WopRUF4794l2; Thu, 5 Jun 2014 12:17:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96C4420013; Thu, 5 Jun 2014 12:17:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 440F12D5223A; Thu, 5 Jun 2014 12:17:04 +0200 (CEST) Date: Thu, 5 Jun 2014 12:17:03 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140605101703.GA11452@elstar.local> Mail-Followup-To: Martin Bjorklund , per@tail-f.com, netconf@ietf.org References: <539022EA.5030603@amartus.com> <53902ABE.5040603@tail-f.com> <20140605083916.GB10945@elstar.local> <20140605.110026.809546159633050650.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140605.110026.809546159633050650.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8scCeGAwzYo1U9gmD4KkXW3Pxpc Cc: netconf@ietf.org Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 10:17:17 -0000 On Thu, Jun 05, 2014 at 11:00:26AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Jun 05, 2014 at 10:30:54AM +0200, Per Hedeland wrote: > > > > > > I frequently see confusion about the semantics of leafref among our > > > "YANG newbie" customers, mostly that it is thought of as some kind of > > > "link" rather than a constraint. Maybe the name isn't ideal (I'm not > > > suggesting to change it though:-), and the text in RFC 6020, while it > > > does eventually tell everything, is perhaps not ideal either. E.g. it > > > starts out with > > > > > > The leafref type is used to reference a particular leaf instance in > > > the data tree. > > > > > > - which, if not actually incorrect in the general case (see above), is > > > at least IMHO leading the reader down the wrong thought path. Maybe > > > > > > The leafref type is used to declare a constraint on the value space of > > > a leaf, based on a reference to a set of leaf instances in the data > > > tree. > > > > > > would be better... > > > > I agree that the first sentence in 9.9, in particular the phrase > > "reference a particular leaf instance", is likely confusing. If others > > feel the same, perhaps the right thing is to open an erratum so we can > > track this and finally fix it in YANG 1.1. > > +1 for fix in 1.1, but do we really need to open an errata? > It is a way of documenting the issue right now in a place where people can easily find it right now and we won't loose it during the work on YANG 1.1. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jun 5 03:28:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112381A0436 for ; Thu, 5 Jun 2014 03:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1rs0lNU87eP for ; Thu, 5 Jun 2014 03:28:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF441A0434 for ; Thu, 5 Jun 2014 03:28:55 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id D025312801AA; Thu, 5 Jun 2014 12:27:49 +0200 (CEST) Date: Thu, 05 Jun 2014 12:28:48 +0200 (CEST) Message-Id: <20140605.122848.852650215545298577.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140605101703.GA11452@elstar.local> References: <20140605083916.GB10945@elstar.local> <20140605.110026.809546159633050650.mbj@tail-f.com> <20140605101703.GA11452@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yB4vXwMep7G2PKeh9hsNrJVx8AI Cc: netconf@ietf.org Subject: Re: [Netconf] handling YANG leafrefs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 10:28:57 -0000 Juergen Schoenwaelder wrote: > On Thu, Jun 05, 2014 at 11:00:26AM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Jun 05, 2014 at 10:30:54AM +0200, Per Hedeland wrote: > > > > > > > > I frequently see confusion about the semantics of leafref among our > > > > "YANG newbie" customers, mostly that it is thought of as some kind of > > > > "link" rather than a constraint. Maybe the name isn't ideal (I'm not > > > > suggesting to change it though:-), and the text in RFC 6020, while it > > > > does eventually tell everything, is perhaps not ideal either. E.g. it > > > > starts out with > > > > > > > > The leafref type is used to reference a particular leaf instance in > > > > the data tree. > > > > > > > > - which, if not actually incorrect in the general case (see above), is > > > > at least IMHO leading the reader down the wrong thought path. Maybe > > > > > > > > The leafref type is used to declare a constraint on the value space of > > > > a leaf, based on a reference to a set of leaf instances in the data > > > > tree. > > > > > > > > would be better... > > > > > > I agree that the first sentence in 9.9, in particular the phrase > > > "reference a particular leaf instance", is likely confusing. If others > > > feel the same, perhaps the right thing is to open an erratum so we can > > > track this and finally fix it in YANG 1.1. > > > > +1 for fix in 1.1, but do we really need to open an errata? > > > > It is a way of documenting the issue right now in a place where people > can easily find it right now Ok. >and we won't loose it during the work on > YANG 1.1. I won't loose it; I've already edited the source. /martin From nobody Thu Jun 5 03:41:56 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E591A043A for ; Thu, 5 Jun 2014 03:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.672 X-Spam-Level: **** X-Spam-Status: No, score=4.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCHdB1mU0O6Z for ; Thu, 5 Jun 2014 03:41:48 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE751A0439 for ; Thu, 5 Jun 2014 03:41:48 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so1200037qgd.41 for ; Thu, 05 Jun 2014 03:41:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=03IUwJTvlaUfnVuc1j+7LmxoBY1TXWNcFHfUZTJlp9s=; b=kJgCFZBhLgghRuqM4uWvhz7mvRpO9RQy+Vnei/H2XU4KkyYx1ZkCQbDPmUAU/geZ30 m/KV64GNcCmBgFwVdsiQrr0SHXeZIqF6GS8txhSG0CRDbvpQyYRFFDns/YxFSwi72xRJ 7DrIIf4Xe+bhts0/e8Xhm5JsrRQV/Yb9UWXyTrSEzqOwVxhw4IThKN7RerUrZjreTHTX Jss8A2yECB24dddQGA0niK8sY0UxcpaIDXGxKBLF/zy3ZcEptqQ6+UjGypExWZ/g5bKF 8CGqeqkXlmmwLzI2pwWGJM8rcyQsJBjXixnyH9LbbUq2XA79vRxpFX2sP3Fc+kJEesS+ CkLQ== X-Gm-Message-State: ALoCoQkF6RjB0Rzq4bq6V0RvpT02JpuaqGeA/omNMdvM0f4I72jtevKDT0N0dFd8rFapYGpUMeau MIME-Version: 1.0 X-Received: by 10.224.79.198 with SMTP id q6mr15449524qak.99.1401964901760; Thu, 05 Jun 2014 03:41:41 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Thu, 5 Jun 2014 03:41:41 -0700 (PDT) In-Reply-To: <53902CAD.6010906@bwijnen.net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <53902CAD.6010906@bwijnen.net> Date: Thu, 5 Jun 2014 03:41:41 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=047d7bdca5daf513da04fb146358 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3gbGj7r7HUw_C1yPeOvuPy_ORKg Cc: Zhengguangying , Yangang , Netconf , Netconf Subject: Re: [Netconf] =?gb2312?b?tPC4tDogUmU6IE5ldGNvbmYgZnJhZ21lbnRhdGlvbi0v?= =?gb2312?b?L0ZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1u?= =?gb2312?b?ZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 10:41:51 -0000 --047d7bdca5daf513da04fb146358 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Thu, Jun 5, 2014 at 1:39 AM, Bert Wijnen (IETF) wrote: > I am a bit concerned that we are now discussing a possible solution. > > BUT.... I think we should first discuss on this list: > > - Is the problem statement describing a real problem that we all agree > with? > > which problem? more than 1 has been described: 1) the client can get a reply that is "too big" so it wants to ask for well-formed XML documents that fragment the reply 2) data skew can happen across polls so the server needs to snapshot the request and store it for the client to retrieve in pieces > - If it is do we believe that our WG should work on a solution? > > no -- neither problem is important enough to solve right now. The client can use filtering to achieve (1) and (2) is not practical because of memory constraints in devices. Once we have agree on that, we can decide if we want to add this topic > to our WG charter and work on it. > Would we be asking the IESG to approve a new charter while so much of the current charter remains unfinished? > Bert (speaking as co-chair) > Andy > > On 05/06/14 02:59, feng.chong33@zte.com.cn wrote: > >> andy, >> How to process nested lists using your solution? >> >> For example: >> list foo { >> key a; >> leaf a {...} >> leaf b {...} >> list nested-foo { >> key nested-a; >> leaf nested-a {...} >> leaf netsted-b {...} >> } >> } >> >> If request is: >> >> >> /foo >> >> >> What is the response? >> >> And, another question: >> Start-index is not reliable, if some entries are deleted. I think you ca= n >> use start key instead. >> >> >> >> /frank >> >> "Netconf" =D0=B4=D3=DA 2014-06-05 00:43:12: >> >> > Andy Bierman >> > =B7=A2=BC=FE=C8=CB: "Netconf" >> > >> > 2014-06-05 00:43 >> > >> > =CA=D5=BC=FE=C8=CB >> > >> > chong feng , >> > >> > =B3=AD=CB=CD >> > >> > Zhengguangying , Netconf >> > , Yangang >> > >> > =D6=F7=CC=E2 >> > >> > Re: [Netconf] Netconf fragmentation-//FW: New Version Notification >> > for draft-liu-netconf-fragmentation-00.txt >> > >> > >> >> > On Wed, Jun 4, 2014 at 8:32 AM, chong feng >> wrote: >> > Hi, >> > I have reviewed this new draft. >> > I understand your solution is that NETCONF server reserve break >> > points and wait for client to retrieve the next response. >> > I think it's not a good solution, because server may need to reserve >> > many break points if there a large number of concurrent requests. >> > It's too heavy for server. And, the server must be stateful if it >> > support get-block capability. >> > >> > >> > I agree with these concerns. Holding a snapshot of state data for >> > interactive retrieval >> > by the client is very expensive. >> > >> > I do not agree with the premise that the client needs to know the >> > key values in advance. >> > An "iterator" approach allows a list resource to be retrieved in >> > chunks. This is what RESTCONF >> > is going to do, and NETCONF could add a similar RPC function: >> > >> > rpc get-list { >> > input { >> > leaf target { >> > type schema-instance-identifier; >> > description "Identifies subtree to retrieve."; >> > } >> > leaf start { >> > type uint32; >> > default 0; >> > description "Number of entries to skip before starting >> retrieval"; >> > } >> > leaf max-entries { >> > type uint32 { range "1..max"; } >> > default 25; >> > description "Maximum number of list entries to retrieve"; >> > } >> > } >> > output { >> > anyxml data { >> > description "Contains the requested data"; >> > } >> > } >> > } >> > >> > >> > >> > /if:interfaces/if:interface >> > >> > >> > >> > >> > >> > >> > .... first entry >> > ... >> > .... 25th entry >> > >> > >> > >> > >> > >> > >> > /if:interfaces/if:interface >> > 25 >> > >> > >> > >> > >> > >> > >> > .... 26th entry >> > ... >> > .... 50th entry >> > >> > >> > >> > >> > There is a problem with rapidly changing lists >> > (could get repeat entries on miss some entries), but the snapshot >> > approach uses too much memory, and if the list instances >> > change rapidly, a stale snapshot is not very useful. >> > >> > Andy >> > >> > The other questions and comments are listed below: >> > 1. Get-block capability should not change the get-config operation's >> > behavior. If client use get-config operation to retrieve data, >> > all data must be sent in one response or get-block capability should >> > add a parameter to get-config operation to indicate the >> > response data will be fragmented. >> > 2. A set-id can be aged? when client never send a request to >> > retrieve the next fragment for a long time, I think this set-id >> > should be aged, >> > otherwise, server will be reserve more and more set-ids. >> > 3. A set-id is unique in session level or server level? >> > 4. If a session is killed or closed, other session can retrieved the >> > next fragment if the client provide the correct set-id? >> > /frank >> > >> >> > 2014-06-04 18:22 GMT+08:00 Liubing (Leo) : >> > Hi all, >> > >> > We've posted a new draft, which is about NETCONF data fragmentation. >> > >> > The basic idea is, when NMS is retrieving a large size of data in >> > the device, the might be very big (e.g. the routes in a >> > core router). >> > Currently there are mainly two methods of handling the big > > reply>: one is stream-oriented handling; the other is just request a >> > portion of the data. >> > >> > This draft considers both the two methods are problematic in some >> > situations, and proposes a new method which allows the large size >> > to be fragmented in NETCONF level. >> > >> > Please read the draft and comment. >> > Many thanks! >> > >> > Best regards, >> > Bing >> > >> > -----Original Message----- >> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> > Sent: Wednesday, June 04, 2014 5:27 PM >> > To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying >> > Subject: New Version Notification for draft-liu-netconf- >> fragmentation-00.txt >> > >> > >> > A new version of I-D, draft-liu-netconf-fragmentation-00.txt >> > has been successfully submitted by Bing Liu and posted to the IETF >> repository. >> > >> > Name: draft-liu-netconf-fragmentation >> > Revision: 00 >> > Title: A NETCONF Extension for Data Fragmentation >> > Document date: 2014-06-04 >> > Group: Individual Submission >> > Pages: 12 >> > URL: http://www.ietf.org/internet-drafts/draft-liu- >> > netconf-fragmentation-00.txt >> > Status: https://datatracker.ietf.org/doc/draft-liu-netconf- >> > fragmentation/ >> > Htmlized: http://tools.ietf.org/html/draft-liu-netconf- >> fragmentation-00 >> > >> > >> > Abstract: >> > This document introduces an extension to NETCONF (Network >> > Configuration) protocol. The extension allows NETCONF to handle >> large >> > size data as fragmented RPC messages. Specifically, this document >> > defines a new capability and relevant operations to >> > handle the fragmentations. >> > >> > >> > >> > >> > Please note that it may take a couple of minutes from the time of >> > submission until the htmlized version and diff are available at >> tools.ietf.org >> > . >> > >> > The IETF Secretariat >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> > >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail >> (and any attachment transmitted herewith) is privileged and confidential >> and is intended for the exclusive use of the addressee(s). If you are n= ot >> an intended recipient, any disclosure, reproduction, distribution or oth= er >> dissemination or use of the information contained is strictly prohibited= . >> If you have received this mail in error, please delete it and notify us >> immediately. >> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail >> (and any attachment transmitted herewith) is privileged and confidential >> and is intended for the exclusive use of the addressee(s). If you are n= ot >> an intended recipient, any disclosure, reproduction, distribution or oth= er >> dissemination or use of the information contained is strictly prohibited= . >> If you have received this mail in error, please delete it and notify us >> immediately. >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> --047d7bdca5daf513da04fb146358 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 5, 2014 at 1:39 AM, Bert Wijnen (IETF) <bertietf@bw= ijnen.net> wrote:
I am a bit concerned that we are now discuss= ing a possible solution.

BUT.... I think we should first discuss on this list:

- Is the problem statement describing a real problem that we all agree with= ?



which problem? more tha= n 1 has been described:

  1) the client can g= et a reply that is "too big" so it wants to ask for well-formed
      XML documents that fragment the reply
<= br>
  2) data skew can happen across polls so the server nee= ds to snapshot
      the request and store it for = the client to retrieve in pieces

 
- If it is do we believe that our WG should work on a solution?


no -- neither problem is important eno= ugh to solve right now.
The client can use filtering to achieve (= 1) and (2) is not practical
because of memory constraints in devi= ces.


Once we have agree on that, we can decide if we want to add this topic
to our WG charter and work on it.

Would= we be asking the IESG to approve a new charter while so much
of = the current charter remains unfinished?


Bert (speaking as co-chair)

Andy
<= div> 

On 05/06/14 02:59, feng.chong33@zte.com.cn wrote:
andy,
    How to process nested lists using your solution?

For example:
    list foo {
        key a;
        leaf a {...}
        leaf b {...}
        list nested-foo {
key nested-a;
leaf nested-a {...}
leaf netsted-b {...}
        }
    }

   If request is:
<rpc>
      <get-list>
        <target>/foo</target>
      </get-list>
    </rpc>
   What is the response?

And, another question:
Start-index is not reliable, if some entries are deleted. I think you can u= se start key instead.



/frank

"Netconf" <netconf-bounces@ietf.org> =D0=B4=D3=DA 2014-06-05 00:43:= 12:

 > Andy Bierman <andy@yumaworks.com>
 > =B7=A2=BC=FE=C8=CB:  "Netconf" <netconf-bounces@ietf.org>
 >
 > 2014-06-05 00:43
 >
 > =CA=D5=BC=FE=C8=CB
 >
 > chong feng <fengchongllly@gmail.com>,
 >
 > =B3=AD=CB=CD
 >
 > Zhengguangying <zhengguangying@huawei.com>, Netconf
 > <netcon= f@ietf.org>, Yangang <yangang@huawei.com>
 >
 > =D6=F7=CC=E2
 >
 > Re: [Netconf] Netconf fragmentation-//FW: New Version Notificati= on
 > for draft-liu-netconf-fragmentation-00.txt
 >
 >

 > On Wed, Jun 4, 2014 at 8:32 AM, chong feng <fengchongllly@gmail.com>= wrote:
 > Hi,
 >    I have reviewed this new draft.
 >    I understand your solution is that NETCONF server r= eserve break
 > points and wait for client to retrieve the next response.
 > I think it's not a good solution, because server may need to= reserve
 > many break points if there a large number of concurrent requests= .
 > It's too heavy for server. And, the server must be stateful = if it
 > support get-block capability.
 >
 >
 > I agree with these concerns.  Holding a snapshot of state d= ata for
 > interactive retrieval
 > by the client is very expensive.
 >
 > I do not agree with the premise that the client needs to know th= e
 > key values in advance.
 > An "iterator" approach allows a list resource to be re= trieved in
 > chunks.  This is what RESTCONF
 > is going to do, and NETCONF could add a similar RPC function:  >
 >    rpc get-list {
 >      input {
 >        leaf target {
 >           type schema-instance-identifi= er;
 >           description "Identifies = subtree to retrieve.";
 >       }
 >       leaf start {
 >          type uint32;
 >          default 0;
 >          description "Number of en= tries to skip before starting retrieval";
 >       }
 >       leaf max-entries {
 >         type uint32 { range "1..max&quo= t;; }
 >         default 25;
 >         description "Maximum number of = list entries to retrieve";
 >       }
 >     }
 >     output {
 >        anyxml data {
 >           description "Contains th= e requested data";
 >        }
 >     }
 >   }
 >
 >   <rpc>
 >     <get-list>
 >       <target>/if:interfaces/if:inte= rface</target>
 >     </get-list>
 >   </rpc>
 >
 >   <rpc-reply>
 >      <data>
 >         <interfaces>
 >            <interface>  = ; .... first entry </interface>
 >            ...
 >            <interface>  = ; .... 25th entry </interface>
 >         </interfaces>
 >      </data>
 >   </rpc-reply>
 >
 >    <rpc>
 >     <get-list>
 >       <target>/if:interfaces/if:inte= rface</target>
 >       <start>25</start>
 >     </get-list>
 >   </rpc>
 >
 >   <rpc-reply>
 >      <data>
 >         <interfaces>
 >            <interface>  = ; .... 26th entry </interface>
 >            ...
 >            <interface>  = ; .... 50th entry </interface>
 >         </interfaces>
 >      </data>
 >   </rpc-reply>
 >
 > There is a problem with rapidly changing lists
 > (could get repeat entries on miss some entries), but the snapsho= t
 > approach uses too much memory, and if the list instances
 > change rapidly, a stale snapshot is not very useful.
 >
 > Andy
 >
 > The other questions and comments are listed below:
 > 1. Get-block capability should not change the get-config operati= on's
 > behavior. If client use get-config operation to retrieve data,  > all data must be sent in one response or get-block capability sh= ould
 > add a parameter to get-config operation to indicate the
 > response data will be fragmented.
 > 2. A set-id can be aged? when client never send a request to
 > retrieve the next fragment for a long time, I think this set-id<= br>  > should be aged,
 > otherwise, server will be reserve more and more set-ids.
 > 3. A set-id is unique in session level or server level?
 > 4. If a session is killed or closed, other session can retrieved= the
 > next fragment if the client provide the correct set-id?
 > /frank
 >

 > 2014-06-04 18:22 GMT+08:00 Liubing (Leo) <leo.liubing@huawei.com>:  > Hi all,
 >
 > We've posted a new draft, which is about NETCONF data fragme= ntation.
 >
 > The basic idea is, when NMS is retrieving a large size of data i= n
 > the device, the <rpc-reply> might be very big (e.g. the ro= utes in a
 > core router).
 > Currently there are mainly two methods of handling the big <r= pc-
 > reply>: one is stream-oriented handling; the other is just re= quest a
 > portion of the data.
 >
 > This draft considers both the two methods are problematic in som= e
 > situations, and proposes a new method which allows the large siz= e
 > <rpc-reply> to be fragmented in NETCONF level.
 >
 > Please read the draft and comment.
 > Many thanks!
 >
 > Best regards,
 > Bing
 >
 > -----Original Message-----
 > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
 > Sent: Wednesday, June 04, 2014 5:27 PM
 > To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying=
 > Subject: New Version Notification for draft-liu-netconf-f= ragmentation-00.txt
 >
 >
 > A new version of I-D, draft-liu-netconf-fragmentation-00.= txt
 > has been successfully submitted by Bing Liu and posted to the IE= TF repository.
 >
 > Name:           draft-liu-netconf-fragmentation
 > Revision:       00
 > Title:          A NETCONF Extension for= Data Fragmentation
 > Document date:  2014-06-04
 > Group:          Individual Submission  > Pages:          12
 > URL: http://www.ietf.org/internet-drafts/draft-liu-=
 > netconf-fragmentation-00.txt
 > Status: https://datatracker.ietf.org/doc/draft-liu= -netconf-
 > fragmentation/
 > Htmlized: http://tools.ietf.org/html/dra= ft-liu-netconf-fragmentation-00
 >
 >
 > Abstract:
 >    This document introduces an extension to NETCONF (N= etwork
 >    Configuration) protocol. The extension allows NETCO= NF to handle large
 >    size data as fragmented RPC messages. Specifically,= this document
 >    defines a new <get-block> capability and rele= vant operations to
 >    handle the fragmentations.
 >
 >
 >
 >
 > Please note that it may take a couple of minutes from the time o= f
 > submission until the htmlized version and diff are available at = tools.ietf.org
 > .
 >
 > The IETF Secretariat
 >
 > _______________________________________________
 > Netconf mailing list
 > Netconf@ie= tf.org
 > https://www.ietf.org/mailman/listinfo/netconf
 >
 >
 > _______________________________________________
 > Netconf mailing list
 > Netconf@ie= tf.org
 > https://www.ietf.org/mailman/listinfo/netconf

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


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s).  If you are not = an intended recipient, any disclosure, reproduction, distribution or other = dissemination or use of the information contained is strictly prohibited. &= nbsp;If you have received this mail in error, please delete it and notify u= s immediately.




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s).  If you are not = an intended recipient, any disclosure, reproduction, distribution or other = dissemination or use of the information contained is strictly prohibited. &= nbsp;If you have received this mail in error, please delete it and notify u= s immediately.




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


--047d7bdca5daf513da04fb146358-- From nobody Thu Jun 5 03:47:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184611A0218 for ; Thu, 5 Jun 2014 03:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcJRVlRODyP7 for ; Thu, 5 Jun 2014 03:47:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2321A021B for ; Thu, 5 Jun 2014 03:47:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX04353; Thu, 05 Jun 2014 10:46:54 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 11:45:58 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 11:46:47 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 5 Jun 2014 18:46:36 +0800 From: "Liubing (Leo)" To: "Bert Wijnen (IETF)" , "feng.chong33@zte.com.cn" , Andy Bierman Thread-Topic: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt Thread-Index: AQHPgKtsXt2eMyf30UumiXdOJ24bDQ== Date: Thu, 5 Jun 2014 10:46:35 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA41C@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <53902CAD.6010906@bwijnen.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nA0Yq3MYHVkPTpBRrHY1SIndbCc Cc: Zhengguangying , Netconf , Yangang Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 10:47:05 -0000 Rm9yIHlvdXIgY29udmVuaWVuY2UsIGxldCBtZSBwb3N0IHRoZSBwcm9ibGVtcyBzdGF0ZW1lbnQg aW4gdGhlIGRyYWZ0IGFzIHRoZSBmb2xsb3dpbmc6DQoNCm8gUHJvYmxlbXMgb2YgU3RyZWFtLU9y aWVudGVkIGhhbmRsaW5nDQpTdHJlYW0tT3JpZW50ZWQgbWV0aG9kIGxhY2tzIHRoZSBjYXBhYmls aXR5IG9mIGRpc2NvbnRpbnVpbmcgbGFyZ2Ugc2l6ZSBwcm9jZXNzaW5nIGluIHRoZSBzZXJ2ZXIu IEl0IHdvdWxkIGNhdXNlIHVubmVjZXNzYXJ5IHJlc291cmNlL3BlcmZvcm1hbmNlIGNvc3QgaW4g dGhlIGRldmljZXMgaWYgdGhlIE5NUyBoYXMgYWxyZWFkeSBnb3QgdGhlIGludGVuZGVkIHBvcnRp b24gb3IganVzdCBjYW5jZWxlZCBieSB0aGUgYWRtaW5pc3RyYXRvcnMuDQpBbm90aGVyIHByb2Js ZW0gaXMgdGhlIGltcGxlbWVudGF0aW9uLiBTQVggaXMgbm90IGFzIHdpZGVseSBzdXBwb3J0ZWQg YXMgRE9NIFtET00tUEFSU0lOR10uIEZvciBleGFtcGxlLCBpdCBpcyBub3Qgc3VwcG9ydGVkIGJ5 IHNvbWUgZXhpc3RpbmcgbGlicmFyaWVzIHN1Y2ggYXMgbGlieG1sIFtMSUJYTUxdLiANCm8gUHJv YmxlbXMgb2Ygc3Vic2V0cyByZXF1ZXN0DQpUaGlzIG1ldGhvZCBoYXMgYW4gaW1wbGljYXRpb24g dGhhdCB0aGUgY2xpZW50IG5lZWRzIHRvIGtub3cgdGhlIGxpc3QvaW5kZXggb2YgdGhlIGludGVu ZGVkIGxhcmdlIHNpemUgZGF0YSBpbiBhZHZhbmNlIGJlZm9yZSBpdCBzdGFydGluZyB0aGUgc2Vh cmNoIHJlcXVlc3QuIEl0IGNhbuKAmXQgZml0IHRoZSBzY2VuYXJpb3Mgb2YgcmVhbC10aW1lIG9u LWRlbWFuZCBkYXRhIHJldHJpZXZpbmcuIEFuZCB0aGVyZSBpcyBubyBzdGFuZGFyZCB0byBzcGVj aWZ5IHRoZSBsaXN0L2luZGV4IGZvcm1hdCBpbiBhIHVuaWZvcm0gd2F5LiBUaHVzIGl0IGlzIG9u bHkgc3VpdGFibGUgZm9yIHByaXZhdGUgaW1wbGVtZW50YXRpb24sIHRodXMgbXVsdGktdmVuZG9y IGludGVyYWN0aW9uIGlzIG5vdCBzdXBwb3J0ZWQuDQpNb3JlIGltcG9ydGFudCwgaXQgaXMganVz dCBhbiBpbmRpcmVjdCB3YXkgdG8gc29sdmUgdGhlIHByb2JsZW0uIEl0IGNvdWxkIG5vdCBmaXQg dGhlIHNjZW5hcmlvcyB3aGVyZSB0aGUgY2xpZW50IGp1c3QgbmVlZHMgdGhlIHdob2xlIGxhcmdl IHNpemUgZGF0YSBpbiB0aGUgc2VydmVyLg0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGl1YmluZyAoTGVvKQ0KPiBTZW50OiBU aHVyc2RheSwgSnVuZSAwNSwgMjAxNCA2OjA0IFBNDQo+IFRvOiAnQmVydCBXaWpuZW4gKElFVEYp JzsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY247IEFuZHkgQmllcm1hbg0KPiBDYzogWmhlbmdndWFu Z3lpbmc7IE5ldGNvbmY7IE5ldGNvbmY7IFlhbmdhbmcNCj4gU3ViamVjdDogUkU6IFtOZXRjb25m XSBOZXRjb25mIGZyYWdtZW50YXRpb24tLy9GVzogTmV3IFZlcnNpb24NCj4gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA0KPiANCj4gSGkgQmVy dCwNCj4gDQo+IE1hbnkgdGhhbmtzIGZvciB5b3VyIGNvbnNpZGVyYXRpb24uDQo+IEkgZnVsbHkg YWdyZWUgd2Ugc2hvdWxkIGZvY3VzaW5nIG9uIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBjb25zaWRl cmluZyBpdCBpcyBhDQo+IC0wMCB2ZXJzaW9uIGRyYWZ0Lg0KPiANCj4gRm9yIHRoZSBzb2x1dGlv bnMsIHdlJ3JlIG9wZW4gdG8gZGlzY3VzcyB0aGUgYWx0ZXJuYXRpdmVzLg0KPiANCj4gQmVzdCBy ZWdhcmRzLA0KPiBCaW5nDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEJlcnQNCj4gPiBXaWpuZW4NCj4gPiAoSUVURikNCj4gPiBTZW50OiBUaHVyc2RheSwgSnVu ZSAwNSwgMjAxNCA0OjM5IFBNDQo+ID4gVG86IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuOyBBbmR5 IEJpZXJtYW4NCj4gPiBDYzogWmhlbmdndWFuZ3lpbmc7IE5ldGNvbmY7IE5ldGNvbmY7IFlhbmdh bmcNCj4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIOetlOWkjTogUmU6IE5ldGNvbmYgZnJhZ21l bnRhdGlvbi0vL0ZXOiBOZXcNCj4gVmVyc2lvbg0KPiA+IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt bGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQNCj4gPg0KPiA+IEkgYW0gYSBiaXQgY29u Y2VybmVkIHRoYXQgd2UgYXJlIG5vdyBkaXNjdXNzaW5nIGEgcG9zc2libGUgc29sdXRpb24uDQo+ ID4NCj4gPiBCVVQuLi4uIEkgdGhpbmsgd2Ugc2hvdWxkIGZpcnN0IGRpc2N1c3Mgb24gdGhpcyBs aXN0Og0KPiA+DQo+ID4gLSBJcyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZGVzY3JpYmluZyBhIHJl YWwgcHJvYmxlbSB0aGF0IHdlIGFsbCBhZ3JlZQ0KPiB3aXRoPw0KPiA+DQo+ID4gLSBJZiBpdCBp cywgZG8gd2UgYmVsaWV2ZSB0aGF0IG91ciBXRyBzaG91bGQgd29yayBvbiBhIHNvbHV0aW9uPw0K PiA+DQo+ID4gT25jZSB3ZSBoYXZlIGFncmVlIG9uIHRoYXQsIHdlIGNhbiBkZWNpZGUgaWYgd2Ug d2FudCB0byBhZGQgdGhpcyB0b3BpYw0KPiA+IHRvIG91ciBXRyBjaGFydGVyIGFuZCB3b3JrIG9u IGl0Lg0KPiA+DQo+ID4gQmVydCAoc3BlYWtpbmcgYXMgY28tY2hhaXIpDQo+ID4NCj4gPiBPbiAw NS8wNi8xNCAwMjo1OSwgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4gPiBhbmR5 LA0KPiA+ID4gICAgIEhvdyB0byBwcm9jZXNzIG5lc3RlZCBsaXN0cyB1c2luZyB5b3VyIHNvbHV0 aW9uPw0KPiA+ID4NCj4gPiA+IEZvciBleGFtcGxlOg0KPiA+ID4gICAgIGxpc3QgZm9vIHsNCj4g PiA+ICAgICAgICAga2V5IGE7DQo+ID4gPiAgICAgICAgIGxlYWYgYSB7Li4ufQ0KPiA+ID4gICAg ICAgICBsZWFmIGIgey4uLn0NCj4gPiA+ICAgICAgICAgbGlzdCBuZXN0ZWQtZm9vIHsNCj4gPiA+ IGtleSBuZXN0ZWQtYTsNCj4gPiA+IGxlYWYgbmVzdGVkLWEgey4uLn0NCj4gPiA+IGxlYWYgbmV0 c3RlZC1iIHsuLi59DQo+ID4gPiAgICAgICAgIH0NCj4gPiA+ICAgICB9DQo+ID4gPg0KPiA+ID4g ICAgSWYgcmVxdWVzdCBpczoNCj4gPiA+IDxycGM+DQo+ID4gPiAgICAgICA8Z2V0LWxpc3Q+DQo+ ID4gPiAgICAgICAgIDx0YXJnZXQ+L2ZvbzwvdGFyZ2V0Pg0KPiA+ID4gICAgICAgPC9nZXQtbGlz dD4NCj4gPiA+ICAgICA8L3JwYz4NCj4gPiA+ICAgIFdoYXQgaXMgdGhlIHJlc3BvbnNlPw0KPiA+ ID4NCj4gPiA+IEFuZCwgYW5vdGhlciBxdWVzdGlvbjoNCj4gPiA+IFN0YXJ0LWluZGV4IGlzIG5v dCByZWxpYWJsZSwgaWYgc29tZSBlbnRyaWVzIGFyZSBkZWxldGVkLiBJIHRoaW5rDQo+ID4gPiB5 b3UgY2FuIHVzZQ0KPiA+IHN0YXJ0IGtleSBpbnN0ZWFkLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0K PiA+ID4gL2ZyYW5rDQo+ID4gPg0KPiA+ID4gIk5ldGNvbmYiIDxuZXRjb25mLWJvdW5jZXNAaWV0 Zi5vcmc+IOWGmeS6jiAyMDE0LTA2LTA1IDAwOjQzOjEyOg0KPiA+ID4NCj4gPiA+ICA+IEFuZHkg Qmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiAgPiDlj5Hku7bkuro6ICAiTmV0Y29uZiINCj4g PiA+IDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+ICA+ICA+IDIwMTQtMDYtMDUNCj4gPiAwMDo0 Mw0KPiA+ID4gPiAgPiDmlLbku7bkuroNCj4gPiA+ICA+DQo+ID4gPiAgPiBjaG9uZyBmZW5nIDxm ZW5nY2hvbmdsbGx5QGdtYWlsLmNvbT4sICA+ICA+IOaKhOmAgQ0KPiA+ID4gID4NCj4gPiA+ICA+ IFpoZW5nZ3Vhbmd5aW5nIDx6aGVuZ2d1YW5neWluZ0BodWF3ZWkuY29tPiwgTmV0Y29uZiAgPg0K PiA+ID4gPG5ldGNvbmZAaWV0Zi5vcmc+LCBZYW5nYW5nIDx5YW5nYW5nQGh1YXdlaS5jb20+ICA+ ICA+IOS4u+mimA0KPiA+ID4gID4NCj4gPiA+ICA+IFJlOiBbTmV0Y29uZl0gTmV0Y29uZiBmcmFn bWVudGF0aW9uLS8vRlc6IE5ldyBWZXJzaW9uDQo+ID4gPiBOb3RpZmljYXRpb24NCj4gPiA+ID4g Zm9yIGRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0DQo+ID4gPiAgPg0KPiA+ ID4gID4NCj4gPiA+DQo+ID4gPiAgPiBPbiBXZWQsIEp1biA0LCAyMDE0IGF0IDg6MzIgQU0sIGNo b25nIGZlbmcNCj4gPiA8ZmVuZ2Nob25nbGxseUBnbWFpbC5jb20+IHdyb3RlOg0KPiA+ID4gID4g SGksDQo+ID4gPiAgPiAgICBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBuZXcgZHJhZnQuDQo+ID4gPiAg PiAgICBJIHVuZGVyc3RhbmQgeW91ciBzb2x1dGlvbiBpcyB0aGF0IE5FVENPTkYgc2VydmVyIHJl c2VydmUgYnJlYWsNCj4gPiA+ICA+IHBvaW50cyBhbmQgd2FpdCBmb3IgY2xpZW50IHRvIHJldHJp ZXZlIHRoZSBuZXh0IHJlc3BvbnNlLg0KPiA+ID4gID4gSSB0aGluayBpdCdzIG5vdCBhIGdvb2Qg c29sdXRpb24sIGJlY2F1c2Ugc2VydmVyIG1heSBuZWVkIHRvDQo+ID4gPiByZXNlcnZlICA+IG1h bnkgYnJlYWsgcG9pbnRzIGlmIHRoZXJlIGEgbGFyZ2UgbnVtYmVyIG9mIGNvbmN1cnJlbnQNCj4g PiByZXF1ZXN0cy4NCj4gPiA+ICA+IEl0J3MgdG9vIGhlYXZ5IGZvciBzZXJ2ZXIuIEFuZCwgdGhl IHNlcnZlciBtdXN0IGJlIHN0YXRlZnVsIGlmIGl0DQo+ID4gPiA+IHN1cHBvcnQgZ2V0LWJsb2Nr IGNhcGFiaWxpdHkuDQo+ID4gPiAgPg0KPiA+ID4gID4NCj4gPiA+ICA+IEkgYWdyZWUgd2l0aCB0 aGVzZSBjb25jZXJucy4gIEhvbGRpbmcgYSBzbmFwc2hvdCBvZiBzdGF0ZSBkYXRhDQo+ID4gPiBm b3INCj4gPiA+ID4gaW50ZXJhY3RpdmUgcmV0cmlldmFsICA+IGJ5IHRoZSBjbGllbnQgaXMgdmVy eSBleHBlbnNpdmUuDQo+ID4gPiAgPg0KPiA+ID4gID4gSSBkbyBub3QgYWdyZWUgd2l0aCB0aGUg cHJlbWlzZSB0aGF0IHRoZSBjbGllbnQgbmVlZHMgdG8ga25vdyB0aGUNCj4gPiA+ID4ga2V5IHZh bHVlcyBpbiBhZHZhbmNlLg0KPiA+ID4gID4gQW4gIml0ZXJhdG9yIiBhcHByb2FjaCBhbGxvd3Mg YSBsaXN0IHJlc291cmNlIHRvIGJlIHJldHJpZXZlZCBpbg0KPiA+ID4gPiBjaHVua3MuICBUaGlz IGlzIHdoYXQgUkVTVENPTkYgID4gaXMgZ29pbmcgdG8gZG8sIGFuZCBORVRDT05GDQo+ID4gPiBj b3VsZCBhZGQgYSBzaW1pbGFyIFJQQyBmdW5jdGlvbjoNCj4gPiA+ICA+DQo+ID4gPiAgPiAgICBy cGMgZ2V0LWxpc3Qgew0KPiA+ID4gID4gICAgICBpbnB1dCB7DQo+ID4gPiAgPiAgICAgICAgbGVh ZiB0YXJnZXQgew0KPiA+ID4gID4gICAgICAgICAgIHR5cGUgc2NoZW1hLWluc3RhbmNlLWlkZW50 aWZpZXI7DQo+ID4gPiAgPiAgICAgICAgICAgZGVzY3JpcHRpb24gIklkZW50aWZpZXMgc3VidHJl ZSB0byByZXRyaWV2ZS4iOw0KPiA+ID4gID4gICAgICAgfQ0KPiA+ID4gID4gICAgICAgbGVhZiBz dGFydCB7DQo+ID4gPiAgPiAgICAgICAgICB0eXBlIHVpbnQzMjsNCj4gPiA+ICA+ICAgICAgICAg IGRlZmF1bHQgMDsNCj4gPiA+ICA+ICAgICAgICAgIGRlc2NyaXB0aW9uICJOdW1iZXIgb2YgZW50 cmllcyB0byBza2lwIGJlZm9yZSBzdGFydGluZw0KPiA+IHJldHJpZXZhbCI7DQo+ID4gPiAgPiAg ICAgICB9DQo+ID4gPiAgPiAgICAgICBsZWFmIG1heC1lbnRyaWVzIHsNCj4gPiA+ICA+ICAgICAg ICAgdHlwZSB1aW50MzIgeyByYW5nZSAiMS4ubWF4IjsgfQ0KPiA+ID4gID4gICAgICAgICBkZWZh dWx0IDI1Ow0KPiA+ID4gID4gICAgICAgICBkZXNjcmlwdGlvbiAiTWF4aW11bSBudW1iZXIgb2Yg bGlzdCBlbnRyaWVzIHRvIHJldHJpZXZlIjsNCj4gPiA+ICA+ICAgICAgIH0NCj4gPiA+ICA+ICAg ICB9DQo+ID4gPiAgPiAgICAgb3V0cHV0IHsNCj4gPiA+ICA+ICAgICAgICBhbnl4bWwgZGF0YSB7 DQo+ID4gPiAgPiAgICAgICAgICAgZGVzY3JpcHRpb24gIkNvbnRhaW5zIHRoZSByZXF1ZXN0ZWQg ZGF0YSI7DQo+ID4gPiAgPiAgICAgICAgfQ0KPiA+ID4gID4gICAgIH0NCj4gPiA+ICA+ICAgfQ0K PiA+ID4gID4NCj4gPiA+ICA+ICAgPHJwYz4NCj4gPiA+ICA+ICAgICA8Z2V0LWxpc3Q+DQo+ID4g PiAgPiAgICAgICA8dGFyZ2V0Pi9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZTwvdGFyZ2V0Pg0K PiA+ID4gID4gICAgIDwvZ2V0LWxpc3Q+DQo+ID4gPiAgPiAgIDwvcnBjPg0KPiA+ID4gID4NCj4g PiA+ICA+ICAgPHJwYy1yZXBseT4NCj4gPiA+ICA+ICAgICAgPGRhdGE+DQo+ID4gPiAgPiAgICAg ICAgIDxpbnRlcmZhY2VzPg0KPiA+ID4gID4gICAgICAgICAgICA8aW50ZXJmYWNlPiAgIC4uLi4g Zmlyc3QgZW50cnkgPC9pbnRlcmZhY2U+DQo+ID4gPiAgPiAgICAgICAgICAgIC4uLg0KPiA+ID4g ID4gICAgICAgICAgICA8aW50ZXJmYWNlPiAgIC4uLi4gMjV0aCBlbnRyeSA8L2ludGVyZmFjZT4N Cj4gPiA+ICA+ICAgICAgICAgPC9pbnRlcmZhY2VzPg0KPiA+ID4gID4gICAgICA8L2RhdGE+DQo+ ID4gPiAgPiAgIDwvcnBjLXJlcGx5Pg0KPiA+ID4gID4NCj4gPiA+ICA+ICAgIDxycGM+DQo+ID4g PiAgPiAgICAgPGdldC1saXN0Pg0KPiA+ID4gID4gICAgICAgPHRhcmdldD4vaWY6aW50ZXJmYWNl cy9pZjppbnRlcmZhY2U8L3RhcmdldD4NCj4gPiA+ICA+ICAgICAgIDxzdGFydD4yNTwvc3RhcnQ+ DQo+ID4gPiAgPiAgICAgPC9nZXQtbGlzdD4NCj4gPiA+ICA+ICAgPC9ycGM+DQo+ID4gPiAgPg0K PiA+ID4gID4gICA8cnBjLXJlcGx5Pg0KPiA+ID4gID4gICAgICA8ZGF0YT4NCj4gPiA+ICA+ICAg ICAgICAgPGludGVyZmFjZXM+DQo+ID4gPiAgPiAgICAgICAgICAgIDxpbnRlcmZhY2U+ICAgLi4u LiAyNnRoIGVudHJ5IDwvaW50ZXJmYWNlPg0KPiA+ID4gID4gICAgICAgICAgICAuLi4NCj4gPiA+ ICA+ICAgICAgICAgICAgPGludGVyZmFjZT4gICAuLi4uIDUwdGggZW50cnkgPC9pbnRlcmZhY2U+ DQo+ID4gPiAgPiAgICAgICAgIDwvaW50ZXJmYWNlcz4NCj4gPiA+ICA+ICAgICAgPC9kYXRhPg0K PiA+ID4gID4gICA8L3JwYy1yZXBseT4NCj4gPiA+ICA+DQo+ID4gPiAgPiBUaGVyZSBpcyBhIHBy b2JsZW0gd2l0aCByYXBpZGx5IGNoYW5naW5nIGxpc3RzICA+IChjb3VsZCBnZXQNCj4gPiA+IHJl cGVhdCBlbnRyaWVzIG9uIG1pc3Mgc29tZSBlbnRyaWVzKSwgYnV0IHRoZSBzbmFwc2hvdCAgPiBh cHByb2FjaA0KPiA+ID4gdXNlcyB0b28gbXVjaCBtZW1vcnksIGFuZCBpZiB0aGUgbGlzdCBpbnN0 YW5jZXMgID4gY2hhbmdlIHJhcGlkbHksIGENCj4gPiA+IHN0YWxlIHNuYXBzaG90IGlzIG5vdCB2 ZXJ5IHVzZWZ1bC4NCj4gPiA+ICA+DQo+ID4gPiAgPiBBbmR5DQo+ID4gPiAgPg0KPiA+ID4gID4g VGhlIG90aGVyIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIGxpc3RlZCBiZWxvdzoNCj4gPiA+ ICA+IDEuIEdldC1ibG9jayBjYXBhYmlsaXR5IHNob3VsZCBub3QgY2hhbmdlIHRoZSBnZXQtY29u ZmlnDQo+ID4gPiBvcGVyYXRpb24ncyAgPiBiZWhhdmlvci4gSWYgY2xpZW50IHVzZSBnZXQtY29u ZmlnIG9wZXJhdGlvbiB0bw0KPiA+ID4gcmV0cmlldmUgZGF0YSwgID4gYWxsIGRhdGEgbXVzdCBi ZSBzZW50IGluIG9uZSByZXNwb25zZSBvciBnZXQtYmxvY2sNCj4gPiA+IGNhcGFiaWxpdHkgc2hv dWxkICA+IGFkZCBhIHBhcmFtZXRlciB0byBnZXQtY29uZmlnIG9wZXJhdGlvbiB0bw0KPiA+ID4g aW5kaWNhdGUgdGhlICA+IHJlc3BvbnNlIGRhdGEgd2lsbCBiZSBmcmFnbWVudGVkLg0KPiA+ID4g ID4gMi4gQSBzZXQtaWQgY2FuIGJlIGFnZWQ/IHdoZW4gY2xpZW50IG5ldmVyIHNlbmQgYSByZXF1 ZXN0IHRvICA+DQo+ID4gPiByZXRyaWV2ZSB0aGUgbmV4dCBmcmFnbWVudCBmb3IgYSBsb25nIHRp bWUsIEkgdGhpbmsgdGhpcyBzZXQtaWQgID4NCj4gPiA+IHNob3VsZCBiZSBhZ2VkLCAgPiBvdGhl cndpc2UsIHNlcnZlciB3aWxsIGJlIHJlc2VydmUgbW9yZSBhbmQgbW9yZQ0KPiA+ID4gc2V0LWlk cy4NCj4gPiA+ICA+IDMuIEEgc2V0LWlkIGlzIHVuaXF1ZSBpbiBzZXNzaW9uIGxldmVsIG9yIHNl cnZlciBsZXZlbD8NCj4gPiA+ICA+IDQuIElmIGEgc2Vzc2lvbiBpcyBraWxsZWQgb3IgY2xvc2Vk LCBvdGhlciBzZXNzaW9uIGNhbiByZXRyaWV2ZWQNCj4gPiA+IHRoZSAgPiBuZXh0IGZyYWdtZW50 IGlmIHRoZSBjbGllbnQgcHJvdmlkZSB0aGUgY29ycmVjdCBzZXQtaWQ/DQo+ID4gPiAgPiAvZnJh bmsNCj4gPiA+ICA+DQo+ID4gPg0KPiA+ID4gID4gMjAxNC0wNi0wNCAxODoyMiBHTVQrMDg6MDAg TGl1YmluZyAoTGVvKQ0KPiA+IDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjoNCj4gPiA+ICA+IEhp IGFsbCwNCj4gPiA+ICA+DQo+ID4gPiAgPiBXZSd2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQsIHdoaWNo IGlzIGFib3V0IE5FVENPTkYgZGF0YQ0KPiA+IGZyYWdtZW50YXRpb24uDQo+ID4gPiAgPg0KPiA+ ID4gID4gVGhlIGJhc2ljIGlkZWEgaXMsIHdoZW4gTk1TIGlzIHJldHJpZXZpbmcgYSBsYXJnZSBz aXplIG9mIGRhdGEgaW4NCj4gPiA+ID4gdGhlIGRldmljZSwgdGhlIDxycGMtcmVwbHk+IG1pZ2h0 IGJlIHZlcnkgYmlnIChlLmcuIHRoZSByb3V0ZXMgaW4NCj4gPiA+ID4gYSBjb3JlIHJvdXRlciku DQo+ID4gPiAgPiBDdXJyZW50bHkgdGhlcmUgYXJlIG1haW5seSB0d28gbWV0aG9kcyBvZiBoYW5k bGluZyB0aGUgYmlnIDxycGMtDQo+ID4gPiA+DQo+ID4gPiByZXBseT46IG9uZSBpcyBzdHJlYW0t b3JpZW50ZWQgaGFuZGxpbmc7IHRoZSBvdGhlciBpcyBqdXN0IHJlcXVlc3QgYQ0KPiA+ID4gPiBw b3J0aW9uIG9mIHRoZSBkYXRhLg0KPiA+ID4gID4NCj4gPiA+ICA+IFRoaXMgZHJhZnQgY29uc2lk ZXJzIGJvdGggdGhlIHR3byBtZXRob2RzIGFyZSBwcm9ibGVtYXRpYyBpbiBzb21lDQo+ID4gPiA+ IHNpdHVhdGlvbnMsIGFuZCBwcm9wb3NlcyBhIG5ldyBtZXRob2Qgd2hpY2ggYWxsb3dzIHRoZSBs YXJnZSBzaXplDQo+ID4gPiA+ID4NCj4gPiA+IDxycGMtcmVwbHk+IHRvIGJlIGZyYWdtZW50ZWQg aW4gTkVUQ09ORiBsZXZlbC4NCj4gPiA+ICA+DQo+ID4gPiAgPiBQbGVhc2UgcmVhZCB0aGUgZHJh ZnQgYW5kIGNvbW1lbnQuDQo+ID4gPiAgPiBNYW55IHRoYW5rcyENCj4gPiA+ICA+DQo+ID4gPiAg PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiAgPiBCaW5nDQo+ID4gPiAgPg0KPiA+ID4gID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ICA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPiA+ID4NCj4gPiA+IFNl bnQ6IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCA1OjI3IFBNICA+IFRvOiBMaXViaW5nIChMZW8p OyBMaXViaW5nDQo+ID4gPiAoTGVvKTsgWmhlbmdndWFuZ3lpbmc7IFpoZW5nZ3Vhbmd5aW5nICA+ IFN1YmplY3Q6IE5ldyBWZXJzaW9uDQo+ID4gPiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1u ZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0DQo+ID4gPiAgPg0KPiA+ID4gID4NCj4gPiA+ICA+ IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAw LnR4dA0KPiA+ID4gID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5nIExp dSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+ID4gSUVURg0KPiA+IHJlcG9zaXRvcnkuDQo+ID4gPiAg Pg0KPiA+ID4gID4gTmFtZTogICAgICAgICAgIGRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRp b24NCj4gPiA+ICA+IFJldmlzaW9uOiAgICAgICAwMA0KPiA+ID4gID4gVGl0bGU6ICAgICAgICAg IEEgTkVUQ09ORiBFeHRlbnNpb24gZm9yIERhdGEgRnJhZ21lbnRhdGlvbg0KPiA+ID4gID4gRG9j dW1lbnQgZGF0ZTogIDIwMTQtMDYtMDQNCj4gPiA+ICA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCj4gPiA+ICA+IFBhZ2VzOiAgICAgICAgICAxMg0KPiA+ID4gID4gVVJM OiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtDQo+ID4gPiAg PiBuZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0DQo+ID4gPiAgPiBTdGF0dXM6IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1uZXRjb25mLQ0KPiA+ID4gID4gZnJh Z21lbnRhdGlvbi8NCj4gPiA+ICA+IEh0bWxpemVkOg0KPiA+ID4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMA0KPiA+ID4gID4NCj4g PiA+ICA+DQo+ID4gPiAgPiBBYnN0cmFjdDoNCj4gPiA+ICA+ICAgIFRoaXMgZG9jdW1lbnQgaW50 cm9kdWNlcyBhbiBleHRlbnNpb24gdG8gTkVUQ09ORiAoTmV0d29yaw0KPiA+ID4gID4gICAgQ29u ZmlndXJhdGlvbikgcHJvdG9jb2wuIFRoZSBleHRlbnNpb24gYWxsb3dzIE5FVENPTkYgdG8NCj4g aGFuZGxlDQo+ID4gbGFyZ2UNCj4gPiA+ICA+ICAgIHNpemUgZGF0YSBhcyBmcmFnbWVudGVkIFJQ QyBtZXNzYWdlcy4gU3BlY2lmaWNhbGx5LCB0aGlzDQo+IGRvY3VtZW50DQo+ID4gPiAgPiAgICBk ZWZpbmVzIGEgbmV3IDxnZXQtYmxvY2s+IGNhcGFiaWxpdHkgYW5kIHJlbGV2YW50IG9wZXJhdGlv bnMgdG8NCj4gPiA+ICA+ICAgIGhhbmRsZSB0aGUgZnJhZ21lbnRhdGlvbnMuDQo+ID4gPiAgPg0K PiA+ID4gID4NCj4gPiA+ICA+DQo+ID4gPiAgPg0KPiA+ID4gID4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiA+ID4g c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0DQo+ID4gPiB0b29scy5pZXRmLm9yZyAgPiAuDQo+ID4gPiAgPg0KPiA+ID4gID4gVGhl IElFVEYgU2VjcmV0YXJpYXQNCj4gPiA+ICA+DQo+ID4gPiAgPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gID4gTmV0Y29uZiBtYWlsaW5nIGxp c3QNCj4gPiA+ICA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiA+ICA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+ID4gID4NCj4gPiA+ICA+DQo+ID4gPiAg PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4g ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ICA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiA+ ICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+ID4N Cj4gPiA+ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gPiAgPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ID4gID4gTmV0Y29uZkBpZXRmLm9y Zw0KPiA+ID4gID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCj4gPiA+IG1haWwNCj4gPiAo YW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFu ZA0KPiA+IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNl IG9mIHRoZQ0KPiA+IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJl Y2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsDQo+ID4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24g b3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlDQo+ID4gaW5mb3JtYXRpb24gY29u dGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZA0KPiA+ IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVk aWF0ZWx5Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiBaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMNCj4gPiA+IG1haWwNCj4gPiAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3 aXRoKSBpcyBwcml2aWxlZ2VkIGFuZA0KPiA+IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KPiA+IGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsDQo+ID4gcmVwcm9k dWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhl DQo+ID4gaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5 b3UgaGF2ZSByZWNlaXZlZA0KPiA+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBp dCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4N Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4gPg0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Thu Jun 5 04:43:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E4E1A004A for ; Thu, 5 Jun 2014 04:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtROpdN6nkeH for ; Thu, 5 Jun 2014 04:43:28 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96411A0049 for ; Thu, 5 Jun 2014 04:43:27 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so956187wes.29 for ; Thu, 05 Jun 2014 04:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Fx1p7gRM8J5XlRWawY1z/5CHnMA/fyY5LL4LnbkvCk=; b=SXJrMcWfu10tT/rJL0X7yy1BrSNGdD9RCm+zsnYz4D0PN6ZEis/cZ006ZSTc/VVdcw bPv/IzAhZXOYd99MS0ZwXFNjNobudbeeushqlKTTHNNwDNkdSS5NwecHkhmIrflElcXY 4TOiNit8GrV8QNWLBPHCdnb0A0AT6EhJLB+yVJcJxoH1z6kf3C05Sbeg5ewWDIIN+044 K7rZ9snClKWOWlGBH6In6UGoTtXlZC2NJenR09J2f0dJMaPmjhryza/uOLLq5L79/87m hxqgHLyePnzPFHiollOaITHvOK5qN9lyKDPkACL7BJBifM27mdRboaoafRyj3MxRTO6b 8Trw== X-Received: by 10.14.212.9 with SMTP id x9mr83572eeo.46.1401968600436; Thu, 05 Jun 2014 04:43:20 -0700 (PDT) Received: from [10.61.213.241] (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id d3sm13904334eem.43.2014.06.05.04.43.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 04:43:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Giles Heron In-Reply-To: <235736C59B081941AD5490A89823819B1D34CA4A@xmb-rcd-x11.cisco.com> Date: Thu, 5 Jun 2014 12:43:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <538F178E.6060400@cisco.com> <539034A1.4000500@cesnet.cz> <235736C59B081941AD5490A89823819B1D34CA4A@xmb-rcd-x11.cisco.com> To: "Matus Fabian -X (matfabia - Pantheon Technologies SRO at Cisco)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/isP2Rsb1WbCAgfQ_hd-KAkOZnP0 Cc: "Boris Pilka -X \(bpilka - Pantheon Technologies SRO at Cisco\)" , Netconf Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 11:43:30 -0000 Agreed, and I think while we're at it perhaps we should change the XML = schemas in the doc to YANG? And I suspect it's also worth changing the wording in RFC5277 to make it = explicit that the NETCONF stream is only used for "meta-notifications" = (i.e. notifications about the operation of NETCONF such as the base = notifications defined in RFC6470). Also it may also be worth considering adding the ability to change = filters without dropping the session and starting again (section 6.5 = currently states that you can't modify subscriptions or create multiple = subscriptions on the same session). In fact given that there's an = option to interleave subscriptions with other NETCONF operations it = might also be worth having the ability to delete a subscription. One = option for modifying a subscription could then be to delete it and = create a new one - though I guess there's a risk of missing any = notifications sent between the delete and the create. Chairs - is it worth kicking off an "RFC5277-bis" effort? Giles On 5 Jun 2014, at 10:44, Matus Fabian -X (matfabia - Pantheon = Technologies SRO at Cisco) wrote: > Hi, >=20 > If we extend stream list data which is described in RFC-6277 (reply of = get operation for the list of available event streams) client will be = able to see notification associated with stream. > I suggest add following into /netconf/streams/stream >=20 > list module { > description "List of modules and notifications associated with this = stream."; > key module-name; > leaf module-name { > type string; > description "Name of the module."; > } > leaf-list notification { > type string; > description "Name of the notification."; > } >=20 > Regards, > Matus >=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ladislav = Lhotka > Sent: Thursday, June 05, 2014 11:24 AM > To: Radek Krej=C4=8D=C3=AD > Cc: Boris Pilka -X (bpilka - Pantheon Technologies SRO at Cisco); = Netconf > Subject: Re: [Netconf] Should Default Event Stream contain really all = the notifications ? >=20 >=20 > On 05 Jun 2014, at 11:13, Radek Krej=C4=8D=C3=AD = wrote: >=20 >>=20 >> Dne 4.6.2014 20:31, Kent Watsen napsal(a): >>>> This stream contains all NETCONF XML event notifications = supported by >>>> the NETCONF server. =20 >>>>=20 >>>> It says "NETCONF XML". >>>> Does this imply that a SYSLOG text stream also needs to be wrapped=20= >>>> in XML and sent as a element on the NETCONF stream? = I hope not. >>>=20 >>> My interpretation is that the NETCONF stream contains all = notifications defined by all YANG modules advertised by the device. = Only problem is the RFC5277 doesn't mention YANG anywhere... >>=20 >> I understand the text the same way and libnetconf implements it this = way. RFC says "all NETCONF XML event notifications supported by the = NETCONF server", not "all standard event notifications=E2=80=9D. >=20 > I wonder, isn=E2=80=99t it another conformance-related issue? A simple = server may implement a YANG module but not its notifications, perhaps = because it doesn=E2=80=99t implement notifications in the first place. = Then, a server implementing only the NETCONF stream might send all = notifications in it but another server may use a more fine-grained = approach. >=20 > So probably there should be a way for the server to declare to the = client how notifications are organised. >=20 > Lada=20 >=20 >>=20 >> Radek >>=20 >>>=20 >>> That reading would exclude SYSLOG messages, thankfully. >>>=20 >>>=20 >>>> Probably needs clarification. ;-) >>>=20 >>> Right, e.g., what is "NETCONF XML" ? >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>>=20 >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> -- >> Radek Krejci >> mobile : +420 732 212 714 >> office : +420 234 680 256 >> e-mail :=20 >> rkrejci@cesnet.cz >>=20 >> LinkedIn:=20 >> http://www.linkedin.com/in/radekkrejci >>=20 >>=20 >> CESNET >> Association of Legal Entities >> 160 00 Praha 6, Zikova 4 >> Czech Republic >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Jun 5 05:42:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8341A00D7 for ; Thu, 5 Jun 2014 05:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xZPKI0_V8pF for ; Thu, 5 Jun 2014 05:42:37 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED17B1A009A for ; Thu, 5 Jun 2014 05:42:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 38461111F; Thu, 5 Jun 2014 14:42:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jtKeapZ22ksT; Thu, 5 Jun 2014 14:41:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Jun 2014 14:42:15 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 414CD20017; Thu, 5 Jun 2014 14:42:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QBS6KibVBknB; Thu, 5 Jun 2014 14:42:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C12DB20013; Thu, 5 Jun 2014 14:42:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A7F332D5242D; Thu, 5 Jun 2014 14:42:14 +0200 (CEST) Date: Thu, 5 Jun 2014 14:42:14 +0200 From: Juergen Schoenwaelder To: "Liubing (Leo)" Message-ID: <20140605124214.GA11799@elstar.local> Mail-Followup-To: "Liubing (Leo)" , "Bert Wijnen (IETF)" , "feng.chong33@zte.com.cn" , Andy Bierman , Zhengguangying , Netconf , Yangang References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <53902CAD.6010906@bwijnen.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA41C@nkgeml506-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA41C@nkgeml506-mbx.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yKIAxicV1Jt2RnuihTB0kowdbgM Cc: Zhengguangying , Yangang , Netconf Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 12:42:39 -0000 On Thu, Jun 05, 2014 at 10:46:35AM +0000, Liubing (Leo) wrote: > Another problem is the implementation. SAX is not as widely > supported as DOM [DOM-PARSING]. For example, it is not supported by > some existing libraries such as libxml [LIBXML]. I think this is not correct. http://xmlsoft.org/interface.html /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jun 5 07:45:56 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2C81A008F for ; Thu, 5 Jun 2014 07:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF8O2_v5S-ob for ; Thu, 5 Jun 2014 07:45:48 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2BD1A0189 for ; Thu, 5 Jun 2014 07:45:43 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id i13so1518954qae.7 for ; Thu, 05 Jun 2014 07:45:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bV1ewSwTe4KHdCp9nE/RCT/oTWavQb+CV5KtXXjpyK4=; b=gvx3MmjtcTUAgEclLGufIGUhNF86TuFitrwAgRiZyXGGi7UsEPXVIQSn81uHDKzvDL iEvi0UxwwIUyuQFMQczdoMyrcuxPNQB+HRsaQxg7tc6sWCrI0rrH1PU0+m5sRDw1W/qy d255RYmXYKOCp0i0vnZmjpxLbnQp02znm7PYxp65WlV5JhLv+o/Jj1W1Sa8/SCvAaobp kPbosRvNUjqisQUg4Tne+tsQsKvlS4X/Kc+pL3z3o8+Wym/vGgQv1iKbOd4L9dwEnpuN FplM1Tm7rVUsbqp36+2utgtP/t4rE9gd/KzRw2lCidkhn+Fe4fGbPgfBudiOoDB3qoMg llCA== X-Gm-Message-State: ALoCoQnHymW4ST+FYIwevRxx1PoCCFDWRXXqSFbZQqzLGXqdqNtZPZ6U9YholWsKiNSOvBj7Oz4o MIME-Version: 1.0 X-Received: by 10.224.24.134 with SMTP id v6mr18381657qab.88.1401979536615; Thu, 05 Jun 2014 07:45:36 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Thu, 5 Jun 2014 07:45:36 -0700 (PDT) In-Reply-To: References: <538F178E.6060400@cisco.com> <539034A1.4000500@cesnet.cz> Date: Thu, 5 Jun 2014 07:45:36 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c252c643587e04fb17cc06 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7_mJVJO6w_TAUogSRFPe0mntcGM Cc: Netconf , Boris Pilka Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:45:54 -0000 --001a11c252c643587e04fb17cc06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 5, 2014 at 2:24 AM, Ladislav Lhotka wrote: > > On 05 Jun 2014, at 11:13, Radek Krej=C4=8D=C3=AD wrot= e: > > > > > Dne 4.6.2014 20:31, Kent Watsen napsal(a): > >> > This stream contains all NETCONF XML event notifications supporte= d > by > >> > the NETCONF server. > >> > > >> > It says "NETCONF XML". > >> > Does this imply that a SYSLOG text stream also needs to be wrapped i= n > XML > >> > and sent as a element on the NETCONF stream? I hope > not. > >> > >> My interpretation is that the NETCONF stream contains all notification= s > defined by all YANG modules advertised by the device. Only problem is > the RFC5277 doesn't mention YANG anywhere... > > > > I understand the text the same way and libnetconf implements it this > way. RFC says "all NETCONF XML event notifications supported by the NETCO= NF > server", not "all standard event notifications=E2=80=9D. > > I wonder, isn=E2=80=99t it another conformance-related issue? A simple se= rver may > implement a YANG module but not its notifications, perhaps because it > doesn=E2=80=99t implement notifications in the first place. Then, a serve= r > implementing only the NETCONF stream might send all notifications in it b= ut > another server may use a more fine-grained approach. > > The conformance model seems clear enough: 1) :notification:1.0 capability MUST be advertised or else notification-stmt is not relevant for this server 2) if YANG module capability "foo" advertised then all notification-stmts that are in the "base" module MUST be supported in the NETCONF stream 3) if YANG module capability "foo" advertised then all notification-stmt= s that are conditional via YANG features MUST be supported in the NETCONF stream if all if-feature-stmts within the notification-stmt are true. 4) Not clear if notifications not defined in YANG must be supported. Since our standard conformance model is for YANG only, this seems out of scope (up to vendor to use NETCONF stream or not) > So probably there should be a way for the server to declare to the client > how notifications are organised. > > When we get a 2nd standard notification stream, then I will agree with this effort. Until then, we have 1 stream called NETCONF that contains every event. I think it helps to have an architecture for notifications. 1) an event occurs in the system 2) the NETCONF server detects the event 3) the NETCONF server generates an internal event notification 4) the NETCONF server picks 1 or more streams for the event notification and renders a message for each stream. For NETCONF stream that means use XML encoding and honor replay-buffer requirements. In this interpretation, it makes no sense at all to talk about combining streams because each stream contains different representations of the same events. Lada > > Andy > > > > Radek > > > >> > >> That reading would exclude SYSLOG messages, thankfully. > >> > >> > >> > Probably needs clarification. ;-) > >> > >> Right, e.g., what is "NETCONF XML" ? > >> > >> > >> > >> > >> _______________________________________________ > >> Netconf mailing list > >> > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > Radek Krejci > > mobile : +420 732 212 714 > > office : +420 234 680 256 > > e-mail : > > rkrejci@cesnet.cz > > > > LinkedIn: > > http://www.linkedin.com/in/radekkrejci > > > > > > CESNET > > Association of Legal Entities > > 160 00 Praha 6, Zikova 4 > > Czech Republic > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c252c643587e04fb17cc06 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 5, 2014 at 2:24 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 05 Jun 2014, at 11:13, Radek Krej=E8=ED <rkrejci@cesnet.cz> wrote:

>
> Dne 4.6.2014 20:31, Kent Watsen napsal(a):
>> >    This stream contains all NETCONF XML event notif= ications supported by
>> >    the NETCONF server.
>> >
>> > It says "NETCONF XML".
>> > Does this imply that a SYSLOG text stream also needs to be wr= apped in XML
>> > and sent as a <notification> element on the NETCONF str= eam?  I hope not.
>>
>> My interpretation is that the NETCONF stream contains all notifica= tions defined by all YANG modules advertised by the device.    On= ly problem is the RFC5277 doesn't mention YANG anywhere...
>
> I understand the text the same way and libnetconf implements it this w= ay. RFC says "all NETCONF XML event notifications supported by the NET= CONF server", not "all standard event notifications”.

I wonder, isn’t it another conformance-related issue? A simple server= may implement a YANG module but not its notifications, perhaps because it = doesn’t implement notifications in the first place. Then, a server im= plementing only the NETCONF stream might send all notifications in it but a= nother server may use a more fine-grained approach.



The conformance model s= eems clear enough:

  1)  :notification:1= .0 capability MUST be advertised or else notification-stmt
 =      is not relevant for this server

  2) if YANG module capability "foo" adv= ertised then all notification-stmts
      that are= in the "base" module MUST be supported in the NETCONF stream

  3)  if YANG module capability "foo" advertised t= hen all notification-stmts
      that are conditio= nal via YANG features MUST be supported in the NETCONF stream
&nb= sp;     if all if-feature-stmts within the notification-stmt are = true.

  4) Not clear if notifications not defined in YAN= G must be supported.  Since our standard
     = ; conformance model is for YANG only, this seems out of scope (up to vendor= to use
      NETCONF stream or not)


 
So probably there should be a way for the server to declare to the client h= ow notifications are organised.


When we get a 2nd standard notificatio= n stream, then I will agree with this effort.
Until then, we have= 1 stream called NETCONF that contains every event.

I think it helps to have an architecture for notifications.
=
  1) an event occurs in the system
  2) = the NETCONF server detects the event
  3) the NETCONF server= generates an internal event notification
  4) the NETCONF server picks 1 or more streams for the event not= ification
      and renders a message for each str= eam.  For NETCONF stream that means
      use= XML encoding and honor replay-buffer requirements.

In this interpretation, it makes no sense at all to tal= k about combining streams
because each stream contains different = representations of the same events.


Lada


Andy
 
>
> Radek
>
>>
>> That reading would exclude SYSLOG messages, thankfully.
>>
>>
>> > Probably needs clarification. ;-)
>>
>> Right, e.g., what is "NETCONF XML" ?
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>>
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Radek Krejci
> mobile  : +420 732 212 714
> office  : +420 234 680 256
> e-mail  :
> rkrejci@cesnet.cz
>
> LinkedIn:
> h= ttp://www.linkedin.com/in/radekkrejci
>
>
> CESNET
> Association of Legal Entities
> 160 00 Praha 6, Zikova 4
> Czech Republic
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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





--001a11c252c643587e04fb17cc06-- From nobody Thu Jun 5 08:47:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439E11A0143 for ; Thu, 5 Jun 2014 08:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj_ORMv3yLLF for ; Thu, 5 Jun 2014 08:47:01 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B1F1A0075 for ; Thu, 5 Jun 2014 08:47:00 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id cm18so1604824qab.8 for ; Thu, 05 Jun 2014 08:46:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mdR9x+ZWKOMt0jo+rk+PjwRMGF/wvFxMZuZvKPbUzXw=; b=GnqWZaGd4gtMDorECCMHXsCQA0kmplHm/U7TJk1be68apgDmUvh7ZlZI8UM3dkeLz4 GtfMaBFNq8XuQHxlFRZxEBIZEeK0NtJ5KihsGOAeL57taCzBbx6uWh2jnCOhmkKrTqCj 8oJ6bbG9KDwMCCDRXlAcFpKzkfiVLhnceiB6s8K6yH+GX/zf8jlYc0p+yMVTG6uZ3/Z0 Bnh2mfvatBwomR76BKcH7AXb6cqmcdWXg/Ng2hI9mztz589Qo/IDBz31Pekb0YGXZINq BQrwHMq5Jcq5PmMClcHzngpho5GkQgvegmjS9hDmpD/m7eN8Xh3qABff1W/Lu93aurvC i3hA== X-Gm-Message-State: ALoCoQloVwkVDUJq5dYTqUTvq4ObsLFY0YuqyvPygUNcTmJozxR/WrQY8sUxkyVkhzzzxtVtibM0 MIME-Version: 1.0 X-Received: by 10.229.87.201 with SMTP id x9mr83293058qcl.20.1401983213919; Thu, 05 Jun 2014 08:46:53 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Thu, 5 Jun 2014 08:46:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Jun 2014 08:46:53 -0700 Message-ID: From: Andy Bierman To: feng.chong33@zte.com.cn Content-Type: multipart/alternative; boundary=001a11337b7a728cba04fb18a7bc Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WzYvDZG94hOy4Y5fGcOWkkGl8tk Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:47:03 -0000 --001a11337b7a728cba04fb18a7bc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 4, 2014 at 6:35 PM, wrote: > Hi all, > I have some questions about the usage of 'operation' attribute in > edit-config. > 1. 'replace' attribute can only be used to remove configuration? > For example, the rpc request listed below is valid? > > > > > > > > > > > > > 2.How to process nested operation attribute? > For example: > > > > > > > > > eth0/0/0 > > true > > > > > > > The sequence of process is merge interface name 'eth0/0/0' and remov= e > mtu and merge enabled to 'true' > or merge interface name 'eth0/0/0' and merge > enabled to 'true' and remove mtu? > In other words, NETCONF will process outer layer operation firstly > and process inner layer operation later, or process operations in > accordance with XML tree traversal order? > There is no required processing order. It is an implementation detail. Some things to consider: 1) all operations are against the target datastore at the start of the operation 2) the operations are all-or-none, not incremental 2a) this implies that create within delete, or delete within create, is always an error because 'data-exists' or 'data-missing' must be true In your example there is no problem because 'remove' works even if the data is missing. > > 3. If other operation attribute nested in operation attribute > 'remove',what should NETCONF server do? Only process remove operation? > > 4. Can NETCONF support the nested operation attribute equals to parent > operation attribute? > > /frank > > Andy > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11337b7a728cba04fb18a7bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 6:35 PM, <feng.chong33@zte.com.cn> wrote:
Hi all,
=A0 =A0I have some questions about the usage of =A0'operation' attribute in edit-config.
=A0 =A01. 'replace' attribute can only be used to remove configuration?
=A0 =A0 =A0 For example, the rpc request listed below is valid?
=A0 =A0 =A0 <rpc message-id =3D "101">
=A0 =A0 =A0 =A0 =A0 =A0<edit-config>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<target>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <running/>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</target>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<config>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <interfaces operation=3D "replace"/>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</config>
=A0 =A0 =A0 =A0 =A0 =A0</edit-config>
=A0 =A0 =A0 </rpc>


=A0 =A02.How to process nested operation attribute?
=A0 =A0 =A0For example:
=A0 =A0 =A0 =A0 =A0 =A0<rpc message-id =3D "101">
=A0 =A0 =A0 =A0 =A0 =A0<edit-config>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<target>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <running/>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</target>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<config>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <interfaces>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <interface operation=3D "merge">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<name>eth0/0/0</name>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mtu operation=3D "remove">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<enabled>true</enalbled>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </interface>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </interfaces>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</config>
=A0 =A0 =A0 =A0 =A0 =A0</edit-config>
=A0 =A0 =A0 </rpc>

=A0 =A0 =A0The sequence of process is merge interface name 'eth0/0/0' and remove mtu and merge= enabled to 'true'
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or merge interface name 'eth0/0/0' and merge enabled to 'true' and r= emove mtu?
=A0 =A0 =A0In other words, NETCONF will process outer layer operation firstly and process inner layer operation later, or process operations in accordance with XML tree traversa= l order?
=A0

<= br>
There is no required processing order.
It is an imp= lementation detail.
Some things to consider:
=A0 1) all= operations are against the target datastore at the start of the operation<= /div>
=A0 2) the operations are all-or-none, not incremental
=A0 2= a) this implies that create within delete, or delete within create, is alwa= ys an error
=A0 =A0 =A0 =A0because 'data-exists' or '= data-missing' must be true

In your example there is no problem because 'remove= ' works even if the data is missing.


=A0 =A0 =A0 =A0=A0

3. If other operation attribute nested in operation attribute 'remove',what should NETCONF server do? Only= process remove operation?

=A0 4. Can NETCONF support the nested operation attribute equals to parent operation attribute?
=A0 =A0 =A0
/frank


Andy
=A0
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s). If you are not an in= tended recipient, any disclosure, reproduction, distribution or other disse= mination or use of the information contained is strictly prohibited. If yo= u have received this mail in error, please delete it and notify us immediat= ely.

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


--001a11337b7a728cba04fb18a7bc-- From nobody Thu Jun 5 23:18:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64B41A028E for ; Thu, 5 Jun 2014 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFAekO9nl11g for ; Thu, 5 Jun 2014 23:18:37 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB771A0276 for ; Thu, 5 Jun 2014 23:18:35 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 828102D033 for ; Fri, 6 Jun 2014 14:18:16 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 67A02CE0C77; Fri, 6 Jun 2014 14:18:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s566IHmR073749; Fri, 6 Jun 2014 14:18:17 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: References: To: Andy Bierman MIME-Version: 1.0 X-KeepSent: BC2F39E7:19F484DE-48257CEF:002240EF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Fri, 6 Jun 2014 14:18:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-06 14:18:18, Serialize complete at 2014-06-06 14:18:18 Content-Type: multipart/alternative; boundary="=_alternative 0022A27448257CEF_=" X-MAIL: mse01.zte.com.cn s566IHmR073749 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/rmJNoB3rkLJJXXJC8PdQcYOKT84 Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 06:18:40 -0000 This is a multipart message in MIME format. --=_alternative 0022A27448257CEF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 YW5keSwNCiAgIFRoYW5rcyBhIGxvdC4NCiAgIENhbiB5b3UgYW5zd2VyIHRoZSBmaXJzdCBxdWVz dGlvbj8gJ3JlcGxhY2UnIGNhbiBiZSB1c2VkIGFzICdyZW1vdmUnPw0KL2ZyYW5rDQoNCkFuZHkg Qmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYtMDUgMjM6NDY6NTM6DQoN Cj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiAyMDE0LTA2LTA1IDIzOjQ2 DQo+IA0KPiDK1bz+yMsNCj4gDQo+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gDQo+ILOt y80NCj4gDQo+IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+LCB5ZS54dTFAenRlLmNvbS5jbiwg ZG91LndlaTFAenRlLmNvbS5jbiwgDQo+IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24NCj4gDQo+INb3 zOINCj4gDQo+IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9m ICdvcGVyYXRpb24nIA0KPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcNCj4gDQo+IA0KDQo+IE9u IFdlZCwgSnVuIDQsIDIwMTQgYXQgNjozNSBQTSwgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiB3 cm90ZToNCj4gSGkgYWxsLCANCj4gICAgSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSB1 c2FnZSBvZiAgJ29wZXJhdGlvbicgYXR0cmlidXRlIA0KPiBpbiBlZGl0LWNvbmZpZy4gDQo+ICAg IDEuICdyZXBsYWNlJyBhdHRyaWJ1dGUgY2FuIG9ubHkgYmUgdXNlZCB0byByZW1vdmUgY29uZmln dXJhdGlvbj8gDQo+ICAgICAgIEZvciBleGFtcGxlLCB0aGUgcnBjIHJlcXVlc3QgbGlzdGVkIGJl bG93IGlzIHZhbGlkPyANCj4gICAgICAgPHJwYyBtZXNzYWdlLWlkID0gIjEwMSI+IA0KPiAgICAg ICAgICAgIDxlZGl0LWNvbmZpZz4gDQo+ICAgICAgICAgICAgICAgIDx0YXJnZXQ+IA0KPiAgICAg ICAgICAgICAgICAgICA8cnVubmluZy8+IA0KPiAgICAgICAgICAgICAgICA8L3RhcmdldD4gDQo+ ICAgICAgICAgICAgICAgIDxjb25maWc+IA0KPiAgICAgICAgICAgICAgICAgICA8aW50ZXJmYWNl cyBvcGVyYXRpb249ICJyZXBsYWNlIi8+IA0KPiAgICAgICAgICAgICAgICA8L2NvbmZpZz4gDQo+ ICAgICAgICAgICAgPC9lZGl0LWNvbmZpZz4gDQo+ICAgICAgIDwvcnBjPiANCj4gDQo+IA0KPiAg ICAyLkhvdyB0byBwcm9jZXNzIG5lc3RlZCBvcGVyYXRpb24gYXR0cmlidXRlPyANCj4gICAgICBG b3IgZXhhbXBsZTogDQo+ICAgICAgICAgICAgPHJwYyBtZXNzYWdlLWlkID0gIjEwMSI+IA0KPiAg ICAgICAgICAgIDxlZGl0LWNvbmZpZz4gDQo+ICAgICAgICAgICAgICAgIDx0YXJnZXQ+IA0KPiAg ICAgICAgICAgICAgICAgICA8cnVubmluZy8+IA0KPiAgICAgICAgICAgICAgICA8L3RhcmdldD4g DQo+ICAgICAgICAgICAgICAgIDxjb25maWc+IA0KPiAgICAgICAgICAgICAgICAgICA8aW50ZXJm YWNlcz4gDQo+ICAgICAgICAgICAgICAgICAgICAgICA8aW50ZXJmYWNlIG9wZXJhdGlvbj0gIm1l cmdlIj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxuYW1lPmV0aDAvMC8wPC9uYW1l PiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPG10dSBvcGVyYXRpb249ICJyZW1vdmUi PiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPGVuYWJsZWQ+dHJ1ZTwvZW5hbGJsZWQ+ IA0KPiAgICAgICAgICAgICAgICAgICAgICAgPC9pbnRlcmZhY2U+IA0KPiAgICAgICAgICAgICAg ICAgICA8L2ludGVyZmFjZXM+IA0KPiAgICAgICAgICAgICAgICA8L2NvbmZpZz4gDQo+ICAgICAg ICAgICAgPC9lZGl0LWNvbmZpZz4gDQo+ICAgICAgIDwvcnBjPiANCj4gDQo+ICAgICAgVGhlIHNl cXVlbmNlIG9mIHByb2Nlc3MgaXMgbWVyZ2UgaW50ZXJmYWNlIG5hbWUgJ2V0aDAvMC8wJyBhbmQg DQo+IHJlbW92ZSBtdHUgYW5kIG1lcmdlIGVuYWJsZWQgdG8gJ3RydWUnIA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG9yIG1lcmdlIGludGVyZmFjZSBuYW1lICdldGgwLzAvMCcgYW5k IA0KPiBtZXJnZSBlbmFibGVkIHRvICd0cnVlJyBhbmQgcmVtb3ZlIG10dT8gDQo+ICAgICAgSW4g b3RoZXIgd29yZHMsIE5FVENPTkYgd2lsbCBwcm9jZXNzIG91dGVyIGxheWVyIG9wZXJhdGlvbiAN Cj4gZmlyc3RseSBhbmQgcHJvY2VzcyBpbm5lciBsYXllciBvcGVyYXRpb24gbGF0ZXIsIG9yIHBy b2Nlc3MgDQo+IG9wZXJhdGlvbnMgaW4gYWNjb3JkYW5jZSB3aXRoIFhNTCB0cmVlIHRyYXZlcnNh bCBvcmRlcj8gDQo+ICAgDQo+IA0KPiBUaGVyZSBpcyBubyByZXF1aXJlZCBwcm9jZXNzaW5nIG9y ZGVyLg0KPiBJdCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuDQo+IFNvbWUgdGhpbmdzIHRv IGNvbnNpZGVyOg0KPiAgIDEpIGFsbCBvcGVyYXRpb25zIGFyZSBhZ2FpbnN0IHRoZSB0YXJnZXQg ZGF0YXN0b3JlIGF0IHRoZSBzdGFydCBvZg0KPiB0aGUgb3BlcmF0aW9uDQo+ICAgMikgdGhlIG9w ZXJhdGlvbnMgYXJlIGFsbC1vci1ub25lLCBub3QgaW5jcmVtZW50YWwNCj4gICAyYSkgdGhpcyBp bXBsaWVzIHRoYXQgY3JlYXRlIHdpdGhpbiBkZWxldGUsIG9yIGRlbGV0ZSB3aXRoaW4gDQo+IGNy ZWF0ZSwgaXMgYWx3YXlzIGFuIGVycm9yDQo+ICAgICAgICBiZWNhdXNlICdkYXRhLWV4aXN0cycg b3IgJ2RhdGEtbWlzc2luZycgbXVzdCBiZSB0cnVlDQo+IA0KPiBJbiB5b3VyIGV4YW1wbGUgdGhl cmUgaXMgbm8gcHJvYmxlbSBiZWNhdXNlICdyZW1vdmUnIHdvcmtzIGV2ZW4gaWYgDQo+IHRoZSBk YXRhIGlzIG1pc3NpbmcuDQo+IA0KPiAgICAgICAgIA0KPiANCj4gMy4gSWYgb3RoZXIgb3BlcmF0 aW9uIGF0dHJpYnV0ZSBuZXN0ZWQgaW4gb3BlcmF0aW9uIGF0dHJpYnV0ZSANCj4gJ3JlbW92ZScs d2hhdCBzaG91bGQgTkVUQ09ORiBzZXJ2ZXIgZG8/IE9ubHkgcHJvY2VzcyByZW1vdmUgb3BlcmF0 aW9uPyANCj4gDQo+ICAgNC4gQ2FuIE5FVENPTkYgc3VwcG9ydCB0aGUgbmVzdGVkIG9wZXJhdGlv biBhdHRyaWJ1dGUgZXF1YWxzIHRvIA0KPiBwYXJlbnQgb3BlcmF0aW9uIGF0dHJpYnV0ZT8gDQo+ ICAgICAgIA0KPiAvZnJhbmsgDQo+IA0KPiBBbmR5DQo+ICANCj4gDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyAN Cj4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2 aWxlZ2VkIGFuZCANCj4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1 c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRl bmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gcmVwcm9kdWN0aW9uLCBkaXN0cmli dXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiBpbmZvcm1hdGlv biBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVk IA0KPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBp bW1lZGlhdGVseS4NCj4gDQoNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiBOZXRjb25mQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhl IGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGlu dGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg bWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5 Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdp dGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBp bnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1 dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVs eS4NCg== --=_alternative 0022A27448257CEF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuZHksPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7VGhhbmtzIGEgbG90LjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0NhbiB5b3Ug YW5zd2VyIHRoZSBmaXJzdA0KcXVlc3Rpb24/ICdyZXBsYWNlJyBjYW4gYmUgdXNlZCBhcyAncmVt b3ZlJz88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwv Zm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkFuZHkgQmllcm1hbiAmbHQ7YW5keUB5 dW1hd29ya3MuY29tJmd0OyDQtNPaIDIwMTQtMDYtMDUNCjIzOjQ2OjUzOjxicj4NCjxicj4NCiZn dDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyMDE0LTA2LTA1IDIzOjQ2PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20u Y24sIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOt y808L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBOZXRj b25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgeWUueHUxQHp0ZS5jb20uY24sIGRvdS53ZWkx QHp0ZS5jb20uY24sDQo8YnI+DQomZ3Q7IHhpYW8ueXVxaW5nQHp0ZS5jb20uY248L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDW98ziPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgUmU6IFtOZXRjb25mXSBTb21l IHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgPGJyPg0KJmd0OyBhdHRy aWJ1dGUgaW4gZWRpdC1jb25maWc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgT24gV2VkLCBKdW4gNCwgMjAxNCBhdCA2OjM1IFBNLCAmbHQ7ZmVuZy5jaG9uZzMzQHp0ZS5j b20uY24mZ3Q7DQp3cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg SGkgYWxsLCA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJv dXQgdGhlIHVzYWdlIG9mICZuYnNwOydvcGVyYXRpb24nDQphdHRyaWJ1dGUgPGJyPg0KJmd0OyBp biBlZGl0LWNvbmZpZy4gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7MS4gJ3JlcGxhY2UnIGF0dHJp YnV0ZSBjYW4gb25seSBiZSB1c2VkIHRvIHJlbW92ZSBjb25maWd1cmF0aW9uPw0KPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGb3IgZXhhbXBsZSwgdGhlIHJwYyByZXF1ZXN0IGxpc3Rl ZCBiZWxvdyBpcw0KdmFsaWQ/IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3Jw YyBtZXNzYWdlLWlkID0gJnF1b3Q7MTAxJnF1b3Q7Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2VkaXQtY29uZmlnJmd0OyA8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7dGFyZ2V0Jmd0Ow0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7cnVubmluZy8mZ3Q7DQo8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7L3RhcmdldCZndDsNCjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtjb25maWcmZ3Q7DQo8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZsdDtpbnRlcmZhY2VzDQpvcGVyYXRpb249ICZxdW90O3JlcGxhY2UmcXVvdDsvJmd0 OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7L2NvbmZpZyZndDsNCjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2VkaXQtY29uZmlnJmd0OyA8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvcnBjJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7Mi5Ib3cgdG8gcHJvY2VzcyBuZXN0ZWQgb3BlcmF0aW9uIGF0 dHJpYnV0ZT8gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZvciBleGFtcGxlOiA8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3JwYyBt ZXNzYWdlLWlkID0gJnF1b3Q7MTAxJnF1b3Q7Jmd0Ow0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtlZGl0LWNvbmZpZyZndDsgPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O3RhcmdldCZndDsNCjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3J1bm5pbmcvJmd0Ow0KPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0Oy90YXJnZXQmZ3Q7DQo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Y29uZmlnJmd0Ow0KPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbHQ7aW50ZXJmYWNlcyZndDsNCjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jmx0O2ludGVyZmFjZSBvcGVyYXRpb249ICZxdW90O21lcmdlJnF1b3Q7Jmd0OyA8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O25hbWUmZ3Q7ZXRo MC8wLzAmbHQ7L25hbWUmZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7bXR1IG9wZXJhdGlvbj0gJnF1b3Q7cmVtb3ZlJnF1b3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2Vu YWJsZWQmZ3Q7dHJ1ZSZsdDsvZW5hbGJsZWQmZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJmx0Oy9pbnRlcmZhY2UmZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9pbnRlcmZhY2Vz Jmd0Ow0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0Oy9jb25maWcmZ3Q7DQo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9lZGl0LWNvbmZpZyZndDsgPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3JwYyZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHNlcXVlbmNlIG9mIHByb2Nlc3MgaXMgbWVyZ2UgaW50 ZXJmYWNlIG5hbWUNCidldGgwLzAvMCcgYW5kIDxicj4NCiZndDsgcmVtb3ZlIG10dSBhbmQgbWVy Z2UgZW5hYmxlZCB0byAndHJ1ZScgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvciBtZXJnZSBpbnRlcmZhY2UgbmFtZSAnZXRoMC8wLzAn IGFuZA0KPGJyPg0KJmd0OyBtZXJnZSBlbmFibGVkIHRvICd0cnVlJyBhbmQgcmVtb3ZlIG10dT8g PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luIG90aGVyIHdvcmRzLCBORVRDT05GIHdp bGwgcHJvY2VzcyBvdXRlciBsYXllcg0Kb3BlcmF0aW9uIDxicj4NCiZndDsgZmlyc3RseSBhbmQg cHJvY2VzcyBpbm5lciBsYXllciBvcGVyYXRpb24gbGF0ZXIsIG9yIHByb2Nlc3MgPGJyPg0KJmd0 OyBvcGVyYXRpb25zIGluIGFjY29yZGFuY2Ugd2l0aCBYTUwgdHJlZSB0cmF2ZXJzYWwgb3JkZXI/ IDxicj4NCiZndDsgJm5ic3A7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyA8YnI+DQomZ3Q7IFRoZXJlIGlzIG5vIHJlcXVpcmVkIHByb2Nlc3Npbmcgb3JkZXIuPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEl0IGlzIGFuIGltcGxlbWVudGF0aW9u IGRldGFpbC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU29tZSB0aGlu Z3MgdG8gY29uc2lkZXI6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZu YnNwOyAxKSBhbGwgb3BlcmF0aW9ucyBhcmUgYWdhaW5zdCB0aGUgdGFyZ2V0DQpkYXRhc3RvcmUg YXQgdGhlIHN0YXJ0IG9mPGJyPg0KJmd0OyB0aGUgb3BlcmF0aW9uPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAyKSB0aGUgb3BlcmF0aW9ucyBhcmUgYWxsLW9y LW5vbmUsIG5vdA0KaW5jcmVtZW50YWw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgJm5ic3A7IDJhKSB0aGlzIGltcGxpZXMgdGhhdCBjcmVhdGUgd2l0aGluIGRlbGV0ZSwN Cm9yIGRlbGV0ZSB3aXRoaW4gPGJyPg0KJmd0OyBjcmVhdGUsIGlzIGFsd2F5cyBhbiBlcnJvcjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtiZWNhdXNlICdkYXRhLWV4aXN0cycNCm9yICdkYXRhLW1pc3NpbmcnIG11c3QgYmUg dHJ1ZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IElu IHlvdXIgZXhhbXBsZSB0aGVyZSBpcyBubyBwcm9ibGVtIGJlY2F1c2UgJ3JlbW92ZScgd29ya3Mg ZXZlbiBpZg0KPGJyPg0KJmd0OyB0aGUgZGF0YSBpcyBtaXNzaW5nLjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IDMuIElmIG90aGVyIG9wZXJhdGlvbiBhdHRyaWJ1dGUgbmVzdGVkIGluIG9wZXJhdGlvbiBh dHRyaWJ1dGUgPGJyPg0KJmd0OyAncmVtb3ZlJyx3aGF0IHNob3VsZCBORVRDT05GIHNlcnZlciBk bz8gT25seSBwcm9jZXNzIHJlbW92ZSBvcGVyYXRpb24/DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsg Jm5ic3A7IDQuIENhbiBORVRDT05GIHN1cHBvcnQgdGhlIG5lc3RlZCBvcGVyYXRpb24gYXR0cmli dXRlIGVxdWFscw0KdG8gPGJyPg0KJmd0OyBwYXJlbnQgb3BlcmF0aW9uIGF0dHJpYnV0ZT8gPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7IC9mcmFuayA8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBBbmR5PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCjxicj4NCiZn dDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2 aWxlZ2VkIGFuZCA8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWU8YnI+DQomZ3Q7IChzKS4gJm5ic3A7SWYg eW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgPGJyPg0K Jmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9y IHVzZSBvZiB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQNCjxicj4NCiZndDsgdGhpcyBt YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHku PGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiZndDsgTmV0 Y29uZkBpZXRmLm9yZzxicj4NCiZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY+PHR0Pjxmb250IHNpemU9Mj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2ZvbnQ+PC90dD48L2E+PHR0 Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9 ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQg aGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRp c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1l ZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJs dWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBh biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlh dGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 0022A27448257CEF_=-- From nobody Fri Jun 6 02:42:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0643A1A02C1 for ; Fri, 6 Jun 2014 02:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkRbs4uNJutf for ; Fri, 6 Jun 2014 02:42:21 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353941A0109 for ; Fri, 6 Jun 2014 02:42:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CCC415407AF; Fri, 6 Jun 2014 11:42:11 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0NZkTWdPtzU; Fri, 6 Jun 2014 11:42:06 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id A0D7C54026C; Fri, 6 Jun 2014 11:42:05 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <538F178E.6060400@cisco.com> <539034A1.4000500@cesnet.cz> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Fri, 06 Jun 2014 11:42:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/fwa3u3vtJjMPate2xxHA28gsXX8 Cc: Netconf , Boris Pilka Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 09:42:24 -0000 Andy Bierman writes: > On Thu, Jun 5, 2014 at 2:24 AM, Ladislav Lhotka wrote: > >> >> On 05 Jun 2014, at 11:13, Radek Krej=C4=8D=C3=AD wro= te: >> >> > >> > Dne 4.6.2014 20:31, Kent Watsen napsal(a): >> >> > This stream contains all NETCONF XML event notifications support= ed >> by >> >> > the NETCONF server. >> >> > >> >> > It says "NETCONF XML". >> >> > Does this imply that a SYSLOG text stream also needs to be wrapped = in >> XML >> >> > and sent as a element on the NETCONF stream? I hope >> not. >> >> >> >> My interpretation is that the NETCONF stream contains all notificatio= ns >> defined by all YANG modules advertised by the device. Only problem is >> the RFC5277 doesn't mention YANG anywhere... >> > >> > I understand the text the same way and libnetconf implements it this >> way. RFC says "all NETCONF XML event notifications supported by the NETC= ONF >> server", not "all standard event notifications=E2=80=9D. >> >> I wonder, isn=E2=80=99t it another conformance-related issue? A simple s= erver may >> implement a YANG module but not its notifications, perhaps because it >> doesn=E2=80=99t implement notifications in the first place. Then, a serv= er >> implementing only the NETCONF stream might send all notifications in it = but >> another server may use a more fine-grained approach. >> >> > > The conformance model seems clear enough: > > 1) :notification:1.0 capability MUST be advertised or else > notification-stmt > is not relevant for this server This should be stated somewhere because the other interpretation may be tha= t a server has to support notification in order to be able to implement a m= odule that defines notification(s). > > 2) if YANG module capability "foo" advertised then all notification-stm= ts > that are in the "base" module MUST be supported in the NETCONF stre= am > > 3) if YANG module capability "foo" advertised then all notification-st= mts > that are conditional via YANG features MUST be supported in the > NETCONF stream > if all if-feature-stmts within the notification-stmt are true. > > 4) Not clear if notifications not defined in YANG must be supported. > Since our standard > conformance model is for YANG only, this seems out of scope (up to > vendor to use > NETCONF stream or not) > > > > >> So probably there should be a way for the server to declare to the client >> how notifications are organised. >> >> > When we get a 2nd standard notification stream, then I will agree with th= is > effort. > Until then, we have 1 stream called NETCONF that contains every event. Currently, there probably isn't any mechanism for the client to discover in= which stream a particular YANG-defined notification is sent, unless the st= reams are user-configurable. It might be useful to extend the "stream" subtree/resource with this info. Lada > > I think it helps to have an architecture for notifications. > > 1) an event occurs in the system > 2) the NETCONF server detects the event > 3) the NETCONF server generates an internal event notification > 4) the NETCONF server picks 1 or more streams for the event notification > and renders a message for each stream. For NETCONF stream that mea= ns > use XML encoding and honor replay-buffer requirements. > > In this interpretation, it makes no sense at all to talk about combining > streams > because each stream contains different representations of the same events. > > > Lada >> >> > Andy > > >> > >> > Radek >> > >> >> >> >> That reading would exclude SYSLOG messages, thankfully. >> >> >> >> >> >> > Probably needs clarification. ;-) >> >> >> >> Right, e.g., what is "NETCONF XML" ? >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Netconf mailing list >> >> >> >> Netconf@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netconf >> > >> > -- >> > Radek Krejci >> > mobile : +420 732 212 714 >> > office : +420 234 680 256 >> > e-mail : >> > rkrejci@cesnet.cz >> > >> > LinkedIn: >> > http://www.linkedin.com/in/radekkrejci >> > >> > >> > CESNET >> > Association of Legal Entities >> > 160 00 Praha 6, Zikova 4 >> > Czech Republic >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jun 6 03:42:16 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F461A0438 for ; Fri, 6 Jun 2014 03:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW4ON8wPjmPc for ; Fri, 6 Jun 2014 03:42:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062871A0132 for ; Fri, 6 Jun 2014 03:42:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX99015; Fri, 06 Jun 2014 10:42:01 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 11:41:07 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 11:41:59 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 18:41:49 +0800 From: "Liubing (Leo)" To: Andy Bierman , "Bert Wijnen (IETF)" Thread-Topic: =?gb2312?B?W05ldGNvbmZdILTwuLQ6IFJlOiBOZXRjb25mIGZyYWdtZW50YXRpb24tLy9G?= =?gb2312?B?VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtbmV0?= =?gb2312?Q?conf-fragmentation-00.txt?= Thread-Index: AQHPgKrSd7SeyGT0j0Su3YhtRK6+cptj2TPQ Date: Fri, 6 Jun 2014 10:41:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA902@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <53902CAD.6010906@bwijnen.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BA902nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/fGrdnA3ZhISoGZYpGu6DjK7G1yk Cc: Zhengguangying , Netconf , Yangang Subject: Re: [Netconf] =?gb2312?b?tPC4tDogUmU6IE5ldGNvbmYgZnJhZ21lbnRhdGlvbi0v?= =?gb2312?b?L0ZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1u?= =?gb2312?b?ZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 10:42:13 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BA902nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogVGh1cnNkYXksIEp1bmUgMDUsIDIw MTQgNjo0MiBQTQ0KVG86IEJlcnQgV2lqbmVuIChJRVRGKQ0KQ2M6IFpoZW5nZ3Vhbmd5aW5nOyBZ YW5nYW5nOyBOZXRjb25mOyBOZXRjb25mDQpTdWJqZWN0OiBSZTogW05ldGNvbmZdILTwuLQ6IFJl OiBOZXRjb25mIGZyYWdtZW50YXRpb24tLy9GVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA0KDQoNCg0KT24gVGh1LCBK dW4gNSwgMjAxNCBhdCAxOjM5IEFNLCBCZXJ0IFdpam5lbiAoSUVURikgPGJlcnRpZXRmQGJ3aWpu ZW4ubmV0PG1haWx0bzpiZXJ0aWV0ZkBid2lqbmVuLm5ldD4+IHdyb3RlOg0KSSBhbSBhIGJpdCBj b25jZXJuZWQgdGhhdCB3ZSBhcmUgbm93IGRpc2N1c3NpbmcgYSBwb3NzaWJsZSBzb2x1dGlvbi4N Cg0KQlVULi4uLiBJIHRoaW5rIHdlIHNob3VsZCBmaXJzdCBkaXNjdXNzIG9uIHRoaXMgbGlzdDoN Cg0KLSBJcyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZGVzY3JpYmluZyBhIHJlYWwgcHJvYmxlbSB0 aGF0IHdlIGFsbCBhZ3JlZSB3aXRoPw0KDQoNCndoaWNoIHByb2JsZW0/IG1vcmUgdGhhbiAxIGhh cyBiZWVuIGRlc2NyaWJlZDoNCg0KICAxKSB0aGUgY2xpZW50IGNhbiBnZXQgYSByZXBseSB0aGF0 IGlzICJ0b28gYmlnIiBzbyBpdCB3YW50cyB0byBhc2sgZm9yIHdlbGwtZm9ybWVkDQogICAgICBY TUwgZG9jdW1lbnRzIHRoYXQgZnJhZ21lbnQgdGhlIHJlcGx5DQoNCiAgMikgZGF0YSBza2V3IGNh biBoYXBwZW4gYWNyb3NzIHBvbGxzIHNvIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gc25hcHNob3QNCiAg ICAgIHRoZSByZXF1ZXN0IGFuZCBzdG9yZSBpdCBmb3IgdGhlIGNsaWVudCB0byByZXRyaWV2ZSBp biBwaWVjZXMNCg0KDQotIElmIGl0IGlzIGRvIHdlIGJlbGlldmUgdGhhdCBvdXIgV0cgc2hvdWxk IHdvcmsgb24gYSBzb2x1dGlvbj8NCg0Kbm8gLS0gbmVpdGhlciBwcm9ibGVtIGlzIGltcG9ydGFu dCBlbm91Z2ggdG8gc29sdmUgcmlnaHQgbm93Lg0KW0JpbmddIFRoZSChsHRvbyBiaWcgcmVwbHmh sSBwcm9ibGVtIGFjdHVhbGx5IGNvbWVzIGZyb20gcmVhbCBkZXBsb3ltZW50IHJlcXVpcmVtZW50 LiBOb3cgdGhlcmUgYXJlIHNvbWUgTk1TIHRoYXQgb25seSBwcm92aWRlIE5FVENPTkYgaW50ZXJm YWNlIHRvIHRoZSBkZXZpY2VzLg0KRXNwZWNpYWxseSB3aGVuIHRoZSBOTVMgYWxzbyBnZXQgc3Rh dGUgZGF0YSBmcm9tIE5FVENPTkYsIHRoZSBiaWcgcmVwbHkgcHJvYmxlbSB3b3VsZCBiZSBoaWdo bHkgZXhwZWN0ZWQuIEFuZCBzaW5jZSB0aGV5IG9ubHkgdXNlIE5FVENPTkYgaW50ZXJmYWNlLCBp dCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBzb2x2ZSB0aGUgcHJvYmxlbSBpbiBhIHN0YW5kYXJk IHdheS4NCg0KVGhlIGNsaWVudCBjYW4gdXNlIGZpbHRlcmluZyB0byBhY2hpZXZlICgxKQ0KW0Jp bmddIE1heSBJIGFzayB3aGV0aGVyIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHNvbWUgc3BlY2lmaWMg ZmlsdGVyaW5nIG9yIGp1c3QgaW4gZ2VuZXJhbD8NCkFzIEkgdW5kZXJzdGFuZCwgZmlsdGVyaW5n IG1lY2hhbmlzbXMgY291bGQgYmU6DQoNCi0gICAgICAgIEZvciBleGFtcGxlLCB3aGVuIHRoZSBO TVMgd2FudHMgdG8gZ2V0IGEgcG9ydGlvbiBvZiB0aGUgbGFyZ2UgYW1vdW50IHJvdXRlcywgaXQg Y291bGQgZmlsdGVyIGJ5IGludGVyZmFjZSwgYnkgcHJlZml4IG9yIHNvbWUgb3RoZXIgY29uZGl0 aW9ucy4gSG93ZXZlciwgc2luY2UgcmVhbCBkZXBsb3ltZW50IHNjZW5hcmlvcyB2YXJpZWQgYSBs b3QsIHRoZXNlIGNvbmRpdGlvbnMgbWlnaHQgbm90IGJlIGFibGUgdG8gZ3VhcmFudGVlIHRoZSBy ZXN1bHQgaXMgaW4gdGhlIGV4cGVjdGVkIGFtb3VudC4gU29tZSBpbnRlcmZhY2VzIG1pZ2h0IGhh dmUgb25seSBhIGZldyByb3V0ZXMsIHdoaWxlIHNvbWUgbWlnaHQgc3RpbGwgaGF2ZSChsHRvbyBi aWehsSByb3V0ZXMgZGF0YS4NCg0KLSAgICAgICAgUHJlY2lzZSBmaWx0ZXJpbmcgbGlrZSBYUGF0 aCwgaXQgbWlnaHQgYmUgYmV0dGVyIHRoYW4gYWJvdmUsIGJ1dCBhZ2FpbiBpdCBpcyBub3QgYmUg YWJsZSB0byBndWFyYW50ZWUgdG8gZ2V0IGEgcHJvcGVyIGFtb3VudCByZXBseS4gTW9yZSBpbXBv cnRhbnQsIFhQYXRoIGlzIHNvIHNvcGhpc3RpY2F0ZWQgdGhhdCBzb21lIGRldmljZXMganVzdCBk b26hr3Qgc3VwcG9ydCBpdC4gRXZlbiBpZiBpdCBpcyBzdXBwb3J0ZWQsIGl0IGlzIG9idmlvdXNs eSBoZWF2aWVyIHRoYW4ganVzdCByZXRyaWV2aW5nLg0KDQpTbyBpbiBnZW5lcmFsLCBJIHRoaW5r IGZpbHRlcmluZyBtaWdodCBiZSBoZWxwZnVsLCBidXQgaXQgZG9lc26hr3QgcmVhbGx5IHNvbHZl IHRoZSBwcm9ibGVtLg0KDQphbmQgKDIpIGlzIG5vdCBwcmFjdGljYWwNCmJlY2F1c2Ugb2YgbWVt b3J5IGNvbnN0cmFpbnRzIGluIGRldmljZXMuDQpbQmluZ10gQWx0aG91Z2ggbm93IHdlIGp1c3Qg bmVlZCB0byBmb2N1cyBvbiB0aGUgcHJvYmxlbSwgSaGvZCBsaWtlIHRvIGV4cGxhaW4gYSBiaXQg bW9yZSBvbiBvdXIgc29sdXRpb24uDQoNCk91ciBwcm9wb3NhbCBpcyBOT1Qgc25hcHNob3QuIEl0 IGRvZXNuoa90IGhvbGQgdGhlIHdob2xlIHJlc3VsdCBpbiB0aGUgbWVtb3J5LCBpdCBvbmx5IGhv bGRzIHRoZSBjb250ZXh0IChkYXRhIG9mZnNldCAuZXRjKS4gV2hlbiB0aGUgTk1TIHJlcXVlc3Qg dGhlIG5leHQgYmxvY2ssIHRoZSBkZXZpY2UgY291bGQgZWFzaWx5IGFjY2VzcyB0byB0aGUgYmxv Y2sgYWNjb3JkaW5nIHRvIHRoZSBjb250ZXh0Lg0KDQoNCkJlc3QgcmVnYXJkcywNCkJpbmcNCg0K DQpPbmNlIHdlIGhhdmUgYWdyZWUgb24gdGhhdCwgd2UgY2FuIGRlY2lkZSBpZiB3ZSB3YW50IHRv IGFkZCB0aGlzIHRvcGljDQp0byBvdXIgV0cgY2hhcnRlciBhbmQgd29yayBvbiBpdC4NCg0KV291 bGQgd2UgYmUgYXNraW5nIHRoZSBJRVNHIHRvIGFwcHJvdmUgYSBuZXcgY2hhcnRlciB3aGlsZSBz byBtdWNoDQpvZiB0aGUgY3VycmVudCBjaGFydGVyIHJlbWFpbnMgdW5maW5pc2hlZD8NCg0KDQpC ZXJ0IChzcGVha2luZyBhcyBjby1jaGFpcikNCg0KQW5keQ0KDQoNCk9uIDA1LzA2LzE0IDAyOjU5 LCBmZW5nLmNob25nMzNAenRlLmNvbS5jbjxtYWlsdG86ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24+ IHdyb3RlOg0KYW5keSwNCiAgICBIb3cgdG8gcHJvY2VzcyBuZXN0ZWQgbGlzdHMgdXNpbmcgeW91 ciBzb2x1dGlvbj8NCg0KRm9yIGV4YW1wbGU6DQogICAgbGlzdCBmb28gew0KICAgICAgICBrZXkg YTsNCiAgICAgICAgbGVhZiBhIHsuLi59DQogICAgICAgIGxlYWYgYiB7Li4ufQ0KICAgICAgICBs aXN0IG5lc3RlZC1mb28gew0Ka2V5IG5lc3RlZC1hOw0KbGVhZiBuZXN0ZWQtYSB7Li4ufQ0KbGVh ZiBuZXRzdGVkLWIgey4uLn0NCiAgICAgICAgfQ0KICAgIH0NCg0KICAgSWYgcmVxdWVzdCBpczoN CjxycGM+DQogICAgICA8Z2V0LWxpc3Q+DQogICAgICAgIDx0YXJnZXQ+L2ZvbzwvdGFyZ2V0Pg0K ICAgICAgPC9nZXQtbGlzdD4NCiAgICA8L3JwYz4NCiAgIFdoYXQgaXMgdGhlIHJlc3BvbnNlPw0K DQpBbmQsIGFub3RoZXIgcXVlc3Rpb246DQpTdGFydC1pbmRleCBpcyBub3QgcmVsaWFibGUsIGlm IHNvbWUgZW50cmllcyBhcmUgZGVsZXRlZC4gSSB0aGluayB5b3UgY2FuIHVzZSBzdGFydCBrZXkg aW5zdGVhZC4NCg0KDQoNCi9mcmFuaw0KDQoiTmV0Y29uZiIgPG5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPj4g0LTT2iAyMDE0LTA2LTA1IDAw OjQzOjEyOg0KDQogPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5k eUB5dW1hd29ya3MuY29tPj4NCiA+ILeivP7IyzogICJOZXRjb25mIiA8bmV0Y29uZi1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KID4NCiA+IDIwMTQt MDYtMDUgMDA6NDMNCiA+DQogPiDK1bz+yMsNCiA+DQogPiBjaG9uZyBmZW5nIDxmZW5nY2hvbmds bGx5QGdtYWlsLmNvbTxtYWlsdG86ZmVuZ2Nob25nbGxseUBnbWFpbC5jb20+PiwNCiA+DQogPiCz rcvNDQogPg0KID4gWmhlbmdndWFuZ3lpbmcgPHpoZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb208bWFp bHRvOnpoZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb20+PiwgTmV0Y29uZg0KID4gPG5ldGNvbmZAaWV0 Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+PiwgWWFuZ2FuZyA8eWFuZ2FuZ0BodWF3ZWku Y29tPG1haWx0bzp5YW5nYW5nQGh1YXdlaS5jb20+Pg0KID4NCiA+INb3zOINCiA+DQogPiBSZTog W05ldGNvbmZdIE5ldGNvbmYgZnJhZ21lbnRhdGlvbi0vL0ZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24NCiA+IGZvciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA0KID4N CiA+DQoNCiA+IE9uIFdlZCwgSnVuIDQsIDIwMTQgYXQgODozMiBBTSwgY2hvbmcgZmVuZyA8ZmVu Z2Nob25nbGxseUBnbWFpbC5jb208bWFpbHRvOmZlbmdjaG9uZ2xsbHlAZ21haWwuY29tPj4gd3Jv dGU6DQogPiBIaSwNCiA+ICAgIEkgaGF2ZSByZXZpZXdlZCB0aGlzIG5ldyBkcmFmdC4NCiA+ICAg IEkgdW5kZXJzdGFuZCB5b3VyIHNvbHV0aW9uIGlzIHRoYXQgTkVUQ09ORiBzZXJ2ZXIgcmVzZXJ2 ZSBicmVhaw0KID4gcG9pbnRzIGFuZCB3YWl0IGZvciBjbGllbnQgdG8gcmV0cmlldmUgdGhlIG5l eHQgcmVzcG9uc2UuDQogPiBJIHRoaW5rIGl0J3Mgbm90IGEgZ29vZCBzb2x1dGlvbiwgYmVjYXVz ZSBzZXJ2ZXIgbWF5IG5lZWQgdG8gcmVzZXJ2ZQ0KID4gbWFueSBicmVhayBwb2ludHMgaWYgdGhl cmUgYSBsYXJnZSBudW1iZXIgb2YgY29uY3VycmVudCByZXF1ZXN0cy4NCiA+IEl0J3MgdG9vIGhl YXZ5IGZvciBzZXJ2ZXIuIEFuZCwgdGhlIHNlcnZlciBtdXN0IGJlIHN0YXRlZnVsIGlmIGl0DQog PiBzdXBwb3J0IGdldC1ibG9jayBjYXBhYmlsaXR5Lg0KID4NCiA+DQogPiBJIGFncmVlIHdpdGgg dGhlc2UgY29uY2VybnMuICBIb2xkaW5nIGEgc25hcHNob3Qgb2Ygc3RhdGUgZGF0YSBmb3INCiA+ IGludGVyYWN0aXZlIHJldHJpZXZhbA0KID4gYnkgdGhlIGNsaWVudCBpcyB2ZXJ5IGV4cGVuc2l2 ZS4NCiA+DQogPiBJIGRvIG5vdCBhZ3JlZSB3aXRoIHRoZSBwcmVtaXNlIHRoYXQgdGhlIGNsaWVu dCBuZWVkcyB0byBrbm93IHRoZQ0KID4ga2V5IHZhbHVlcyBpbiBhZHZhbmNlLg0KID4gQW4gIml0 ZXJhdG9yIiBhcHByb2FjaCBhbGxvd3MgYSBsaXN0IHJlc291cmNlIHRvIGJlIHJldHJpZXZlZCBp bg0KID4gY2h1bmtzLiAgVGhpcyBpcyB3aGF0IFJFU1RDT05GDQogPiBpcyBnb2luZyB0byBkbywg YW5kIE5FVENPTkYgY291bGQgYWRkIGEgc2ltaWxhciBSUEMgZnVuY3Rpb246DQogPg0KID4gICAg cnBjIGdldC1saXN0IHsNCiA+ICAgICAgaW5wdXQgew0KID4gICAgICAgIGxlYWYgdGFyZ2V0IHsN CiA+ICAgICAgICAgICB0eXBlIHNjaGVtYS1pbnN0YW5jZS1pZGVudGlmaWVyOw0KID4gICAgICAg ICAgIGRlc2NyaXB0aW9uICJJZGVudGlmaWVzIHN1YnRyZWUgdG8gcmV0cmlldmUuIjsNCiA+ICAg ICAgIH0NCiA+ICAgICAgIGxlYWYgc3RhcnQgew0KID4gICAgICAgICAgdHlwZSB1aW50MzI7DQog PiAgICAgICAgICBkZWZhdWx0IDA7DQogPiAgICAgICAgICBkZXNjcmlwdGlvbiAiTnVtYmVyIG9m IGVudHJpZXMgdG8gc2tpcCBiZWZvcmUgc3RhcnRpbmcgcmV0cmlldmFsIjsNCiA+ICAgICAgIH0N CiA+ICAgICAgIGxlYWYgbWF4LWVudHJpZXMgew0KID4gICAgICAgICB0eXBlIHVpbnQzMiB7IHJh bmdlICIxLi5tYXgiOyB9DQogPiAgICAgICAgIGRlZmF1bHQgMjU7DQogPiAgICAgICAgIGRlc2Ny aXB0aW9uICJNYXhpbXVtIG51bWJlciBvZiBsaXN0IGVudHJpZXMgdG8gcmV0cmlldmUiOw0KID4g ICAgICAgfQ0KID4gICAgIH0NCiA+ICAgICBvdXRwdXQgew0KID4gICAgICAgIGFueXhtbCBkYXRh IHsNCiA+ICAgICAgICAgICBkZXNjcmlwdGlvbiAiQ29udGFpbnMgdGhlIHJlcXVlc3RlZCBkYXRh IjsNCiA+ICAgICAgICB9DQogPiAgICAgfQ0KID4gICB9DQogPg0KID4gICA8cnBjPg0KID4gICAg IDxnZXQtbGlzdD4NCiA+ICAgICAgIDx0YXJnZXQ+L2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNl PC90YXJnZXQ+DQogPiAgICAgPC9nZXQtbGlzdD4NCiA+ICAgPC9ycGM+DQogPg0KID4gICA8cnBj LXJlcGx5Pg0KID4gICAgICA8ZGF0YT4NCiA+ICAgICAgICAgPGludGVyZmFjZXM+DQogPiAgICAg ICAgICAgIDxpbnRlcmZhY2U+ICAgLi4uLiBmaXJzdCBlbnRyeSA8L2ludGVyZmFjZT4NCiA+ICAg ICAgICAgICAgLi4uDQogPiAgICAgICAgICAgIDxpbnRlcmZhY2U+ICAgLi4uLiAyNXRoIGVudHJ5 IDwvaW50ZXJmYWNlPg0KID4gICAgICAgICA8L2ludGVyZmFjZXM+DQogPiAgICAgIDwvZGF0YT4N CiA+ICAgPC9ycGMtcmVwbHk+DQogPg0KID4gICAgPHJwYz4NCiA+ICAgICA8Z2V0LWxpc3Q+DQog PiAgICAgICA8dGFyZ2V0Pi9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZTwvdGFyZ2V0Pg0KID4g ICAgICAgPHN0YXJ0PjI1PC9zdGFydD4NCiA+ICAgICA8L2dldC1saXN0Pg0KID4gICA8L3JwYz4N CiA+DQogPiAgIDxycGMtcmVwbHk+DQogPiAgICAgIDxkYXRhPg0KID4gICAgICAgICA8aW50ZXJm YWNlcz4NCiA+ICAgICAgICAgICAgPGludGVyZmFjZT4gICAuLi4uIDI2dGggZW50cnkgPC9pbnRl cmZhY2U+DQogPiAgICAgICAgICAgIC4uLg0KID4gICAgICAgICAgICA8aW50ZXJmYWNlPiAgIC4u Li4gNTB0aCBlbnRyeSA8L2ludGVyZmFjZT4NCiA+ICAgICAgICAgPC9pbnRlcmZhY2VzPg0KID4g ICAgICA8L2RhdGE+DQogPiAgIDwvcnBjLXJlcGx5Pg0KID4NCiA+IFRoZXJlIGlzIGEgcHJvYmxl bSB3aXRoIHJhcGlkbHkgY2hhbmdpbmcgbGlzdHMNCiA+IChjb3VsZCBnZXQgcmVwZWF0IGVudHJp ZXMgb24gbWlzcyBzb21lIGVudHJpZXMpLCBidXQgdGhlIHNuYXBzaG90DQogPiBhcHByb2FjaCB1 c2VzIHRvbyBtdWNoIG1lbW9yeSwgYW5kIGlmIHRoZSBsaXN0IGluc3RhbmNlcw0KID4gY2hhbmdl IHJhcGlkbHksIGEgc3RhbGUgc25hcHNob3QgaXMgbm90IHZlcnkgdXNlZnVsLg0KID4NCiA+IEFu ZHkNCiA+DQogPiBUaGUgb3RoZXIgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBhcmUgbGlzdGVkIGJl bG93Og0KID4gMS4gR2V0LWJsb2NrIGNhcGFiaWxpdHkgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIGdl dC1jb25maWcgb3BlcmF0aW9uJ3MNCiA+IGJlaGF2aW9yLiBJZiBjbGllbnQgdXNlIGdldC1jb25m aWcgb3BlcmF0aW9uIHRvIHJldHJpZXZlIGRhdGEsDQogPiBhbGwgZGF0YSBtdXN0IGJlIHNlbnQg aW4gb25lIHJlc3BvbnNlIG9yIGdldC1ibG9jayBjYXBhYmlsaXR5IHNob3VsZA0KID4gYWRkIGEg cGFyYW1ldGVyIHRvIGdldC1jb25maWcgb3BlcmF0aW9uIHRvIGluZGljYXRlIHRoZQ0KID4gcmVz cG9uc2UgZGF0YSB3aWxsIGJlIGZyYWdtZW50ZWQuDQogPiAyLiBBIHNldC1pZCBjYW4gYmUgYWdl ZD8gd2hlbiBjbGllbnQgbmV2ZXIgc2VuZCBhIHJlcXVlc3QgdG8NCiA+IHJldHJpZXZlIHRoZSBu ZXh0IGZyYWdtZW50IGZvciBhIGxvbmcgdGltZSwgSSB0aGluayB0aGlzIHNldC1pZA0KID4gc2hv dWxkIGJlIGFnZWQsDQogPiBvdGhlcndpc2UsIHNlcnZlciB3aWxsIGJlIHJlc2VydmUgbW9yZSBh bmQgbW9yZSBzZXQtaWRzLg0KID4gMy4gQSBzZXQtaWQgaXMgdW5pcXVlIGluIHNlc3Npb24gbGV2 ZWwgb3Igc2VydmVyIGxldmVsPw0KID4gNC4gSWYgYSBzZXNzaW9uIGlzIGtpbGxlZCBvciBjbG9z ZWQsIG90aGVyIHNlc3Npb24gY2FuIHJldHJpZXZlZCB0aGUNCiA+IG5leHQgZnJhZ21lbnQgaWYg dGhlIGNsaWVudCBwcm92aWRlIHRoZSBjb3JyZWN0IHNldC1pZD8NCiA+IC9mcmFuaw0KID4NCg0K ID4gMjAxNC0wNi0wNCAxODoyMiBHTVQrMDg6MDAgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdA aHVhd2VpLmNvbTxtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4+Og0KID4gSGkgYWxsLA0K ID4NCiA+IFdlJ3ZlIHBvc3RlZCBhIG5ldyBkcmFmdCwgd2hpY2ggaXMgYWJvdXQgTkVUQ09ORiBk YXRhIGZyYWdtZW50YXRpb24uDQogPg0KID4gVGhlIGJhc2ljIGlkZWEgaXMsIHdoZW4gTk1TIGlz IHJldHJpZXZpbmcgYSBsYXJnZSBzaXplIG9mIGRhdGEgaW4NCiA+IHRoZSBkZXZpY2UsIHRoZSA8 cnBjLXJlcGx5PiBtaWdodCBiZSB2ZXJ5IGJpZyAoZS5nLiB0aGUgcm91dGVzIGluIGENCiA+IGNv cmUgcm91dGVyKS4NCiA+IEN1cnJlbnRseSB0aGVyZSBhcmUgbWFpbmx5IHR3byBtZXRob2RzIG9m IGhhbmRsaW5nIHRoZSBiaWcgPHJwYy0NCiA+IHJlcGx5Pjogb25lIGlzIHN0cmVhbS1vcmllbnRl ZCBoYW5kbGluZzsgdGhlIG90aGVyIGlzIGp1c3QgcmVxdWVzdCBhDQogPiBwb3J0aW9uIG9mIHRo ZSBkYXRhLg0KID4NCiA+IFRoaXMgZHJhZnQgY29uc2lkZXJzIGJvdGggdGhlIHR3byBtZXRob2Rz IGFyZSBwcm9ibGVtYXRpYyBpbiBzb21lDQogPiBzaXR1YXRpb25zLCBhbmQgcHJvcG9zZXMgYSBu ZXcgbWV0aG9kIHdoaWNoIGFsbG93cyB0aGUgbGFyZ2Ugc2l6ZQ0KID4gPHJwYy1yZXBseT4gdG8g YmUgZnJhZ21lbnRlZCBpbiBORVRDT05GIGxldmVsLg0KID4NCiA+IFBsZWFzZSByZWFkIHRoZSBk cmFmdCBhbmQgY29tbWVudC4NCiA+IE1hbnkgdGhhbmtzIQ0KID4NCiA+IEJlc3QgcmVnYXJkcywN CiA+IEJpbmcNCiA+DQogPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KID4gRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+XQ0KID4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDA0LCAyMDE0IDU6MjcgUE0NCiA+IFRv OiBMaXViaW5nIChMZW8pOyBMaXViaW5nIChMZW8pOyBaaGVuZ2d1YW5neWluZzsgWmhlbmdndWFu Z3lpbmcNCiA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1 LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQNCiA+DQogPg0KID4gQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0DQogPiBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJpbmcgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCiA+DQogPiBOYW1lOiAgICAgICAgICAgZHJhZnQtbGl1LW5ldGNvbmYt ZnJhZ21lbnRhdGlvbg0KID4gUmV2aXNpb246ICAgICAgIDAwDQogPiBUaXRsZTogICAgICAgICAg QSBORVRDT05GIEV4dGVuc2lvbiBmb3IgRGF0YSBGcmFnbWVudGF0aW9uDQogPiBEb2N1bWVudCBk YXRlOiAgMjAxNC0wNi0wNA0KID4gR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KID4gUGFnZXM6ICAgICAgICAgIDEyDQogPiBVUkw6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS0NCiA+IG5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQN CiA+IFN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LW5l dGNvbmYtDQogPiBmcmFnbWVudGF0aW9uLw0KID4gSHRtbGl6ZWQ6IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDANCiA+DQogPg0KID4g QWJzdHJhY3Q6DQogPiAgICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYW4gZXh0ZW5zaW9uIHRv IE5FVENPTkYgKE5ldHdvcmsNCiA+ICAgIENvbmZpZ3VyYXRpb24pIHByb3RvY29sLiBUaGUgZXh0 ZW5zaW9uIGFsbG93cyBORVRDT05GIHRvIGhhbmRsZSBsYXJnZQ0KID4gICAgc2l6ZSBkYXRhIGFz IGZyYWdtZW50ZWQgUlBDIG1lc3NhZ2VzLiBTcGVjaWZpY2FsbHksIHRoaXMgZG9jdW1lbnQNCiA+ ICAgIGRlZmluZXMgYSBuZXcgPGdldC1ibG9jaz4gY2FwYWJpbGl0eSBhbmQgcmVsZXZhbnQgb3Bl cmF0aW9ucyB0bw0KID4gICAgaGFuZGxlIHRoZSBmcmFnbWVudGF0aW9ucy4NCiA+DQogPg0KID4N CiA+DQogPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZg0KID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5p ZXRmLm9yZz4NCiA+IC4NCiA+DQogPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KID4NCiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogPiBOZXRjb25mIG1h aWxpbmcgbGlzdA0KID4gTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4N CiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KID4NCiA+ DQogPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KID4g TmV0Y29uZiBtYWlsaW5nIGxpc3QNCiA+IE5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZA aWV0Zi5vcmc+DQogPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYNCg0KID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQogPiBOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRj b25mQGlldGYub3JnPg0KID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0 ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5k ZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJl IG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24s IGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBp bW1lZGlhdGVseS4NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQg dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQg aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJ ZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXBy b2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5v dGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYu b3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mDQoNCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BA902nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 = ;

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, June 05, 2014 6:42 PM
To: Bert Wijnen (IETF)
Cc: Zhengguangying; Yangang; Netconf; Netconf
Subject: Re: [Netconf] =B4= =F0=B8=B4: Re: Netconf fragmentation-//FW= : New Version Notification for draft-liu-netconf-fragmentation-00.txt<= /o:p>

 

 

=  

On Thu, Jun 5, 2014 at 1:39 AM,= Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:

= I am a bit concerned that we are now discussing a possible solution.

BUT.... I think we should first discuss on this list:

- Is the problem statement describing a real problem that we all agree with= ?

 

 

which problem? more than 1 has = been described:

 

  1) the client can get a = reply that is "too big" so it wants to ask for well-formed

      XML docume= nts that fragment the reply

 

  2) data skew can happen = across polls so the server needs to snapshot

      the reques= t and store it for the client to retrieve in pieces

 

 

= - If it is do we believe that our WG should work on a solution?<= /span>

 

no -- neither problem is import= ant enough to solve right now.

[Bing] The= =A1=B0too big reply=A1=B1 problem actually comes from real deployment requ= irement. Now there are some NMS that only provide NETCONF interface to the devices.

Especially= when the NMS also get state data from NETCONF, the big reply problem would= be highly expected. And since they only use NETCONF interface, it would be much better to solve the problem in a standard way.

 = ;

The client can use filtering to= achieve (1)

[Bing] May= I ask whether you are referring to some specific filtering or just in gene= ral?

As I under= stand, filtering mechanisms could be:

-Fo= r example, when the NMS wants to get a portion of the large amount routes, = it could filter by interface, by prefix or some other conditions. However, since real deployment scenarios varied a lot, these conditions mi= ght not be able to guarantee the result is in the expected amount. Some int= erfaces might have only a few routes, while some might still have =A1=B0too= big=A1=B1 routes data.

-Pr= ecise filtering like XPath, it might be better than above, but again it is = not be able to guarantee to get a proper amount reply. More important, XPath is so sophisticated that some devices just don=A1=AFt sup= port it. Even if it is supported, it is obviously heavier than just retriev= ing.

 = ;

So in gene= ral, I think filtering might be helpful, but it doesn=A1=AFt really solve t= he problem.

 = ;

and (2) is not practical

because of memory constraints i= n devices.

[Bing] Alt= hough now we just need to focus on the problem, I=A1=AFd like to explain a = bit more on our solution.

 = ;

Our propos= al is NOT snapshot. It doesn=A1=AFt hold the whole result in the memory, it= only holds the context (data offset .etc). When the NMS request the next block, the device could easily access to the block according to t= he context.

 = ;

 = ;

Best regar= ds,

Bing<= /o:p>

 = ;

 

Once we have agree on that, we = can decide if we want to add this topic
to our WG charter and work on it.

 

Would we be asking the IESG to = approve a new charter while so much

of the current charter remains = unfinished?

 


Bert (speaking as co-chair)

 

Andy

 


On 05/06/14 02:59, feng.chong33@zte.com.cn wrote:

= andy,
    How to process nested lists using your solution?

For example:
    list foo {
        key a;
        leaf a {...}
        leaf b {...}
        list nested-foo {
key nested-a;
leaf nested-a {...}
leaf netsted-b {...}
        }
    }

   If request is:
<rpc>
      <get-list>
        <target>/foo</target>
      </get-list>
    </rpc>
   What is the response?

And, another question:
Start-index is not reliable, if some entries are deleted. I think you can u= se start key instead.



/frank

"Netconf" <netconf-bounces@ietf.org> =D0=B4=D3=DA 2014-06-05 00:43:12:

 > Andy Bierman <andy@yumaworks.com>
 > =B7=A2=BC=FE=C8=CB:  "Netc= onf" <netconf-bounces@ietf.org>
 >
 > 2014-06-05 00:43
 >
 > =CA=D5=BC=FE=C8=CB
 >
 > chong feng <fengchongllly@gmail.com>,
 >
 > =B3=AD=CB=CD
 >
 > Zhengguangying <zhengguangying@huawei.com>, Netconf
 > <netcon= f@ietf.org>, Yangang <yangang@huawei.com>
 >
 > =D6=F7=CC=E2
 >
 > Re: [Netconf] Netconf fragmentation-//FW: New Version Notificati= on
 > for draft-liu-netconf-fragmentation-00.txt
 >
 >

 > On Wed, Jun 4, 2014 at 8:32 AM, chong feng <fengchongllly@gmail.com>= wrote:
 > Hi,
 >    I have reviewed this new draft.
 >    I understand your solution is that NETCONF server r= eserve break
 > points and wait for client to retrieve the next response.
 > I think it's not a good solution, because server may need to res= erve
 > many break points if there a large number of concurrent requests= .
 > It's too heavy for server. And, the server must be stateful if i= t
 > support get-block capability.
 >
 >
 > I agree with these concerns.  Holding a snapshot of state d= ata for
 > interactive retrieval
 > by the client is very expensive.
 >
 > I do not agree with the premise that the client needs to know th= e
 > key values in advance.
 > An "iterator" approach allows a list resource to be re= trieved in
 > chunks.  This is what RESTCONF
 > is going to do, and NETCONF could add a similar RPC function:  >
 >    rpc get-list {
 >      input {
 >        leaf target {
 >           type schema-instance-identifi= er;
 >           description "Identifies = subtree to retrieve.";
 >       }
 >       leaf start {
 >          type uint32;
 >          default 0;
 >          description "Number of en= tries to skip before starting retrieval";
 >       }
 >       leaf max-entries {
 >         type uint32 { range "1..max&quo= t;; }
 >         default 25;
 >         description "Maximum number of = list entries to retrieve";
 >       }
 >     }
 >     output {
 >        anyxml data {
 >           description "Contains th= e requested data";
 >        }
 >     }
 >   }
 >
 >   <rpc>
 >     <get-list>
 >       <target>/if:interfaces/if:interface&l= t;/target>
 >     </get-list>
 >   </rpc>
 >
 >   <rpc-reply>
 >      <data>
 >         <interfaces>
 >            <interface>  = ; .... first entry </interface>
 >            ...
 >            <interface>  = ; .... 25th entry </interface>
 >         </interfaces>
 >      </data>
 >   </rpc-reply>
 >
 >    <rpc>
 >     <get-list>
 >       <target>/if:interfaces/if:interface&l= t;/target>
 >       <start>25</start>
 >     </get-list>
 >   </rpc>
 >
 >   <rpc-reply>
 >      <data>
 >         <interfaces>
 >            <interface>  = ; .... 26th entry </interface>
 >            ...
 >            <interface>  = ; .... 50th entry </interface>
 >         </interfaces>
 >      </data>
 >   </rpc-reply>
 >
 > There is a problem with rapidly changing lists
 > (could get repeat entries on miss some entries), but the snapsho= t
 > approach uses too much memory, and if the list instances
 > change rapidly, a stale snapshot is not very useful.
 >
 > Andy
 >
 > The other questions and comments are listed below:
 > 1. Get-block capability should not change the get-config operati= on's
 > behavior. If client use get-config operation to retrieve data,  > all data must be sent in one response or get-block capability sh= ould
 > add a parameter to get-config operation to indicate the
 > response data will be fragmented.
 > 2. A set-id can be aged? when client never send a request to
 > retrieve the next fragment for a long time, I think this set-id<= br>  > should be aged,
 > otherwise, server will be reserve more and more set-ids.
 > 3. A set-id is unique in session level or server level?
 > 4. If a session is killed or closed, other session can retrieved= the
 > next fragment if the client provide the correct set-id?
 > /frank
 >

 > 2014-06-04 18:22 GMT+08:00 Liubing (Leo) <leo.liubing@huawei.com>= :
 > Hi all,
 >
 > We've posted a new draft, which is about NETCONF data fragmentat= ion.
 >
 > The basic idea is, when NMS is retrieving a large size of data i= n
 > the device, the <rpc-reply> might be very big (e.g. the ro= utes in a
 > core router).
 > Currently there are mainly two methods of handling the big <r= pc-
 > reply>: one is stream-oriented handling; the other is just re= quest a
 > portion of the data.
 >
 > This draft considers both the two methods are problematic in som= e
 > situations, and proposes a new method which allows the large siz= e
 > <rpc-reply> to be fragmented in NETCONF level.
 >
 > Please read the draft and comment.
 > Many thanks!
 >
 > Best regards,
 > Bing
 >
 > -----Original Message-----
 > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
 > Sent: Wednesday, June 04, 2014 5:27 PM
 > To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying=
 > Subject: New Version Notification for draft-liu-netconf-fragment= ation-00.txt
 >
 >
 > A new version of I-D, draft-liu-netconf-fragmentation-00.txt
 > has been successfully submitted by Bing Liu and posted to the IE= TF repository.
 >
 > Name:           draft-liu-netconf-fragm= entation
 > Revision:       00
 > Title:          A NETCONF Extension for= Data Fragmentation
 > Document date:  2014-06-04
 > Group:          Individual Submission  > Pages:          12
 > URL: http://www.ietf.org/internet-drafts/draft-liu-
 > netconf-fragmentation-00.txt
 > Status: https://datatracker.ietf.org/doc/draft-liu-netconf-
 > fragmentation/
 > Htmlized: http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00
 >
 >
 > Abstract:
 >    This document introduces an extension to NETCONF (N= etwork
 >    Configuration) protocol. The extension allows NETCO= NF to handle large
 >    size data as fragmented RPC messages. Specifically,= this document
 >    defines a new <get-block> capability and rele= vant operations to
 >    handle the fragmentations.
 >
 >
 >
 >
 > Please note that it may take a couple of minutes from the time o= f
 > submission until the htmlized version and diff are available at = tools.ietf.org
 > .
 >
 > The IETF Secretariat
 >
 > _______________________________________________
 > Netconf mailing list
 > Netconf@ie= tf.org
 > https://www.ietf.org/mailman/listinfo/netconf
 >
 >
 > _______________________________________________
 > Netconf mailing list
 > Netconf@ie= tf.org
 > https://www.ietf.org/mailman/listinfo/netconf

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


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s).  If you are not = an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the informatio= n contained is strictly prohibited.  If you have received this mail in= error, please delete it and notify us immediately.




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s).  If you are not = an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the informatio= n contained is strictly prohibited.  If you have received this mail in= error, please delete it and notify us immediately.




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

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BA902nkgeml506mbxchi_-- From nobody Fri Jun 6 03:45:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C1C1A0461 for ; Fri, 6 Jun 2014 03:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syvwgDgwgV8e for ; Fri, 6 Jun 2014 03:45:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA6A1A0132 for ; Fri, 6 Jun 2014 03:45:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX99229; Fri, 06 Jun 2014 10:44:53 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 11:43:52 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 11:44:45 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 18:44:36 +0800 From: "Liubing (Leo)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt Thread-Index: AQHPgKtsXt2eMyf30UumiXdOJ24bDZth77QAgAH3CMA= Date: Fri, 6 Jun 2014 10:44:36 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA90F@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <53902CAD.6010906@bwijnen.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA41C@nkgeml506-mbx.china.huawei.com> <20140605124214.GA11799@elstar.local> In-Reply-To: <20140605124214.GA11799@elstar.local> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/sDO7KFOVqunE-V3rAm1YvvDj2rM Cc: Zhengguangying , Yangang , Netconf Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 10:45:07 -0000 Hi Juergen, Thanks for correcting the information. We'll revise it in the next version. Nevertheless, it is not the essential problem of stream-oriented processing= . The key point is that it lacks the ability of instant termination during = the large size of data retrieving. Best regards, Bing > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, June 05, 2014 8:42 PM > To: Liubing (Leo) > Cc: Bert Wijnen (IETF); feng.chong33@zte.com.cn; Andy Bierman; > Zhengguangying; Netconf; Yangang > Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version > Notification for draft-liu-netconf-fragmentation-00.txt >=20 > On Thu, Jun 05, 2014 at 10:46:35AM +0000, Liubing (Leo) wrote: >=20 > > Another problem is the implementation. SAX is not as widely supported > > as DOM [DOM-PARSING]. For example, it is not supported by some > > existing libraries such as libxml [LIBXML]. >=20 > I think this is not correct. >=20 > http://xmlsoft.org/interface.html >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > Germany > Fax: +49 421 200 3103 From nobody Fri Jun 6 04:36:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FF71A0245 for ; Fri, 6 Jun 2014 04:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.672 X-Spam-Level: **** X-Spam-Status: No, score=4.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXSdKQNDDD4D for ; Fri, 6 Jun 2014 04:36:52 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BE81A0191 for ; Fri, 6 Jun 2014 04:36:51 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q107so4143354qgd.10 for ; Fri, 06 Jun 2014 04:36:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nU53HIFI/U4p7gzgnAH7Drkxu036W7MmkJUVxh22DpQ=; b=CnHLvK+DEtp7wSuIJSjaqqcDRa/fyvkYDLIzSh5tHi+V/ICsp7NxkuvMNWU9NtxpKB io+4WiDLg3Bn0n1U/bHK+YNZw5fIkIVqCKjRr7x1XwBMk7TgPp5TQQD5KiE8z5ZXM7BB 4mV2xItaaoi+cRj6epSEF2ulXO7B/4sJvzCH7LDRCNtxf5wdh57WF6tYFp7bwbQ1/xpw 9gH2LsRbybmgPdCgSZ7c/p1yHulrFYPS+QCO+umGO6Z/c3Jxzq3Hr7tBLimhqFBUKcz6 rWJOr8PPWsC5Vc/mF7nRUwYeLYexG+Y4f9xJPdsZGlsKptiAnfyw024NuHAZEYGxzdTT TsRw== X-Gm-Message-State: ALoCoQlLjVt+KBhfY7cLF+55v09TOSn8xYFSHQtvwD/dybFomKkzjsvur/75K4JPzlmtxt4e1jPg MIME-Version: 1.0 X-Received: by 10.140.104.204 with SMTP id a70mr6905927qgf.91.1402054604673; Fri, 06 Jun 2014 04:36:44 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Fri, 6 Jun 2014 04:36:44 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA902@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <53902CAD.6010906@bwijnen.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA902@nkgeml506-mbx.china.huawei.com> Date: Fri, 6 Jun 2014 04:36:44 -0700 Message-ID: From: Andy Bierman To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a1134f42aab064d04fb2946ae Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9_3egmh5dNycdUZ3NN7oK8xI9zI Cc: Zhengguangying , Netconf , Yangang Subject: Re: [Netconf] =?gb2312?b?tPC4tDogUmU6IE5ldGNvbmYgZnJhZ21lbnRhdGlvbi0v?= =?gb2312?b?L0ZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1u?= =?gb2312?b?ZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 11:36:56 -0000 --001a1134f42aab064d04fb2946ae Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Fri, Jun 6, 2014 at 3:41 AM, Liubing (Leo) wrote: > Hi Andy, > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Thursday, June 05, 2014 6:42 PM > *To:* Bert Wijnen (IETF) > *Cc:* Zhengguangying; Yangang; Netconf; Netconf > *Subject:* Re: [Netconf] =B4=F0=B8=B4: Re: Netconf fragmentation-//FW: Ne= w Version > Notification for draft-liu-netconf-fragmentation-00.txt > > > > > > > > On Thu, Jun 5, 2014 at 1:39 AM, Bert Wijnen (IETF) > wrote: > > I am a bit concerned that we are now discussing a possible solution. > > BUT.... I think we should first discuss on this list: > > - Is the problem statement describing a real problem that we all agree > with? > > > > > > which problem? more than 1 has been described: > > > > 1) the client can get a reply that is "too big" so it wants to ask for > well-formed > > XML documents that fragment the reply > > > > 2) data skew can happen across polls so the server needs to snapshot > > the request and store it for the client to retrieve in pieces > > > > > > - If it is do we believe that our WG should work on a solution? > > > > no -- neither problem is important enough to solve right now. > > [Bing] The =A1=B0too big reply=A1=B1 problem actually comes from real dep= loyment > requirement. Now there are some NMS that only provide NETCONF interface t= o > the devices. > > Especially when the NMS also get state data from NETCONF, the big reply > problem would be highly expected. And since they only use NETCONF > interface, it would be much better to solve the problem in a standard way= . > > > the current standard supports subtree and XPath filtering. Learn how to use them. The client can use filtering to achieve (1) > > [Bing] May I ask whether you are referring to some specific filtering or > just in general? > > As I understand, filtering mechanisms could be: > > - For example, when the NMS wants to get a portion of the large > amount routes, it could filter by interface, by prefix or some other > conditions. However, since real deployment scenarios varied a lot, these > conditions might not be able to guarantee the result is in the expected > amount. Some interfaces might have only a few routes, while some might > still have =A1=B0too big=A1=B1 routes data. > > - Precise filtering like XPath, it might be better than above, but > again it is not be able to guarantee to get a proper amount reply. More > important, XPath is so sophisticated that some devices just don=A1=AFt su= pport > it. Even if it is supported, it is obviously heavier than just retrieving= . > I think XPath works well enough. Iterate over the list you care about. Retrieve the entire list at once and it might be too big. > > > So in general, I think filtering might be helpful, but it doesn=A1=AFt re= ally > solve the problem. > > > > and (2) is not practical > > because of memory constraints in devices. > > [Bing] Although now we just need to focus on the problem, I=A1=AFd like t= o > explain a bit more on our solution. > > > > Our proposal is NOT snapshot. It doesn=A1=AFt hold the whole result in th= e > memory, it only holds the context (data offset .etc). When the NMS reques= t > the next block, the device could easily access to the block according to > the context. > > In that case, your solution suffers all the data skew problems as if the client held the state, and none of the benefits. The server has the same problems remembering its place in constantly changing state as the client. > > > > Best regards, > > Bing > > > Andy > > > Once we have agree on that, we can decide if we want to add this topic > to our WG charter and work on it. > > > > Would we be asking the IESG to approve a new charter while so much > > of the current charter remains unfinished? > > > > > Bert (speaking as co-chair) > > > > Andy > > > > > On 05/06/14 02:59, feng.chong33@zte.com.cn wrote: > > andy, > How to process nested lists using your solution? > > For example: > list foo { > key a; > leaf a {...} > leaf b {...} > list nested-foo { > key nested-a; > leaf nested-a {...} > leaf netsted-b {...} > } > } > > If request is: > > > /foo > > > What is the response? > > And, another question: > Start-index is not reliable, if some entries are deleted. I think you can > use start key instead. > > > > /frank > > "Netconf" =D0=B4=D3=DA 2014-06-05 00:43:12: > > > Andy Bierman > > =B7=A2=BC=FE=C8=CB: "Netconf" > > > > 2014-06-05 00:43 > > > > =CA=D5=BC=FE=C8=CB > > > > chong feng , > > > > =B3=AD=CB=CD > > > > Zhengguangying , Netconf > > , Yangang > > > > =D6=F7=CC=E2 > > > > Re: [Netconf] Netconf fragmentation-//FW: New Version Notification > > for draft-liu-netconf-fragmentation-00.txt > > > > > > > On Wed, Jun 4, 2014 at 8:32 AM, chong feng > wrote: > > Hi, > > I have reviewed this new draft. > > I understand your solution is that NETCONF server reserve break > > points and wait for client to retrieve the next response. > > I think it's not a good solution, because server may need to reserve > > many break points if there a large number of concurrent requests. > > It's too heavy for server. And, the server must be stateful if it > > support get-block capability. > > > > > > I agree with these concerns. Holding a snapshot of state data for > > interactive retrieval > > by the client is very expensive. > > > > I do not agree with the premise that the client needs to know the > > key values in advance. > > An "iterator" approach allows a list resource to be retrieved in > > chunks. This is what RESTCONF > > is going to do, and NETCONF could add a similar RPC function: > > > > rpc get-list { > > input { > > leaf target { > > type schema-instance-identifier; > > description "Identifies subtree to retrieve."; > > } > > leaf start { > > type uint32; > > default 0; > > description "Number of entries to skip before starting > retrieval"; > > } > > leaf max-entries { > > type uint32 { range "1..max"; } > > default 25; > > description "Maximum number of list entries to retrieve"; > > } > > } > > output { > > anyxml data { > > description "Contains the requested data"; > > } > > } > > } > > > > > > > > /if:interfaces/if:interface > > > > > > > > > > > > > > .... first entry > > ... > > .... 25th entry > > > > > > > > > > > > > > /if:interfaces/if:interface > > 25 > > > > > > > > > > > > > > .... 26th entry > > ... > > .... 50th entry > > > > > > > > > > There is a problem with rapidly changing lists > > (could get repeat entries on miss some entries), but the snapshot > > approach uses too much memory, and if the list instances > > change rapidly, a stale snapshot is not very useful. > > > > Andy > > > > The other questions and comments are listed below: > > 1. Get-block capability should not change the get-config operation's > > behavior. If client use get-config operation to retrieve data, > > all data must be sent in one response or get-block capability should > > add a parameter to get-config operation to indicate the > > response data will be fragmented. > > 2. A set-id can be aged? when client never send a request to > > retrieve the next fragment for a long time, I think this set-id > > should be aged, > > otherwise, server will be reserve more and more set-ids. > > 3. A set-id is unique in session level or server level? > > 4. If a session is killed or closed, other session can retrieved the > > next fragment if the client provide the correct set-id? > > /frank > > > > > 2014-06-04 18:22 GMT+08:00 Liubing (Leo) : > > Hi all, > > > > We've posted a new draft, which is about NETCONF data fragmentation. > > > > The basic idea is, when NMS is retrieving a large size of data in > > the device, the might be very big (e.g. the routes in a > > core router). > > Currently there are mainly two methods of handling the big > reply>: one is stream-oriented handling; the other is just request a > > portion of the data. > > > > This draft considers both the two methods are problematic in some > > situations, and proposes a new method which allows the large size > > to be fragmented in NETCONF level. > > > > Please read the draft and comment. > > Many thanks! > > > > Best regards, > > Bing > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, June 04, 2014 5:27 PM > > To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying > > Subject: New Version Notification for > draft-liu-netconf-fragmentation-00.txt > > > > > > A new version of I-D, draft-liu-netconf-fragmentation-00.txt > > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > > > Name: draft-liu-netconf-fragmentation > > Revision: 00 > > Title: A NETCONF Extension for Data Fragmentation > > Document date: 2014-06-04 > > Group: Individual Submission > > Pages: 12 > > URL: http://www.ietf.org/internet-drafts/draft-liu- > > netconf-fragmentation-00.txt > > Status: https://datatracker.ietf.org/doc/draft-liu-netconf- > > fragmentation/ > > Htmlized: http://tools.ietf.org/html/draft-liu-netconf-fragmentation-0= 0 > > > > > > Abstract: > > This document introduces an extension to NETCONF (Network > > Configuration) protocol. The extension allows NETCONF to handle lar= ge > > size data as fragmented RPC messages. Specifically, this document > > defines a new capability and relevant operations to > > handle the fragmentations. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org > > . > > > > The IETF Secretariat > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail > (and any attachment transmitted herewith) is privileged and confidential > and is intended for the exclusive use of the addressee(s). If you are no= t > an intended recipient, any disclosure, reproduction, distribution or othe= r > dissemination or use of the information contained is strictly prohibited. > If you have received this mail in error, please delete it and notify us > immediately. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail > (and any attachment transmitted herewith) is privileged and confidential > and is intended for the exclusive use of the addressee(s). If you are no= t > an intended recipient, any disclosure, reproduction, distribution or othe= r > dissemination or use of the information contained is strictly prohibited. > If you have received this mail in error, please delete it and notify us > immediately. > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --001a1134f42aab064d04fb2946ae Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable --001a1134f42aab064d04fb2946ae-- From nobody Fri Jun 6 11:43:38 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0B61A021E for ; Fri, 6 Jun 2014 11:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.172 X-Spam-Level: * X-Spam-Status: No, score=1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cWu-TZP1NkE for ; Fri, 6 Jun 2014 11:43:36 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03BC1A021C for ; Fri, 6 Jun 2014 11:43:35 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id j5so5327426qga.28 for ; Fri, 06 Jun 2014 11:43:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z/ruJ7+hXXL2zIGB7v8ziQtm40DvbWfpRMN/YnDoZQY=; b=ETLjG68odYqN/EL1TkpErSM0Tvc2h86RcscTq0C/sdMlN34kwuwSG+n3HqzhLp+jx8 949gic+19M3g2kFohSWf/RFrP9LFzA5P8vtfh1YG/oiEg8o1kIu4cpNC/3OwKjiSMkNw 9AeNqWIFKhT7YGO0m1Gpwwwcq8aJUO20FjADtO2N5lUR3zkmyXXk083v4dvEEUZxatJm sp3HWnVRgDGQKcpYt91goJNIGxtulqSbODPxPO1fqStQSY1/nndkQAL142+UVAcQRmf9 gxJ6/96Kelfxgatryy7892g7fSdsATNTgCTg9qp/EDnfGI/edaGjzOGsqE+JzVs0EkxA Fi4A== X-Gm-Message-State: ALoCoQnLlCS6G4Ky2rYVN9XkEAIcWBpjf+hjHFMaRO2tO+h5OqB04P9po+bFCjDv7Vl4bcP1JD6m MIME-Version: 1.0 X-Received: by 10.224.24.134 with SMTP id v6mr11777960qab.88.1402080208330; Fri, 06 Jun 2014 11:43:28 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Fri, 6 Jun 2014 11:43:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jun 2014 11:43:28 -0700 Message-ID: From: Andy Bierman To: feng.chong33@zte.com.cn Content-Type: multipart/alternative; boundary=001a11c252c6c3d00104fb2f3cc7 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dTP_1i2z72Vt8AH8QJ1E9KlXJx0 Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 18:43:37 -0000 --001a11c252c6c3d00104fb2f3cc7 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Thu, Jun 5, 2014 at 11:18 PM, wrote: > andy, > Thanks a lot. > Can you answer the first question? 'replace' can be used as 'remove'? > Read RFC 6241, sec. 7.2 Attributes section. It explains the difference between the NETCONF operations. > /frank > Andy > > Andy Bierman =D0=B4=D3=DA 2014-06-05 23:46:53: > > > Andy Bierman > > 2014-06-05 23:46 > > > > =CA=D5=BC=FE=C8=CB > > > > feng.chong33@zte.com.cn, > > > > =B3=AD=CB=CD > > > > Netconf , ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, > > xiao.yuqing@zte.com.cn > > > > =D6=F7=CC=E2 > > > > Re: [Netconf] Some questions about the usage of 'operation' > > attribute in edit-config > > > > > > > On Wed, Jun 4, 2014 at 6:35 PM, wrote: > > Hi all, > > I have some questions about the usage of 'operation' attribute > > in edit-config. > > 1. 'replace' attribute can only be used to remove configuration? > > For example, the rpc request listed below is valid? > > > > > > > > > > > > > > > > > > > > > > > > > > 2.How to process nested operation attribute? > > For example: > > > > > > > > > > > > > > > > > > eth0/0/0 > > > > true > > > > > > > > > > > > > > The sequence of process is merge interface name 'eth0/0/0' and > > remove mtu and merge enabled to 'true' > > or merge interface name 'eth0/0/0' and > > merge enabled to 'true' and remove mtu? > > In other words, NETCONF will process outer layer operation > > firstly and process inner layer operation later, or process > > operations in accordance with XML tree traversal order? > > > > > > There is no required processing order. > > It is an implementation detail. > > Some things to consider: > > 1) all operations are against the target datastore at the start of > > the operation > > 2) the operations are all-or-none, not incremental > > 2a) this implies that create within delete, or delete within > > create, is always an error > > because 'data-exists' or 'data-missing' must be true > > > > In your example there is no problem because 'remove' works even if > > the data is missing. > > > > > > > > 3. If other operation attribute nested in operation attribute > > 'remove',what should NETCONF server do? Only process remove operation? > > > > 4. Can NETCONF support the nested operation attribute equals to > > parent operation attribute? > > > > /frank > > > > Andy > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail (and any attachment transmitted herewith) is privileged and > > confidential and is intended for the exclusive use of the addressee > > (s). If you are not an intended recipient, any disclosure, > > reproduction, distribution or other dissemination or use of the > > information contained is strictly prohibited. If you have received > > this mail in error, please delete it and notify us immediately. > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > --001a11c252c6c3d00104fb2f3cc7 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 5, 2014 at 11:18 PM, <feng.chong33@zte.com.cn> wrote:
andy,
   Thanks a lot.
   Can you answer the first question? 'replace' can be used as 'remove'?

Read RFC 6241, sec. 7.2 Attributes sec= tion.
It explains the difference between the NETCONF <edit-con= fig> operations.

 
/frank

Andy
 

Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-05 23:46:53:

> Andy Bierman <andy@yumaworks.com>
> 2014-06-05 23:46
>
> =CA=D5=BC=FE=C8=CB
>
> feng.chon= g33@zte.com.cn,
>
> =B3=AD=CB=CD
>
> Netconf <netc= onf@ietf.org>, ye.xu1@zte.com.cn, dou.wei1@zte.com.cn,
> xiao.yuqin= g@zte.com.cn
>
> =D6=F7=CC=E2
>
> Re: [Netconf] Some questions about the usage of 'operation' > attribute in edit-config
>
>

> On Wed, Jun 4, 2014 at 6:35 PM, <feng.chong33@zte.com.cn> wrote:
> Hi all,
>    I have some questions about the usage of  'opera= tion' attribute
> in edit-config.
>    1. 'replace' attribute can only be used to remove= configuration?
>       For example, the rpc request listed below is valid?
>       <rpc message-id =3D "101">
>            <edit-config>
>                <target>
>                   <run= ning/>
>                </target>
>                <config>
>                   <int= erfaces operation=3D "replace"/>
>                </config>
>            </edit-config>
>       </rpc>
>
>
>    2.How to process nested operation attribute?
>      For example:
>            <rpc message-id =3D "= 101">
>            <edit-config>
>                <target>
>                   <run= ning/>
>                </target>
>                <config>
>                   <int= erfaces>
>                       <interface operation=3D "merge">
>                            <name>eth0/0/0</name>
>                            <mtu operation=3D "remove">
>                            <enabled>true</enalbled>
>                       </interface>
>                   </in= terfaces>
>                </config>
>            </edit-config>
>       </rpc>
>
>      The sequence of process is merge interface name 'eth0/0/0' and
> remove mtu and merge enabled to 'true'
>                              or merge interface name 'eth0/0/0'= ; and
> merge enabled to 'true' and remove mtu?
>      In other words, NETCONF will process outer layer operation
> firstly and process inner layer operation later, or process
> operations in accordance with XML tree traversal order?
>  
>
> There is no required processing order.
> It is an implementation detail.
> Some things to consider:
>   1) all operations are against the target datastore at the start of
> the operation
>   2) the operations are all-or-none, not incremental
>   2a) this implies that create within delete, or delete within
> create, is always an error
>        because 'data-exists' or 'data-missing' must be true
>
> In your example there is no problem because 'remove' works eve= n if
> the data is missing.
>
>         
>
> 3. If other operation attribute nested in operation attribute
> 'remove',what should NETCONF server do? Only process remove op= eration?
>
>   4. Can NETCONF support the nested operation attribute equals to
> parent operation attribute?
>      
> /frank
>
> Andy
>  
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail (and any attachment transmitted herewith) is privileged and
> confidential and is intended for the exclusive use of the addressee > (s).  If you are not an intended recipient, any disclosure,
> reproduction, distribution or other dissemination or use of the
> information contained is strictly prohibited.  If you have receiv= ed
> this mail in error, please delete it and notify us immediately.
>

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


--001a11c252c6c3d00104fb2f3cc7-- From nobody Sun Jun 8 18:19:02 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDFE1B2793 for ; Sun, 8 Jun 2014 18:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.8 X-Spam-Level: X-Spam-Status: No, score=-96.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDriMDGN_V0S for ; Sun, 8 Jun 2014 18:18:58 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id F0AAC1B278C for ; Sun, 8 Jun 2014 18:18:55 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id B5DEA193BAD6 for ; Mon, 9 Jun 2014 09:18:45 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 85B71CD083C; Mon, 9 Jun 2014 09:18:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s591IYHc095926; Mon, 9 Jun 2014 09:18:34 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: References: To: Andy Bierman MIME-Version: 1.0 X-KeepSent: 9F315E00:DA6F422E-48257CF2:000663AF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Mon, 9 Jun 2014 09:18:32 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-09 09:18:35, Serialize complete at 2014-06-09 09:18:35 Content-Type: multipart/alternative; boundary="=_alternative 0007308B48257CF2_=" X-MAIL: mse01.zte.com.cn s591IYHc095926 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/X7BoNuS0WZHlWHhnu4AegKZ3myI Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 01:19:01 -0000 This is a multipart message in MIME format. --=_alternative 0007308B48257CF2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QW5keaOsDQogICAgSSBoYXZlIGxvb2tlZCB0aHJvdWdoIHRoaXMgc2VjdGlvbiBmb3IgbWFueSB0 aW1lcy4gSW4gbXkgb3BpbmlvbiwgSSANCnRoaW5rDQp0aGUgZWxlbWVudCBjb250YWlucyBhdHRy aWJ1dGUgJ3JlcGxhY2UnIG11c3QgaGF2ZSBzdWJ0cmVlLCBhbmQgdGhpcyANCnN1YnRyZWUgDQpz aG91bGQgYmUgYSB2YWxpZCBjb25maWd1cmF0aW9uLiBCdXQgbXkgY29sbGVhZ3VlcyBkb24ndCB0 aGluayBzbywgdGhleSANCmFyZ3VlZA0KdGhhdCB0aGUgZW1wdHkgY29uZmlndXJhdGlvbiBpcyBh bHNvIGNvbmZpZ3VyYXRpb24sIHRoZXkgd2FudCB0byB1c2UgDQoncmVwbGFjZScNCmFzICdyZW1v dmUnLCBJIGNhbid0IHBlcnN1YWRlIHRoZW0sIDopDQogICAgU28sSSB3YW50IHRvIGdldCBhIGNs YXJpZmljYXRpb24sIHRoYW5rcy4NCi9mcmFuaw0KDQpBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbT4g0LTT2iAyMDE0LTA2LTA3IDAyOjQzOjI4Og0KDQo+IEFuZHkgQmllcm1hbiA8YW5k eUB5dW1hd29ya3MuY29tPiANCj4gMjAxNC0wNi0wNyAwMjo0Mw0KPiANCj4gytW8/sjLDQo+IA0K PiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgDQo+IA0KPiCzrcvNDQo+IA0KPiBkb3Uud2VpMUB6 dGUuY29tLmNuLCBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgDQo+IHhpYW8ueXVxaW5nQHp0 ZS5jb20uY24sIHllLnh1MUB6dGUuY29tLmNuDQo+IA0KPiDW98ziDQo+IA0KPiBSZTogW05ldGNv bmZdIFNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyANCj4gYXR0 cmlidXRlIGluIGVkaXQtY29uZmlnDQo+IA0KPiANCg0KPiBPbiBUaHUsIEp1biA1LCAyMDE0IGF0 IDExOjE4IFBNLCA8ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24+IHdyb3RlOg0KPiBhbmR5LCANCj4g ICAgVGhhbmtzIGEgbG90LiANCj4gICAgQ2FuIHlvdSBhbnN3ZXIgdGhlIGZpcnN0IHF1ZXN0aW9u PyAncmVwbGFjZScgY2FuIGJlIHVzZWQgYXMgJ3JlbW92ZSc/IA0KDQo+IA0KPiBSZWFkIFJGQyA2 MjQxLCBzZWMuIDcuMiBBdHRyaWJ1dGVzIHNlY3Rpb24uDQo+IEl0IGV4cGxhaW5zIHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gdGhlIE5FVENPTkYgPGVkaXQtY29uZmlnPiBvcGVyYXRpb25zLg0KPiAN Cj4gDQo+IC9mcmFuayANCj4gDQo+IEFuZHkNCj4gDQo+IA0KPiBBbmR5IEJpZXJtYW4gPGFuZHlA eXVtYXdvcmtzLmNvbT4g0LTT2iAyMDE0LTA2LTA1IDIzOjQ2OjUzOg0KPiANCj4gPiBBbmR5IEJp ZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gDQo+ID4gMjAxNC0wNi0wNSAyMzo0NiANCj4gPiAN Cj4gPiDK1bz+yMsgDQo+ID4gDQo+ID4gZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIA0KPiA+IA0K PiA+ILOty80gDQo+ID4gDQo+ID4gTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4sIHllLnh1MUB6 dGUuY29tLmNuLCBkb3Uud2VpMUB6dGUuY29tLmNuLCANCj4gPiB4aWFvLnl1cWluZ0B6dGUuY29t LmNuIA0KPiA+IA0KPiA+INb3zOIgDQo+ID4gDQo+ID4gUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0 aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgDQo+ID4gYXR0cmlidXRlIGluIGVk aXQtY29uZmlnIA0KPiA+IA0KPiA+IA0KPiANCj4gPiBPbiBXZWQsIEp1biA0LCAyMDE0IGF0IDY6 MzUgUE0sIDxmZW5nLmNob25nMzNAenRlLmNvbS5jbj4gd3JvdGU6IA0KPiA+IEhpIGFsbCwgDQo+ ID4gICAgSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAgJ29wZXJhdGlv bicgYXR0cmlidXRlIA0KPiA+IGluIGVkaXQtY29uZmlnLiANCj4gPiAgICAxLiAncmVwbGFjZScg YXR0cmlidXRlIGNhbiBvbmx5IGJlIHVzZWQgdG8gcmVtb3ZlIGNvbmZpZ3VyYXRpb24/IA0KPiA+ ICAgICAgIEZvciBleGFtcGxlLCB0aGUgcnBjIHJlcXVlc3QgbGlzdGVkIGJlbG93IGlzIHZhbGlk PyANCj4gPiAgICAgICA8cnBjIG1lc3NhZ2UtaWQgPSAiMTAxIj4gDQo+ID4gICAgICAgICAgICA8 ZWRpdC1jb25maWc+IA0KPiA+ICAgICAgICAgICAgICAgIDx0YXJnZXQ+IA0KPiA+ICAgICAgICAg ICAgICAgICAgIDxydW5uaW5nLz4gDQo+ID4gICAgICAgICAgICAgICAgPC90YXJnZXQ+IA0KPiA+ ICAgICAgICAgICAgICAgIDxjb25maWc+IA0KPiA+ICAgICAgICAgICAgICAgICAgIDxpbnRlcmZh Y2VzIG9wZXJhdGlvbj0gInJlcGxhY2UiLz4gDQo+ID4gICAgICAgICAgICAgICAgPC9jb25maWc+ IA0KPiA+ICAgICAgICAgICAgPC9lZGl0LWNvbmZpZz4gDQo+ID4gICAgICAgPC9ycGM+IA0KPiA+ IA0KPiA+IA0KPiA+ICAgIDIuSG93IHRvIHByb2Nlc3MgbmVzdGVkIG9wZXJhdGlvbiBhdHRyaWJ1 dGU/IA0KPiA+ICAgICAgRm9yIGV4YW1wbGU6IA0KPiA+ICAgICAgICAgICAgPHJwYyBtZXNzYWdl LWlkID0gIjEwMSI+IA0KPiA+ICAgICAgICAgICAgPGVkaXQtY29uZmlnPiANCj4gPiAgICAgICAg ICAgICAgICA8dGFyZ2V0PiANCj4gPiAgICAgICAgICAgICAgICAgICA8cnVubmluZy8+IA0KPiA+ ICAgICAgICAgICAgICAgIDwvdGFyZ2V0PiANCj4gPiAgICAgICAgICAgICAgICA8Y29uZmlnPiAN Cj4gPiAgICAgICAgICAgICAgICAgICA8aW50ZXJmYWNlcz4gDQo+ID4gICAgICAgICAgICAgICAg ICAgICAgIDxpbnRlcmZhY2Ugb3BlcmF0aW9uPSAibWVyZ2UiPiANCj4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8bmFtZT5ldGgwLzAvMDwvbmFtZT4gDQo+ID4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgPG10dSBvcGVyYXRpb249ICJyZW1vdmUiPiANCj4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8ZW5hYmxlZD50cnVlPC9lbmFsYmxlZD4gDQo+ID4gICAgICAgICAgICAg ICAgICAgICAgIDwvaW50ZXJmYWNlPiANCj4gPiAgICAgICAgICAgICAgICAgICA8L2ludGVyZmFj ZXM+IA0KPiA+ICAgICAgICAgICAgICAgIDwvY29uZmlnPiANCj4gPiAgICAgICAgICAgIDwvZWRp dC1jb25maWc+IA0KPiA+ICAgICAgIDwvcnBjPiANCj4gPiANCj4gPiAgICAgIFRoZSBzZXF1ZW5j ZSBvZiBwcm9jZXNzIGlzIG1lcmdlIGludGVyZmFjZSBuYW1lICdldGgwLzAvMCcgYW5kIA0KPiA+ IHJlbW92ZSBtdHUgYW5kIG1lcmdlIGVuYWJsZWQgdG8gJ3RydWUnIA0KPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgb3IgbWVyZ2UgaW50ZXJmYWNlIG5hbWUgJ2V0aDAvMC8wJyBhbmQg DQo+ID4gbWVyZ2UgZW5hYmxlZCB0byAndHJ1ZScgYW5kIHJlbW92ZSBtdHU/IA0KPiA+ICAgICAg SW4gb3RoZXIgd29yZHMsIE5FVENPTkYgd2lsbCBwcm9jZXNzIG91dGVyIGxheWVyIG9wZXJhdGlv biANCj4gPiBmaXJzdGx5IGFuZCBwcm9jZXNzIGlubmVyIGxheWVyIG9wZXJhdGlvbiBsYXRlciwg b3IgcHJvY2VzcyANCj4gPiBvcGVyYXRpb25zIGluIGFjY29yZGFuY2Ugd2l0aCBYTUwgdHJlZSB0 cmF2ZXJzYWwgb3JkZXI/IA0KPiA+IA0KPiA+IA0KPiA+IFRoZXJlIGlzIG5vIHJlcXVpcmVkIHBy b2Nlc3Npbmcgb3JkZXIuIA0KPiA+IEl0IGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4gDQo+ ID4gU29tZSB0aGluZ3MgdG8gY29uc2lkZXI6IA0KPiA+ICAgMSkgYWxsIG9wZXJhdGlvbnMgYXJl IGFnYWluc3QgdGhlIHRhcmdldCBkYXRhc3RvcmUgYXQgdGhlIHN0YXJ0IG9mDQo+ID4gdGhlIG9w ZXJhdGlvbiANCj4gPiAgIDIpIHRoZSBvcGVyYXRpb25zIGFyZSBhbGwtb3Itbm9uZSwgbm90IGlu Y3JlbWVudGFsIA0KPiA+ICAgMmEpIHRoaXMgaW1wbGllcyB0aGF0IGNyZWF0ZSB3aXRoaW4gZGVs ZXRlLCBvciBkZWxldGUgd2l0aGluIA0KPiA+IGNyZWF0ZSwgaXMgYWx3YXlzIGFuIGVycm9yIA0K PiA+ICAgICAgICBiZWNhdXNlICdkYXRhLWV4aXN0cycgb3IgJ2RhdGEtbWlzc2luZycgbXVzdCBi ZSB0cnVlIA0KPiA+IA0KPiA+IEluIHlvdXIgZXhhbXBsZSB0aGVyZSBpcyBubyBwcm9ibGVtIGJl Y2F1c2UgJ3JlbW92ZScgd29ya3MgZXZlbiBpZiANCj4gPiB0aGUgZGF0YSBpcyBtaXNzaW5nLiAN Cj4gPiANCj4gPiANCj4gPiANCj4gPiAzLiBJZiBvdGhlciBvcGVyYXRpb24gYXR0cmlidXRlIG5l c3RlZCBpbiBvcGVyYXRpb24gYXR0cmlidXRlIA0KPiA+ICdyZW1vdmUnLHdoYXQgc2hvdWxkIE5F VENPTkYgc2VydmVyIGRvPyBPbmx5IHByb2Nlc3MgcmVtb3ZlIG9wZXJhdGlvbj8gDQoNCj4gPiAN Cj4gPiAgIDQuIENhbiBORVRDT05GIHN1cHBvcnQgdGhlIG5lc3RlZCBvcGVyYXRpb24gYXR0cmli dXRlIGVxdWFscyB0byANCj4gPiBwYXJlbnQgb3BlcmF0aW9uIGF0dHJpYnV0ZT8gDQo+ID4gDQo+ ID4gL2ZyYW5rIA0KPiA+IA0KPiA+IEFuZHkgDQo+ID4gDQo+ID4gDQo+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgDQo+ID4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp cyBwcml2aWxlZ2VkIGFuZCANCj4gPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+ID4gKHMpLiAgSWYgeW91IGFyZSBu b3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+ID4gcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0K PiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgDQo+ID4gdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0 IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+ID4gDQo+IA0KPiA+IA0KPiA+IA0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTmV0Y29u ZiBtYWlsaW5nIGxpc3QNCj4gPiBOZXRjb25mQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyANCj4g bWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxl Z2VkIGFuZCANCj4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRl ZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiBpbmZvcm1hdGlvbiBj b250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0K PiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1l ZGlhdGVseS4NCj4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5z bWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGlu dGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91 IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkg dXMgaW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFu c21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBp bnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlv dSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVj dGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5 IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 0007308B48257CF2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuZHmjrDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBJIGhhdmUgbG9va2VkIHRocm91 Z2gNCnRoaXMgc2VjdGlvbiBmb3IgbWFueSB0aW1lcy4gSW4gbXkgb3BpbmlvbiwgSSB0aGluazwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIGVsZW1lbnQgY29u dGFpbnMgYXR0cmlidXRlICdyZXBsYWNlJw0KbXVzdCBoYXZlIHN1YnRyZWUsIGFuZCB0aGlzIHN1 YnRyZWUgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zaG91bGQg YmUgYSB2YWxpZCBjb25maWd1cmF0aW9uLiBCdXQNCm15IGNvbGxlYWd1ZXMgZG9uJ3QgdGhpbmsg c28sIHRoZXkgYXJndWVkPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij50aGF0IHRoZSBlbXB0eSBjb25maWd1cmF0aW9uIGlzIGFsc28NCmNvbmZpZ3VyYXRpb24sIHRo ZXkgd2FudCB0byB1c2UgJ3JlcGxhY2UnPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5hcyAncmVtb3ZlJywgSSBjYW4ndCBwZXJzdWFkZSB0aGVtLA0KOik8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgU28sSSB3 YW50IHRvIGdldCBhIGNsYXJpZmljYXRpb24sDQp0aGFua3MuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4vZnJhbms8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5BbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsg0LTT2iAyMDE0 LTA2LTA3DQowMjo0MzoyODo8YnI+DQo8YnI+DQomZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5 dW1hd29ya3MuY29tJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg MjAxNC0wNi0wNyAwMjo0MzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8 YnI+DQomZ3Q7IMrVvP7IyzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8 YnI+DQomZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgZG91LndlaTFAenRlLmNvbS5jbiwgTmV0Y29uZiAm bHQ7bmV0Y29uZkBpZXRmLm9yZyZndDssIDxicj4NCiZndDsgeGlhby55dXFpbmdAenRlLmNvbS5j biwgeWUueHUxQHp0ZS5jb20uY248L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgPGJyPg0KJmd0OyDW98ziPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IDxicj4NCiZndDsgUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ug b2YgJ29wZXJhdGlvbicgPGJyPg0KJmd0OyBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWc8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgT24gVGh1LCBKdW4gNSwgMjAxNCBhdCAx MToxOCBQTSwgJmx0O2ZlbmcuY2hvbmczM0B6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGFuZHksIDxicj4NCiZndDsgJm5ic3A7ICZu YnNwO1RoYW5rcyBhIGxvdC4gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Q2FuIHlvdSBhbnN3ZXIg dGhlIGZpcnN0IHF1ZXN0aW9uPyAncmVwbGFjZScgY2FuIGJlIHVzZWQNCmFzICdyZW1vdmUnPyA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBSZWFkIFJG QyA2MjQxLCBzZWMuIDcuMiBBdHRyaWJ1dGVzIHNlY3Rpb24uPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IEl0IGV4cGxhaW5zIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhl IE5FVENPTkYNCiZsdDtlZGl0LWNvbmZpZyZndDsgb3BlcmF0aW9ucy48L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgL2ZyYW5rIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEFuZHk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IDxicj4NCiZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7INC009og MjAxNC0wNi0wNSAyMzo0Njo1Mzo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBBbmR5IEJpZXJt YW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7IDIwMTQtMDYtMDUg MjM6NDYgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDK1bz+yMsgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyCzrcvNIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg TmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDssIHllLnh1MUB6dGUuY29tLmNuLCBkb3Uu d2VpMUB6dGUuY29tLmNuLA0KPGJyPg0KJmd0OyAmZ3Q7IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24g PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDW98ziIDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ug b2YgJ29wZXJhdGlvbicgPGJyPg0KJmd0OyAmZ3Q7IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZpZyA8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7 IE9uIFdlZCwgSnVuIDQsIDIwMTQgYXQgNjozNSBQTSwgJmx0O2ZlbmcuY2hvbmczM0B6dGUuY29t LmNuJmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyBIaSBhbGwsIDxicj4NCiZndDsgJmd0OyAm bmJzcDsgJm5ic3A7SSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAmbmJz cDsnb3BlcmF0aW9uJw0KYXR0cmlidXRlIDxicj4NCiZndDsgJmd0OyBpbiBlZGl0LWNvbmZpZy4g PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsxLiAncmVwbGFjZScgYXR0cmlidXRlIGNhbiBv bmx5IGJlIHVzZWQgdG8gcmVtb3ZlDQpjb25maWd1cmF0aW9uPyA8YnI+DQomZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgRm9yIGV4YW1wbGUsIHRoZSBycGMgcmVxdWVzdCBsaXN0ZWQgYmVs b3cNCmlzIHZhbGlkPyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3Jw YyBtZXNzYWdlLWlkID0gJnF1b3Q7MTAxJnF1b3Q7Jmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2VkaXQtY29uZmlnJmd0Ow0K PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7dGFyZ2V0Jmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombHQ7 cnVubmluZy8mZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy90YXJnZXQmZ3Q7DQo8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZsdDtjb25maWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZsdDtpbnRlcmZhY2VzIG9w ZXJhdGlvbj0gJnF1b3Q7cmVwbGFjZSZxdW90Oy8mZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9jb25m aWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmbHQ7L2VkaXQtY29uZmlnJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDsvcnBjJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7Mi5Ib3cgdG8gcHJvY2VzcyBuZXN0ZWQgb3BlcmF0 aW9uIGF0dHJpYnV0ZT8gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Rm9yIGV4 YW1wbGU6IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZsdDtycGMgbWVzc2FnZS1pZCA9DQomcXVvdDsxMDEmcXVvdDsmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtlZGl0 LWNvbmZpZyZndDsNCjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3RhcmdldCZndDsNCjxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJmx0O3J1bm5pbmcvJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvdGFyZ2V0Jmd0Ow0K PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7Y29uZmlnJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombHQ7 aW50ZXJmYWNlcyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZsdDtp bnRlcmZhY2Ugb3BlcmF0aW9uPSAmcXVvdDttZXJnZSZxdW90OyZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O25hbWUmZ3Q7ZXRo MC8wLzAmbHQ7L25hbWUmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDttdHUgb3BlcmF0aW9uPSAmcXVvdDtyZW1vdmUmcXVvdDsm Z3Q7DQo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7ZW5hYmxlZCZndDt0cnVlJmx0Oy9lbmFsYmxlZCZndDsNCjxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbHQ7L2ludGVyZmFjZSZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombHQ7L2ludGVyZmFjZXMmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9jb25maWcmZ3Q7 DQo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7L2VkaXQtY29uZmlnJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDsvcnBjJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7VGhlIHNlcXVlbmNlIG9mIHByb2Nlc3MgaXMgbWVyZ2UgaW50ZXJmYWNlDQpu YW1lICdldGgwLzAvMCcgYW5kIDxicj4NCiZndDsgJmd0OyByZW1vdmUgbXR1IGFuZCBtZXJnZSBl bmFibGVkIHRvICd0cnVlJyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3IgbWVyZ2UgaW50ZXJmYWNlIG5hbWUgJ2V0aDAvMC8w Jw0KYW5kIDxicj4NCiZndDsgJmd0OyBtZXJnZSBlbmFibGVkIHRvICd0cnVlJyBhbmQgcmVtb3Zl IG10dT8gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW4gb3RoZXIgd29yZHMs IE5FVENPTkYgd2lsbCBwcm9jZXNzIG91dGVyDQpsYXllciBvcGVyYXRpb24gPGJyPg0KJmd0OyAm Z3Q7IGZpcnN0bHkgYW5kIHByb2Nlc3MgaW5uZXIgbGF5ZXIgb3BlcmF0aW9uIGxhdGVyLCBvciBw cm9jZXNzIDxicj4NCiZndDsgJmd0OyBvcGVyYXRpb25zIGluIGFjY29yZGFuY2Ugd2l0aCBYTUwg dHJlZSB0cmF2ZXJzYWwgb3JkZXI/IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyBUaGVyZSBpcyBubyByZXF1aXJlZCBwcm9jZXNzaW5nIG9yZGVy LiA8YnI+DQomZ3Q7ICZndDsgSXQgaXMgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLiA8YnI+DQom Z3Q7ICZndDsgU29tZSB0aGluZ3MgdG8gY29uc2lkZXI6IDxicj4NCiZndDsgJmd0OyAmbmJzcDsg MSkgYWxsIG9wZXJhdGlvbnMgYXJlIGFnYWluc3QgdGhlIHRhcmdldCBkYXRhc3RvcmUgYXQNCnRo ZSBzdGFydCBvZjxicj4NCiZndDsgJmd0OyB0aGUgb3BlcmF0aW9uIDxicj4NCiZndDsgJmd0OyAm bmJzcDsgMikgdGhlIG9wZXJhdGlvbnMgYXJlIGFsbC1vci1ub25lLCBub3QgaW5jcmVtZW50YWwg PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAyYSkgdGhpcyBpbXBsaWVzIHRoYXQgY3JlYXRlIHdpdGhp biBkZWxldGUsIG9yIGRlbGV0ZQ0Kd2l0aGluIDxicj4NCiZndDsgJmd0OyBjcmVhdGUsIGlzIGFs d2F5cyBhbiBlcnJvciA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 YmVjYXVzZSAnZGF0YS1leGlzdHMnIG9yICdkYXRhLW1pc3NpbmcnDQptdXN0IGJlIHRydWUgPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbiB5b3VyIGV4YW1wbGUgdGhlcmUgaXMgbm8g cHJvYmxlbSBiZWNhdXNlICdyZW1vdmUnIHdvcmtzIGV2ZW4NCmlmIDxicj4NCiZndDsgJmd0OyB0 aGUgZGF0YSBpcyBtaXNzaW5nLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IDMuIElmIG90aGVyIG9wZXJhdGlvbiBhdHRyaWJ1dGUgbmVzdGVkIGluIG9wZXJhdGlvbiBh dHRyaWJ1dGUNCjxicj4NCiZndDsgJmd0OyAncmVtb3ZlJyx3aGF0IHNob3VsZCBORVRDT05GIHNl cnZlciBkbz8gT25seSBwcm9jZXNzIHJlbW92ZSBvcGVyYXRpb24/DQo8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA0LiBDYW4gTkVUQ09ORiBzdXBwb3J0IHRoZSBuZXN0ZWQg b3BlcmF0aW9uIGF0dHJpYnV0ZQ0KZXF1YWxzIHRvIDxicj4NCiZndDsgJmd0OyBwYXJlbnQgb3Bl cmF0aW9uIGF0dHJpYnV0ZT8gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxi cj4NCiZndDsgJmd0OyAvZnJhbmsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBbmR5 IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluDQp0aGlzIDxicj4NCiZndDsgJmd0OyBtYWlsIChhbmQgYW55IGF0 dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQNCmFuZCA8YnI+DQom Z3Q7ICZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1 c2Ugb2YgdGhlIGFkZHJlc3NlZTxicj4NCiZndDsgJmd0OyAocykuICZuYnNwO0lmIHlvdSBhcmUg bm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsDQo8YnI+DQomZ3Q7ICZn dDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1 c2Ugb2YgdGhlDQo8YnI+DQomZ3Q7ICZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlDQpyZWNlaXZlZCA8YnI+DQomZ3Q7ICZn dDsgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1t ZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7ICZndDsgTmV0Y29uZkBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+PC90dD48 YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZj48dHQ+ PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u ZjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCjxi cj4NCiZndDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp cyBwcml2aWxlZ2VkIGFuZCA8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWU8YnI+DQomZ3Q7IChzKS4gJm5i c3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwg PGJyPg0KJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0 aW9uIG9yIHVzZSBvZiB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQNCjxicj4NCiZndDsg dGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRp YXRlbHkuPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29s b3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0 ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5k ZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJl IG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24s IGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBp bW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9 ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQg aGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRp c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1l ZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 0007308B48257CF2_=-- From nobody Sun Jun 8 19:36:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8A01B27B0 for ; Sun, 8 Jun 2014 19:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.072 X-Spam-Level: * X-Spam-Status: No, score=1.072 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws3kfNwu9qHs for ; Sun, 8 Jun 2014 19:36:17 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5EF1B27AE for ; Sun, 8 Jun 2014 19:36:17 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j5so7346044qaq.15 for ; Sun, 08 Jun 2014 19:36:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NU1jT0RdJQsUhBsv8jB8SEwXBLW5AM2ZZXpaqitaRPg=; b=lkV6JndZsvCHSc7p+rZZcz+oL5vdKByejqhD88kDBbPxSlsX1G99TVc3jyHdC5E63b D+PXZviwv5mQaOqZSIQMDt1d2KL78TIi11KDDVFwbI2e4H2BPEMP11ahVCVObDtFvRNn g2x0CcqRyg4TChDGINmv6NJXxH64PisFvR9oTt+h+9XNXZKsiaA9DgRxkug0x8mtHwP/ PJkHI7IrA2EKWvaIhcc6AP2ibdFoOYD36By7WYlIrj5G9Ovgqnz9xPV94p3p3H84RUqo 4xINoRzgewJWHXF6Upb858f22agtiFsBBnmMiytFIkbAYU4dLsKlAKdjfIjlnLSAqq0m Th+Q== X-Gm-Message-State: ALoCoQnc3L7tDNgxqSN/wOmuBu5ybPIhZRuCdWtWagkgNU2QgLd5mIlwAAVp3szQS+TbQ/FuRe7p MIME-Version: 1.0 X-Received: by 10.224.24.134 with SMTP id v6mr29096449qab.88.1402281376309; Sun, 08 Jun 2014 19:36:16 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Sun, 8 Jun 2014 19:36:16 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Jun 2014 19:36:16 -0700 Message-ID: From: Andy Bierman To: feng.chong33@zte.com.cn Content-Type: multipart/alternative; boundary=001a11c252c64f764304fb5e139f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xrnjurWhJXLhEOqqo05-msnovIA Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 02:36:19 -0000 --001a11c252c64f764304fb5e139f Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Sun, Jun 8, 2014 at 6:18 PM, wrote: > Andy=A3=AC > I have looked through this section for many times. In my opinion, I > think > the element contains attribute 'replace' must have subtree, and this > subtree > should be a valid configuration. But my colleagues don't think so, they > argued > that the empty configuration is also configuration, they want to use > 'replace' > as 'remove', I can't persuade them, :) > So,I want to get a clarification, thanks. > you are both right ;-) the replace attribute does have to appear in a subtree, but a subtree may b= e an empty node (if it is schema valid). start: 42 replace foo: result: The text seems very clear to me. /frank > Andy > > Andy Bierman =D0=B4=D3=DA 2014-06-07 02:43:28: > > > Andy Bierman > > 2014-06-07 02:43 > > > > =CA=D5=BC=FE=C8=CB > > > > feng.chong33@zte.com.cn, > > > > =B3=AD=CB=CD > > > > dou.wei1@zte.com.cn, Netconf , > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > =D6=F7=CC=E2 > > > > Re: [Netconf] Some questions about the usage of 'operation' > > attribute in edit-config > > > > > > > On Thu, Jun 5, 2014 at 11:18 PM, wrote: > > andy, > > Thanks a lot. > > Can you answer the first question? 'replace' can be used as 'remove'= ? > > > > Read RFC 6241, sec. 7.2 Attributes section. > > It explains the difference between the NETCONF operations= . > > > > > > /frank > > > > Andy > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-05 23:46:53: > > > > > Andy Bierman > > > 2014-06-05 23:46 > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > feng.chong33@zte.com.cn, > > > > > > =B3=AD=CB=CD > > > > > > Netconf , ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, > > > xiao.yuqing@zte.com.cn > > > > > > =D6=F7=CC=E2 > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > attribute in edit-config > > > > > > > > > > > On Wed, Jun 4, 2014 at 6:35 PM, wrote: > > > Hi all, > > > I have some questions about the usage of 'operation' attribute > > > in edit-config. > > > 1. 'replace' attribute can only be used to remove configuration? > > > For example, the rpc request listed below is valid? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.How to process nested operation attribute? > > > For example: > > > > > > > > > > > > > > > > > > > > > > > > > > > eth0/0/0 > > > > > > true > > > > > > > > > > > > > > > > > > > > > The sequence of process is merge interface name 'eth0/0/0' and > > > remove mtu and merge enabled to 'true' > > > or merge interface name 'eth0/0/0' and > > > merge enabled to 'true' and remove mtu? > > > In other words, NETCONF will process outer layer operation > > > firstly and process inner layer operation later, or process > > > operations in accordance with XML tree traversal order? > > > > > > > > > There is no required processing order. > > > It is an implementation detail. > > > Some things to consider: > > > 1) all operations are against the target datastore at the start of > > > the operation > > > 2) the operations are all-or-none, not incremental > > > 2a) this implies that create within delete, or delete within > > > create, is always an error > > > because 'data-exists' or 'data-missing' must be true > > > > > > In your example there is no problem because 'remove' works even if > > > the data is missing. > > > > > > > > > > > > 3. If other operation attribute nested in operation attribute > > > 'remove',what should NETCONF server do? Only process remove operation= ? > > > > > > 4. Can NETCONF support the nested operation attribute equals to > > > parent operation attribute? > > > > > > /frank > > > > > > Andy > > > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail (and any attachment transmitted herewith) is privileged and > > > confidential and is intended for the exclusive use of the addressee > > > (s). If you are not an intended recipient, any disclosure, > > > reproduction, distribution or other dissemination or use of the > > > information contained is strictly prohibited. If you have received > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail (and any attachment transmitted herewith) is privileged and > > confidential and is intended for the exclusive use of the addressee > > (s). If you are not an intended recipient, any disclosure, > > reproduction, distribution or other dissemination or use of the > > information contained is strictly prohibited. If you have received > > this mail in error, please delete it and notify us immediately. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > --001a11c252c64f764304fb5e139f Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 6, 2014 at 3:41 AM, Liubing (Leo) <= ;leo.liubing@hu= awei.com> wrote:

Hi Andy,

&nb= sp;

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, June 05, 2014 6:42 PM
To: Bert Wijnen (IETF)
Cc: Zhengguangying; Yangang; Netconf; Netconf
Subject: Re: [Netconf] =B4= =F0=B8=B4: Re: Netconf fragmentation-//FW= : New Version Notification for draft-liu-netconf-fragmentation-00.txt

 

 

=  

On Thu, Jun 5, 2014 at 1:39 AM,= Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:

= I am a bit concerned that we are now discussing a possible solution.

BUT.... I think we should first discuss on this list:

- Is the problem statement describing a real problem that we all agree with= ?

 

 

which problem? more than 1 has = been described:

 

  1) the client can get a = reply that is "too big" so it wants to ask for well-formed=

      XML docume= nts that fragment the reply

 

  2) data skew can happen = across polls so the server needs to snapshot

      the reques= t and store it for the client to retrieve in pieces

 

 

= - If it is do we believe that our WG should work on a solution?

 

no -- neither problem is import= ant enough to solve right now.

[Bing] The= “too big reply” problem actually comes from real deployment re= quirement. Now there are some NMS that only provide NETCONF interface to the devices.

Especially= when the NMS also get state data from NETCONF, the big reply problem would= be highly expected. And since they only use NETCONF interface, it would be much better to solve the problem in a standard way.


 

the current standard suppor= ts subtree and XPath filtering.
Learn how to use them.
=

The client can use filtering to= achieve (1)

[Bing] May= I ask whether you are referring to some specific filtering or just in gene= ral?

As I under= stand, filtering mechanisms could be:

-      &nb= sp; For e= xample, when the NMS wants to get a portion of the large amount routes, it = could filter by interface, by prefix or some other conditions. However, since real deployment scenarios varied a lot, these conditions mi= ght not be able to guarantee the result is in the expected amount. Some int= erfaces might have only a few routes, while some might still have “to= o big” routes data.

-      &nb= sp; Preci= se filtering like XPath, it might be better than above, but again it is not= be able to guarantee to get a proper amount reply. More important, XPath is so sophisticated that some devices just don’t su= pport it. Even if it is supported, it is obviously heavier than just retrie= ving.


I think XPath works well enough.  Iterate over the list= you care about.
Retrieve the entire list at once and it might be= too big.

 

&nb= sp;

So in gene= ral, I think filtering might be helpful, but it doesn’t really solve = the problem.

&nb= sp;

and (2) is not practical=

because of memory constraints i= n devices.

[Bing] Alt= hough now we just need to focus on the problem, I’d like to explain a= bit more on our solution.

&nb= sp;

Our propos= al is NOT snapshot. It doesn’t hold the whole result in the memory, i= t only holds the context (data offset .etc). When the NMS request the next block, the device could easily access to the block according to t= he context.



In that case, your solution suffers all the data skew p= roblems as if the client held the state,
and none of the benefits= . The server has the same problems remembering its place in constantly
changing state as the client.


 

&nb= sp;

Best regar= ds,

Bing

&nb= sp;

<= br>
Andy
 

 

Once we have agree on that, we = can decide if we want to add this topic
to our WG charter and work on it.

 

Would we be asking the IESG to = approve a new charter while so much

of the current charter remains = unfinished?

 


Bert (speaking as co-chair)

 

Andy

 


On 05/06/14 02:59, feng.chong33@zte.com.cn wrote:

= andy,
    How to process nested lists using your solution?

For example:
    list foo {
        key a;
        leaf a {...}
        leaf b {...}
        list nested-foo {
key nested-a;
leaf nested-a {...}
leaf netsted-b {...}
        }
    }

   If request is:
<rpc>
      <get-list>
        <target>/foo</target>
      </get-list>
    </rpc>
   What is the response?

And, another question:
Start-index is not reliable, if some entries are deleted. I think you can u= se start key instead.



/frank

"Netconf" <netconf-bounces@ietf.org> =D0=B4=D3=DA 2014-06-05 00:43:12:

 > Andy Bierman <andy@yumaworks.com>
 > =B7=A2=BC=FE=C8=CB:  "Netc= onf" <netconf-bounces@ietf.org>
 >
 > 2014-06-05 00:43
 >
 > =CA=D5=BC=FE=C8=CB
 >
 > chong feng <fengchongllly@gmail.com>,
 >
 > =B3=AD=CB=CD
 >
 > Zhengguangying <zhengguangying@huawei.com>, Netconf
 > <netcon= f@ietf.org>, Yangang <yangang@huawei.com>
 >
 > =D6=F7=CC=E2
 >
 > Re: [Netconf] Netconf fragmentation-//FW: New Version Notificati= on
 > for draft-liu-netconf-fragmentation-00.txt
 >
 >

 > On Wed, Jun 4, 2014 at 8:32 AM, chong feng <fengchongllly@gmail.com>= wrote:
 > Hi,
 >    I have reviewed this new draft.
 >    I understand your solution is that NETCONF server r= eserve break
 > points and wait for client to retrieve the next response.
 > I think it's not a good solution, because server may need to= reserve
 > many break points if there a large number of concurrent requests= .
 > It's too heavy for server. And, the server must be stateful = if it
 > support get-block capability.
 >
 >
 > I agree with these concerns.  Holding a snapshot of state d= ata for
 > interactive retrieval
 > by the client is very expensive.
 >
 > I do not agree with the premise that the client needs to know th= e
 > key values in advance.
 > An "iterator" approach allows a list resource to be re= trieved in
 > chunks.  This is what RESTCONF
 > is going to do, and NETCONF could add a similar RPC function:  >
 >    rpc get-list {
 >      input {
 >        leaf target {
 >           type schema-instance-identifi= er;
 >           description "Identifies = subtree to retrieve.";
 >       }
 >       leaf start {
 >          type uint32;
 >          default 0;
 >          description "Number of en= tries to skip before starting retrieval";
 >       }
 >       leaf max-entries {
 >         type uint32 { range "1..max&quo= t;; }
 >         default 25;
 >         description "Maximum number of = list entries to retrieve";
 >       }
 >     }
 >     output {
 >        anyxml data {
 >           description "Contains th= e requested data";
 >        }
 >     }
 >   }
 >
 >   <rpc>
 >     <get-list>
 >       <target>/if:interfaces/if:interface&l= t;/target>
 >     </get-list>
 >   </rpc>
 >
 >   <rpc-reply>
 >      <data>
 >         <interfaces>
 >            <interface>  = ; .... first entry </interface>
 >            ...
 >            <interface>  = ; .... 25th entry </interface>
 >         </interfaces>
 >      </data>
 >   </rpc-reply>
 >
 >    <rpc>
 >     <get-list>
 >       <target>/if:interfaces/if:interface&l= t;/target>
 >       <start>25</start>
 >     </get-list>
 >   </rpc>
 >
 >   <rpc-reply>
 >      <data>
 >         <interfaces>
 >            <interface>  = ; .... 26th entry </interface>
 >            ...
 >            <interface>  = ; .... 50th entry </interface>
 >         </interfaces>
 >      </data>
 >   </rpc-reply>
 >
 > There is a problem with rapidly changing lists
 > (could get repeat entries on miss some entries), but the snapsho= t
 > approach uses too much memory, and if the list instances
 > change rapidly, a stale snapshot is not very useful.
 >
 > Andy
 >
 > The other questions and comments are listed below:
 > 1. Get-block capability should not change the get-config operati= on's
 > behavior. If client use get-config operation to retrieve data,  > all data must be sent in one response or get-block capability sh= ould
 > add a parameter to get-config operation to indicate the
 > response data will be fragmented.
 > 2. A set-id can be aged? when client never send a request to
 > retrieve the next fragment for a long time, I think this set-id<= br>  > should be aged,
 > otherwise, server will be reserve more and more set-ids.
 > 3. A set-id is unique in session level or server level?
 > 4. If a session is killed or closed, other session can retrieved= the
 > next fragment if the client provide the correct set-id?
 > /frank
 >

 > 2014-06-04 18:22 GMT+08:00 Liubing (Leo) <leo.liubing@huawei.com>:  > Hi all,
 >
 > We've posted a new draft, which is about NETCONF data fragme= ntation.
 >
 > The basic idea is, when NMS is retrieving a large size of data i= n
 > the device, the <rpc-reply> might be very big (e.g. the ro= utes in a
 > core router).
 > Currently there are mainly two methods of handling the big <r= pc-
 > reply>: one is stream-oriented handling; the other is just re= quest a
 > portion of the data.
 >
 > This draft considers both the two methods are problematic in som= e
 > situations, and proposes a new method which allows the large siz= e
 > <rpc-reply> to be fragmented in NETCONF level.
 >
 > Please read the draft and comment.
 > Many thanks!
 >
 > Best regards,
 > Bing
 >
 > -----Original Message-----
 > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
 > Sent: Wednesday, June 04, 2014 5:27 PM
 > To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying=
 > Subject: New Version Notification for draft-liu-netconf-fragment= ation-00.txt
 >
 >
 > A new version of I-D, draft-liu-netconf-fragmentation-00.txt
 > has been successfully submitted by Bing Liu and posted to the IE= TF repository.
 >
 > Name:           draft-liu-netconf-fragm= entation
 > Revision:       00
 > Title:          A NETCONF Extension for= Data Fragmentation
 > Document date:  2014-06-04
 > Group:          Individual Submission  > Pages:          12
 > URL: http://www.ietf.org/internet-drafts/draft-liu-
 > netconf-fragmentation-00.txt
 > Status: https://datatracker.ietf.org/doc/draft-liu-netconf-
 > fragmentation/
 > Htmlized: http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00
 >
 >
 > Abstract:
 >    This document introduces an extension to NETCONF (N= etwork
 >    Configuration) protocol. The extension allows NETCO= NF to handle large
 >    size data as fragmented RPC messages. Specifically,= this document
 >    defines a new <get-block> capability and rele= vant operations to
 >    handle the fragmentations.
 >
 >
 >
 >
 > Please note that it may take a couple of minutes from the time o= f
 > submission until the htmlized version and diff are available at = tools.ietf.org
 > .
 >
 > The IETF Secretariat
 >
 > _______________________________________________
 > Netconf mailing list
 > Netconf@ie= tf.org
 > https://www.ietf.org/mailman/listinfo/netconf
 >
 >
 > _______________________________________________
 > Netconf mailing list
 > Netconf@ie= tf.org
 > https://www.ietf.org/mailman/listinfo/netconf

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


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s).  If you are not = an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the informatio= n contained is strictly prohibited.  If you have received this mail in= error, please delete it and notify us immediately.




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s).  If you are not = an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the informatio= n contained is strictly prohibited.  If you have received this mail in= error, please delete it and notify us immediately.




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

 





On Sun, Jun 8, 2014 at 6:18 PM, <feng.chong33@zte.com.cn> wrote:
Andy=A3=AC
    I have looked through this section for many times. In my opinion, I think
the element contains attribute 'replace&#= 39; must have subtree, and this subtree
should be a valid configuration. But my colleagues don't think so, they argued
that the empty configuration is also configuration, they want to use 'replace'
as 'remove', I can't persuade the= m, :)
    So,I want to get a clarificatio= n, thanks.

you are both right ;-)

<= /div>
the replace attribute does have to appear in a subtree, but a sub= tree may be
an empty node (if it is schema valid).

start:

  <config>
<= div>     <foo>
        &= lt;a>42</a>
     </foo>
&= nbsp; </config>

replace foo:

 <config>
     = ;<foo operation=3D"replace" />
  </config= >

result:

&= nbsp; <config>
     <foo />
  </config>

The text seems very clear to me.



/frank

Andy
 

Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-07 02:43:28:

> Andy Bierman <andy@yumaworks.com>
> 2014-06-07 02:43
>
> =CA=D5=BC=FE=C8=CB
>
> feng.chon= g33@zte.com.cn,
>
> =B3=AD=CB=CD
>
> dou.wei1@zte.= com.cn, Netconf <netconf@ietf.org>,
> xiao.yuqin= g@zte.com.cn, ye= .xu1@zte.com.cn
>
> =D6=F7=CC=E2
>
> Re: [Netconf] Some questions about the usage of 'operation' > attribute in edit-config
>
>

> On Thu, Jun 5, 2014 at 11:18 PM, <feng.chong33@zte.com.cn> wrote:
> andy,
>    Thanks a lot.
>    Can you answer the first question? 'replace' can = be used as 'remove'?
>
> Read RFC 6241, sec. 7.2 Attributes section.
> It explains the difference between the NETCONF <edit-config> operations.
>
>  
> /frank
>
> Andy
>  
>
> Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-05 23:46:53:
>
> > Andy Bierman <andy@yumaworks.com>
> > 2014-06-05 23:46
> >
> > =CA=D5=BC=FE=C8=CB
> >
> > feng= .chong33@zte.com.cn,
> >
> > =B3=AD=CB=CD
> >
> > Netconf <netconf@ietf.org>, ye.xu1@zte.com.cn, dou.wei1@zte.com.cn,
> > xiao.= yuqing@zte.com.cn
> >
> > =D6=F7=CC=E2
> >
> > Re: [Netconf] Some questions about the usage of 'operation= 9;
> > attribute in edit-config
> >
> >
>
> > On Wed, Jun 4, 2014 at 6:35 PM, <feng.chong33@zte.com.cn> wrote:
> > Hi all,
> >    I have some questions about the usage of  '= operation' attribute
> > in edit-config.
> >    1. 'replace' attribute can only be used to r= emove configuration?
> >       For example, the rpc request listed below is valid?
> >       <rpc message-id =3D "101">
> >            <edit-config>
> >                <target= >
> >                   <running/>
> >                </targe= t>
> >                <config= >
> >                   <interfaces operation=3D "replace"/>
> >                </confi= g>
> >            </edit-config>
> >       </rpc>
> >
> >
> >    2.How to process nested operation attribute?
> >      For example:
> >            <rpc message-id =3D "101">
> >            <edit-config>
> >                <target= >
> >                   <running/>
> >                </targe= t>
> >                <config= >
> >                   <interfaces>
> >                       <interface operation=3D "merge">
> >                            <name>eth0/0/0</name>
> >                            <mtu operation=3D "remove"&g= t;
> >                            <enabled>true</enalbled>
> >                       </interface>
> >                   </interfaces>
> >                </confi= g>
> >            </edit-config>
> >       </rpc>
> >
> >      The sequence of process is merge interface name 'eth0/0/0' and
> > remove mtu and merge enabled to 'true'
> >                              or merge interface name 'eth0/= 0/0' and
> > merge enabled to 'true' and remove mtu?
> >      In other words, NETCONF will process outer layer operation
> > firstly and process inner layer operation later, or process
> > operations in accordance with XML tree traversal order?
> >  
> >
> > There is no required processing order.
> > It is an implementation detail.
> > Some things to consider:
> >   1) all operations are against the target datastore at the start of
> > the operation
> >   2) the operations are all-or-none, not incremental
> >   2a) this implies that create within delete, or delete within
> > create, is always an error
> >        because 'data-exists' or '= data-missing' must be true
> >
> > In your example there is no problem because 'remove' work= s even if
> > the data is missing.
> >
> >          
> >
> > 3. If other operation attribute nested in operation attribute
> > 'remove',what should NETCONF server do? Only process remo= ve operation?
> >
> >   4. Can NETCONF support the nested operation attribute equals to
> > parent operation attribute?
> >      
> > /frank
> >
> > Andy
> >  
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the address= ee
> > (s).  If you are not an intended recipient, any disclosure,
> > reproduction, distribution or other dissemination or use of the
> > information contained is strictly prohibited.  If you have received
> > this mail in error, please delete it and notify us immediately. > >
>
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netc= onf
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail (and any attachment transmitted herewith) is privileged and
> confidential and is intended for the exclusive use of the addressee > (s).  If you are not an intended recipient, any disclosure,
> reproduction, distribution or other dissemination or use of the
> information contained is strictly prohibited.  If you have receiv= ed
> this mail in error, please delete it and notify us immediately.
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


--001a11c252c64f764304fb5e139f-- From nobody Sun Jun 8 20:18:34 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D851B27CC for ; Sun, 8 Jun 2014 20:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.9 X-Spam-Level: X-Spam-Status: No, score=-98.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7EV-x-x7qwX for ; Sun, 8 Jun 2014 20:18:30 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9087B1B27CB for ; Sun, 8 Jun 2014 20:18:29 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 56E81193C7AA for ; Mon, 9 Jun 2014 11:18:18 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 147D9714408; Mon, 9 Jun 2014 11:18:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s593IB2L030951; Mon, 9 Jun 2014 11:18:11 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: References: To: Andy Bierman MIME-Version: 1.0 X-KeepSent: 9A17CF7C:65852465-48257CF2:00114DD0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Mon, 9 Jun 2014 11:18:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-09 11:18:12, Serialize complete at 2014-06-09 11:18:12 Content-Type: multipart/alternative; boundary="=_alternative 001224C048257CF2_=" X-MAIL: mse01.zte.com.cn s593IB2L030951 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Fnq2wnx_joqJOn1gf7osl-no8qo Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 03:18:33 -0000 This is a multipart message in MIME format. --=_alternative 001224C048257CF2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QW5keSwNCiAgIHRoYW5rcyw6KQ0KICAgSSB1bmRlcnN0YW5kIG9ubHkgcHJlc2VuY2UgY29udGFp bmVyIG9yIGxlYWYgbm9kZSB3aXRoIGVtcHR5IHR5cGUgY2FuIA0KYmUgcGxhY2VkICdyZXBsYWNl JyBhdHRyaWJ1dGUNCmFuZCBoYXZlIGEgZW1wdHkgbm9kZSBzdWJ0cmVlLiBJcyBpdCByaWdodD8N Ci9mcmFuaw0KDQpBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4g0LTT2iAyMDE0LTA2 LTA5IDEwOjM2OjE2Og0KDQo+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4g MjAxNC0wNi0wOSAxMDozNg0KPiANCj4gytW8/sjLDQo+IA0KPiBmZW5nLmNob25nMzNAenRlLmNv bS5jbiwgDQo+IA0KPiCzrcvNDQo+IA0KPiBkb3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mIDxu ZXRjb25mQGlldGYub3JnPiwgDQo+IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24sIHllLnh1MUB6dGUu Y29tLmNuDQo+IA0KPiDW98ziDQo+IA0KPiBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25zIGFi b3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyANCj4gYXR0cmlidXRlIGluIGVkaXQtY29uZmln DQo+IA0KPiANCg0KPiBPbiBTdW4sIEp1biA4LCAyMDE0IGF0IDY6MTggUE0sIDxmZW5nLmNob25n MzNAenRlLmNvbS5jbj4gd3JvdGU6DQo+IEFuZHmjrCANCj4gICAgIEkgaGF2ZSBsb29rZWQgdGhy b3VnaCB0aGlzIHNlY3Rpb24gZm9yIG1hbnkgdGltZXMuIEluIG15IG9waW5pb24sIEkgDQp0aGlu ayANCj4gdGhlIGVsZW1lbnQgY29udGFpbnMgYXR0cmlidXRlICdyZXBsYWNlJyBtdXN0IGhhdmUg c3VidHJlZSwgYW5kIHRoaXMgDQpzdWJ0cmVlIA0KPiBzaG91bGQgYmUgYSB2YWxpZCBjb25maWd1 cmF0aW9uLiBCdXQgbXkgY29sbGVhZ3VlcyBkb24ndCB0aGluayBzbywgDQo+IHRoZXkgYXJndWVk IA0KPiB0aGF0IHRoZSBlbXB0eSBjb25maWd1cmF0aW9uIGlzIGFsc28gY29uZmlndXJhdGlvbiwg dGhleSB3YW50IHRvIA0KdXNlJ3JlcGxhY2UnIA0KPiBhcyAncmVtb3ZlJywgSSBjYW4ndCBwZXJz dWFkZSB0aGVtLCA6KSANCj4gICAgIFNvLEkgd2FudCB0byBnZXQgYSBjbGFyaWZpY2F0aW9uLCB0 aGFua3MuIA0KPiANCj4geW91IGFyZSBib3RoIHJpZ2h0IDstKQ0KPiANCj4gdGhlIHJlcGxhY2Ug YXR0cmlidXRlIGRvZXMgaGF2ZSB0byBhcHBlYXIgaW4gYSBzdWJ0cmVlLCBidXQgYSBzdWJ0cmVl IA0KbWF5IGJlDQo+IGFuIGVtcHR5IG5vZGUgKGlmIGl0IGlzIHNjaGVtYSB2YWxpZCkuDQo+IA0K PiBzdGFydDoNCj4gDQo+ICAgPGNvbmZpZz4NCj4gICAgICA8Zm9vPg0KPiAgICAgICAgIDxhPjQy PC9hPg0KPiAgICAgIDwvZm9vPg0KPiAgIDwvY29uZmlnPg0KPiANCj4gcmVwbGFjZSBmb286DQo+ IA0KPiAgPGNvbmZpZz4NCj4gICAgICA8Zm9vIG9wZXJhdGlvbj0icmVwbGFjZSIgLz4NCj4gICA8 L2NvbmZpZz4NCj4gDQo+IHJlc3VsdDoNCj4gDQo+ICAgPGNvbmZpZz4NCj4gICAgICA8Zm9vIC8+ DQo+ICAgPC9jb25maWc+DQo+IA0KPiBUaGUgdGV4dCBzZWVtcyB2ZXJ5IGNsZWFyIHRvIG1lLg0K PiANCj4gL2ZyYW5rIA0KPiANCj4gQW5keQ0KPiANCg0KSW4geW91ciBleGFtcGxlLCB0aGUgJ2Zv bycgTVVTVCBiZSBhIHByZXNlbmNlIGNvbnRhaW5lcj8NCiANCj4gDQo+IEFuZHkgQmllcm1hbiA8 YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYtMDcgMDI6NDM6Mjg6DQo+IA0KPiA+IEFu ZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4gPiAyMDE0LTA2LTA3IDAyOjQzIA0K PiA+IA0KPiA+IMrVvP7IyyANCj4gPiANCj4gPiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgDQo+ ID4gDQo+ID4gs63LzSANCj4gPiANCj4gPiBkb3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mIDxu ZXRjb25mQGlldGYub3JnPiwgDQo+ID4geGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0 ZS5jb20uY24gDQo+ID4gDQo+ID4g1vfM4iANCj4gPiANCj4gPiBSZTogW05ldGNvbmZdIFNvbWUg cXVlc3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyANCj4gPiBhdHRyaWJ1dGUg aW4gZWRpdC1jb25maWcgDQo+ID4gDQo+ID4gDQo+IA0KPiA+IE9uIFRodSwgSnVuIDUsIDIwMTQg YXQgMTE6MTggUE0sIDxmZW5nLmNob25nMzNAenRlLmNvbS5jbj4gd3JvdGU6IA0KPiA+IGFuZHks IA0KPiA+ICAgIFRoYW5rcyBhIGxvdC4gDQo+ID4gICAgQ2FuIHlvdSBhbnN3ZXIgdGhlIGZpcnN0 IHF1ZXN0aW9uPyAncmVwbGFjZScgY2FuIGJlIHVzZWQgYXMgDQoncmVtb3ZlJz8gDQo+ID4gDQo+ ID4gUmVhZCBSRkMgNjI0MSwgc2VjLiA3LjIgQXR0cmlidXRlcyBzZWN0aW9uLiANCj4gPiBJdCBl eHBsYWlucyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBORVRDT05GIDxlZGl0LWNvbmZpZz4g DQpvcGVyYXRpb25zLiANCj4gPiANCj4gPiANCj4gPiAvZnJhbmsgDQo+ID4gDQo+ID4gQW5keSAN Cj4gPiANCj4gPiANCj4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4g0LTT2iAy MDE0LTA2LTA1IDIzOjQ2OjUzOg0KPiA+IA0KPiA+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3 b3Jrcy5jb20+IA0KPiA+ID4gMjAxNC0wNi0wNSAyMzo0NiANCj4gPiA+IA0KPiA+ID4gytW8/sjL IA0KPiA+ID4gDQo+ID4gPiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgDQo+ID4gPiANCj4gPiA+ ILOty80gDQo+ID4gPiANCj4gPiA+IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+LCB5ZS54dTFA enRlLmNvbS5jbiwgZG91LndlaTFAenRlLmNvbS5jbiwgDQo+ID4gPiB4aWFvLnl1cWluZ0B6dGUu Y29tLmNuIA0KPiA+ID4gDQo+ID4gPiDW98ziIA0KPiA+ID4gDQo+ID4gPiBSZTogW05ldGNvbmZd IFNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyANCj4gPiA+IGF0 dHJpYnV0ZSBpbiBlZGl0LWNvbmZpZyANCj4gPiA+IA0KPiA+ID4gDQo+ID4gDQo+ID4gPiBPbiBX ZWQsIEp1biA0LCAyMDE0IGF0IDY6MzUgUE0sIDxmZW5nLmNob25nMzNAenRlLmNvbS5jbj4gd3Jv dGU6IA0KPiA+ID4gSGkgYWxsLCANCj4gPiA+ICAgIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91 dCB0aGUgdXNhZ2Ugb2YgICdvcGVyYXRpb24nIGF0dHJpYnV0ZSANCj4gPiA+IGluIGVkaXQtY29u ZmlnLiANCj4gPiA+ICAgIDEuICdyZXBsYWNlJyBhdHRyaWJ1dGUgY2FuIG9ubHkgYmUgdXNlZCB0 byByZW1vdmUgY29uZmlndXJhdGlvbj8gDQo+ID4gPiAgICAgICBGb3IgZXhhbXBsZSwgdGhlIHJw YyByZXF1ZXN0IGxpc3RlZCBiZWxvdyBpcyB2YWxpZD8gDQo+ID4gPiAgICAgICA8cnBjIG1lc3Nh Z2UtaWQgPSAiMTAxIj4gDQo+ID4gPiAgICAgICAgICAgIDxlZGl0LWNvbmZpZz4gDQo+ID4gPiAg ICAgICAgICAgICAgICA8dGFyZ2V0PiANCj4gPiA+ICAgICAgICAgICAgICAgICAgIDxydW5uaW5n Lz4gDQo+ID4gPiAgICAgICAgICAgICAgICA8L3RhcmdldD4gDQo+ID4gPiAgICAgICAgICAgICAg ICA8Y29uZmlnPiANCj4gPiA+ICAgICAgICAgICAgICAgICAgIDxpbnRlcmZhY2VzIG9wZXJhdGlv bj0gInJlcGxhY2UiLz4gDQo+ID4gPiAgICAgICAgICAgICAgICA8L2NvbmZpZz4gDQo+ID4gPiAg ICAgICAgICAgIDwvZWRpdC1jb25maWc+IA0KPiA+ID4gICAgICAgPC9ycGM+IA0KPiA+ID4gDQo+ ID4gPiANCj4gPiA+ICAgIDIuSG93IHRvIHByb2Nlc3MgbmVzdGVkIG9wZXJhdGlvbiBhdHRyaWJ1 dGU/IA0KPiA+ID4gICAgICBGb3IgZXhhbXBsZTogDQo+ID4gPiAgICAgICAgICAgIDxycGMgbWVz c2FnZS1pZCA9ICIxMDEiPiANCj4gPiA+ICAgICAgICAgICAgPGVkaXQtY29uZmlnPiANCj4gPiA+ ICAgICAgICAgICAgICAgIDx0YXJnZXQ+IA0KPiA+ID4gICAgICAgICAgICAgICAgICAgPHJ1bm5p bmcvPiANCj4gPiA+ICAgICAgICAgICAgICAgIDwvdGFyZ2V0PiANCj4gPiA+ICAgICAgICAgICAg ICAgIDxjb25maWc+IA0KPiA+ID4gICAgICAgICAgICAgICAgICAgPGludGVyZmFjZXM+IA0KPiA+ ID4gICAgICAgICAgICAgICAgICAgICAgIDxpbnRlcmZhY2Ugb3BlcmF0aW9uPSAibWVyZ2UiPiAN Cj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxuYW1lPmV0aDAvMC8wPC9uYW1lPiAN Cj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtdHUgb3BlcmF0aW9uPSAicmVtb3Zl Ij4gDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZW5hYmxlZD50cnVlPC9lbmFs YmxlZD4gDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgPC9pbnRlcmZhY2U+IA0KPiA+ID4g ICAgICAgICAgICAgICAgICAgPC9pbnRlcmZhY2VzPiANCj4gPiA+ICAgICAgICAgICAgICAgIDwv Y29uZmlnPiANCj4gPiA+ICAgICAgICAgICAgPC9lZGl0LWNvbmZpZz4gDQo+ID4gPiAgICAgICA8 L3JwYz4gDQo+ID4gPiANCj4gPiA+ICAgICAgVGhlIHNlcXVlbmNlIG9mIHByb2Nlc3MgaXMgbWVy Z2UgaW50ZXJmYWNlIG5hbWUgJ2V0aDAvMC8wJyBhbmQgDQo+ID4gPiByZW1vdmUgbXR1IGFuZCBt ZXJnZSBlbmFibGVkIHRvICd0cnVlJyANCj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgb3IgbWVyZ2UgaW50ZXJmYWNlIG5hbWUgJ2V0aDAvMC8wJyBhbmQgDQo+ID4gPiBtZXJnZSBl bmFibGVkIHRvICd0cnVlJyBhbmQgcmVtb3ZlIG10dT8gDQo+ID4gPiAgICAgIEluIG90aGVyIHdv cmRzLCBORVRDT05GIHdpbGwgcHJvY2VzcyBvdXRlciBsYXllciBvcGVyYXRpb24gDQo+ID4gPiBm aXJzdGx5IGFuZCBwcm9jZXNzIGlubmVyIGxheWVyIG9wZXJhdGlvbiBsYXRlciwgb3IgcHJvY2Vz cyANCj4gPiA+IG9wZXJhdGlvbnMgaW4gYWNjb3JkYW5jZSB3aXRoIFhNTCB0cmVlIHRyYXZlcnNh bCBvcmRlcj8gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gVGhlcmUgaXMgbm8gcmVxdWlyZWQgcHJv Y2Vzc2luZyBvcmRlci4gDQo+ID4gPiBJdCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuIA0K PiA+ID4gU29tZSB0aGluZ3MgdG8gY29uc2lkZXI6IA0KPiA+ID4gICAxKSBhbGwgb3BlcmF0aW9u cyBhcmUgYWdhaW5zdCB0aGUgdGFyZ2V0IGRhdGFzdG9yZSBhdCB0aGUgc3RhcnQgb2YNCj4gPiA+ IHRoZSBvcGVyYXRpb24gDQo+ID4gPiAgIDIpIHRoZSBvcGVyYXRpb25zIGFyZSBhbGwtb3Itbm9u ZSwgbm90IGluY3JlbWVudGFsIA0KPiA+ID4gICAyYSkgdGhpcyBpbXBsaWVzIHRoYXQgY3JlYXRl IHdpdGhpbiBkZWxldGUsIG9yIGRlbGV0ZSB3aXRoaW4gDQo+ID4gPiBjcmVhdGUsIGlzIGFsd2F5 cyBhbiBlcnJvciANCj4gPiA+ICAgICAgICBiZWNhdXNlICdkYXRhLWV4aXN0cycgb3IgJ2RhdGEt bWlzc2luZycgbXVzdCBiZSB0cnVlIA0KPiA+ID4gDQo+ID4gPiBJbiB5b3VyIGV4YW1wbGUgdGhl cmUgaXMgbm8gcHJvYmxlbSBiZWNhdXNlICdyZW1vdmUnIHdvcmtzIGV2ZW4gaWYgDQo+ID4gPiB0 aGUgZGF0YSBpcyBtaXNzaW5nLiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IDMuIElm IG90aGVyIG9wZXJhdGlvbiBhdHRyaWJ1dGUgbmVzdGVkIGluIG9wZXJhdGlvbiBhdHRyaWJ1dGUg DQo+ID4gPiAncmVtb3ZlJyx3aGF0IHNob3VsZCBORVRDT05GIHNlcnZlciBkbz8gT25seSBwcm9j ZXNzIHJlbW92ZSANCm9wZXJhdGlvbj8gDQo+ID4gPiANCj4gPiA+ICAgNC4gQ2FuIE5FVENPTkYg c3VwcG9ydCB0aGUgbmVzdGVkIG9wZXJhdGlvbiBhdHRyaWJ1dGUgZXF1YWxzIHRvIA0KPiA+ID4g cGFyZW50IG9wZXJhdGlvbiBhdHRyaWJ1dGU/IA0KPiA+ID4gDQo+ID4gPiAvZnJhbmsgDQo+ID4g PiANCj4gPiA+IEFuZHkgDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IFpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyAN Cj4gPiA+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMg cHJpdmlsZWdlZCBhbmQgDQo+ID4gPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+ID4gPiAocykuICBJZiB5b3UgYXJl IG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gPiA+IHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSANCj4gPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAg SWYgeW91IGhhdmUgcmVjZWl2ZWQgDQo+ID4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBk ZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiA+IA0KPiA+IA0KPiA+ID4g DQo+ID4gPiANCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ID4gTmV0Y29uZkBpZXRmLm9y Zw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ IA0KPiA+IA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIA0KPiA+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVu dCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgDQo+ID4gY29uZmlkZW50 aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3Nl ZQ0KPiA+IChzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRp c2Nsb3N1cmUsIA0KPiA+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3Nl bWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiA+IHRoaXMgbWFpbCBp biBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPiA+ IA0KDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgDQo+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFu c21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgDQo+IGNvbmZpZGVudGlhbCBhbmQg aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUNCj4gKHMp LiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwg DQo+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3Ig dXNlIG9mIHRoZSANCj4gaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCANCj4gdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2Ug ZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+IA0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ug b2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVu dCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRp c3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwg cGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVn ZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNl IG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGll bnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBk aXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3Is IHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 001224C048257CF2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuZHksPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7dGhhbmtzLDopPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7SSB1bmRlcnN0YW5k IG9ubHkgcHJlc2VuY2UNCmNvbnRhaW5lciBvciBsZWFmIG5vZGUgd2l0aCBlbXB0eSB0eXBlIGNh biBiZSBwbGFjZWQgJ3JlcGxhY2UnIGF0dHJpYnV0ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+YW5kIGhhdmUgYSBlbXB0eSBub2RlIHN1YnRyZWUuIElzIGl0DQpy aWdodD88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwv Zm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkFuZHkgQmllcm1hbiAmbHQ7YW5keUB5 dW1hd29ya3MuY29tJmd0OyDQtNPaIDIwMTQtMDYtMDkNCjEwOjM2OjE2Ojxicj4NCjxicj4NCiZn dDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyMDE0LTA2LTA5IDEwOjM2PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20u Y24sIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOt y808L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBkb3Uu d2VpMUB6dGUuY29tLmNuLCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgPGJyPg0K Jmd0OyB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7INb3zOI8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBSZTogW05ldGNvbmZdIFNvbWUg cXVlc3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyA8YnI+DQomZ3Q7IGF0dHJp YnV0ZSBpbiBlZGl0LWNvbmZpZzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyA8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBPbiBTdW4sIEp1biA4LCAyMDE0IGF0IDY6MTggUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNv bS5jbiZndDsNCndyb3RlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBB bmR5o6wgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEkgaGF2ZSBsb29rZWQgdGhyb3VnaCB0aGlz IHNlY3Rpb24gZm9yIG1hbnkgdGltZXMuIEluDQpteSBvcGluaW9uLCBJIHRoaW5rIDxicj4NCiZn dDsgdGhlIGVsZW1lbnQgY29udGFpbnMgYXR0cmlidXRlICdyZXBsYWNlJyBtdXN0IGhhdmUgc3Vi dHJlZSwgYW5kIHRoaXMNCnN1YnRyZWUgPGJyPg0KJmd0OyBzaG91bGQgYmUgYSB2YWxpZCBjb25m aWd1cmF0aW9uLiBCdXQgbXkgY29sbGVhZ3VlcyBkb24ndCB0aGluayBzbywNCjxicj4NCiZndDsg dGhleSBhcmd1ZWQgPGJyPg0KJmd0OyB0aGF0IHRoZSBlbXB0eSBjb25maWd1cmF0aW9uIGlzIGFs c28gY29uZmlndXJhdGlvbiwgdGhleSB3YW50IHRvIHVzZSdyZXBsYWNlJw0KPGJyPg0KJmd0OyBh cyAncmVtb3ZlJywgSSBjYW4ndCBwZXJzdWFkZSB0aGVtLCA6KSA8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgU28sSSB3YW50IHRvIGdldCBhIGNsYXJpZmljYXRpb24sIHRoYW5rcy4gPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgeW91IGFyZSBib3RoIHJp Z2h0IDstKTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7 IHRoZSByZXBsYWNlIGF0dHJpYnV0ZSBkb2VzIGhhdmUgdG8gYXBwZWFyIGluIGEgc3VidHJlZSwg YnV0IGEgc3VidHJlZQ0KbWF5IGJlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IGFuIGVtcHR5IG5vZGUgKGlmIGl0IGlzIHNjaGVtYSB2YWxpZCkuPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgc3RhcnQ6PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZsdDtjb25maWcmZ3Q7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0O2ZvbyZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDthJmd0OzQyJmx0Oy9hJmd0OzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZm9v Jmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJmx0Oy9j b25maWcmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZn dDsgcmVwbGFjZSBmb286PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsgJm5ic3A7Jmx0O2NvbmZpZyZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Zm9vIG9wZXJhdGlvbj0mcXVvdDty ZXBsYWNlJnF1b3Q7DQovJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDsgJmx0Oy9jb25maWcmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgcmVzdWx0OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbHQ7Y29uZmlnJmd0OzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtmb28gLyZndDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZsdDsvY29uZmln Jmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFRo ZSB0ZXh0IHNlZW1zIHZlcnkgY2xlYXIgdG8gbWUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgL2ZyYW5rIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEFuZHk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JbiB5 b3VyIGV4YW1wbGUsIHRoZSAnZm9vJyBNVVNUIGJlIGEgcHJlc2VuY2UgY29udGFpbmVyPzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3 b3Jrcy5jb20mZ3Q7INC009ogMjAxNC0wNi0wNyAwMjo0MzoyODo8YnI+DQomZ3Q7IDxicj4NCiZn dDsgJmd0OyBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsgPGJyPg0KJmd0 OyAmZ3Q7IDIwMTQtMDYtMDcgMDI6NDMgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDK 1bz+yMsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBmZW5nLmNob25nMzNAenRlLmNv bS5jbiwgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyCzrcvNIDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgZG91LndlaTFAenRlLmNvbS5jbiwgTmV0Y29uZiAmbHQ7bmV0Y29u ZkBpZXRmLm9yZyZndDssIDxicj4NCiZndDsgJmd0OyB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5 ZS54dTFAenRlLmNvbS5jbiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7INb3zOIgPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25z IGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyA8YnI+DQomZ3Q7ICZndDsgYXR0cmlidXRl IGluIGVkaXQtY29uZmlnIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7ICZndDsgT24gVGh1LCBKdW4gNSwgMjAxNCBhdCAxMToxOCBQTSwgJmx0O2Zl bmcuY2hvbmczM0B6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyBhbmR5LCA8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RoYW5rcyBhIGxvdC4gPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDtDYW4geW91IGFuc3dlciB0aGUgZmlyc3QgcXVlc3Rpb24/ICdyZXBsYWNl JyBjYW4NCmJlIHVzZWQgYXMgJ3JlbW92ZSc/IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgUmVhZCBSRkMgNjI0MSwgc2VjLiA3LjIgQXR0cmlidXRlcyBzZWN0aW9uLiA8YnI+DQomZ3Q7 ICZndDsgSXQgZXhwbGFpbnMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgTkVUQ09ORiAmbHQ7 ZWRpdC1jb25maWcmZ3Q7DQpvcGVyYXRpb25zLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgL2ZyYW5rIDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgQW5keSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7INC009og MjAxNC0wNi0wNSAyMzo0Njo1Mzo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg QW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IDIwMTQtMDYtMDUgMjM6NDYgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgytW8/sjLIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGZl bmcuY2hvbmczM0B6dGUuY29tLmNuLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyCzrcvNIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE5l dGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCB5ZS54dTFAenRlLmNvbS5jbiwgZG91Lndl aTFAenRlLmNvbS5jbiwNCjxicj4NCiZndDsgJmd0OyAmZ3Q7IHhpYW8ueXVxaW5nQHp0ZS5jb20u Y24gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg1vfM4iA8YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBSZTogW05ldGNvbmZdIFNvbWUgcXVl c3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJw0KPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgYXR0cmlidXRlIGluIGVkaXQtY29uZmlnIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBPbiBXZWQs IEp1biA0LCAyMDE0IGF0IDY6MzUgUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5jbiZndDsN Cndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSBhbGwsIDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDtJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9mICZu YnNwOydvcGVyYXRpb24nDQphdHRyaWJ1dGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW4gZWRpdC1j b25maWcuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsxLiAncmVwbGFjZScgYXR0 cmlidXRlIGNhbiBvbmx5IGJlIHVzZWQgdG8NCnJlbW92ZSBjb25maWd1cmF0aW9uPyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGb3IgZXhhbXBsZSwgdGhlIHJwYyBy ZXF1ZXN0IGxpc3RlZA0KYmVsb3cgaXMgdmFsaWQ/IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDtycGMgbWVzc2FnZS1pZCA9ICZxdW90OzEwMSZxdW90OyZndDsN Cjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmx0O2VkaXQtY29uZmlnJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDt0YXJnZXQm Z3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJmx0O3J1bm5pbmcvJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmx0Oy90YXJnZXQmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2NvbmZp ZyZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbHQ7aW50ZXJmYWNlcyBvcGVyYXRp b249ICZxdW90O3JlcGxhY2UmcXVvdDsvJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9jb25m aWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDsvZWRpdC1jb25maWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3JwYyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOzIuSG93 IHRvIHByb2Nlc3MgbmVzdGVkIG9wZXJhdGlvbiBhdHRyaWJ1dGU/DQo8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZvciBleGFtcGxlOiA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtycGMgbWVzc2Fn ZS1pZA0KPSAmcXVvdDsxMDEmcXVvdDsmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2VkaXQtY29uZmlnJmd0Ow0KPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZsdDt0YXJnZXQmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJmx0O3J1bm5pbmcvJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy90YXJnZXQmZ3Q7DQo8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2NvbmZpZyZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbHQ7aW50ZXJmYWNlcyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJmx0O2ludGVyZmFjZSBvcGVyYXRpb249ICZxdW90O21lcmdlJnF1b3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZsdDtuYW1lJmd0O2V0aDAvMC8wJmx0Oy9uYW1lJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bXR1IG9wZXJh dGlvbj0gJnF1b3Q7cmVtb3ZlJnF1b3Q7Jmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZW5hYmxlZCZndDt0cnVlJmx0 Oy9lbmFsYmxlZCZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZsdDsvaW50ZXJmYWNlJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJmx0Oy9pbnRl cmZhY2VzJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9jb25maWcmZ3Q7DQo8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsv ZWRpdC1jb25maWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbHQ7L3JwYyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgc2VxdWVuY2Ugb2YgcHJvY2VzcyBpcyBtZXJnZSBpbnRl cmZhY2UNCm5hbWUgJ2V0aDAvMC8wJyBhbmQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVtb3ZlIG10 dSBhbmQgbWVyZ2UgZW5hYmxlZCB0byAndHJ1ZScgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3IgbWVyZ2UgaW50ZXJm YWNlIG5hbWUNCidldGgwLzAvMCcgYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7IG1lcmdlIGVuYWJs ZWQgdG8gJ3RydWUnIGFuZCByZW1vdmUgbXR1PyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0luIG90aGVyIHdvcmRzLCBORVRDT05GIHdpbGwgcHJvY2Vzcw0Kb3V0ZXIg bGF5ZXIgb3BlcmF0aW9uIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGZpcnN0bHkgYW5kIHByb2Nlc3Mg aW5uZXIgbGF5ZXIgb3BlcmF0aW9uIGxhdGVyLCBvciBwcm9jZXNzDQo8YnI+DQomZ3Q7ICZndDsg Jmd0OyBvcGVyYXRpb25zIGluIGFjY29yZGFuY2Ugd2l0aCBYTUwgdHJlZSB0cmF2ZXJzYWwgb3Jk ZXI/DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm8gcmVxdWlyZWQgcHJvY2Vzc2luZyBvcmRlci4g PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSXQgaXMgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLiA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBTb21lIHRoaW5ncyB0byBjb25zaWRlcjogPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7IDEpIGFsbCBvcGVyYXRpb25zIGFyZSBhZ2FpbnN0IHRoZSB0YXJnZXQgZGF0 YXN0b3JlDQphdCB0aGUgc3RhcnQgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGUgb3BlcmF0aW9u IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAyKSB0aGUgb3BlcmF0aW9ucyBhcmUgYWxsLW9y LW5vbmUsIG5vdCBpbmNyZW1lbnRhbA0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDJhKSB0 aGlzIGltcGxpZXMgdGhhdCBjcmVhdGUgd2l0aGluIGRlbGV0ZSwgb3IgZGVsZXRlDQp3aXRoaW4g PGJyPg0KJmd0OyAmZ3Q7ICZndDsgY3JlYXRlLCBpcyBhbHdheXMgYW4gZXJyb3IgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmVjYXVzZSAnZGF0YS1leGlz dHMnIG9yICdkYXRhLW1pc3NpbmcnDQptdXN0IGJlIHRydWUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSW4geW91ciBleGFtcGxlIHRoZXJlIGlzIG5vIHByb2JsZW0g YmVjYXVzZSAncmVtb3ZlJyB3b3Jrcw0KZXZlbiBpZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGUg ZGF0YSBpcyBtaXNzaW5nLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgMy4gSWYgb3RoZXIgb3BlcmF0aW9uIGF0dHJpYnV0ZSBuZXN0 ZWQgaW4gb3BlcmF0aW9uIGF0dHJpYnV0ZQ0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJ3JlbW92ZScs d2hhdCBzaG91bGQgTkVUQ09ORiBzZXJ2ZXIgZG8/IE9ubHkgcHJvY2VzcyByZW1vdmUNCm9wZXJh dGlvbj8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDQu IENhbiBORVRDT05GIHN1cHBvcnQgdGhlIG5lc3RlZCBvcGVyYXRpb24gYXR0cmlidXRlDQplcXVh bHMgdG8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcGFyZW50IG9wZXJhdGlvbiBhdHRyaWJ1dGU/IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IC9mcmFuayA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBbmR5 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQNCmluIHRoaXMgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp cyBwcml2aWxlZ2VkDQphbmQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQphZGRyZXNzZWU8YnI+DQom Z3Q7ICZndDsgJmd0OyAocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lw aWVudCwgYW55IGRpc2Nsb3N1cmUsDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXByb2R1Y3Rpb24s IGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZQ0Kb2YgdGhlIDxicj4N CiZndDsgJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiAmbmJzcDtJZiB5b3UNCmhhdmUgcmVjZWl2ZWQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhp cyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRl bHkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsg TmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBOZXRjb25mQGlldGYub3Jn PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2ZvbnQ+PC90dD48L2E+PHR0Pjxm b250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQomZ3Q7ICZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbg0KdGhpcyA8YnI+DQomZ3Q7ICZndDsgbWFpbCAoYW5kIGFueSBhdHRh Y2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkDQphbmQgPGJyPg0KJmd0 OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNl IG9mIHRoZSBhZGRyZXNzZWU8YnI+DQomZ3Q7ICZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLA0KPGJyPg0KJmd0OyAmZ3Q7 IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNl IG9mIHRoZQ0KPGJyPg0KJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiAmbmJzcDtJZiB5b3UgaGF2ZQ0KcmVjZWl2ZWQgPGJyPg0KJmd0OyAmZ3Q7 IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVk aWF0ZWx5Ljxicj4NCiZndDsgJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQo8YnI+DQomZ3Q7IG1h aWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdl ZCBhbmQgPGJyPg0KJmd0OyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhj bHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAocykuICZuYnNwO0lmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIDxicj4NCiZndDsg cmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ug b2YgdGhlIDxicj4NCiZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlIHJlY2VpdmVkDQo8YnI+DQomZ3Q7IHRoaXMgbWFpbCBp biBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4N CiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRo KSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUg ZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50 ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBt YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHku DQoNCjwvZm9udD48L3ByZT48YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp cyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhj bHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24g b3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWls IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoN CjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 001224C048257CF2_=-- From nobody Sun Jun 8 20:45:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316CD1B27D0 for ; Sun, 8 Jun 2014 20:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.672 X-Spam-Level: * X-Spam-Status: No, score=1.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anM6y3Ut0chl for ; Sun, 8 Jun 2014 20:44:59 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B72D1B27CE for ; Sun, 8 Jun 2014 20:44:59 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id x12so1393363qac.35 for ; Sun, 08 Jun 2014 20:44:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WdWc/ATGhEpwD12H71prJ2n3C+Zop1WgEudh8053/ng=; b=hGQe3VBy17iXPanEkQ79IXX3Mdl2MEaA25DDfWMS4kZ9ulYuBl+Wbgjdwa3dyFYQUj kwS0ZujKH4s7b1Win0Rv3Vhq+U0jZcQG6Ui42/9S2mCsrDzz13lg3HoLkX5/6ZN/HESm ukO3FkMKqp4wCLak3E9hlf2OUOE20m4iXA10gkGNLMH9ikdBN67+imw5wNIKVWJuaGVu 5kYje1ONObnwJrNYNatNBXO0wakv9jzh7N1iYQp3mVuhxpDKVwndrHIVsIj4a5T6Ns+z SI1pj1X/68DjWRZYG+IKhDc1X6EBqF4a+bYg8N8FcMWfOXkhF7bCCyr2EfYIew4iVyac u8Pg== X-Gm-Message-State: ALoCoQmiCzgwZLtWQjo05vR6SM8R8e9XATeUTIZ++IauYBkuzL/4WFNR4/z9y0+oV9sVUnUZp4pm MIME-Version: 1.0 X-Received: by 10.140.41.75 with SMTP id y69mr27301906qgy.34.1402285498525; Sun, 08 Jun 2014 20:44:58 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Sun, 8 Jun 2014 20:44:58 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Jun 2014 20:44:58 -0700 Message-ID: From: Andy Bierman To: feng.chong33@zte.com.cn Content-Type: multipart/alternative; boundary=001a11c126ba03b6f704fb5f0951 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/OdXenHZPY5WSJycYh02A-4Jd5xY Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 03:45:02 -0000 --001a11c126ba03b6f704fb5f0951 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Sun, Jun 8, 2014 at 8:18 PM, wrote: > Andy, > thanks,:) > I understand only presence container or leaf node with empty type can > be placed 'replace' attribute > and have a empty node subtree. Is it right? > no. any container. anyxml. empty leaf. zero-length string leaf. /frank > > Andy Bierman =D0=B4=D3=DA 2014-06-09 10:36:16: > > > Andy Bierman > > 2014-06-09 10:36 > > > > =CA=D5=BC=FE=C8=CB > > > > feng.chong33@zte.com.cn, > > > > =B3=AD=CB=CD > > > > dou.wei1@zte.com.cn, Netconf , > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > =D6=F7=CC=E2 > > > > Re: [Netconf] Some questions about the usage of 'operation' > > attribute in edit-config > > > > > > > On Sun, Jun 8, 2014 at 6:18 PM, wrote: > > Andy=A3=AC > > I have looked through this section for many times. In my opinion, I > think > > the element contains attribute 'replace' must have subtree, and this > subtree > > should be a valid configuration. But my colleagues don't think so, > > they argued > > that the empty configuration is also configuration, they want to > use'replace' > > as 'remove', I can't persuade them, :) > > So,I want to get a clarification, thanks. > > > > you are both right ;-) > > > > the replace attribute does have to appear in a subtree, but a subtree > may be > > an empty node (if it is schema valid). > > > > start: > > > > > > > > 42 > > > > > > > > replace foo: > > > > > > > > > > > > result: > > > > > > > > > > > > The text seems very clear to me. > > > > /frank > > > > Andy > > > > In your example, the 'foo' MUST be a presence container? > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-07 02:43:28: > > > > > Andy Bierman > > > 2014-06-07 02:43 > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > feng.chong33@zte.com.cn, > > > > > > =B3=AD=CB=CD > > > > > > dou.wei1@zte.com.cn, Netconf , > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > =D6=F7=CC=E2 > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > attribute in edit-config > > > > > > > > > > > On Thu, Jun 5, 2014 at 11:18 PM, wrote: > > > andy, > > > Thanks a lot. > > > Can you answer the first question? 'replace' can be used as > 'remove'? > > > > > > Read RFC 6241, sec. 7.2 Attributes section. > > > It explains the difference between the NETCONF > operations. > > > > > > > > > /frank > > > > > > Andy > > > > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-05 23:46:53: > > > > > > > Andy Bierman > > > > 2014-06-05 23:46 > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > =B3=AD=CB=CD > > > > > > > > Netconf , ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, > > > > xiao.yuqing@zte.com.cn > > > > > > > > =D6=F7=CC=E2 > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > attribute in edit-config > > > > > > > > > > > > > > > On Wed, Jun 4, 2014 at 6:35 PM, wrote: > > > > Hi all, > > > > I have some questions about the usage of 'operation' attribute > > > > in edit-config. > > > > 1. 'replace' attribute can only be used to remove configuration? > > > > For example, the rpc request listed below is valid? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.How to process nested operation attribute? > > > > For example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eth0/0/0 > > > > > > > > true > > > > > > > > > > > > > > > > > > > > > > > > > > > > The sequence of process is merge interface name 'eth0/0/0' and > > > > remove mtu and merge enabled to 'true' > > > > or merge interface name 'eth0/0/0' and > > > > merge enabled to 'true' and remove mtu? > > > > In other words, NETCONF will process outer layer operation > > > > firstly and process inner layer operation later, or process > > > > operations in accordance with XML tree traversal order? > > > > > > > > > > > > There is no required processing order. > > > > It is an implementation detail. > > > > Some things to consider: > > > > 1) all operations are against the target datastore at the start o= f > > > > the operation > > > > 2) the operations are all-or-none, not incremental > > > > 2a) this implies that create within delete, or delete within > > > > create, is always an error > > > > because 'data-exists' or 'data-missing' must be true > > > > > > > > In your example there is no problem because 'remove' works even if > > > > the data is missing. > > > > > > > > > > > > > > > > 3. If other operation attribute nested in operation attribute > > > > 'remove',what should NETCONF server do? Only process remove > operation? > > > > > > > > 4. Can NETCONF support the nested operation attribute equals to > > > > parent operation attribute? > > > > > > > > /frank > > > > > > > > Andy > > > > > > > > > > > > -------------------------------------------------------- > > > > ZTE Information Security Notice: The information contained in this > > > > mail (and any attachment transmitted herewith) is privileged and > > > > confidential and is intended for the exclusive use of the addressee > > > > (s). If you are not an intended recipient, any disclosure, > > > > reproduction, distribution or other dissemination or use of the > > > > information contained is strictly prohibited. If you have received > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail (and any attachment transmitted herewith) is privileged and > > > confidential and is intended for the exclusive use of the addressee > > > (s). If you are not an intended recipient, any disclosure, > > > reproduction, distribution or other dissemination or use of the > > > information contained is strictly prohibited. If you have received > > > this mail in error, please delete it and notify us immediately. > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail (and any attachment transmitted herewith) is privileged and > > confidential and is intended for the exclusive use of the addressee > > (s). If you are not an intended recipient, any disclosure, > > reproduction, distribution or other dissemination or use of the > > information contained is strictly prohibited. If you have received > > this mail in error, please delete it and notify us immediately. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > --001a11c126ba03b6f704fb5f0951 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 8, 2014 at 8:18 PM, <feng.chong33@zte.com.cn> wrote:
Andy,
   thanks,:)
   I understand only presence container or leaf node with empty type can be placed 'replace' attr= ibute
and have a empty node subtree. Is it right?
 

no. any container. an= yxml. empty leaf. zero-length string leaf.



/frank

Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-09 10:36:16:

> Andy Bierman <andy@yumaworks.com>
> 2014-06-09 10:36
>
> =CA=D5=BC=FE=C8=CB
>
> feng.chon= g33@zte.com.cn,
>
> =B3=AD=CB=CD
>
> dou.wei1@zte.= com.cn, Netconf <netconf@ietf.org>,
> xiao.yuqin= g@zte.com.cn, ye= .xu1@zte.com.cn
>
> =D6=F7=CC=E2
>
> Re: [Netconf] Some questions about the usage of 'operation' > attribute in edit-config
>
>

> On Sun, Jun 8, 2014 at 6:18 PM, <feng.chong33@zte.com.cn> wrote:
> Andy=A3=AC
>     I have looked through this section for many times. In my opinion, I think
> the element contains attribute 'replace' must have subtree, an= d this subtree
> should be a valid configuration. But my colleagues don't think so,
> they argued
> that the empty configuration is also configuration, they want to use&#= 39;replace'
> as 'remove', I can't persuade them, :)
>     So,I want to get a clarification, thanks.
>
> you are both right ;-)
>
> the replace attribute does have to appear in a subtree, but a subtree may be
> an empty node (if it is schema valid).
>
> start:
>
>   <config>
>      <foo>
>         <a>42</a>=
>      </foo>
>   </config>
>
> replace foo:
>
>  <config>
>      <foo operation=3D"replace&qu= ot; />
>   </config>
>
> result:
>
>   <config>
>      <foo />
>   </config>
>
> The text seems very clear to me.
>
> /frank
>
> Andy
>

In your example, the 'foo' MUST be a presence contain= er?
 
>
> Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-07 02:43:28:
>
> > Andy Bierman <andy@yumaworks.com>
> > 2014-06-07 02:43
> >
> > =CA=D5=BC=FE=C8=CB
> >
> > feng= .chong33@zte.com.cn,
> >
> > =B3=AD=CB=CD
> >
> > dou.wei1= @zte.com.cn, Netconf <netconf@ietf.org>,
> > xiao.= yuqing@zte.com.cn, ye.xu1@zte.com.cn
> >
> > =D6=F7=CC=E2
> >
> > Re: [Netconf] Some questions about the usage of 'operation= 9;
> > attribute in edit-config
> >
> >
>
> > On Thu, Jun 5, 2014 at 11:18 PM, <feng.chong33@zte.com.cn> wrote:
> > andy,
> >    Thanks a lot.
> >    Can you answer the first question? 'replace'= can be used as 'remove'?
> >
> > Read RFC 6241, sec. 7.2 Attributes section.
> > It explains the difference between the NETCONF <edit-config>= ; operations.
> >
> >  
> > /frank
> >
> > Andy
> >  
> >
> > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-05 23:46:53:
> >
> > > Andy Bierman <andy@yumaworks.com>
> > > 2014-06-05 23:46
> > >
> > > =CA=D5=BC=FE=C8=CB
> > >
> > > feng.chong33@zte.com.cn,
> > >
> > > =B3=AD=CB=CD
> > >
> > > Netconf <netconf@ietf.org>, ye.xu1@zte.com.cn, dou.wei1@zte.com.cn,
> > > = xiao.yuqing@zte.com.cn
> > >
> > > =D6=F7=CC=E2
> > >
> > > Re: [Netconf] Some questions about the usage of 'operati= on'
> > > attribute in edit-config
> > >
> > >
> >
> > > On Wed, Jun 4, 2014 at 6:35 PM, <feng.chong33@zte.com.cn> wrote:
> > > Hi all,
> > >    I have some questions about the usage of  = 'operation' attribute
> > > in edit-config.
> > >    1. 'replace' attribute can only be used= to remove configuration?
> > >       For example, the rpc request listed below is valid?
> > >       <rpc message-id =3D "101"&= gt;
> > >            <edit-config>
> > >                <t= arget>
> > >                   <running/>
> > >                </= target>
> > >                <c= onfig>
> > >                   <interfaces operation=3D "replace"/>
> > >                </= config>
> > >            </edit-config>= ;
> > >       </rpc>
> > >
> > >
> > >    2.How to process nested operation attribute?
> > >      For example:
> > >            <rpc message-id =3D "101">
> > >            <edit-config>
> > >                <t= arget>
> > >                   <running/>
> > >                </= target>
> > >                <c= onfig>
> > >                   <interfaces>
> > >                       <interface operation=3D "merge">
> > >                            <name>eth0/0/0</name>
> > >                            <mtu operation=3D "remove&= quot;>
> > >                            <enabled>true</enalbled&g= t;
> > >                       </interface>
> > >                   </interfaces>
> > >                </= config>
> > >            </edit-config>= ;
> > >       </rpc>
> > >
> > >      The sequence of process is merge interfa= ce name 'eth0/0/0' and
> > > remove mtu and merge enabled to 'true'
> > >                              or merge interface name 'eth0/0/0' and
> > > merge enabled to 'true' and remove mtu?
> > >      In other words, NETCONF will process outer layer operation
> > > firstly and process inner layer operation later, or process
> > > operations in accordance with XML tree traversal order?
> > >  
> > >
> > > There is no required processing order.
> > > It is an implementation detail.
> > > Some things to consider:
> > >   1) all operations are against the target datastore at the start of
> > > the operation
> > >   2) the operations are all-or-none, not incremental
> > >   2a) this implies that create within delete, or delete within
> > > create, is always an error
> > >        because 'data-exists' or = 'data-missing' must be true
> > >
> > > In your example there is no problem because 'remove'= works even if
> > > the data is missing.
> > >
> > >          
> > >
> > > 3. If other operation attribute nested in operation attribut= e
> > > 'remove',what should NETCONF server do? Only process= remove operation?
> > >
> > >   4. Can NETCONF support the nested operation attribute equals to
> > > parent operation attribute?
> > >      
> > > /frank
> > >
> > > Andy
> > >  
> > >
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > > mail (and any attachment transmitted herewith) is privileged and
> > > confidential and is intended for the exclusive use of the addressee
> > > (s).  If you are not an intended recipient, any disclos= ure,
> > > reproduction, distribution or other dissemination or use of the
> > > information contained is strictly prohibited.  If you have received
> > > this mail in error, please delete it and notify us immediate= ly.
> > >
> >
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netcon= f@ietf.org
> > > https://www.ietf.org/mailman/listinfo= /netconf
>
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the address= ee
> > (s).  If you are not an intended recipient, any disclosure,
> > reproduction, distribution or other dissemination or use of the
> > information contained is strictly prohibited.  If you have received
> > this mail in error, please delete it and notify us immediately. > >

>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail (and any attachment transmitted herewith) is privileged and
> confidential and is intended for the exclusive use of the addressee > (s).  If you are not an intended recipient, any disclosure,
> reproduction, distribution or other dissemination or use of the
> information contained is strictly prohibited.  If you have receiv= ed
> this mail in error, please delete it and notify us immediately.
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


--001a11c126ba03b6f704fb5f0951-- From nobody Sun Jun 8 22:40:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040F51B27E5 for ; Sun, 8 Jun 2014 22:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.9 X-Spam-Level: X-Spam-Status: No, score=-98.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGfHuqcxoypX for ; Sun, 8 Jun 2014 22:40:22 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5E31B27E3 for ; Sun, 8 Jun 2014 22:40:21 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id EFBD51264FA9; Mon, 9 Jun 2014 13:40:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s595eFdd070255; Mon, 9 Jun 2014 13:40:15 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: References: To: Andy Bierman MIME-Version: 1.0 X-KeepSent: E996A764:3E772E15-48257CF2:001EF3AB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Mon, 9 Jun 2014 13:40:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-09 13:40:18, Serialize complete at 2014-06-09 13:40:18 Content-Type: multipart/alternative; boundary="=_alternative 001F270C48257CF2_=" X-MAIL: mse02.zte.com.cn s595eFdd070255 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/OyIT9KqB77KrD-Kuw08SmCtqkyk Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 05:40:25 -0000 This is a multipart message in MIME format. --=_alternative 001F270C48257CF2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 L2ZyYW5rDQoNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYt MDkgMTE6NDQ6NTg6DQoNCj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiAy MDE0LTA2LTA5IDExOjQ0DQo+IA0KPiDK1bz+yMsNCj4gDQo+IGZlbmcuY2hvbmczM0B6dGUuY29t LmNuLCANCj4gDQo+ILOty80NCj4gDQo+IGRvdS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgPG5l dGNvbmZAaWV0Zi5vcmc+LCANCj4geGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5j b20uY24NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJv dXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0KPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcN Cj4gDQo+IA0KDQo+IE9uIFN1biwgSnVuIDgsIDIwMTQgYXQgODoxOCBQTSwgPGZlbmcuY2hvbmcz M0B6dGUuY29tLmNuPiB3cm90ZToNCj4gQW5keSwgDQo+ICAgIHRoYW5rcyw6KSANCj4gICAgSSB1 bmRlcnN0YW5kIG9ubHkgcHJlc2VuY2UgY29udGFpbmVyIG9yIGxlYWYgbm9kZSB3aXRoIGVtcHR5 IHR5cGUNCj4gY2FuIGJlIHBsYWNlZCAncmVwbGFjZScgYXR0cmlidXRlIA0KPiBhbmQgaGF2ZSBh IGVtcHR5IG5vZGUgc3VidHJlZS4gSXMgaXQgcmlnaHQ/IA0KPiANCj4gDQo+IG5vLiBhbnkgY29u dGFpbmVyLiBhbnl4bWwuIGVtcHR5IGxlYWYuIHplcm8tbGVuZ3RoIHN0cmluZyBsZWFmLg0KPiAN ClJlYWxseT8gYSBOUCBjb250YWluZXIgY2FuIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBpdHNl bGY/DQoNCj4gL2ZyYW5rIA0KPiANCj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+ INC009ogMjAxNC0wNi0wOSAxMDozNjoxNjoNCj4gDQo+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1 bWF3b3Jrcy5jb20+IA0KPiA+IDIwMTQtMDYtMDkgMTA6MzYgDQo+ID4gDQo+ID4gytW8/sjLIA0K PiA+IA0KPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gPiANCj4gPiCzrcvNIA0KPiA+ IA0KPiA+IGRvdS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+LCAN Cj4gPiB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbiANCj4gPiANCj4g PiDW98ziIA0KPiA+IA0KPiA+IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhl IHVzYWdlIG9mICdvcGVyYXRpb24nIA0KPiA+IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZpZyANCj4g PiANCj4gPiANCj4gDQo+ID4gT24gU3VuLCBKdW4gOCwgMjAxNCBhdCA2OjE4IFBNLCA8ZmVuZy5j aG9uZzMzQHp0ZS5jb20uY24+IHdyb3RlOiANCj4gPiBBbmR5o6wgDQo+ID4gICAgIEkgaGF2ZSBs b29rZWQgdGhyb3VnaCB0aGlzIHNlY3Rpb24gZm9yIG1hbnkgdGltZXMuIEluIG15IA0KPiBvcGlu aW9uLCBJIHRoaW5rIA0KPiA+IHRoZSBlbGVtZW50IGNvbnRhaW5zIGF0dHJpYnV0ZSAncmVwbGFj ZScgbXVzdCBoYXZlIHN1YnRyZWUsIGFuZCANCj4gdGhpcyBzdWJ0cmVlIA0KPiA+IHNob3VsZCBi ZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24uIEJ1dCBteSBjb2xsZWFndWVzIGRvbid0IHRoaW5rIHNv LCANCj4gPiB0aGV5IGFyZ3VlZCANCj4gPiB0aGF0IHRoZSBlbXB0eSBjb25maWd1cmF0aW9uIGlz IGFsc28gY29uZmlndXJhdGlvbiwgdGhleSB3YW50IHRvIA0KPiB1c2UncmVwbGFjZScgDQo+ID4g YXMgJ3JlbW92ZScsIEkgY2FuJ3QgcGVyc3VhZGUgdGhlbSwgOikgDQo+ID4gICAgIFNvLEkgd2Fu dCB0byBnZXQgYSBjbGFyaWZpY2F0aW9uLCB0aGFua3MuIA0KPiA+IA0KPiA+IHlvdSBhcmUgYm90 aCByaWdodCA7LSkgDQo+ID4gDQo+ID4gdGhlIHJlcGxhY2UgYXR0cmlidXRlIGRvZXMgaGF2ZSB0 byBhcHBlYXIgaW4gYSBzdWJ0cmVlLCBidXQgYSBzdWJ0cmVlIA0KbWF5IGJlDQo+ID4gYW4gZW1w dHkgbm9kZSAoaWYgaXQgaXMgc2NoZW1hIHZhbGlkKS4gDQo+ID4gDQo+ID4gc3RhcnQ6IA0KPiA+ IA0KPiA+ICAgPGNvbmZpZz4gDQo+ID4gICAgICA8Zm9vPiANCj4gPiAgICAgICAgIDxhPjQyPC9h PiANCj4gPiAgICAgIDwvZm9vPiANCj4gPiAgIDwvY29uZmlnPiANCj4gPiANCj4gPiByZXBsYWNl IGZvbzogDQo+ID4gDQo+ID4gIDxjb25maWc+IA0KPiA+ICAgICAgPGZvbyBvcGVyYXRpb249InJl cGxhY2UiIC8+IA0KPiA+ICAgPC9jb25maWc+IA0KPiA+IA0KPiA+IHJlc3VsdDogDQo+ID4gDQo+ ID4gICA8Y29uZmlnPiANCj4gPiAgICAgIDxmb28gLz4gDQo+ID4gICA8L2NvbmZpZz4gDQo+ID4g DQo+ID4gVGhlIHRleHQgc2VlbXMgdmVyeSBjbGVhciB0byBtZS4gDQo+ID4gDQo+ID4gL2ZyYW5r IA0KPiA+IA0KPiA+IEFuZHkgDQo+ID4gDQo+IA0KPiBJbiB5b3VyIGV4YW1wbGUsIHRoZSAnZm9v JyBNVVNUIGJlIGEgcHJlc2VuY2UgY29udGFpbmVyPyANCj4gDQo+ID4gDQo+ID4gQW5keSBCaWVy bWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+INC009ogMjAxNC0wNi0wNyAwMjo0MzoyODoNCj4gPiAN Cj4gPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4gPiA+IDIwMTQtMDYt MDcgMDI6NDMgDQo+ID4gPiANCj4gPiA+IMrVvP7IyyANCj4gPiA+IA0KPiA+ID4gZmVuZy5jaG9u ZzMzQHp0ZS5jb20uY24sIA0KPiA+ID4gDQo+ID4gPiCzrcvNIA0KPiA+ID4gDQo+ID4gPiBkb3Uu d2VpMUB6dGUuY29tLmNuLCBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgDQo+ID4gPiB4aWFv Lnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbiANCj4gPiA+IA0KPiA+ID4g1vfM 4iANCj4gPiA+IA0KPiA+ID4gUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUg dXNhZ2Ugb2YgJ29wZXJhdGlvbicgDQo+ID4gPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcgDQo+ ID4gPiANCj4gPiA+IA0KPiA+IA0KPiA+ID4gT24gVGh1LCBKdW4gNSwgMjAxNCBhdCAxMToxOCBQ TSwgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiB3cm90ZTogDQo+ID4gPiBhbmR5LCANCj4gPiA+ ICAgIFRoYW5rcyBhIGxvdC4gDQo+ID4gPiAgICBDYW4geW91IGFuc3dlciB0aGUgZmlyc3QgcXVl c3Rpb24/ICdyZXBsYWNlJyBjYW4gYmUgdXNlZCBhcyANCidyZW1vdmUnPyANCj4gPiA+IA0KPiA+ ID4gUmVhZCBSRkMgNjI0MSwgc2VjLiA3LjIgQXR0cmlidXRlcyBzZWN0aW9uLiANCj4gPiA+IEl0 IGV4cGxhaW5zIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIE5FVENPTkYgPGVkaXQtY29uZmln PiANCm9wZXJhdGlvbnMuIA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IC9mcmFuayANCj4gPiA+IA0K PiA+ID4gQW5keSANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVt YXdvcmtzLmNvbT4g0LTT2iAyMDE0LTA2LTA1IDIzOjQ2OjUzOg0KPiA+ID4gDQo+ID4gPiA+IEFu ZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4gPiA+ID4gMjAxNC0wNi0wNSAyMzo0 NiANCj4gPiA+ID4gDQo+ID4gPiA+IMrVvP7IyyANCj4gPiA+ID4gDQo+ID4gPiA+IGZlbmcuY2hv bmczM0B6dGUuY29tLmNuLCANCj4gPiA+ID4gDQo+ID4gPiA+ILOty80gDQo+ID4gPiA+IA0KPiA+ ID4gPiBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgeWUueHUxQHp0ZS5jb20uY24sIA0KZG91 LndlaTFAenRlLmNvbS5jbiwgDQo+ID4gPiA+IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24gDQo+ID4g PiA+IA0KPiA+ID4gPiDW98ziIA0KPiA+ID4gPiANCj4gPiA+ID4gUmU6IFtOZXRjb25mXSBTb21l IHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgDQo+ID4gPiA+IGF0dHJp YnV0ZSBpbiBlZGl0LWNvbmZpZyANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+ IE9uIFdlZCwgSnVuIDQsIDIwMTQgYXQgNjozNSBQTSwgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNu PiB3cm90ZTogDQo+ID4gPiA+IEhpIGFsbCwgDQo+ID4gPiA+ICAgIEkgaGF2ZSBzb21lIHF1ZXN0 aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgICdvcGVyYXRpb24nIGF0dHJpYnV0ZSANCg0KPiA+ID4g PiBpbiBlZGl0LWNvbmZpZy4gDQo+ID4gPiA+ICAgIDEuICdyZXBsYWNlJyBhdHRyaWJ1dGUgY2Fu IG9ubHkgYmUgdXNlZCB0byByZW1vdmUgDQpjb25maWd1cmF0aW9uPyANCj4gPiA+ID4gICAgICAg Rm9yIGV4YW1wbGUsIHRoZSBycGMgcmVxdWVzdCBsaXN0ZWQgYmVsb3cgaXMgdmFsaWQ/IA0KPiA+ ID4gPiAgICAgICA8cnBjIG1lc3NhZ2UtaWQgPSAiMTAxIj4gDQo+ID4gPiA+ICAgICAgICAgICAg PGVkaXQtY29uZmlnPiANCj4gPiA+ID4gICAgICAgICAgICAgICAgPHRhcmdldD4gDQo+ID4gPiA+ ICAgICAgICAgICAgICAgICAgIDxydW5uaW5nLz4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgIDwv dGFyZ2V0PiANCj4gPiA+ID4gICAgICAgICAgICAgICAgPGNvbmZpZz4gDQo+ID4gPiA+ICAgICAg ICAgICAgICAgICAgIDxpbnRlcmZhY2VzIG9wZXJhdGlvbj0gInJlcGxhY2UiLz4gDQo+ID4gPiA+ ICAgICAgICAgICAgICAgIDwvY29uZmlnPiANCj4gPiA+ID4gICAgICAgICAgICA8L2VkaXQtY29u ZmlnPiANCj4gPiA+ID4gICAgICAgPC9ycGM+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+ ICAgIDIuSG93IHRvIHByb2Nlc3MgbmVzdGVkIG9wZXJhdGlvbiBhdHRyaWJ1dGU/IA0KPiA+ID4g PiAgICAgIEZvciBleGFtcGxlOiANCj4gPiA+ID4gICAgICAgICAgICA8cnBjIG1lc3NhZ2UtaWQg PSAiMTAxIj4gDQo+ID4gPiA+ICAgICAgICAgICAgPGVkaXQtY29uZmlnPiANCj4gPiA+ID4gICAg ICAgICAgICAgICAgPHRhcmdldD4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgIDxydW5uaW5n Lz4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgIDwvdGFyZ2V0PiANCj4gPiA+ID4gICAgICAgICAg ICAgICAgPGNvbmZpZz4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgIDxpbnRlcmZhY2VzPiAN Cj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgIDxpbnRlcmZhY2Ugb3BlcmF0aW9uPSAibWVy Z2UiPiANCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPG5hbWU+ZXRoMC8wLzA8 L25hbWU+IA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bXR1IG9wZXJhdGlv bj0gInJlbW92ZSI+IA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZW5hYmxl ZD50cnVlPC9lbmFsYmxlZD4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICA8L2ludGVy ZmFjZT4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgIDwvaW50ZXJmYWNlcz4gDQo+ID4gPiA+ ICAgICAgICAgICAgICAgIDwvY29uZmlnPiANCj4gPiA+ID4gICAgICAgICAgICA8L2VkaXQtY29u ZmlnPiANCj4gPiA+ID4gICAgICAgPC9ycGM+IA0KPiA+ID4gPiANCj4gPiA+ID4gICAgICBUaGUg c2VxdWVuY2Ugb2YgcHJvY2VzcyBpcyBtZXJnZSBpbnRlcmZhY2UgbmFtZSAnZXRoMC8wLzAnIA0K YW5kIA0KPiA+ID4gPiByZW1vdmUgbXR1IGFuZCBtZXJnZSBlbmFibGVkIHRvICd0cnVlJyANCj4g PiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvciBtZXJnZSBpbnRlcmZhY2UgbmFt ZSAnZXRoMC8wLzAnIA0KYW5kIA0KPiA+ID4gPiBtZXJnZSBlbmFibGVkIHRvICd0cnVlJyBhbmQg cmVtb3ZlIG10dT8gDQo+ID4gPiA+ICAgICAgSW4gb3RoZXIgd29yZHMsIE5FVENPTkYgd2lsbCBw cm9jZXNzIG91dGVyIGxheWVyIG9wZXJhdGlvbiANCj4gPiA+ID4gZmlyc3RseSBhbmQgcHJvY2Vz cyBpbm5lciBsYXllciBvcGVyYXRpb24gbGF0ZXIsIG9yIHByb2Nlc3MgDQo+ID4gPiA+IG9wZXJh dGlvbnMgaW4gYWNjb3JkYW5jZSB3aXRoIFhNTCB0cmVlIHRyYXZlcnNhbCBvcmRlcj8gDQo+ID4g PiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gVGhlcmUgaXMgbm8gcmVxdWlyZWQgcHJvY2Vzc2luZyBv cmRlci4gDQo+ID4gPiA+IEl0IGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4gDQo+ID4gPiA+ IFNvbWUgdGhpbmdzIHRvIGNvbnNpZGVyOiANCj4gPiA+ID4gICAxKSBhbGwgb3BlcmF0aW9ucyBh cmUgYWdhaW5zdCB0aGUgdGFyZ2V0IGRhdGFzdG9yZSBhdCB0aGUgc3RhcnQgDQpvZg0KPiA+ID4g PiB0aGUgb3BlcmF0aW9uIA0KPiA+ID4gPiAgIDIpIHRoZSBvcGVyYXRpb25zIGFyZSBhbGwtb3It bm9uZSwgbm90IGluY3JlbWVudGFsIA0KPiA+ID4gPiAgIDJhKSB0aGlzIGltcGxpZXMgdGhhdCBj cmVhdGUgd2l0aGluIGRlbGV0ZSwgb3IgZGVsZXRlIHdpdGhpbiANCj4gPiA+ID4gY3JlYXRlLCBp cyBhbHdheXMgYW4gZXJyb3IgDQo+ID4gPiA+ICAgICAgICBiZWNhdXNlICdkYXRhLWV4aXN0cycg b3IgJ2RhdGEtbWlzc2luZycgbXVzdCBiZSB0cnVlIA0KPiA+ID4gPiANCj4gPiA+ID4gSW4geW91 ciBleGFtcGxlIHRoZXJlIGlzIG5vIHByb2JsZW0gYmVjYXVzZSAncmVtb3ZlJyB3b3JrcyBldmVu IGlmIA0KDQo+ID4gPiA+IHRoZSBkYXRhIGlzIG1pc3NpbmcuIA0KPiA+ID4gPiANCj4gPiA+ID4g DQo+ID4gPiA+IA0KPiA+ID4gPiAzLiBJZiBvdGhlciBvcGVyYXRpb24gYXR0cmlidXRlIG5lc3Rl ZCBpbiBvcGVyYXRpb24gYXR0cmlidXRlIA0KPiA+ID4gPiAncmVtb3ZlJyx3aGF0IHNob3VsZCBO RVRDT05GIHNlcnZlciBkbz8gT25seSBwcm9jZXNzIHJlbW92ZSANCm9wZXJhdGlvbj8gDQo+ID4g PiA+IA0KPiA+ID4gPiAgIDQuIENhbiBORVRDT05GIHN1cHBvcnQgdGhlIG5lc3RlZCBvcGVyYXRp b24gYXR0cmlidXRlIGVxdWFscyB0byANCj4gPiA+ID4gcGFyZW50IG9wZXJhdGlvbiBhdHRyaWJ1 dGU/IA0KPiA+ID4gPiANCj4gPiA+ID4gL2ZyYW5rIA0KPiA+ID4gPiANCj4gPiA+ID4gQW5keSAN Cj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiBaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgDQoNCj4gPiA+ ID4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2 aWxlZ2VkIGFuZCANCj4gPiA+ID4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhl IGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIA0KYWRkcmVzc2VlDQo+ID4gPiA+IChzKS4gIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPiA+ID4gPiBy ZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBv ZiB0aGUgDQo+ID4gPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiAgSWYgeW91IGhhdmUgDQpyZWNlaXZlZCANCj4gPiA+ID4gdGhpcyBtYWlsIGluIGVycm9y LCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+ID4gPiA+IA0K PiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QN Cj4gPiA+ID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPiANCj4gPiA+IA0KPiA+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IFpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyANCj4gPiA+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgDQo+ID4gPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVk IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+ID4gPiAocykuICBJZiB5 b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gPiA+ IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNl IG9mIHRoZSANCj4gPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgDQo+ID4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiA+IA0KPiANCj4g PiANCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyANCj4gPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJh bnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiA+IGNvbmZpZGVudGlhbCBh bmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUNCj4g PiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9z dXJlLCANCj4gPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0 aW9uIG9yIHVzZSBvZiB0aGUgDQo+ID4gaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCANCj4gPiB0aGlzIG1haWwgaW4gZXJy b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiANCg0K PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIA0KPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0 ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiBjb25maWRlbnRpYWwgYW5kIGlzIGlu dGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+IChzKS4gIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPiBy ZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBv ZiB0aGUgDQo+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAg SWYgeW91IGhhdmUgcmVjZWl2ZWQgDQo+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0 ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPiANCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 001F270C48257CF2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPkFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQ tNPaIDIwMTQtMDYtMDkNCjExOjQ0OjU4Ojxicj4NCjxicj4NCiZndDsgQW5keSBCaWVybWFuICZs dDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAyMDE0LTA2LTA5IDExOjQ0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBkb3Uud2VpMUB6dGUuY29tLmNuLCBO ZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgPGJyPg0KJmd0OyB4aWFvLnl1cWluZ0B6 dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyA8YnI+DQomZ3Q7INb3zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KJmd0OyBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25zIGFib3V0IHRo ZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyA8YnI+DQomZ3Q7IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZp ZzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4N CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBPbiBTdW4sIEp1biA4LCAy MDE0IGF0IDg6MTggUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5jbiZndDsNCndyb3RlOjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBBbmR5LCA8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDt0aGFua3MsOikgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7SSB1bmRlcnN0YW5k IG9ubHkgcHJlc2VuY2UgY29udGFpbmVyIG9yIGxlYWYgbm9kZSB3aXRoDQplbXB0eSB0eXBlPGJy Pg0KJmd0OyBjYW4gYmUgcGxhY2VkICdyZXBsYWNlJyBhdHRyaWJ1dGUgPGJyPg0KJmd0OyBhbmQg aGF2ZSBhIGVtcHR5IG5vZGUgc3VidHJlZS4gSXMgaXQgcmlnaHQ/IDwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBuby4gYW55IGNvbnRhaW5lci4gYW55eG1sLiBlbXB0eSBs ZWFmLiB6ZXJvLWxlbmd0aCBzdHJpbmcgbGVhZi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5SZWFsbHk/IGEg TlAgY29udGFpbmVyIGNhbiBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24NCml0c2VsZj88L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgL2ZyYW5rIDxicj4NCiZndDsg PGJyPg0KJmd0OyBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsg0LTT2iAy MDE0LTA2LTA5IDEwOjM2OjE2Ojxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFuZHkgQmllcm1h biAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8YnI+DQomZ3Q7ICZndDsgMjAxNC0wNi0wOSAx MDozNiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IMrVvP7IyyA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ILOty80gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBk b3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgPGJy Pg0KJmd0OyAmZ3Q7IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24sIHllLnh1MUB6dGUuY29tLmNuIDxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg1vfM4iA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9m ICdvcGVyYXRpb24nIDxicj4NCiZndDsgJmd0OyBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcgPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBP biBTdW4sIEp1biA4LCAyMDE0IGF0IDY6MTggUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5j biZndDsNCndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgQW5keaOsIDxicj4NCiZndDsgJmd0OyAmbmJz cDsgJm5ic3A7IEkgaGF2ZSBsb29rZWQgdGhyb3VnaCB0aGlzIHNlY3Rpb24gZm9yIG1hbnkgdGlt ZXMuDQpJbiBteSA8YnI+DQomZ3Q7IG9waW5pb24sIEkgdGhpbmsgPGJyPg0KJmd0OyAmZ3Q7IHRo ZSBlbGVtZW50IGNvbnRhaW5zIGF0dHJpYnV0ZSAncmVwbGFjZScgbXVzdCBoYXZlIHN1YnRyZWUs IGFuZA0KPGJyPg0KJmd0OyB0aGlzIHN1YnRyZWUgPGJyPg0KJmd0OyAmZ3Q7IHNob3VsZCBiZSBh IHZhbGlkIGNvbmZpZ3VyYXRpb24uIEJ1dCBteSBjb2xsZWFndWVzIGRvbid0IHRoaW5rDQpzbywg PGJyPg0KJmd0OyAmZ3Q7IHRoZXkgYXJndWVkIDxicj4NCiZndDsgJmd0OyB0aGF0IHRoZSBlbXB0 eSBjb25maWd1cmF0aW9uIGlzIGFsc28gY29uZmlndXJhdGlvbiwgdGhleSB3YW50DQp0byA8YnI+ DQomZ3Q7IHVzZSdyZXBsYWNlJyA8YnI+DQomZ3Q7ICZndDsgYXMgJ3JlbW92ZScsIEkgY2FuJ3Qg cGVyc3VhZGUgdGhlbSwgOikgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgU28sSSB3YW50 IHRvIGdldCBhIGNsYXJpZmljYXRpb24sIHRoYW5rcy4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyB5b3UgYXJlIGJvdGggcmlnaHQgOy0pIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgdGhlIHJlcGxhY2UgYXR0cmlidXRlIGRvZXMgaGF2ZSB0byBhcHBlYXIgaW4gYSBzdWJ0 cmVlLCBidXQgYQ0Kc3VidHJlZSBtYXkgYmU8YnI+DQomZ3Q7ICZndDsgYW4gZW1wdHkgbm9kZSAo aWYgaXQgaXMgc2NoZW1hIHZhbGlkKS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBz dGFydDogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJmx0O2NvbmZpZyZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ZvbyZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7YSZndDs0MiZsdDsvYSZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9mb28mZ3Q7IDxicj4N CiZndDsgJmd0OyAmbmJzcDsgJmx0Oy9jb25maWcmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgcmVwbGFjZSBmb286IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5i c3A7Jmx0O2NvbmZpZyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0 O2ZvbyBvcGVyYXRpb249JnF1b3Q7cmVwbGFjZSZxdW90OyAvJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyAmbHQ7L2NvbmZpZyZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBy ZXN1bHQ6IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZsdDtjb25maWcm Z3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtmb28gLyZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbHQ7L2NvbmZpZyZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBUaGUgdGV4dCBzZWVtcyB2ZXJ5IGNsZWFyIHRvIG1lLiA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IC9mcmFuayA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IEFuZHkgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBJbiB5b3VyIGV4YW1w bGUsIHRoZSAnZm9vJyBNVVNUIGJlIGEgcHJlc2VuY2UgY29udGFpbmVyPyA8YnI+DQomZ3Q7ICZu YnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5k eUB5dW1hd29ya3MuY29tJmd0OyDQtNPaIDIwMTQtMDYtMDcgMDI6NDM6Mjg6PGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3Mu Y29tJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAyMDE0LTA2LTA3IDAyOjQzIDxicj4NCiZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IMrVvP7IyyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBkb3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mICZsdDtu ZXRjb25mQGlldGYub3JnJmd0OywgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgeGlhby55dXFpbmdAenRl LmNvbS5jbiwgeWUueHUxQHp0ZS5jb20uY24gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsg1vfM4iA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0 aW9uJw0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYXR0cmlidXRlIGluIGVkaXQtY29uZmlnIDxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBPbiBUaHUsIEp1biA1LCAyMDE0IGF0IDExOjE4IFBNLCAmbHQ7ZmVu Zy5jaG9uZzMzQHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYW5k eSwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RoYW5rcyBhIGxvdC4gPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0NhbiB5b3UgYW5zd2VyIHRoZSBmaXJzdCBxdWVz dGlvbj8gJ3JlcGxhY2UnDQpjYW4gYmUgdXNlZCBhcyAncmVtb3ZlJz8gPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmVhZCBSRkMgNjI0MSwgc2VjLiA3LjIgQXR0cmli dXRlcyBzZWN0aW9uLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJdCBleHBsYWlucyB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIHRoZSBORVRDT05GICZsdDtlZGl0LWNvbmZpZyZndDsNCm9wZXJhdGlvbnMu IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAvZnJhbmsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgQW5keSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5j b20mZ3Q7INC009ogMjAxNC0wNi0wNQ0KMjM6NDY6NTM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNv bSZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAyMDE0LTA2LTA1IDIzOjQ2IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyDK1bz+yMsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZlbmcuY2hvbmcz M0B6dGUuY29tLmNuLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDssIHllLnh1MUB6dGUuY29t LmNuLA0KZG91LndlaTFAenRlLmNvbS5jbiwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB4aWFv Lnl1cWluZ0B6dGUuY29tLmNuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyDW98ziIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSB1c2Fn ZSBvZiAnb3BlcmF0aW9uJw0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhdHRyaWJ1dGUgaW4g ZWRpdC1jb25maWcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgT24g V2VkLCBKdW4gNCwgMjAxNCBhdCA2OjM1IFBNLCAmbHQ7ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24m Z3Q7DQp3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSBhbGwsIDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0kgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0 aGUgdXNhZ2UNCm9mICZuYnNwOydvcGVyYXRpb24nIGF0dHJpYnV0ZSA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGluIGVkaXQtY29uZmlnLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsxLiAncmVwbGFjZScgYXR0cmlidXRlIGNhbiBvbmx5IGJlIHVzZWQNCnRvIHJlbW92 ZSBjb25maWd1cmF0aW9uPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEZvciBleGFtcGxlLCB0aGUgcnBjIHJlcXVlc3QgbGlzdGVkDQpiZWxvdyBpcyB2YWxp ZD8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7cnBj IG1lc3NhZ2UtaWQgPSAmcXVvdDsxMDEmcXVvdDsmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2VkaXQtY29u ZmlnJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3RhcmdldCZndDsNCjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZsdDtydW5uaW5nLyZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0Oy90YXJnZXQmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Y29u ZmlnJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJmx0O2ludGVyZmFjZXMg b3BlcmF0aW9uPSAmcXVvdDtyZXBsYWNlJnF1b3Q7LyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0Oy9jb25maWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9lZGl0LWNvbmZpZyZndDsNCjxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9ycGMmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsyLkhvdyB0byBwcm9jZXNzIG5lc3RlZCBv cGVyYXRpb24gYXR0cmlidXRlPw0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwO0ZvciBleGFtcGxlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3JwYyBtZXNzYWdlLWlkDQo9ICZx dW90OzEwMSZxdW90OyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtlZGl0LWNvbmZpZyZndDsNCjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZsdDt0YXJnZXQmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbHQ7cnVubmluZy8mZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvdGFy Z2V0Jmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2NvbmZpZyZndDsNCjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZsdDtpbnRlcmZhY2VzJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtpbnRlcmZhY2Ugb3BlcmF0aW9u PSAmcXVvdDttZXJnZSZxdW90OyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtuYW1lJmd0O2V0aDAvMC8wJmx0 Oy9uYW1lJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDttdHUgb3BlcmF0aW9uPSAmcXVvdDtyZW1vdmUmcXVv dDsmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2VuYWJsZWQmZ3Q7dHJ1ZSZsdDsvZW5hbGJsZWQmZ3Q7DQo8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvaW50ZXJm YWNlJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbHQ7L2ludGVyZmFjZXMm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvY29uZmlnJmd0Ow0KPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZs dDsvZWRpdC1jb25maWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDsvcnBjJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgc2VxdWVuY2Ugb2YgcHJv Y2VzcyBpcyBtZXJnZQ0KaW50ZXJmYWNlIG5hbWUgJ2V0aDAvMC8wJyBhbmQgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyByZW1vdmUgbXR1IGFuZCBtZXJnZSBlbmFibGVkIHRvICd0cnVlJyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO29yIG1lcmdlIGludGVyZmFjZSBuYW1lDQonZXRoMC8wLzAnIGFuZCA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1lcmdlIGVuYWJsZWQgdG8gJ3RydWUnIGFuZCByZW1vdmUg bXR1PyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW4gb3Ro ZXIgd29yZHMsIE5FVENPTkYgd2lsbCBwcm9jZXNzDQpvdXRlciBsYXllciBvcGVyYXRpb24gPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBmaXJzdGx5IGFuZCBwcm9jZXNzIGlubmVyIGxheWVyIG9w ZXJhdGlvbiBsYXRlciwgb3INCnByb2Nlc3MgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBvcGVy YXRpb25zIGluIGFjY29yZGFuY2Ugd2l0aCBYTUwgdHJlZSB0cmF2ZXJzYWwgb3JkZXI/DQo8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm8gcmVxdWlyZWQgcHJvY2Vzc2luZyBv cmRlci4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJdCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBk ZXRhaWwuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU29tZSB0aGluZ3MgdG8gY29uc2lkZXI6 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDEpIGFsbCBvcGVyYXRpb25zIGFyZSBh Z2FpbnN0IHRoZSB0YXJnZXQgZGF0YXN0b3JlDQphdCB0aGUgc3RhcnQgb2Y8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHRoZSBvcGVyYXRpb24gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz cDsgMikgdGhlIG9wZXJhdGlvbnMgYXJlIGFsbC1vci1ub25lLCBub3QgaW5jcmVtZW50YWwNCjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDJhKSB0aGlzIGltcGxpZXMgdGhhdCBjcmVh dGUgd2l0aGluIGRlbGV0ZSwNCm9yIGRlbGV0ZSB3aXRoaW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBjcmVhdGUsIGlzIGFsd2F5cyBhbiBlcnJvciA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlY2F1c2UgJ2RhdGEtZXhpc3RzJyBvcg0KJ2Rh dGEtbWlzc2luZycgbXVzdCBiZSB0cnVlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJbiB5b3VyIGV4YW1wbGUgdGhlcmUgaXMgbm8gcHJvYmxlbSBi ZWNhdXNlICdyZW1vdmUnDQp3b3JrcyBldmVuIGlmIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg dGhlIGRhdGEgaXMgbWlzc2luZy4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgMy4gSWYgb3RoZXIg b3BlcmF0aW9uIGF0dHJpYnV0ZSBuZXN0ZWQgaW4gb3BlcmF0aW9uDQphdHRyaWJ1dGUgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAncmVtb3ZlJyx3aGF0IHNob3VsZCBORVRDT05GIHNlcnZlciBk bz8gT25seSBwcm9jZXNzDQpyZW1vdmUgb3BlcmF0aW9uPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDQuIENhbiBORVRDT05GIHN1cHBv cnQgdGhlIG5lc3RlZCBvcGVyYXRpb24NCmF0dHJpYnV0ZSBlcXVhbHMgdG8gPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBwYXJlbnQgb3BlcmF0aW9uIGF0dHJpYnV0ZT8gPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IC9mcmFuayA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgQW5keSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQNCmluIHRoaXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBtYWlsIChhbmQgYW55IGF0 dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQNCmFuZCA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBl eGNsdXNpdmUgdXNlDQpvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAo cykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55DQpkaXNj bG9zdXJlLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3INCnVzZSBvZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g Jm5ic3A7SWYNCnlvdSBoYXZlIHJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhp cyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMNCmltbWVkaWF0 ZWx5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBOZXRjb25mQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiZndDsgJmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQNCmluIHRoaXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbWFpbCAoYW5k IGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkDQphbmQg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhl IGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQphZGRyZXNzZWU8YnI+DQomZ3Q7ICZndDsgJmd0OyAocyku ICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1 cmUsDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBv dGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZQ0Kb2YgdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAmbmJzcDtJZiB5b3UN CmhhdmUgcmVjZWl2ZWQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhpcyBtYWlsIGluIGVycm9yLCBw bGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0 OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4NCnRoaXMgPGJyPg0KJmd0OyAmZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVu dCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZA0KYW5kIDxicj4NCiZndDsgJmd0 OyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0 aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4g aW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwNCjxicj4NCiZndDsgJmd0OyByZXBy b2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0 aGUNCjxicj4NCiZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUNCnJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyB0aGlz IG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVs eS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KPGJyPg0KJmd0OyBtYWlsIChh bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k IDxicj4NCiZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZTxicj4NCiZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCA8YnI+DQomZ3Q7IHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSA8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk LiAmbmJzcDtJZiB5b3UgaGF2ZSByZWNlaXZlZA0KPGJyPg0KJmd0OyB0aGlzIG1haWwgaW4gZXJy b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQomZ3Q7 IDxicj4NCjwvZm9udD48L3R0Pg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMg cHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1 c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVk IHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9y IG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBp biBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8 L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 001F270C48257CF2_=-- From nobody Sun Jun 8 23:05:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E461B27EE for ; Sun, 8 Jun 2014 23:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a3kTECG-Ury for ; Sun, 8 Jun 2014 23:05:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD481B27ED for ; Sun, 8 Jun 2014 23:05:25 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E98B1280F26; Mon, 9 Jun 2014 08:04:07 +0200 (CEST) Date: Mon, 09 Jun 2014 08:05:22 +0200 (CEST) Message-Id: <20140609.080522.297779351.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8EUNv_CpW3SCNFTgMbogHvEDUao Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, netconf@ietf.org, xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 06:05:27 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBTdW4sIEp1biA4 LCAyMDE0IGF0IDY6MTggUE0sIDxmZW5nLmNob25nMzNAenRlLmNvbS5jbj4gd3JvdGU6DQo+IA0K PiA+IEFuZHnvvIwNCj4gPiAgICAgSSBoYXZlIGxvb2tlZCB0aHJvdWdoIHRoaXMgc2VjdGlvbiBm b3IgbWFueSB0aW1lcy4gSW4gbXkgb3BpbmlvbiwgSQ0KPiA+IHRoaW5rDQo+ID4gdGhlIGVsZW1l bnQgY29udGFpbnMgYXR0cmlidXRlICdyZXBsYWNlJyBtdXN0IGhhdmUgc3VidHJlZSwgYW5kIHRo aXMNCj4gPiBzdWJ0cmVlDQo+ID4gc2hvdWxkIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbi4gQnV0 IG15IGNvbGxlYWd1ZXMgZG9uJ3QgdGhpbmsgc28sIHRoZXkNCj4gPiBhcmd1ZWQNCj4gPiB0aGF0 IHRoZSBlbXB0eSBjb25maWd1cmF0aW9uIGlzIGFsc28gY29uZmlndXJhdGlvbiwgdGhleSB3YW50 IHRvIHVzZQ0KPiA+ICdyZXBsYWNlJw0KPiA+IGFzICdyZW1vdmUnLCBJIGNhbid0IHBlcnN1YWRl IHRoZW0sIDopDQo+ID4gICAgIFNvLEkgd2FudCB0byBnZXQgYSBjbGFyaWZpY2F0aW9uLCB0aGFu a3MuDQo+ID4NCj4gDQo+IHlvdSBhcmUgYm90aCByaWdodCA7LSkNCj4gDQo+IHRoZSByZXBsYWNl IGF0dHJpYnV0ZSBkb2VzIGhhdmUgdG8gYXBwZWFyIGluIGEgc3VidHJlZSwgYnV0IGEgc3VidHJl ZSBtYXkgYmUNCj4gYW4gZW1wdHkgbm9kZSAoaWYgaXQgaXMgc2NoZW1hIHZhbGlkKS4NCj4gDQo+ IHN0YXJ0Og0KPiANCj4gICA8Y29uZmlnPg0KPiAgICAgIDxmb28+DQo+ICAgICAgICAgPGE+NDI8 L2E+DQo+ICAgICAgPC9mb28+DQo+ICAgPC9jb25maWc+DQo+IA0KPiByZXBsYWNlIGZvbzoNCj4g DQo+ICA8Y29uZmlnPg0KPiAgICAgIDxmb28gb3BlcmF0aW9uPSJyZXBsYWNlIiAvPg0KPiAgIDwv Y29uZmlnPg0KPiANCj4gcmVzdWx0Og0KPiANCj4gICA8Y29uZmlnPg0KPiAgICAgIDxmb28gLz4N Cj4gICA8L2NvbmZpZz4NCg0KVGhpcyBpcyBjb3JyZWN0LCBidXQgdGhlIG9yaWdpbmFsIHF1ZXN0 aW9uIHdhcyBpZiAicmVwbGFjZSIgY291bGQgYmUNCnVzZWQgaW5zdGVhZCBvZiAicmVtb3ZlIiAo aWYgSSB1bmRlcnN0YW5kIHRoZSBxdWVzdGlvbiBjb3JyZWN0bHkpLCBhbmQNCnRoZSBhbnN3ZXIg aXMgbm8sIGl0IGNhbm5vdC4gIFdpdGggdGhlIGNvbmZpZyBhYm92ZSwgaWYgeW91IGluc3RlYWQN CnNlbmQ6DQoNCiAgPGNvbmZpZz4NCiAgICAgIDxmb28gb3BlcmF0aW9uPSJyZXBsYWNlIiAvPg0K ICAgPC9jb25maWc+DQogDQpUaGUgcmVzdWx0IGlzOg0KIA0KICAgPGNvbmZpZz4NCiAgIDwvY29u ZmlnPg0KDQoNCi9tYXJ0aW4NCg== From nobody Sun Jun 8 23:09:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDCF1A0653; Sun, 8 Jun 2014 23:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6KeAMTsL002; Sun, 8 Jun 2014 23:09:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 143F61B27E5; Sun, 8 Jun 2014 23:09:20 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 8427712654D1; Mon, 9 Jun 2014 14:09:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s5968wDF022504; Mon, 9 Jun 2014 14:08:58 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" MIME-Version: 1.0 X-KeepSent: D338F4B4:CF2A3664-48257CF2:0007C45D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Mon, 9 Jun 2014 14:08:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-09 14:09:00, Serialize complete at 2014-06-09 14:09:00 Content-Type: multipart/alternative; boundary="=_alternative 0021C81748257CF2_=" X-MAIL: mse02.zte.com.cn s5968wDF022504 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/p-epBeY8qFCDZGbNRXZlV7VRfw0 Cc: Zhengguangying , Yangang , Netconf , Netconf , Yangshouchuan Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 06:09:24 -0000 This is a multipart message in MIME format. --=_alternative 0021C81748257CF2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQogIFdoYXQncyB5b3VyIHByb2JsZW0/IE5NUyB3YW50cyB0byBnZXQgYSBwYXJ0aWN1bGFy IHJlc3VsdCwgYnV0IHNlcnZlciANCnJldHVybnMgdG9vIGxhcmdlIHJlc3VsdD8gDQogIFdoeSBu b3QgdXNlIHN1YnRyZWUgZmlsdGVyLCBYUEFUSCBmaWx0ZXIgb3IgY2xpZW50J3MgIml0ZXJhdG9y IiBpbiANCmFuZHkncyBwcm9wb3NhbD8NCg0KICBJIHRoaW5rIHRoZSBwcm9ibGVtIGlzIHRoYXQg Tk1TIHdhbnRzIHRvIGdldCBhIHZlcnkgbGFyZ2UgZGF0YSwgYnV0IHRoZXkgDQpkb24ndCB3YW50 IHRvIG9yIGNhbid0IHBhcnNlIHRvbyBsYXJnZSB4bWwgcmVwc29uc2UuIA0KIA0KICBUaGVyZSBh cmUgMiBzb2x1dGlvbnMgdG8gc29sdmUgaXQuIChJIGhhdmUgZGV2ZWxvcGVkIHRoZSBib3RoIG1h bnkgeWVhcnMgDQphZ28sOi0pKQ0KIA0KICBUaGUgZmlyc3QgaXMgeW91ciBzb2x1dGlvbi4gc2Vy dmVyIGtlZXAgYnJlYWsgcG9pbnRzIGFuZCB3YWl0IGZvciANCmNsaWVudCdzIHJlcXVlc3QgdG8g Z2V0IHRoZSBuZXh0IGZyYWdtZW50LiBUaGlzIHNvbHV0aW9uIGhhdmUNCiAgMiBtYWluIHByb2Js ZW1zLiBUaGUgZm9ybWVyIGlzIHRoZSBzZXZlciBtdXN0IGJlIHN0YXRlZnVsIGFuZCB0aGUgc3Rh dGUgDQppcyBoZWxkIGJ5IGNsaWVudC4gSXQncyBub3QgYSBnb29kIGRlc2lnbiBwYXR0ZXJuIGlu IEMvUyBhcmNoaXRlY3R1cmUuDQogIFRoZSBsYXR0ZXIgaXMgaWYgY2xpZW50IHNlbmQgbWFueSBy ZXF1ZXN0cyB0byByZXRyaWV2ZSBsYXJnZSBkYXRhLCB0aGUgDQpzZXZlciBoYXZlIHRvIGtlZXAg bWFueSBicmVhayBwb2ludHMsIGl0J3MgdG9vIGhlYXZ5IGZvciBzZXJ2ZXIuDQoNCiAgVGhlIHNl Y29uZCBpcyAiaXRlcmF0b3IiIHRoYXQgYW5keSBwcm9wb3NlLiBJZiByZXNwb25zZSBkYXRhIGlz IHRvbyANCmxhcmdlLCBjbGllbnQgY2FuIHNlbmQgYSByZXF1ZXN0IHRvIGdldCB0aGUgc3BlY2lh bCBwYXJ0IG9mIHRoZSBkYXRhLGUuZyANCjI1IGluc3RhbmNlcyBvZiB0aGUgbGlzdCwNCiAgYW5k IHNlbmQgYSBuZXh0IHJlcXVlc3QgdG8gZ2V0IHRoZSBuZXh0IHBhcnQuIFNldmVyIGRvZXMgbm90 IG5lZWQgdG8gDQprZWVwIGFueSBicmVhayBwb2ludHMuDQogIEkgdGhpbmsgdGhpcyBzb2x1dGlv biBpcyBiZXR0ZXIgdGhhbiB5b3Vycy4gQnV0IGlmIHRoZXJlIGlzIG5lc3RlZCBsaXN0LCANCnRo ZSBwcm9jZXNzIGlzIG5vdCBzaW1wbGUgYXMgYW5keSdzIGV4YW1wbGUuIA0KIA0KL2ZyYW5rDQoN CiJOZXRjb25mIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiDQtNPaIDIwMTQtMDYtMDUgMTc6 NTg6NTY6DQoNCj4gIkxpdWJpbmcgKExlbykiIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPiANCj4g t6K8/sjLOiAgIk5ldGNvbmYiIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+DQo+IA0KPiAyMDE0 LTA2LTA1IDE3OjU4DQo+IA0KPiDK1bz+yMsNCj4gDQo+IGNob25nIGZlbmcgPGZlbmdjaG9uZ2xs bHlAZ21haWwuY29tPiwgDQo+IA0KPiCzrcvNDQo+IA0KPiBaaGVuZ2d1YW5neWluZyA8emhlbmdn dWFuZ3lpbmdAaHVhd2VpLmNvbT4sIFlhbmdzaG91Y2h1YW4gDQo+IDx5YW5nc2hvdWNodWFuQGh1 YXdlaS5jb20+LCBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgWWFuZ2FuZyANCj4gPHlhbmdh bmdAaHVhd2VpLmNvbT4NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbTmV0Y29uZl0gTmV0Y29uZiBm cmFnbWVudGF0aW9uLS8vRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiANCj4gZm9yIGRyYWZ0 LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0DQo+IA0KPiBIaSBDaG9uZywNCj4gDQo+ IFRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIHJlcGxpZXMg aW5saW5lLg0KPiANCj4gRnJvbTogY2hvbmcgZmVuZyBbbWFpbHRvOmZlbmdjaG9uZ2xsbHlAZ21h aWwuY29tXSANCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDA0LCAyMDE0IDExOjMzIFBNDQo+IFRv OiBMaXViaW5nIChMZW8pDQo+IENjOiBOZXRjb25mOyBaaGVuZ2d1YW5neWluZzsgWWFuZ2FuZw0K PiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIE5ldGNvbmYgZnJhZ21lbnRhdGlvbi0vL0ZXOiBOZXcg VmVyc2lvbiANCj4gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0 aW9uLTAwLnR4dA0KPiANCj4gSGksDQo+ICAgIEkgaGF2ZSByZXZpZXdlZCB0aGlzIG5ldyBkcmFm dC4NCj4gICAgSSB1bmRlcnN0YW5kIHlvdXIgc29sdXRpb24gaXMgdGhhdCBORVRDT05GIHNlcnZl ciByZXNlcnZlIGJyZWFrIA0KPiBwb2ludHMgYW5kIHdhaXQgZm9yIGNsaWVudCB0byByZXRyaWV2 ZSB0aGUgbmV4dCByZXNwb25zZS4NCj4gSSB0aGluayBpdCdzIG5vdCBhIGdvb2Qgc29sdXRpb24s IGJlY2F1c2Ugc2VydmVyIG1heSBuZWVkIHRvIHJlc2VydmUNCj4gbWFueSBicmVhayBwb2ludHMg aWYgdGhlcmUgYSBsYXJnZSBudW1iZXIgb2YgY29uY3VycmVudCByZXF1ZXN0cy4NCj4gSXQncyB0 b28gaGVhdnkgZm9yIHNlcnZlci4gQW5kLCB0aGUgc2VydmVyIG11c3QgYmUgc3RhdGVmdWwgaWYg aXQgDQo+IHN1cHBvcnQgZ2V0LWJsb2NrIGNhcGFiaWxpdHkuDQo+IFtCaW5nXSBUaGUgYnJlYWsg cG9pbnQgZGVzaWduIGlzIG1haW5seSBmb3IgdGhlIGlzc3VlIG9mIHRlcm1pbmF0aW5nDQo+IHRo ZSByZXRyaWV2aW5nIG9wZXJhdGlvbiBpbnN0YW50bHkuIFNvIGJlZm9yZSB0aGlua2luZyBvZiB0 aGUgZGVzaWduDQo+IGFzIHRvbyBoZWF2eSBvciB3aGF0LCBtYXkgSSBhc2sgZG8geW91IGFncmVl IGl0IGlzIGEgcmVxdWlyZW1lbnQgDQo+IG5lZWQgdG8gYmUgc29sdmVkPw0KPiANCj4gVGhlbiBm b3IgdGhlIKGwdG9vIGhlYXZ5obEgY29uc2lkZXJhdGlvbiwgSSBkb26hr3QgdGhpbmsgPGdldC1i bG9jaz4gDQo+IHdvdWxkIGJlIHdpZGUgdXNlZCBhbW9uZyBvcGVyYXRpb25zLCBvbmx5IGlmIHRo ZSByZXRyaWV2aW5nIGRhdGEgaXMgDQo+IHRvbyBiaWcuIFNvIGJhc2ljYWxseSBJIGRvbqGvdCB0 aGluayB0aGVyZSB3b3VsZCBiZSBhIGxhcmdlIG51bWJlciBvZg0KPiBjb25jdXJyZW50IHJlcXVl c3RzLg0KPiANCj4gVGhlIG90aGVyIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIGxpc3RlZCBi ZWxvdzoNCj4gMS4gR2V0LWJsb2NrIGNhcGFiaWxpdHkgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIGdl dC1jb25maWcgb3BlcmF0aW9uJ3MNCj4gYmVoYXZpb3IuIElmIGNsaWVudCB1c2UgZ2V0LWNvbmZp ZyBvcGVyYXRpb24gdG8gcmV0cmlldmUgZGF0YSwNCj4gYWxsIGRhdGEgbXVzdCBiZSBzZW50IGlu IG9uZSByZXNwb25zZSBvciBnZXQtYmxvY2sgY2FwYWJpbGl0eSBzaG91bGQNCj4gYWRkIGEgcGFy YW1ldGVyIHRvIGdldC1jb25maWcgb3BlcmF0aW9uIHRvIGluZGljYXRlIHRoZSANCj4gcmVzcG9u c2UgZGF0YSB3aWxsIGJlIGZyYWdtZW50ZWQuDQo+IFtCaW5nXSBZZXMsIGdldC1ibG9jayBjYXBh YmlsaXR5IGlzIGluIHVzZSBvbmx5IGlmIGJvdGggb2YgdGhlIA0KPiBjbGllbnQgYW5kIHNlcnZl ciBzdXBwb3J0IHRoZSBjYXBhYmlsaXR5LiBBbmQgaW4gY3VycmVudCBkZXNpZ24sIA0KPiA8Z2V0 LWJsb2NrPiBpcyBkZWZpbmVkIGFzIGEgbmV3IG9wZXJhdGlvbiBhbG9uZyB3aXRoIDxnZXQtY29u ZmlnPi4NCj4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IGhhZCB0aGUgYXNzdW1wdGlv biB0aGF0IGl0IGlzIHRoZSANCj4gc2VydmVyIHdobyB0cmlnZ2VycyB0aGUgPGdldC1ibG9jaz4g b3BlcmF0aW9uIGluIGEgcmVzcG9uc2UgdG8gPGdldC0NCj4gY29uZmlnPj8gSWYgc28sIEkgdGhp bmsgaXQgaXMgYSBnb29kIHBvaW50IHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyLiANCj4gDQo+IDIu IEEgc2V0LWlkIGNhbiBiZSBhZ2VkPyB3aGVuIGNsaWVudCBuZXZlciBzZW5kIGEgcmVxdWVzdCB0 byANCj4gcmV0cmlldmUgdGhlIG5leHQgZnJhZ21lbnQgZm9yIGEgbG9uZyB0aW1lLCBJIHRoaW5r IHRoaXMgc2V0LWlkIA0KPiBzaG91bGQgYmUgYWdlZCwNCj4gb3RoZXJ3aXNlLCBzZXJ2ZXIgd2ls bCBiZSByZXNlcnZlIG1vcmUgYW5kIG1vcmUgc2V0LWlkcy4NCj4gMy4gQSBzZXQtaWQgaXMgdW5p cXVlIGluIHNlc3Npb24gbGV2ZWwgb3Igc2VydmVyIGxldmVsPw0KPiA0LiBJZiBhIHNlc3Npb24g aXMga2lsbGVkIG9yIGNsb3NlZCwgb3RoZXIgc2Vzc2lvbiBjYW4gcmV0cmlldmVkIHRoZQ0KPiBu ZXh0IGZyYWdtZW50IGlmIHRoZSBjbGllbnQgcHJvdmlkZSB0aGUgY29ycmVjdCBzZXQtaWQ/DQo+ IFtCaW5nXSBTZXQtaWQgaXMgdXNlZCBmb3IgZGlzdGluZ3Vpc2hpbmcgZnJhZ21lbnRzIGluIGEg c3BlY2lmaWMgDQo+IHNlc3Npb24uIFNvIHdoZW4gdGhlIHNlc3Npb24gaXMga2lsbGVkLCB0aGUg c2V0LWlkcyBhcmUgaW52YWxpZCBhcyB3ZWxsLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBCaW5n DQo+IA0KPiAvZnJhbmsNCj4gDQo+IDIwMTQtMDYtMDQgMTg6MjIgR01UKzA4OjAwIExpdWJpbmcg KExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb20+Og0KPiBIaSBhbGwsDQo+IA0KPiBXZSd2ZSBw b3N0ZWQgYSBuZXcgZHJhZnQsIHdoaWNoIGlzIGFib3V0IE5FVENPTkYgZGF0YSBmcmFnbWVudGF0 aW9uLg0KPiANCj4gVGhlIGJhc2ljIGlkZWEgaXMsIHdoZW4gTk1TIGlzIHJldHJpZXZpbmcgYSBs YXJnZSBzaXplIG9mIGRhdGEgaW4gDQo+IHRoZSBkZXZpY2UsIHRoZSA8cnBjLXJlcGx5PiBtaWdo dCBiZSB2ZXJ5IGJpZyAoZS5nLiB0aGUgcm91dGVzIGluIGEgDQo+IGNvcmUgcm91dGVyKS4NCj4g Q3VycmVudGx5IHRoZXJlIGFyZSBtYWlubHkgdHdvIG1ldGhvZHMgb2YgaGFuZGxpbmcgdGhlIGJp ZyA8cnBjLQ0KPiByZXBseT46IG9uZSBpcyBzdHJlYW0tb3JpZW50ZWQgaGFuZGxpbmc7IHRoZSBv dGhlciBpcyBqdXN0IHJlcXVlc3QgYQ0KPiBwb3J0aW9uIG9mIHRoZSBkYXRhLg0KPiANCj4gVGhp cyBkcmFmdCBjb25zaWRlcnMgYm90aCB0aGUgdHdvIG1ldGhvZHMgYXJlIHByb2JsZW1hdGljIGlu IHNvbWUgDQo+IHNpdHVhdGlvbnMsIGFuZCBwcm9wb3NlcyBhIG5ldyBtZXRob2Qgd2hpY2ggYWxs b3dzIHRoZSBsYXJnZSBzaXplIA0KPiA8cnBjLXJlcGx5PiB0byBiZSBmcmFnbWVudGVkIGluIE5F VENPTkYgbGV2ZWwuDQo+IA0KPiBQbGVhc2UgcmVhZCB0aGUgZHJhZnQgYW5kIGNvbW1lbnQuDQo+ IE1hbnkgdGhhbmtzIQ0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBCaW5nDQo+IA0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAw NCwgMjAxNCA1OjI3IFBNDQo+IFRvOiBMaXViaW5nIChMZW8pOyBMaXViaW5nIChMZW8pOyBaaGVu Z2d1YW5neWluZzsgWmhlbmdndWFuZ3lpbmcNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciANCmRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0DQo+IA0K PiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRp b24tMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmluZyBMaXUg YW5kIHBvc3RlZCB0byB0aGUgSUVURiANCnJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOiAgICAgICAg ICAgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbg0KPiBSZXZpc2lvbjogICAgICAgMDAN Cj4gVGl0bGU6ICAgICAgICAgIEEgTkVUQ09ORiBFeHRlbnNpb24gZm9yIERhdGEgRnJhZ21lbnRh dGlvbg0KPiBEb2N1bWVudCBkYXRlOiAgMjAxNC0wNi0wNA0KPiBHcm91cDogICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOiAgICAgICAgICAxMg0KPiBVUkw6ICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LQ0KPiBuZXRj b25mLWZyYWdtZW50YXRpb24tMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtbmV0Y29uZi0NCj4gZnJhZ21lbnRhdGlvbi8N Cj4gSHRtbGl6ZWQ6ICAgICAgIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1 LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlz IGRvY3VtZW50IGludHJvZHVjZXMgYW4gZXh0ZW5zaW9uIHRvIE5FVENPTkYgKE5ldHdvcmsNCj4g ICAgQ29uZmlndXJhdGlvbikgcHJvdG9jb2wuIFRoZSBleHRlbnNpb24gYWxsb3dzIE5FVENPTkYg dG8gaGFuZGxlIGxhcmdlDQo+ICAgIHNpemUgZGF0YSBhcyBmcmFnbWVudGVkIFJQQyBtZXNzYWdl cy4gU3BlY2lmaWNhbGx5LCB0aGlzIGRvY3VtZW50DQo+ICAgIGRlZmluZXMgYSBuZXcgPGdldC1i bG9jaz4gY2FwYWJpbGl0eSBhbmQgcmVsZXZhbnQgb3BlcmF0aW9ucyB0bw0KPiAgICBoYW5kbGUg dGhlIGZyYWdtZW50YXRpb25zLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCANCnRvb2xzLmlldGYub3JnDQo+IC4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRj b25mIG1haWxpbmcgbGlzdA0KPiBOZXRjb25mQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29u ZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBh biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlh dGVseS4NCg== --=_alternative 0021C81748257CF2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFdoYXQncyB5b3VyIHByb2JsZW0/IE5NUyB3YW50 cw0KdG8gZ2V0IGEgcGFydGljdWxhciByZXN1bHQsIGJ1dCBzZXJ2ZXIgcmV0dXJucyB0b28gbGFy Z2UgcmVzdWx0PyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyBXaHkgbm90IHVzZSBzdWJ0cmVlIGZpbHRlciwgWFBBVEgNCmZpbHRlciBvciBjbGllbnQn cyAmcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPml0ZXJhdG9yPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsNCmluIGFuZHkncyBwcm9w b3NhbD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyBJIHRoaW5rIHRoZSBwcm9ibGVtIGlzIHRoYXQgTk1TDQp3YW50cyB0byBnZXQgYSB2ZXJ5 IGxhcmdlIGRhdGEsIGJ1dCB0aGV5IGRvbid0IHdhbnQgdG8gb3IgY2FuJ3QgcGFyc2UgdG9vDQps YXJnZSB4bWwgcmVwc29uc2UuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7IFRoZXJlIGFyZSAyIHNvbHV0aW9ucyB0byBzb2x2ZQ0KaXQuIChJIGhhdmUgZGV2ZWxv cGVkIHRoZSBib3RoIG1hbnkgeWVhcnMgYWdvLDotKSk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyBUaGUgZmlyc3QgaXMgeW91ciBzb2x1dGlvbi4gc2VydmVyDQpr ZWVwIGJyZWFrIHBvaW50cyBhbmQgd2FpdCBmb3IgY2xpZW50J3MgcmVxdWVzdCB0byBnZXQgdGhl IG5leHQgZnJhZ21lbnQuDQpUaGlzIHNvbHV0aW9uIGhhdmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAyIG1haW4gcHJvYmxlbXMuIFRoZSBmb3JtZXIg aXMNCnRoZSBzZXZlciBtdXN0IGJlIHN0YXRlZnVsIGFuZCB0aGUgc3RhdGUgaXMgaGVsZCBieSBj bGllbnQuIEl0J3Mgbm90IGENCmdvb2QgZGVzaWduIHBhdHRlcm4gaW4gQy9TIGFyY2hpdGVjdHVy ZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBUaGUg bGF0dGVyIGlzIGlmIGNsaWVudCBzZW5kDQptYW55IHJlcXVlc3RzIHRvIHJldHJpZXZlIGxhcmdl IGRhdGEsIHRoZSBzZXZlciBoYXZlIHRvIGtlZXAgbWFueSBicmVhaw0KcG9pbnRzLCBpdCdzIHRv byBoZWF2eSBmb3Igc2VydmVyLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7IFRoZSBzZWNvbmQgaXMgJnF1b3Q7aXRlcmF0b3ImcXVvdDsNCnRo YXQgYW5keSBwcm9wb3NlLiBJZiByZXNwb25zZSBkYXRhIGlzIHRvbyBsYXJnZSwgY2xpZW50IGNh biBzZW5kIGEgcmVxdWVzdA0KdG8gZ2V0IHRoZSBzcGVjaWFsIHBhcnQgb2YgdGhlIGRhdGEsZS5n IDI1IGluc3RhbmNlcyBvZiB0aGUgbGlzdCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyBhbmQgc2VuZCBhIG5leHQgcmVxdWVzdCB0byBnZXQNCnRoZSBu ZXh0IHBhcnQuIFNldmVyIGRvZXMgbm90IG5lZWQgdG8ga2VlcCBhbnkgYnJlYWsgcG9pbnRzLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEkgdGhpbmsg dGhpcyBzb2x1dGlvbiBpcyBiZXR0ZXINCnRoYW4geW91cnMuIEJ1dCBpZiB0aGVyZSBpcyBuZXN0 ZWQgbGlzdCwgdGhlIHByb2Nlc3MgaXMgbm90IHNpbXBsZSBhcyBhbmR5J3MNCmV4YW1wbGUuIDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+L2ZyYW5rPC9mb250Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7TmV0Y29uZiZxdW90OyAmbHQ7bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnJmd0Ow0K0LTT2iAyMDE0LTA2LTA1IDE3OjU4OjU2Ojxicj4NCjxicj4NCiZn dDsgJnF1b3Q7TGl1YmluZyAoTGVvKSZxdW90OyAmbHQ7bGVvLmxpdWJpbmdAaHVhd2VpLmNvbSZn dDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ILeivP7IyzogJm5ic3A7 JnF1b3Q7TmV0Y29uZiZxdW90OyAmbHQ7bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnJmd0Ozxicj4N CiZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDIwMTQtMDYtMDUg MTc6NTg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDK 1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBj aG9uZyBmZW5nICZsdDtmZW5nY2hvbmdsbGx5QGdtYWlsLmNvbSZndDssIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBaaGVuZ2d1YW5neWluZyAmbHQ7emhl bmdndWFuZ3lpbmdAaHVhd2VpLmNvbSZndDssIFlhbmdzaG91Y2h1YW4gPGJyPg0KJmd0OyAmbHQ7 eWFuZ3Nob3VjaHVhbkBodWF3ZWkuY29tJmd0OywgTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9y ZyZndDssDQpZYW5nYW5nIDxicj4NCiZndDsgJmx0O3lhbmdhbmdAaHVhd2VpLmNvbSZndDs8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDW98ziPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgUmU6IFtOZXRjb25m XSBOZXRjb25mIGZyYWdtZW50YXRpb24tLy9GVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uDQo8 YnI+DQomZ3Q7IGZvciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEhpIENob25nLDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29t bWVudHMuIFBsZWFzZSBzZWUNCnJlcGxpZXMgaW5saW5lLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgRnJvbTogY2hvbmcgZmVuZyBbPC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86ZmVuZ2No b25nbGxseUBnbWFpbC5jb20+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86ZmVuZ2Nob25nbGxseUBn bWFpbC5jb208L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj5dDQo8YnI+DQomZ3Q7IFNl bnQ6IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCAxMTozMyBQTTxicj4NCiZndDsgVG86IExpdWJp bmcgKExlbyk8YnI+DQomZ3Q7IENjOiBOZXRjb25mOyBaaGVuZ2d1YW5neWluZzsgWWFuZ2FuZzxi cj4NCiZndDsgU3ViamVjdDogUmU6IFtOZXRjb25mXSBOZXRjb25mIGZyYWdtZW50YXRpb24tLy9G VzogTmV3IFZlcnNpb24gPGJyPg0KJmd0OyBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1uZXRj b25mLWZyYWdtZW50YXRpb24tMDAudHh0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBIaSw8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO0kgaGF2 ZSByZXZpZXdlZCB0aGlzIG5ldyBkcmFmdC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7ICZuYnNwO0kgdW5kZXJzdGFuZCB5b3VyIHNvbHV0aW9uIGlzIHRoYXQN Ck5FVENPTkYgc2VydmVyIHJlc2VydmUgYnJlYWsgPGJyPg0KJmd0OyBwb2ludHMgYW5kIHdhaXQg Zm9yIGNsaWVudCB0byByZXRyaWV2ZSB0aGUgbmV4dCByZXNwb25zZS48L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSSB0aGluayBpdCdzIG5vdCBhIGdvb2Qgc29sdXRpb24s IGJlY2F1c2Ugc2VydmVyDQptYXkgbmVlZCB0byByZXNlcnZlPGJyPg0KJmd0OyBtYW55IGJyZWFr IHBvaW50cyBpZiB0aGVyZSBhIGxhcmdlIG51bWJlciBvZiBjb25jdXJyZW50IHJlcXVlc3RzLjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJdCdzIHRvbyBoZWF2eSBmb3Ig c2VydmVyLiBBbmQsIHRoZSBzZXJ2ZXIgbXVzdA0KYmUgc3RhdGVmdWwgaWYgaXQgPGJyPg0KJmd0 OyBzdXBwb3J0IGdldC1ibG9jayBjYXBhYmlsaXR5LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyBbQmluZ10gVGhlIGJyZWFrIHBvaW50IGRlc2lnbiBpcyBtYWlubHkgZm9y IHRoZQ0KaXNzdWUgb2YgdGVybWluYXRpbmc8YnI+DQomZ3Q7IHRoZSByZXRyaWV2aW5nIG9wZXJh dGlvbiBpbnN0YW50bHkuIFNvIGJlZm9yZSB0aGlua2luZyBvZiB0aGUgZGVzaWduPGJyPg0KJmd0 OyBhcyB0b28gaGVhdnkgb3Igd2hhdCwgbWF5IEkgYXNrIGRvIHlvdSBhZ3JlZSBpdCBpcyBhIHJl cXVpcmVtZW50IDxicj4NCiZndDsgbmVlZCB0byBiZSBzb2x2ZWQ/PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBUaGVuIGZvciB0aGUgobB0b28gaGVhdnmhsSBjb25zaWRlcmF0aW9uLCBJDQpk b26hr3QgdGhpbmsgJmx0O2dldC1ibG9jayZndDsgPGJyPg0KJmd0OyB3b3VsZCBiZSB3aWRlIHVz ZWQgYW1vbmcgb3BlcmF0aW9ucywgb25seSBpZiB0aGUgcmV0cmlldmluZyBkYXRhIGlzDQo8YnI+ DQomZ3Q7IHRvbyBiaWcuIFNvIGJhc2ljYWxseSBJIGRvbqGvdCB0aGluayB0aGVyZSB3b3VsZCBi ZSBhIGxhcmdlIG51bWJlcg0Kb2Y8YnI+DQomZ3Q7IGNvbmN1cnJlbnQgcmVxdWVzdHMuPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGUgb3RoZXIgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBh cmUgbGlzdGVkIGJlbG93OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAx LiBHZXQtYmxvY2sgY2FwYWJpbGl0eSBzaG91bGQgbm90IGNoYW5nZSB0aGUNCmdldC1jb25maWcg b3BlcmF0aW9uJ3M8YnI+DQomZ3Q7IGJlaGF2aW9yLiBJZiBjbGllbnQgdXNlIGdldC1jb25maWcg b3BlcmF0aW9uIHRvIHJldHJpZXZlIGRhdGEsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IGFsbCBkYXRhIG11c3QgYmUgc2VudCBpbiBvbmUgcmVzcG9uc2Ugb3IgZ2V0LWJs b2NrDQpjYXBhYmlsaXR5IHNob3VsZDxicj4NCiZndDsgYWRkIGEgcGFyYW1ldGVyIHRvIGdldC1j b25maWcgb3BlcmF0aW9uIHRvIGluZGljYXRlIHRoZSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgcmVzcG9uc2UgZGF0YSB3aWxsIGJlIGZyYWdtZW50ZWQuPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtCaW5nXSBZZXMsIGdldC1ibG9jayBjYXBh YmlsaXR5IGlzIGluIHVzZSBvbmx5DQppZiBib3RoIG9mIHRoZSA8YnI+DQomZ3Q7IGNsaWVudCBh bmQgc2VydmVyIHN1cHBvcnQgdGhlIGNhcGFiaWxpdHkuIEFuZCBpbiBjdXJyZW50IGRlc2lnbiwg PGJyPg0KJmd0OyAmbHQ7Z2V0LWJsb2NrJmd0OyBpcyBkZWZpbmVkIGFzIGEgbmV3IG9wZXJhdGlv biBhbG9uZyB3aXRoICZsdDtnZXQtY29uZmlnJmd0Oy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IGhhZCB0aGUgYXNz dW1wdGlvbg0KdGhhdCBpdCBpcyB0aGUgPGJyPg0KJmd0OyBzZXJ2ZXIgd2hvIHRyaWdnZXJzIHRo ZSAmbHQ7Z2V0LWJsb2NrJmd0OyBvcGVyYXRpb24gaW4gYSByZXNwb25zZQ0KdG8gJmx0O2dldC08 YnI+DQomZ3Q7IGNvbmZpZyZndDs/IElmIHNvLCBJIHRoaW5rIGl0IGlzIGEgZ29vZCBwb2ludCB0 aGF0IHdlIHNob3VsZCBjb25zaWRlci4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMi4g QSBzZXQtaWQgY2FuIGJlIGFnZWQ/IHdoZW4gY2xpZW50IG5ldmVyIHNlbmQNCmEgcmVxdWVzdCB0 byA8YnI+DQomZ3Q7IHJldHJpZXZlIHRoZSBuZXh0IGZyYWdtZW50IGZvciBhIGxvbmcgdGltZSwg SSB0aGluayB0aGlzIHNldC1pZCA8YnI+DQomZ3Q7IHNob3VsZCBiZSBhZ2VkLDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBvdGhlcndpc2UsIHNlcnZlciB3aWxsIGJlIHJl c2VydmUgbW9yZSBhbmQgbW9yZQ0Kc2V0LWlkcy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgMy4gQSBzZXQtaWQgaXMgdW5pcXVlIGluIHNlc3Npb24gbGV2ZWwgb3Igc2Vy dmVyDQpsZXZlbD88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgNC4gSWYg YSBzZXNzaW9uIGlzIGtpbGxlZCBvciBjbG9zZWQsIG90aGVyIHNlc3Npb24NCmNhbiByZXRyaWV2 ZWQgdGhlPGJyPg0KJmd0OyBuZXh0IGZyYWdtZW50IGlmIHRoZSBjbGllbnQgcHJvdmlkZSB0aGUg Y29ycmVjdCBzZXQtaWQ/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtC aW5nXSBTZXQtaWQgaXMgdXNlZCBmb3IgZGlzdGluZ3Vpc2hpbmcgZnJhZ21lbnRzDQppbiBhIHNw ZWNpZmljIDxicj4NCiZndDsgc2Vzc2lvbi4gU28gd2hlbiB0aGUgc2Vzc2lvbiBpcyBraWxsZWQs IHRoZSBzZXQtaWRzIGFyZSBpbnZhbGlkIGFzDQp3ZWxsLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgQmVzdCByZWdhcmRzLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBCaW5nPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAvZnJhbms8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDIwMTQtMDYtMDQgMTg6MjIgR01UKzA4OjAwIExpdWJpbmcgKExlbykgJmx0 O2xlby5saXViaW5nQGh1YXdlaS5jb20mZ3Q7OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBIaSBhbGwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlJ3ZlIHBvc3RlZCBhIG5l dyBkcmFmdCwgd2hpY2ggaXMgYWJvdXQgTkVUQ09ORiBkYXRhIGZyYWdtZW50YXRpb24uPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRoZSBiYXNpYyBpZGVhIGlzLCB3aGVuIE5NUyBpcyByZXRyaWV2aW5n IGEgbGFyZ2Ugc2l6ZSBvZiBkYXRhIGluDQo8YnI+DQomZ3Q7IHRoZSBkZXZpY2UsIHRoZSAmbHQ7 cnBjLXJlcGx5Jmd0OyBtaWdodCBiZSB2ZXJ5IGJpZyAoZS5nLiB0aGUgcm91dGVzDQppbiBhIDxi cj4NCiZndDsgY29yZSByb3V0ZXIpLjxicj4NCiZndDsgQ3VycmVudGx5IHRoZXJlIGFyZSBtYWlu bHkgdHdvIG1ldGhvZHMgb2YgaGFuZGxpbmcgdGhlIGJpZyAmbHQ7cnBjLTxicj4NCiZndDsgcmVw bHkmZ3Q7OiBvbmUgaXMgc3RyZWFtLW9yaWVudGVkIGhhbmRsaW5nOyB0aGUgb3RoZXIgaXMganVz dCByZXF1ZXN0DQphPGJyPg0KJmd0OyBwb3J0aW9uIG9mIHRoZSBkYXRhLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBUaGlzIGRyYWZ0IGNvbnNpZGVycyBib3RoIHRoZSB0d28gbWV0aG9kcyBhcmUgcHJv YmxlbWF0aWMgaW4gc29tZQ0KPGJyPg0KJmd0OyBzaXR1YXRpb25zLCBhbmQgcHJvcG9zZXMgYSBu ZXcgbWV0aG9kIHdoaWNoIGFsbG93cyB0aGUgbGFyZ2Ugc2l6ZQ0KPGJyPg0KJmd0OyAmbHQ7cnBj LXJlcGx5Jmd0OyB0byBiZSBmcmFnbWVudGVkIGluIE5FVENPTkYgbGV2ZWwuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFBsZWFzZSByZWFkIHRoZSBkcmFmdCBhbmQgY29tbWVudC48YnI+DQomZ3Q7IE1h bnkgdGhhbmtzITxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyBC aW5nPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K Jmd0OyBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgWzwvZm9udD48L3R0PjxhIGhyZWY9 Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPjx0dD48Zm9udCBzaXplPTI+bWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0y Pl08YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCA1OjI3IFBNPGJyPg0K Jmd0OyBUbzogTGl1YmluZyAoTGVvKTsgTGl1YmluZyAoTGVvKTsgWmhlbmdndWFuZ3lpbmc7IFpo ZW5nZ3Vhbmd5aW5nPGJyPg0KJmd0OyBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpdS1uZXRjb25m LWZyYWdtZW50YXRpb24tMDAudHh0PGJyPg0KJmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEJpbmcgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCnJlcG9zaXRvcnkuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IE5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbjxicj4NCiZndDsgUmV2aXNpb246ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDAwPGJyPg0KJmd0OyBUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0EgTkVUQ09ORiBFeHRlbnNpb24gZm9yIERhdGENCkZyYWdtZW50YXRp b248YnI+DQomZ3Q7IERvY3VtZW50IGRhdGU6ICZuYnNwOzIwMTQtMDYtMDQ8YnI+DQomZ3Q7IEdy b3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNz aW9uPGJyPg0KJmd0OyBQYWdlczogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEy PGJyPg0KJmd0OyBVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtbGl1LSI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1saXUtPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0K Jmd0OyBuZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0PGJyPg0KJmd0OyBTdGF0dXM6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtbmV0Y29uZi0iPjx0dD48Zm9udCBzaXplPTI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LW5ldGNvbmYtPC9mb250 PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBmcmFnbWVudGF0aW9uLzxicj4N CiZndDsgSHRtbGl6ZWQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48L3R0PjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1uZXRjb25mLWZyYWdtZW50YXRp b24tMDAiPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6 ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsg Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBhbiBleHRlbnNpb24gdG8gTkVU Q09ORiAoTmV0d29yazxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0NvbmZpZ3VyYXRpb24pIHByb3Rv Y29sLiBUaGUgZXh0ZW5zaW9uIGFsbG93cyBORVRDT05GDQp0byBoYW5kbGUgbGFyZ2U8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDtzaXplIGRhdGEgYXMgZnJhZ21lbnRlZCBSUEMgbWVzc2FnZXMuIFNw ZWNpZmljYWxseSwgdGhpcw0KZG9jdW1lbnQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtkZWZpbmVz IGEgbmV3ICZsdDtnZXQtYmxvY2smZ3Q7IGNhcGFiaWxpdHkgYW5kIHJlbGV2YW50DQpvcGVyYXRp b25zIHRvPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7aGFuZGxlIHRoZSBmcmFnbWVudGF0aW9ucy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2YNCjxicj4NCiZndDsgc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGJyPg0KJmd0OyAuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiZndDsgTmV0Y29uZkBpZXRmLm9yZzxicj4NCiZn dDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmY+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGNvbmY8L2ZvbnQ+PC90dD48L2E+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiZndDsgTmV0Y29uZkBpZXRmLm9y Zzxicj4NCiZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmY+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9 Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlz IHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNs dXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRl ZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBv ciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwg aW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0K PC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 0021C81748257CF2_=-- From nobody Sun Jun 8 23:11:47 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016CB1B27F2 for ; Sun, 8 Jun 2014 23:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96 X-Spam-Level: X-Spam-Status: No, score=-96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3SUtyGxwb2W for ; Sun, 8 Jun 2014 23:11:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29C1A0653 for ; Sun, 8 Jun 2014 23:11:44 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 12A25126551D; Mon, 9 Jun 2014 14:11:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s596BFuZ029846; Mon, 9 Jun 2014 14:11:15 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <20140609.080522.297779351.mbj@tail-f.com> References: <20140609.080522.297779351.mbj@tail-f.com> To: Martin Bjorklund MIME-Version: 1.0 X-KeepSent: 193F4D7F:C26AFCA5-48257CF2:0021E8F7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Mon, 9 Jun 2014 14:11:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-09 14:11:17, Serialize complete at 2014-06-09 14:11:17 Content-Type: multipart/alternative; boundary="=_alternative 0021FDA448257CF2_=" X-MAIL: mse02.zte.com.cn s596BFuZ029846 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NoKXCXBR7__du39P-bTQRMYSHJs Cc: ye.xu1@zte.com.cn, xiao.yuqing@zte.com.cn, dou.wei1@zte.com.cn, netconf@ietf.org Subject: [Netconf] =?gb2312?b?tPC4tDogUmU6ICBTb21lIHF1ZXN0aW9ucyBhYm91dCB0?= =?gb2312?b?aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgYXR0cmlidXRlIGluIGVkaXQtY29u?= =?gb2312?b?Zmln?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 06:11:46 -0000 This is a multipart message in MIME format. --=_alternative 0021FDA448257CF2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 L2ZyYW5rDQoNCk1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiDQtNPaIDIwMTQtMDYt MDkgMTQ6MDU6MjI6DQoNCj4gTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IA0KPiAy MDE0LTA2LTA5IDE0OjA1DQo+IA0KPiDK1bz+yMsNCj4gDQo+IGFuZHlAeXVtYXdvcmtzLmNvbSwg DQo+IA0KPiCzrcvNDQo+IA0KPiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5j b20uY24sIGRvdS53ZWkxQHp0ZS5jb20uY24sIA0KPiBuZXRjb25mQGlldGYub3JnLCB4aWFvLnl1 cWluZ0B6dGUuY29tLmNuDQo+IA0KPiDW98ziDQo+IA0KPiBSZTogW05ldGNvbmZdIFNvbWUgcXVl c3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyANCj4gYXR0cmlidXRlIGluIGVk aXQtY29uZmlnDQo+IA0KPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6 DQo+ID4gT24gU3VuLCBKdW4gOCwgMjAxNCBhdCA2OjE4IFBNLCA8ZmVuZy5jaG9uZzMzQHp0ZS5j b20uY24+IHdyb3RlOg0KPiA+IA0KPiA+ID4gQW5keaOsDQo+ID4gPiAgICAgSSBoYXZlIGxvb2tl ZCB0aHJvdWdoIHRoaXMgc2VjdGlvbiBmb3IgbWFueSB0aW1lcy4gSW4gbXkgDQpvcGluaW9uLCBJ DQo+ID4gPiB0aGluaw0KPiA+ID4gdGhlIGVsZW1lbnQgY29udGFpbnMgYXR0cmlidXRlICdyZXBs YWNlJyBtdXN0IGhhdmUgc3VidHJlZSwgYW5kIHRoaXMNCj4gPiA+IHN1YnRyZWUNCj4gPiA+IHNo b3VsZCBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24uIEJ1dCBteSBjb2xsZWFndWVzIGRvbid0IHRo aW5rIHNvLCANCnRoZXkNCj4gPiA+IGFyZ3VlZA0KPiA+ID4gdGhhdCB0aGUgZW1wdHkgY29uZmln dXJhdGlvbiBpcyBhbHNvIGNvbmZpZ3VyYXRpb24sIHRoZXkgd2FudCB0byB1c2UNCj4gPiA+ICdy ZXBsYWNlJw0KPiA+ID4gYXMgJ3JlbW92ZScsIEkgY2FuJ3QgcGVyc3VhZGUgdGhlbSwgOikNCj4g PiA+ICAgICBTbyxJIHdhbnQgdG8gZ2V0IGEgY2xhcmlmaWNhdGlvbiwgdGhhbmtzLg0KPiA+ID4N Cj4gPiANCj4gPiB5b3UgYXJlIGJvdGggcmlnaHQgOy0pDQo+ID4gDQo+ID4gdGhlIHJlcGxhY2Ug YXR0cmlidXRlIGRvZXMgaGF2ZSB0byBhcHBlYXIgaW4gYSBzdWJ0cmVlLCBidXQgYSBzdWJ0cmVl IA0KbWF5IGJlDQo+ID4gYW4gZW1wdHkgbm9kZSAoaWYgaXQgaXMgc2NoZW1hIHZhbGlkKS4NCj4g PiANCj4gPiBzdGFydDoNCj4gPiANCj4gPiAgIDxjb25maWc+DQo+ID4gICAgICA8Zm9vPg0KPiA+ ICAgICAgICAgPGE+NDI8L2E+DQo+ID4gICAgICA8L2Zvbz4NCj4gPiAgIDwvY29uZmlnPg0KPiA+ IA0KPiA+IHJlcGxhY2UgZm9vOg0KPiA+IA0KPiA+ICA8Y29uZmlnPg0KPiA+ICAgICAgPGZvbyBv cGVyYXRpb249InJlcGxhY2UiIC8+DQo+ID4gICA8L2NvbmZpZz4NCj4gPiANCj4gPiByZXN1bHQ6 DQo+ID4gDQo+ID4gICA8Y29uZmlnPg0KPiA+ICAgICAgPGZvbyAvPg0KPiA+ICAgPC9jb25maWc+ DQo+IA0KPiBUaGlzIGlzIGNvcnJlY3QsIGJ1dCB0aGUgb3JpZ2luYWwgcXVlc3Rpb24gd2FzIGlm ICJyZXBsYWNlIiBjb3VsZCBiZQ0KPiB1c2VkIGluc3RlYWQgb2YgInJlbW92ZSIgKGlmIEkgdW5k ZXJzdGFuZCB0aGUgcXVlc3Rpb24gY29ycmVjdGx5KSwgYW5kDQo+IHRoZSBhbnN3ZXIgaXMgbm8s IGl0IGNhbm5vdC4gIFdpdGggdGhlIGNvbmZpZyBhYm92ZSwgaWYgeW91IGluc3RlYWQNCj4gc2Vu ZDoNCj4gDQo+ICAgPGNvbmZpZz4NCj4gICAgICAgPGZvbyBvcGVyYXRpb249InJlcGxhY2UiIC8+ DQo+ICAgIDwvY29uZmlnPg0KPiANCj4gVGhlIHJlc3VsdCBpczoNCj4gDQo+ICAgIDxjb25maWc+ DQo+ICAgIDwvY29uZmlnPg0KPiANCj4gDQpZZXMsIHRoaXMgaXMgbXkgcXVlc3Rpb24uOikNCj4g L21hcnRpbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRl ZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRl ZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUg bm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwg ZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGlt bWVkaWF0ZWx5Lg0K --=_alternative 0021FDA448257CF2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPk1hcnRpbiBCam9ya2x1bmQgJmx0O21iakB0YWlsLWYuY29tJmd0OyDQ tNPaIDIwMTQtMDYtMDkNCjE0OjA1OjIyOjxicj4NCjxicj4NCiZndDsgTWFydGluIEJqb3JrbHVu ZCAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAyMDE0LTA2LTA5IDE0OjA1PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgYW5keUB5dW1hd29ya3MuY29tLCA8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIHll Lnh1MUB6dGUuY29tLmNuLCBkb3Uud2VpMUB6dGUuY29tLmNuLCA8YnI+DQomZ3Q7IG5ldGNvbmZA aWV0Zi5vcmcsIHhpYW8ueXVxaW5nQHp0ZS5jb20uY248L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDW98ziPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91 dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgPGJyPg0KJmd0OyBhdHRyaWJ1dGUgaW4gZWRpdC1j b25maWc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBB bmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyAm Z3Q7IE9uIFN1biwgSnVuIDgsIDIwMTQgYXQgNjoxOCBQTSwgJmx0O2ZlbmcuY2hvbmczM0B6dGUu Y29tLmNuJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFu ZHmjrDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgSSBoYXZlIGxvb2tlZCB0aHJv dWdoIHRoaXMgc2VjdGlvbiBmb3IgbWFueQ0KdGltZXMuIEluIG15IG9waW5pb24sIEk8YnI+DQom Z3Q7ICZndDsgJmd0OyB0aGluazxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSBlbGVtZW50IGNvbnRh aW5zIGF0dHJpYnV0ZSAncmVwbGFjZScgbXVzdCBoYXZlIHN1YnRyZWUsDQphbmQgdGhpczxicj4N CiZndDsgJmd0OyAmZ3Q7IHN1YnRyZWU8YnI+DQomZ3Q7ICZndDsgJmd0OyBzaG91bGQgYmUgYSB2 YWxpZCBjb25maWd1cmF0aW9uLiBCdXQgbXkgY29sbGVhZ3VlcyBkb24ndA0KdGhpbmsgc28sIHRo ZXk8YnI+DQomZ3Q7ICZndDsgJmd0OyBhcmd1ZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGF0IHRo ZSBlbXB0eSBjb25maWd1cmF0aW9uIGlzIGFsc28gY29uZmlndXJhdGlvbiwgdGhleQ0Kd2FudCB0 byB1c2U8YnI+DQomZ3Q7ICZndDsgJmd0OyAncmVwbGFjZSc8YnI+DQomZ3Q7ICZndDsgJmd0OyBh cyAncmVtb3ZlJywgSSBjYW4ndCBwZXJzdWFkZSB0aGVtLCA6KTxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgU28sSSB3YW50IHRvIGdldCBhIGNsYXJpZmljYXRpb24sIHRoYW5rcy48 YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgeW91IGFy ZSBib3RoIHJpZ2h0IDstKTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgdGhlIHJlcGxh Y2UgYXR0cmlidXRlIGRvZXMgaGF2ZSB0byBhcHBlYXIgaW4gYSBzdWJ0cmVlLCBidXQgYQ0Kc3Vi dHJlZSBtYXkgYmU8YnI+DQomZ3Q7ICZndDsgYW4gZW1wdHkgbm9kZSAoaWYgaXQgaXMgc2NoZW1h IHZhbGlkKS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IHN0YXJ0Ojxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZsdDtjb25maWcmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ZvbyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDthJmd0OzQyJmx0Oy9hJmd0Ozxicj4NCiZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZm9vJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJmx0 Oy9jb25maWcmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyByZXBsYWNlIGZvbzo8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZsdDtjb25maWcmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ZvbyBvcGVyYXRpb249JnF1b3Q7cmVw bGFjZSZxdW90OyAvJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJmx0Oy9jb25maWcmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyByZXN1bHQ6PGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmbmJzcDsgJmx0O2NvbmZpZyZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7Zm9vIC8mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbHQ7L2NvbmZp ZyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBpcyBjb3JyZWN0LCBidXQgdGhlIG9yaWdp bmFsIHF1ZXN0aW9uIHdhcyBpZiAmcXVvdDtyZXBsYWNlJnF1b3Q7DQpjb3VsZCBiZTxicj4NCiZn dDsgdXNlZCBpbnN0ZWFkIG9mICZxdW90O3JlbW92ZSZxdW90OyAoaWYgSSB1bmRlcnN0YW5kIHRo ZSBxdWVzdGlvbiBjb3JyZWN0bHkpLA0KYW5kPGJyPg0KJmd0OyB0aGUgYW5zd2VyIGlzIG5vLCBp dCBjYW5ub3QuICZuYnNwO1dpdGggdGhlIGNvbmZpZyBhYm92ZSwgaWYgeW91IGluc3RlYWQ8YnI+ DQomZ3Q7IHNlbmQ6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbHQ7Y29uZmlnJmd0Ozxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2ZvbyBvcGVyYXRpb249JnF1b3Q7cmVw bGFjZSZxdW90OyAvJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyZsdDsvY29uZmlnJmd0Ozxi cj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyBUaGUgcmVzdWx0IGlzOjxicj4NCiZndDsgJm5ic3A7 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Jmx0O2NvbmZpZyZndDs8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsmbHQ7L2NvbmZpZyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5ZZXMsIHRoaXMgaXMgbXkgcXVlc3Rpb24uOik8YnI+DQomZ3Q7 IC9tYXJ0aW48YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUi Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdp dGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBp bnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1 dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVs eS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 0021FDA448257CF2_=-- From nobody Mon Jun 9 07:19:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8631A01B3 for ; Mon, 9 Jun 2014 07:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.672 X-Spam-Level: * X-Spam-Status: No, score=1.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt-2hCaFOGJT for ; Mon, 9 Jun 2014 07:19:27 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E191A01AE for ; Mon, 9 Jun 2014 07:19:26 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id s7so7889970qap.34 for ; Mon, 09 Jun 2014 07:19:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1D4D7iNZXVibF+wSjZeWyunYdR/Bw979WAMhIe9ewy8=; b=BMGIB3A0W4X6c3Ch1xlAa2V/J0mYncQs+1qX85Fbe0Czad3rFl1JmvIhJlNGk1BwZs DSvQAFnrPD/6Cs1C+sfONoeUOY2i5MSE8oz9HJw1RqunLZek8zimsmPQcl2dn4MVWnZn Jn5TJFES7XFV8CGlzh6fvUA9SIgjvgUqpFTK0ryJ4H80v6B5TyYhKfeO3Imacnl1Zn2a R358zZqiufq7w2yLipoycQNQerKrTB3UdbVm1UXU4xgNqhDGASoEdNOq7pVXrVweZ1ML mY0DgJgsLRaoGDv5hZjBRu1hXftoGRX2BcdcXRFHiFIgQo/0tHwGzQt7yK2YABmAyRBs bRgQ== X-Gm-Message-State: ALoCoQl8VZn36dV0w6jJC2/lXRwnKDpc0hiaBSBgT27mwqF5rA5uaWHgrRgRmznwPrsA43zHbEYB MIME-Version: 1.0 X-Received: by 10.229.57.129 with SMTP id c1mr32932729qch.7.1402323565988; Mon, 09 Jun 2014 07:19:25 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 9 Jun 2014 07:19:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 07:19:25 -0700 Message-ID: From: Andy Bierman To: feng.chong33@zte.com.cn Content-Type: multipart/alternative; boundary=001a11330ca203809a04fb67e664 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Nhlvc_L2lRdrcdiToHkQHQhfb38 Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:19:29 -0000 --001a11330ca203809a04fb67e664 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Sun, Jun 8, 2014 at 10:40 PM, wrote: > /frank > > Andy Bierman =D0=B4=D3=DA 2014-06-09 11:44:58: > > > Andy Bierman > > 2014-06-09 11:44 > > > > =CA=D5=BC=FE=C8=CB > > > > feng.chong33@zte.com.cn, > > > > =B3=AD=CB=CD > > > > dou.wei1@zte.com.cn, Netconf , > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > =D6=F7=CC=E2 > > > > Re: [Netconf] Some questions about the usage of 'operation' > > attribute in edit-config > > > > > > > On Sun, Jun 8, 2014 at 8:18 PM, wrote: > > Andy, > > thanks,:) > > I understand only presence container or leaf node with empty type > > can be placed 'replace' attribute > > and have a empty node subtree. Is it right? > > > > > > no. any container. anyxml. empty leaf. zero-length string leaf. > > > Really? a NP container can be a valid configuration itself? > > Yes -- there is some confusion because it is widely believed that NP containers have no semantics -- but this is false. They are collections. must-stmt validation that fails on an NP-container will cause the edit/commit to fail just like any other node. They are not as standard as other YANG data nodes because a server MAY choose to delete these nodes. Some server implementations even create them, although the spec is silent on this point. As Lada pointed out, the server flexibility for NP-containers is more of a bug than a feature. BTW, empty bits is another empty node that is legal (for replace operation)= . You can replace a leaf-list with itself (the instance containing the empty node, if any). > /frank > Andy > > > > Andy Bierman =D0=B4=D3=DA 2014-06-09 10:36:16: > > > > > Andy Bierman > > > 2014-06-09 10:36 > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > feng.chong33@zte.com.cn, > > > > > > =B3=AD=CB=CD > > > > > > dou.wei1@zte.com.cn, Netconf , > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > =D6=F7=CC=E2 > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > attribute in edit-config > > > > > > > > > > > On Sun, Jun 8, 2014 at 6:18 PM, wrote: > > > Andy=A3=AC > > > I have looked through this section for many times. In my > > opinion, I think > > > the element contains attribute 'replace' must have subtree, and > > this subtree > > > should be a valid configuration. But my colleagues don't think so, > > > they argued > > > that the empty configuration is also configuration, they want to > > use'replace' > > > as 'remove', I can't persuade them, :) > > > So,I want to get a clarification, thanks. > > > > > > you are both right ;-) > > > > > > the replace attribute does have to appear in a subtree, but a subtree > may be > > > an empty node (if it is schema valid). > > > > > > start: > > > > > > > > > > > > 42 > > > > > > > > > > > > replace foo: > > > > > > > > > > > > > > > > > > result: > > > > > > > > > > > > > > > > > > The text seems very clear to me. > > > > > > /frank > > > > > > Andy > > > > > > > In your example, the 'foo' MUST be a presence container? > > > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-07 02:43:28: > > > > > > > Andy Bierman > > > > 2014-06-07 02:43 > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > =B3=AD=CB=CD > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > =D6=F7=CC=E2 > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > attribute in edit-config > > > > > > > > > > > > > > > On Thu, Jun 5, 2014 at 11:18 PM, wrote: > > > > andy, > > > > Thanks a lot. > > > > Can you answer the first question? 'replace' can be used as > 'remove'? > > > > > > > > Read RFC 6241, sec. 7.2 Attributes section. > > > > It explains the difference between the NETCONF > operations. > > > > > > > > > > > > /frank > > > > > > > > Andy > > > > > > > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-05 23:46:53: > > > > > > > > > Andy Bierman > > > > > 2014-06-05 23:46 > > > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > =B3=AD=CB=CD > > > > > > > > > > Netconf , ye.xu1@zte.com.cn, dou.wei1@zte.com.c= n, > > > > > > xiao.yuqing@zte.com.cn > > > > > > > > > > =D6=F7=CC=E2 > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > On Wed, Jun 4, 2014 at 6:35 PM, wrote: > > > > > Hi all, > > > > > I have some questions about the usage of 'operation' attribut= e > > > > > in edit-config. > > > > > 1. 'replace' attribute can only be used to remove > configuration? > > > > > For example, the rpc request listed below is valid? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.How to process nested operation attribute? > > > > > For example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eth0/0/0 > > > > > > > > > > true > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The sequence of process is merge interface name 'eth0/0/0' > and > > > > > remove mtu and merge enabled to 'true' > > > > > or merge interface name 'eth0/0/0' > and > > > > > merge enabled to 'true' and remove mtu? > > > > > In other words, NETCONF will process outer layer operation > > > > > firstly and process inner layer operation later, or process > > > > > operations in accordance with XML tree traversal order? > > > > > > > > > > > > > > > There is no required processing order. > > > > > It is an implementation detail. > > > > > Some things to consider: > > > > > 1) all operations are against the target datastore at the start > of > > > > > the operation > > > > > 2) the operations are all-or-none, not incremental > > > > > 2a) this implies that create within delete, or delete within > > > > > create, is always an error > > > > > because 'data-exists' or 'data-missing' must be true > > > > > > > > > > In your example there is no problem because 'remove' works even i= f > > > > > the data is missing. > > > > > > > > > > > > > > > > > > > > 3. If other operation attribute nested in operation attribute > > > > > 'remove',what should NETCONF server do? Only process remove > operation? > > > > > > > > > > 4. Can NETCONF support the nested operation attribute equals to > > > > > parent operation attribute? > > > > > > > > > > /frank > > > > > > > > > > Andy > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > ZTE Information Security Notice: The information contained in thi= s > > > > > mail (and any attachment transmitted herewith) is privileged and > > > > > confidential and is intended for the exclusive use of the address= ee > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > reproduction, distribution or other dissemination or use of the > > > > > information contained is strictly prohibited. If you have > received > > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > -------------------------------------------------------- > > > > ZTE Information Security Notice: The information contained in this > > > > mail (and any attachment transmitted herewith) is privileged and > > > > confidential and is intended for the exclusive use of the addressee > > > > (s). If you are not an intended recipient, any disclosure, > > > > reproduction, distribution or other dissemination or use of the > > > > information contained is strictly prohibited. If you have received > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail (and any attachment transmitted herewith) is privileged and > > > confidential and is intended for the exclusive use of the addressee > > > (s). If you are not an intended recipient, any disclosure, > > > reproduction, distribution or other dissemination or use of the > > > information contained is strictly prohibited. If you have received > > > this mail in error, please delete it and notify us immediately. > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail (and any attachment transmitted herewith) is privileged and > > confidential and is intended for the exclusive use of the addressee > > (s). If you are not an intended recipient, any disclosure, > > reproduction, distribution or other dissemination or use of the > > information contained is strictly prohibited. If you have received > > this mail in error, please delete it and notify us immediately. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > --001a11330ca203809a04fb67e664 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 8, 2014 at 10:40 PM, <feng.chong33@zte.com.cn> wrote:
/frank

Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-09 11:44:58:

> Andy Bierman <andy@yumaworks.com>
> 2014-06-09 11:44
>
> =CA=D5=BC=FE=C8=CB
>
> feng.chon= g33@zte.com.cn,
>
> =B3=AD=CB=CD
>
> dou.wei1@zte.= com.cn, Netconf <netconf@ietf.org>,
> xiao.yuqin= g@zte.com.cn, ye= .xu1@zte.com.cn
>
> =D6=F7=CC=E2
>
> Re: [Netconf] Some questions about the usage of 'operation' > attribute in edit-config
>
>

> On Sun, Jun 8, 2014 at 8:18 PM, <feng.chong33@zte.com.cn> wrote:
> Andy,
>    thanks,:)
>    I understand only presence container or leaf node with empty type
> can be placed 'replace' attribute
> and have a empty node subtree. Is it right?
>  
>
> no. any container. anyxml. empty leaf. zero-length string leaf.=
>
Really? a NP container can be a valid configuration itself?



Yes -- there is some confusion because it is widely believed that NP con= tainers
have no semantics -- but this is false.  They are co= llections.  must-stmt validation
that fails on an NP-container will cause the edit/commit to fail just = like any other node.

They are not as standard as o= ther YANG data nodes because a server MAY choose
to delete these = nodes. Some server implementations even create them, although the
spec is silent on this point.

As Lada pointed= out, the server flexibility for NP-containers is more of a bug than a feat= ure.

BTW, empty bits is another empty node that is= legal (for replace operation).
You can replace a leaf-list with itself (the instance containing the e= mpty node, if any).



> /frank

Andy
=  
>
> Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-09 10:36:16:
>
> > Andy Bierman <andy@yumaworks.com>
> > 2014-06-09 10:36
> >
> > =CA=D5=BC=FE=C8=CB
> >
> > feng= .chong33@zte.com.cn,
> >
> > =B3=AD=CB=CD
> >
> > dou.wei1= @zte.com.cn, Netconf <netconf@ietf.org>,
> > xiao.= yuqing@zte.com.cn, ye.xu1@zte.com.cn
> >
> > =D6=F7=CC=E2
> >
> > Re: [Netconf] Some questions about the usage of 'operation= 9;
> > attribute in edit-config
> >
> >
>
> > On Sun, Jun 8, 2014 at 6:18 PM, <feng.chong33@zte.com.cn> wrote:
> > Andy=A3=AC
> >     I have looked through this section for many times. In my
> opinion, I think
> > the element contains attribute 'replace' must have subtre= e, and
> this subtree
> > should be a valid configuration. But my colleagues don't thin= k so,
> > they argued
> > that the empty configuration is also configuration, they want to
> use'replace'
> > as 'remove', I can't persuade them, :)
> >     So,I want to get a clarification, thanks.
> >
> > you are both right ;-)
> >
> > the replace attribute does have to appear in a subtree, but a subtree may be
> > an empty node (if it is schema valid).
> >
> > start:
> >
> >   <config>
> >      <foo>
> >         <a>42</a>
> >      </foo>
> >   </config>
> >
> > replace foo:
> >
> >  <config>
> >      <foo operation=3D"replace" />
> >   </config>
> >
> > result:
> >
> >   <config>
> >      <foo />
> >   </config>
> >
> > The text seems very clear to me.
> >
> > /frank
> >
> > Andy
> >
>
> In your example, the 'foo' MUST be a presence container?
>  
> >
> > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-07 02:43:28:
> >
> > > Andy Bierman <andy@yumaworks.com>
> > > 2014-06-07 02:43
> > >
> > > =CA=D5=BC=FE=C8=CB
> > >
> > > feng.chong33@zte.com.cn,
> > >
> > > =B3=AD=CB=CD
> > >
> > > dou= .wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > = xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > >
> > > =D6=F7=CC=E2
> > >
> > > Re: [Netconf] Some questions about the usage of 'operati= on'
> > > attribute in edit-config
> > >
> > >
> >
> > > On Thu, Jun 5, 2014 at 11:18 PM, <feng.chong33@zte.com.cn> wrote:
> > > andy,
> > >    Thanks a lot.
> > >    Can you answer the first question? 'replace= ' can be used as 'remove'?
> > >
> > > Read RFC 6241, sec. 7.2 Attributes section.
> > > It explains the difference between the NETCONF <edit-conf= ig> operations.
> > >
> > >  
> > > /frank
> > >
> > > Andy
> > >  
> > >
> > > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-05 23:46:53:
> > >
> > > > Andy Bierman <andy@yumaworks.com>
> > > > 2014-06-05 23:46
> > > >
> > > > =CA=D5=BC=FE=C8=CB
> > > >
> > > > feng.chong33@zte.com.cn,
> > > >
> > > > =B3=AD=CB=CD
> > > >
> > > > Netconf <netconf@ietf.org>, ye.xu1@zte.com.cn, dou.wei1@zte.com.c= n,
> > > > xiao.yuqing@zte.com.cn
> > > >
> > > > =D6=F7=CC=E2
> > > >
> > > > Re: [Netconf] Some questions about the usage of 'op= eration'
> > > > attribute in edit-config
> > > >
> > > >
> > >
> > > > On Wed, Jun 4, 2014 at 6:35 PM, <feng.chong33@zte.com.cn> wrote:
> > > > Hi all,
> > > >    I have some questions about the usage of  'operation' attribute
> > > > in edit-config.
> > > >    1. 'replace' attribute can only be= used to remove configuration?
> > > >       For example, the rpc request liste= d below is valid?
> > > >       <rpc message-id =3D "101&q= uot;>
> > > >            <edit-confi= g>
> > > >                = <target>
> > > >                   <running/>
> > > >                = </target>
> > > >                = <config>
> > > >                   <interfaces operation=3D "replace"/>
> > > >                = </config>
> > > >            </edit-conf= ig>
> > > >       </rpc>
> > > >
> > > >
> > > >    2.How to process nested operation attribut= e?
> > > >      For example:
> > > >            <rpc messag= e-id =3D "101">
> > > >            <edit-confi= g>
> > > >                = <target>
> > > >                   <running/>
> > > >                = </target>
> > > >                = <config>
> > > >                   <interfaces>
> > > >                       <interface operation=3D "merge">
> > > >                            <name>eth0/0/0</name>
> > > >                            <mtu operation=3D "remove&= quot;>
> > > >                            <enabled>true</enalbled&g= t;
> > > >                       </interface>
> > > >                   </interfaces>
> > > >                = </config>
> > > >            </edit-conf= ig>
> > > >       </rpc>
> > > >
> > > >      The sequence of process is merge interface name 'eth0/0/0' and
> > > > remove mtu and merge enabled to 'true'
> > > >                              or merge interface name 'eth0/0/0' and
> > > > merge enabled to 'true' and remove mtu?
> > > >      In other words, NETCONF will proces= s outer layer operation
> > > > firstly and process inner layer operation later, or process
> > > > operations in accordance with XML tree traversal order?
> > > >  
> > > >
> > > > There is no required processing order.
> > > > It is an implementation detail.
> > > > Some things to consider:
> > > >   1) all operations are against the target datasto= re at the start of
> > > > the operation
> > > >   2) the operations are all-or-none, not increment= al
> > > >   2a) this implies that create within delete, or delete within
> > > > create, is always an error
> > > >        because 'data-exists'= ; or 'data-missing' must be true
> > > >
> > > > In your example there is no problem because 'remove= ' works even if
> > > > the data is missing.
> > > >
> > > >          
> > > >
> > > > 3. If other operation attribute nested in operation attribute
> > > > 'remove',what should NETCONF server do? Only pr= ocess remove operation?
> > > >
> > > >   4. Can NETCONF support the nested operation attribute equals to
> > > > parent operation attribute?
> > > >      
> > > > /frank
> > > >
> > > > Andy
> > > >  
> > > >
> > > > -------------------------------------------------------= -
> > > > ZTE Information Security Notice: The information contai= ned in this
> > > > mail (and any attachment transmitted herewith) is privi= leged and
> > > > confidential and is intended for the exclusive use of the addressee
> > > > (s).  If you are not an intended recipient, any disclosure,
> > > > reproduction, distribution or other dissemination or use of the
> > > > information contained is strictly prohibited.  If you have received
> > > > this mail in error, please delete it and notify us immediately.
> > > >
> > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > N= etconf@ietf.org
> > > > https://www.ietf.org/mailman/lis= tinfo/netconf
> >
> > >
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > > mail (and any attachment transmitted herewith) is privileged and
> > > confidential and is intended for the exclusive use of the addressee
> > > (s).  If you are not an intended recipient, any disclos= ure,
> > > reproduction, distribution or other dissemination or use of the
> > > information contained is strictly prohibited.  If you have received
> > > this mail in error, please delete it and notify us immediate= ly.
> > >
>
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the address= ee
> > (s).  If you are not an intended recipient, any disclosure,
> > reproduction, distribution or other dissemination or use of the
> > information contained is strictly prohibited.  If you have received
> > this mail in error, please delete it and notify us immediately. > >

>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail (and any attachment transmitted herewith) is privileged and
> confidential and is intended for the exclusive use of the addressee > (s).  If you are not an intended recipient, any disclosure,
> reproduction, distribution or other dissemination or use of the
> information contained is strictly prohibited.  If you have receiv= ed
> this mail in error, please delete it and notify us immediately.
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


--001a11330ca203809a04fb67e664-- From nobody Mon Jun 9 17:47:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B122F1A02BD for ; Mon, 9 Jun 2014 17:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.3 X-Spam-Level: X-Spam-Status: No, score=-98.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_37=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92tkiBsp7-uZ for ; Mon, 9 Jun 2014 17:46:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 838721A02AD for ; Mon, 9 Jun 2014 17:46:58 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 65B9D125266A; Tue, 10 Jun 2014 08:46:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s5A0kgCS091955; Tue, 10 Jun 2014 08:46:42 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: References: To: Andy Bierman MIME-Version: 1.0 X-KeepSent: 1C740A53:16BE16EC-48257CF3:0002EC8E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Tue, 10 Jun 2014 08:46:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-10 08:46:43, Serialize complete at 2014-06-10 08:46:43 Content-Type: multipart/alternative; boundary="=_alternative 0004466348257CF3_=" X-MAIL: mse02.zte.com.cn s5A0kgCS091955 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qYLbVMOv12TBIuBqwLeeUVvW-N4 Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 00:47:02 -0000 This is a multipart message in MIME format. --=_alternative 0004466348257CF3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 L2ZyYW5rDQoNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYt MDkgMjI6MTk6MjU6DQoNCj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiAy MDE0LTA2LTA5IDIyOjE5DQo+IA0KPiDK1bz+yMsNCj4gDQo+IGZlbmcuY2hvbmczM0B6dGUuY29t LmNuLCANCj4gDQo+ILOty80NCj4gDQo+IGRvdS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgPG5l dGNvbmZAaWV0Zi5vcmc+LCANCj4geGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5j b20uY24NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJv dXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0KPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcN Cj4gDQo+IA0KDQo+IE9uIFN1biwgSnVuIDgsIDIwMTQgYXQgMTA6NDAgUE0sIDxmZW5nLmNob25n MzNAenRlLmNvbS5jbj4gd3JvdGU6DQo+IC9mcmFuayANCj4gDQo+IEFuZHkgQmllcm1hbiA8YW5k eUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYtMDkgMTE6NDQ6NTg6DQo+IA0KPiA+IEFuZHkg Qmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4gPiAyMDE0LTA2LTA5IDExOjQ0IA0KPiA+ IA0KPiA+IMrVvP7IyyANCj4gPiANCj4gPiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgDQo+ID4g DQo+ID4gs63LzSANCj4gPiANCj4gPiBkb3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mIDxuZXRj b25mQGlldGYub3JnPiwgDQo+ID4geGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5j b20uY24gDQo+ID4gDQo+ID4g1vfM4iANCj4gPiANCj4gPiBSZTogW05ldGNvbmZdIFNvbWUgcXVl c3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyANCj4gPiBhdHRyaWJ1dGUgaW4g ZWRpdC1jb25maWcgDQo+ID4gDQo+ID4gDQo+IA0KPiA+IE9uIFN1biwgSnVuIDgsIDIwMTQgYXQg ODoxOCBQTSwgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiB3cm90ZTogDQo+ID4gQW5keSwgDQo+ ID4gICAgdGhhbmtzLDopIA0KPiA+ICAgIEkgdW5kZXJzdGFuZCBvbmx5IHByZXNlbmNlIGNvbnRh aW5lciBvciBsZWFmIG5vZGUgd2l0aCBlbXB0eSB0eXBlDQo+ID4gY2FuIGJlIHBsYWNlZCAncmVw bGFjZScgYXR0cmlidXRlIA0KPiA+IGFuZCBoYXZlIGEgZW1wdHkgbm9kZSBzdWJ0cmVlLiBJcyBp dCByaWdodD8gDQo+ID4gDQo+ID4gDQo+ID4gbm8uIGFueSBjb250YWluZXIuIGFueXhtbC4gZW1w dHkgbGVhZi4gemVyby1sZW5ndGggc3RyaW5nIGxlYWYuIA0KPiA+IA0KPiBSZWFsbHk/IGEgTlAg Y29udGFpbmVyIGNhbiBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gaXRzZWxmPyANCg0KPiANCj4g WWVzIC0tIHRoZXJlIGlzIHNvbWUgY29uZnVzaW9uIGJlY2F1c2UgaXQgaXMgd2lkZWx5IGJlbGll dmVkIHRoYXQgDQpOUGNvbnRhaW5lcnMNCj4gaGF2ZSBubyBzZW1hbnRpY3MgLS0gYnV0IHRoaXMg aXMgZmFsc2UuICBUaGV5IGFyZSBjb2xsZWN0aW9ucy4gDQo+IG11c3Qtc3RtdCB2YWxpZGF0aW9u DQo+IHRoYXQgZmFpbHMgb24gYW4gTlAtY29udGFpbmVyIHdpbGwgY2F1c2UgdGhlIGVkaXQvY29t bWl0IHRvIGZhaWwgDQo+IGp1c3QgbGlrZSBhbnkgb3RoZXIgbm9kZS4NCj4gDQoNCkkgZG9uJ3Qg YWdyZWUuIEkgdGhpbmsgTlAtY29udGFpbmVyIE1VU1Qgbm90IGJlIGEgdmFsaWQgY29uZmlndXJh dGlvbiBpZiANCml0IGhhcyBubyBjaGlsZHJlbiwNCmV2ZW4gaWYgTlAtY29udGFpbmVyIGhhcyBz b21lIHNlbWFudGljcywgaW4gdGhhdCBjYXNlLCBOUC1jb250YWluZXIganVzdCANCmFjdCBhcyBh IHVuaXQgY2FuIGJlIA0KZXZhbHVhdGVkIG9yIHZhbGlkYXRlZC4NCg0KSWYgYSBOUC1jb250YWlu ZXIgY2FuIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBpdHNlbGYsIHdoYXQncyB0aGUgDQpkaWZm ZXJlbmNlIGJldHdlZW4gTlAtY29udGFpbmVyIGFuZCBwcmVzZW5jZSBjb250YWluZXI/DQoNCj4g VGhleSBhcmUgbm90IGFzIHN0YW5kYXJkIGFzIG90aGVyIFlBTkcgZGF0YSBub2RlcyBiZWNhdXNl IGEgc2VydmVyIE1BWSANCmNob29zZQ0KPiB0byBkZWxldGUgdGhlc2Ugbm9kZXMuIFNvbWUgc2Vy dmVyIGltcGxlbWVudGF0aW9ucyBldmVuIGNyZWF0ZSB0aGVtLA0KPiBhbHRob3VnaCB0aGUNCj4g c3BlYyBpcyBzaWxlbnQgb24gdGhpcyBwb2ludC4NCj4gDQo+IEFzIExhZGEgcG9pbnRlZCBvdXQs IHRoZSBzZXJ2ZXIgZmxleGliaWxpdHkgZm9yIE5QLWNvbnRhaW5lcnMgaXMgDQo+IG1vcmUgb2Yg YSBidWcgdGhhbiBhIGZlYXR1cmUuDQo+IA0KPiBCVFcsIGVtcHR5IGJpdHMgaXMgYW5vdGhlciBl bXB0eSBub2RlIHRoYXQgaXMgbGVnYWwgKGZvciByZXBsYWNlIA0Kb3BlcmF0aW9uKS4NCj4gWW91 IGNhbiByZXBsYWNlIGEgbGVhZi1saXN0IHdpdGggaXRzZWxmICh0aGUgaW5zdGFuY2UgY29udGFp bmluZyB0aGUNCj4gZW1wdHkgbm9kZSwgaWYgYW55KS4NCg0KSWYgbGVhZi1saXN0IGNhbiBiZSBy ZXBsYWNlIHdpdGggaXRzZWxmLCB0aGVuIHRoZSBsaXN0IGNhbiBiZSByZXBsYWNlIHdpdGggDQpp dHNlbGYgYWxzby4NClRoZW4gYWxsIG5vZGVzIGNvbnRhaW5lciBlbXB0eSBub2RlIHNob3VsZCBi ZSBjb25zaWRlcmVkIHRvIGJlIGEgdmFsaWQgDQpjb25maWd1cmF0aW9uPw0KDQpJIHRoaW5rIFdH IHNob3VsZCBnaXZlIGEgbW9yZSBjbGVhciBjbGFyaWZpY2F0aW9uLiANCg0KSU1PIEkgdGhpbmsg b25seSBOUC1jb250YWluZXIsZW1wdHkgbGVhZiwgYW55eG1sLCB6ZXJvLWxlbmd0aCBzdHJpbmcg b3IgDQpiaW5hcnksIGJpdHMgY2FuIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBpdHNlbGYuIA0K PiANCj4gPiAvZnJhbmsNCj4gDQo+IEFuZHkNCj4gDQo+ID4gDQo+ID4gQW5keSBCaWVybWFuIDxh bmR5QHl1bWF3b3Jrcy5jb20+INC009ogMjAxNC0wNi0wOSAxMDozNjoxNjoNCj4gPiANCj4gPiA+ IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4gPiA+IDIwMTQtMDYtMDkgMTA6 MzYgDQo+ID4gPiANCj4gPiA+IMrVvP7IyyANCj4gPiA+IA0KPiA+ID4gZmVuZy5jaG9uZzMzQHp0 ZS5jb20uY24sIA0KPiA+ID4gDQo+ID4gPiCzrcvNIA0KPiA+ID4gDQo+ID4gPiBkb3Uud2VpMUB6 dGUuY29tLmNuLCBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgDQo+ID4gPiB4aWFvLnl1cWlu Z0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbiANCj4gPiA+IA0KPiA+ID4g1vfM4iANCj4g PiA+IA0KPiA+ID4gUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ug b2YgJ29wZXJhdGlvbicgDQo+ID4gPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcgDQo+ID4gPiAN Cj4gPiA+IA0KPiA+IA0KPiA+ID4gT24gU3VuLCBKdW4gOCwgMjAxNCBhdCA2OjE4IFBNLCA8ZmVu Zy5jaG9uZzMzQHp0ZS5jb20uY24+IHdyb3RlOiANCj4gPiA+IEFuZHmjrCANCj4gPiA+ICAgICBJ IGhhdmUgbG9va2VkIHRocm91Z2ggdGhpcyBzZWN0aW9uIGZvciBtYW55IHRpbWVzLiBJbiBteSAN Cj4gPiBvcGluaW9uLCBJIHRoaW5rIA0KPiA+ID4gdGhlIGVsZW1lbnQgY29udGFpbnMgYXR0cmli dXRlICdyZXBsYWNlJyBtdXN0IGhhdmUgc3VidHJlZSwgYW5kIA0KPiA+IHRoaXMgc3VidHJlZSAN Cj4gPiA+IHNob3VsZCBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24uIEJ1dCBteSBjb2xsZWFndWVz IGRvbid0IHRoaW5rIHNvLCANCj4gPiA+IHRoZXkgYXJndWVkIA0KPiA+ID4gdGhhdCB0aGUgZW1w dHkgY29uZmlndXJhdGlvbiBpcyBhbHNvIGNvbmZpZ3VyYXRpb24sIHRoZXkgd2FudCB0byANCj4g PiB1c2UncmVwbGFjZScgDQo+ID4gPiBhcyAncmVtb3ZlJywgSSBjYW4ndCBwZXJzdWFkZSB0aGVt LCA6KSANCj4gPiA+ICAgICBTbyxJIHdhbnQgdG8gZ2V0IGEgY2xhcmlmaWNhdGlvbiwgdGhhbmtz LiANCj4gPiA+IA0KPiA+ID4geW91IGFyZSBib3RoIHJpZ2h0IDstKSANCj4gPiA+IA0KPiA+ID4g dGhlIHJlcGxhY2UgYXR0cmlidXRlIGRvZXMgaGF2ZSB0byBhcHBlYXIgaW4gYSBzdWJ0cmVlLCBi dXQgYSANCj4gc3VidHJlZSBtYXkgYmUNCj4gPiA+IGFuIGVtcHR5IG5vZGUgKGlmIGl0IGlzIHNj aGVtYSB2YWxpZCkuIA0KPiA+ID4gDQo+ID4gPiBzdGFydDogDQo+ID4gPiANCj4gPiA+ICAgPGNv bmZpZz4gDQo+ID4gPiAgICAgIDxmb28+IA0KPiA+ID4gICAgICAgICA8YT40MjwvYT4gDQo+ID4g PiAgICAgIDwvZm9vPiANCj4gPiA+ICAgPC9jb25maWc+IA0KPiA+ID4gDQo+ID4gPiByZXBsYWNl IGZvbzogDQo+ID4gPiANCj4gPiA+ICA8Y29uZmlnPiANCj4gPiA+ICAgICAgPGZvbyBvcGVyYXRp b249InJlcGxhY2UiIC8+IA0KPiA+ID4gICA8L2NvbmZpZz4gDQo+ID4gPiANCj4gPiA+IHJlc3Vs dDogDQo+ID4gPiANCj4gPiA+ICAgPGNvbmZpZz4gDQo+ID4gPiAgICAgIDxmb28gLz4gDQo+ID4g PiAgIDwvY29uZmlnPiANCj4gPiA+IA0KPiA+ID4gVGhlIHRleHQgc2VlbXMgdmVyeSBjbGVhciB0 byBtZS4gDQo+ID4gPiANCj4gPiA+IC9mcmFuayANCj4gPiA+IA0KPiA+ID4gQW5keSANCj4gPiA+ IA0KPiA+IA0KPiA+IEluIHlvdXIgZXhhbXBsZSwgdGhlICdmb28nIE1VU1QgYmUgYSBwcmVzZW5j ZSBjb250YWluZXI/IA0KPiA+IA0KPiA+ID4gDQo+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVt YXdvcmtzLmNvbT4g0LTT2iAyMDE0LTA2LTA3IDAyOjQzOjI4Og0KPiA+ID4gDQo+ID4gPiA+IEFu ZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4gPiA+ID4gMjAxNC0wNi0wNyAwMjo0 MyANCj4gPiA+ID4gDQo+ID4gPiA+IMrVvP7IyyANCj4gPiA+ID4gDQo+ID4gPiA+IGZlbmcuY2hv bmczM0B6dGUuY29tLmNuLCANCj4gPiA+ID4gDQo+ID4gPiA+ILOty80gDQo+ID4gPiA+IA0KPiA+ ID4gPiBkb3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgDQo+ ID4gPiA+IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24sIHllLnh1MUB6dGUuY29tLmNuIA0KPiA+ID4g PiANCj4gPiA+ID4g1vfM4iANCj4gPiA+ID4gDQo+ID4gPiA+IFJlOiBbTmV0Y29uZl0gU29tZSBx dWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0KPiA+ID4gPiBhdHRyaWJ1 dGUgaW4gZWRpdC1jb25maWcgDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+IA0KPiA+ID4gPiBP biBUaHUsIEp1biA1LCAyMDE0IGF0IDExOjE4IFBNLCA8ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24+ IHdyb3RlOiANCj4gPiA+ID4gYW5keSwgDQo+ID4gPiA+ICAgIFRoYW5rcyBhIGxvdC4gDQo+ID4g PiA+ICAgIENhbiB5b3UgYW5zd2VyIHRoZSBmaXJzdCBxdWVzdGlvbj8gJ3JlcGxhY2UnIGNhbiBi ZSB1c2VkIA0KYXMncmVtb3ZlJz8gDQo+ID4gPiA+IA0KPiA+ID4gPiBSZWFkIFJGQyA2MjQxLCBz ZWMuIDcuMiBBdHRyaWJ1dGVzIHNlY3Rpb24uIA0KPiA+ID4gPiBJdCBleHBsYWlucyB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIHRoZSBORVRDT05GIDxlZGl0LWNvbmZpZz4gDQo+IG9wZXJhdGlvbnMu IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IC9mcmFuayANCj4gPiA+ID4gDQo+ID4gPiA+ IEFuZHkgDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1 bWF3b3Jrcy5jb20+INC009ogMjAxNC0wNi0wNSAyMzo0Njo1MzoNCj4gPiA+ID4gDQo+ID4gPiA+ ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiA+ID4gPiA+IDIwMTQtMDYt MDUgMjM6NDYgDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gytW8/sjLIA0KPiA+ID4gPiA+IA0KPiA+ ID4gPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiCz rcvNIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+LCB5 ZS54dTFAenRlLmNvbS5jbiwgDQpkb3Uud2VpMUB6dGUuY29tLmNuLCANCj4gPiA+ID4gPiB4aWFv Lnl1cWluZ0B6dGUuY29tLmNuIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+INb3zOIgDQo+ID4gPiA+ ID4gDQo+ID4gPiA+ID4gUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNh Z2Ugb2YgJ29wZXJhdGlvbicgDQo+ID4gPiA+ID4gYXR0cmlidXRlIGluIGVkaXQtY29uZmlnIA0K PiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gPiBPbiBXZWQsIEp1biA0 LCAyMDE0IGF0IDY6MzUgUE0sIDxmZW5nLmNob25nMzNAenRlLmNvbS5jbj4gd3JvdGU6IA0KDQo+ ID4gPiA+ID4gSGkgYWxsLCANCj4gPiA+ID4gPiAgICBJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJv dXQgdGhlIHVzYWdlIG9mICAnb3BlcmF0aW9uJyANCmF0dHJpYnV0ZSANCj4gPiA+ID4gPiBpbiBl ZGl0LWNvbmZpZy4gDQo+ID4gPiA+ID4gICAgMS4gJ3JlcGxhY2UnIGF0dHJpYnV0ZSBjYW4gb25s eSBiZSB1c2VkIHRvIHJlbW92ZSANCmNvbmZpZ3VyYXRpb24/IA0KPiA+ID4gPiA+ICAgICAgIEZv ciBleGFtcGxlLCB0aGUgcnBjIHJlcXVlc3QgbGlzdGVkIGJlbG93IGlzIHZhbGlkPyANCj4gPiA+ ID4gPiAgICAgICA8cnBjIG1lc3NhZ2UtaWQgPSAiMTAxIj4gDQo+ID4gPiA+ID4gICAgICAgICAg ICA8ZWRpdC1jb25maWc+IA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgIDx0YXJnZXQ+IA0KPiA+ ID4gPiA+ICAgICAgICAgICAgICAgICAgIDxydW5uaW5nLz4gDQo+ID4gPiA+ID4gICAgICAgICAg ICAgICAgPC90YXJnZXQ+IA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgIDxjb25maWc+IA0KPiA+ ID4gPiA+ICAgICAgICAgICAgICAgICAgIDxpbnRlcmZhY2VzIG9wZXJhdGlvbj0gInJlcGxhY2Ui Lz4gDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgPC9jb25maWc+IA0KPiA+ID4gPiA+ICAgICAg ICAgICAgPC9lZGl0LWNvbmZpZz4gDQo+ID4gPiA+ID4gICAgICAgPC9ycGM+IA0KPiA+ID4gPiA+ IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ICAgIDIuSG93IHRvIHByb2Nlc3MgbmVzdGVkIG9wZXJh dGlvbiBhdHRyaWJ1dGU/IA0KPiA+ID4gPiA+ICAgICAgRm9yIGV4YW1wbGU6IA0KPiA+ID4gPiA+ ICAgICAgICAgICAgPHJwYyBtZXNzYWdlLWlkID0gIjEwMSI+IA0KPiA+ID4gPiA+ICAgICAgICAg ICAgPGVkaXQtY29uZmlnPiANCj4gPiA+ID4gPiAgICAgICAgICAgICAgICA8dGFyZ2V0PiANCj4g PiA+ID4gPiAgICAgICAgICAgICAgICAgICA8cnVubmluZy8+IA0KPiA+ID4gPiA+ICAgICAgICAg ICAgICAgIDwvdGFyZ2V0PiANCj4gPiA+ID4gPiAgICAgICAgICAgICAgICA8Y29uZmlnPiANCj4g PiA+ID4gPiAgICAgICAgICAgICAgICAgICA8aW50ZXJmYWNlcz4gDQo+ID4gPiA+ID4gICAgICAg ICAgICAgICAgICAgICAgIDxpbnRlcmZhY2Ugb3BlcmF0aW9uPSAibWVyZ2UiPiANCj4gPiA+ID4g PiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bmFtZT5ldGgwLzAvMDwvbmFtZT4gDQo+ID4g PiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPG10dSBvcGVyYXRpb249ICJyZW1vdmUi PiANCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZW5hYmxlZD50cnVlPC9l bmFsYmxlZD4gDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgIDwvaW50ZXJmYWNlPiAN Cj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICA8L2ludGVyZmFjZXM+IA0KPiA+ID4gPiA+ICAg ICAgICAgICAgICAgIDwvY29uZmlnPiANCj4gPiA+ID4gPiAgICAgICAgICAgIDwvZWRpdC1jb25m aWc+IA0KPiA+ID4gPiA+ICAgICAgIDwvcnBjPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiAgICAg IFRoZSBzZXF1ZW5jZSBvZiBwcm9jZXNzIGlzIG1lcmdlIGludGVyZmFjZSBuYW1lICdldGgwLzAv MCcgDQphbmQgDQo+ID4gPiA+ID4gcmVtb3ZlIG10dSBhbmQgbWVyZ2UgZW5hYmxlZCB0byAndHJ1 ZScgDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvciBtZXJnZSBpbnRl cmZhY2UgbmFtZSAnZXRoMC8wLzAnIA0KYW5kIA0KPiA+ID4gPiA+IG1lcmdlIGVuYWJsZWQgdG8g J3RydWUnIGFuZCByZW1vdmUgbXR1PyANCj4gPiA+ID4gPiAgICAgIEluIG90aGVyIHdvcmRzLCBO RVRDT05GIHdpbGwgcHJvY2VzcyBvdXRlciBsYXllciBvcGVyYXRpb24gDQo+ID4gPiA+ID4gZmly c3RseSBhbmQgcHJvY2VzcyBpbm5lciBsYXllciBvcGVyYXRpb24gbGF0ZXIsIG9yIHByb2Nlc3Mg DQo+ID4gPiA+ID4gb3BlcmF0aW9ucyBpbiBhY2NvcmRhbmNlIHdpdGggWE1MIHRyZWUgdHJhdmVy c2FsIG9yZGVyPyANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBUaGVyZSBpcyBu byByZXF1aXJlZCBwcm9jZXNzaW5nIG9yZGVyLiANCj4gPiA+ID4gPiBJdCBpcyBhbiBpbXBsZW1l bnRhdGlvbiBkZXRhaWwuIA0KPiA+ID4gPiA+IFNvbWUgdGhpbmdzIHRvIGNvbnNpZGVyOiANCj4g PiA+ID4gPiAgIDEpIGFsbCBvcGVyYXRpb25zIGFyZSBhZ2FpbnN0IHRoZSB0YXJnZXQgZGF0YXN0 b3JlIGF0IHRoZSANCnN0YXJ0IG9mDQo+ID4gPiA+ID4gdGhlIG9wZXJhdGlvbiANCj4gPiA+ID4g PiAgIDIpIHRoZSBvcGVyYXRpb25zIGFyZSBhbGwtb3Itbm9uZSwgbm90IGluY3JlbWVudGFsIA0K PiA+ID4gPiA+ICAgMmEpIHRoaXMgaW1wbGllcyB0aGF0IGNyZWF0ZSB3aXRoaW4gZGVsZXRlLCBv ciBkZWxldGUgd2l0aGluIA0KPiA+ID4gPiA+IGNyZWF0ZSwgaXMgYWx3YXlzIGFuIGVycm9yIA0K PiA+ID4gPiA+ICAgICAgICBiZWNhdXNlICdkYXRhLWV4aXN0cycgb3IgJ2RhdGEtbWlzc2luZycg bXVzdCBiZSB0cnVlIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEluIHlvdXIgZXhhbXBsZSB0aGVy ZSBpcyBubyBwcm9ibGVtIGJlY2F1c2UgJ3JlbW92ZScgd29ya3MgZXZlbiANCmlmIA0KPiA+ID4g PiA+IHRoZSBkYXRhIGlzIG1pc3NpbmcuIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4g PiA+IA0KPiA+ID4gPiA+IDMuIElmIG90aGVyIG9wZXJhdGlvbiBhdHRyaWJ1dGUgbmVzdGVkIGlu IG9wZXJhdGlvbiBhdHRyaWJ1dGUgDQo+ID4gPiA+ID4gJ3JlbW92ZScsd2hhdCBzaG91bGQgTkVU Q09ORiBzZXJ2ZXIgZG8/IE9ubHkgcHJvY2VzcyByZW1vdmUgDQo+IG9wZXJhdGlvbj8gDQo+ID4g PiA+ID4gDQo+ID4gPiA+ID4gICA0LiBDYW4gTkVUQ09ORiBzdXBwb3J0IHRoZSBuZXN0ZWQgb3Bl cmF0aW9uIGF0dHJpYnV0ZSBlcXVhbHMgDQp0byANCj4gPiA+ID4gPiBwYXJlbnQgb3BlcmF0aW9u IGF0dHJpYnV0ZT8gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gL2ZyYW5rIA0KPiA+ID4gPiA+IA0K PiA+ID4gPiA+IEFuZHkgDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ ID4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIA0KdGhpcyANCj4gPiA+ID4gPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJh bnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KDQo+ID4gPiA+ID4gY29uZmlk ZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIA0KYWRk cmVzc2VlDQo+ID4gPiA+ID4gKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBp ZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+ID4gPiA+ID4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiA+ID4gPiA+IGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgDQpy ZWNlaXZlZCANCj4gPiA+ID4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQg YW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+ ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ID4g PiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4g WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIA0KDQo+ID4gPiA+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRl ZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgDQo+ID4gPiA+IGNvbmZpZGVudGlhbCBhbmQg aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSANCmFkZHJlc3NlZQ0KPiA+ ID4gPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNj bG9zdXJlLCANCj4gPiA+ID4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlz c2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiA+ID4gPiBpbmZvcm1hdGlvbiBjb250YWluZWQg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIA0KcmVjZWl2ZWQgDQo+ID4gPiA+ IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVk aWF0ZWx5Lg0KPiA+ID4gPiANCj4gPiANCj4gPiA+IA0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IFpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyAN Cj4gPiA+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMg cHJpdmlsZWdlZCBhbmQgDQo+ID4gPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+ID4gPiAocykuICBJZiB5b3UgYXJl IG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gPiA+IHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSANCj4gPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAg SWYgeW91IGhhdmUgcmVjZWl2ZWQgDQo+ID4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBk ZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiA+IA0KPiANCj4gPiANCj4g PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyANCj4gPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0 ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiA+IGNvbmZpZGVudGlhbCBhbmQgaXMg aW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUNCj4gPiAocyku ICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCAN Cj4gPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9y IHVzZSBvZiB0aGUgDQo+ID4gaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCANCj4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiANCg0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIA0KPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVk IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+IChzKS4gIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPiByZXByb2R1 Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUg DQo+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgDQo+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBh bmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55 IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZp ZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRy ZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNj bG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9u IG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxl dGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 0004466348257CF3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPkFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQ tNPaIDIwMTQtMDYtMDkNCjIyOjE5OjI1Ojxicj4NCjxicj4NCiZndDsgQW5keSBCaWVybWFuICZs dDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAyMDE0LTA2LTA5IDIyOjE5PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBkb3Uud2VpMUB6dGUuY29tLmNuLCBO ZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgPGJyPg0KJmd0OyB4aWFvLnl1cWluZ0B6 dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyA8YnI+DQomZ3Q7INb3zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KJmd0OyBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25zIGFib3V0IHRo ZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyA8YnI+DQomZ3Q7IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZp ZzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4N CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBPbiBTdW4sIEp1biA4LCAy MDE0IGF0IDEwOjQwIFBNLCAmbHQ7ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTo8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgL2ZyYW5rIDxicj4NCiZndDsg PGJyPg0KJmd0OyBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsg0LTT2iAy MDE0LTA2LTA5IDExOjQ0OjU4Ojxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFuZHkgQmllcm1h biAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8YnI+DQomZ3Q7ICZndDsgMjAxNC0wNi0wOSAx MTo0NCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IMrVvP7IyyA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ILOty80gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBk b3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgPGJy Pg0KJmd0OyAmZ3Q7IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24sIHllLnh1MUB6dGUuY29tLmNuIDxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg1vfM4iA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9m ICdvcGVyYXRpb24nIDxicj4NCiZndDsgJmd0OyBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcgPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBP biBTdW4sIEp1biA4LCAyMDE0IGF0IDg6MTggUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5j biZndDsNCndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgQW5keSwgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDt0aGFua3MsOikgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtJIHVuZGVyc3Rh bmQgb25seSBwcmVzZW5jZSBjb250YWluZXIgb3IgbGVhZiBub2RlDQp3aXRoIGVtcHR5IHR5cGU8 YnI+DQomZ3Q7ICZndDsgY2FuIGJlIHBsYWNlZCAncmVwbGFjZScgYXR0cmlidXRlIDxicj4NCiZn dDsgJmd0OyBhbmQgaGF2ZSBhIGVtcHR5IG5vZGUgc3VidHJlZS4gSXMgaXQgcmlnaHQ/IDxicj4N CiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBuby4gYW55 IGNvbnRhaW5lci4gYW55eG1sLiBlbXB0eSBsZWFmLiB6ZXJvLWxlbmd0aCBzdHJpbmcgbGVhZi4N Cjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IFJlYWxseT8gYSBOUCBjb250YWluZXIgY2FuIGJl IGEgdmFsaWQgY29uZmlndXJhdGlvbiBpdHNlbGY/IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFllcyAtLSB0aGVyZSBpcyBzb21lIGNvbmZ1 c2lvbiBiZWNhdXNlIGl0IGlzIHdpZGVseSBiZWxpZXZlZCB0aGF0DQpOUGNvbnRhaW5lcnM8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgaGF2ZSBubyBzZW1hbnRpY3MgLS0g YnV0IHRoaXMgaXMgZmFsc2UuICZuYnNwO1RoZXkNCmFyZSBjb2xsZWN0aW9ucy4gJm5ic3A7PGJy Pg0KJmd0OyBtdXN0LXN0bXQgdmFsaWRhdGlvbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyB0aGF0IGZhaWxzIG9uIGFuIE5QLWNvbnRhaW5lciB3aWxsIGNhdXNlIHRoZQ0K ZWRpdC9jb21taXQgdG8gZmFpbCA8YnI+DQomZ3Q7IGp1c3QgbGlrZSBhbnkgb3RoZXIgbm9kZS48 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIGRvbid0IGFncmVlLiBJIHRoaW5rIE5QLWNvbnRhaW5l ciBNVVNUIG5vdCBiZSBhDQp2YWxpZCBjb25maWd1cmF0aW9uIGlmIGl0IGhhcyBubyBjaGlsZHJl biw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmV2ZW4gaWYgTlAtY29udGFpbmVy IGhhcyBzb21lIHNlbWFudGljcywgaW4gdGhhdCBjYXNlLA0KTlAtY29udGFpbmVyIGp1c3QgYWN0 IGFzIGEgdW5pdCBjYW4gYmUgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5ldmFs dWF0ZWQgb3IgdmFsaWRhdGVkLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+SWYgYSBOUC1jb250YWluZXIgY2FuIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBpdHNlbGYs DQp3aGF0J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBOUC1jb250YWluZXIgYW5kIHByZXNlbmNl IGNvbnRhaW5lcj88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsg VGhleSBhcmUgbm90IGFzIHN0YW5kYXJkIGFzIG90aGVyIFlBTkcgZGF0YSBub2RlcyBiZWNhdXNl IGEgc2VydmVyDQpNQVkgY2hvb3NlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IHRvIGRlbGV0ZSB0aGVzZSBub2Rlcy4gU29tZSBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zDQpl dmVuIGNyZWF0ZSB0aGVtLDxicj4NCiZndDsgYWx0aG91Z2ggdGhlPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHNwZWMgaXMgc2lsZW50IG9uIHRoaXMgcG9pbnQuPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQXMgTGFkYSBwb2lu dGVkIG91dCwgdGhlIHNlcnZlciBmbGV4aWJpbGl0eSBmb3IgTlAtY29udGFpbmVycyBpcyA8YnI+ DQomZ3Q7IG1vcmUgb2YgYSBidWcgdGhhbiBhIGZlYXR1cmUuPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQlRXLCBlbXB0eSBiaXRzIGlzIGFub3RoZXIg ZW1wdHkgbm9kZSB0aGF0IGlzIGxlZ2FsIChmb3IgcmVwbGFjZSBvcGVyYXRpb24pLjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBZb3UgY2FuIHJlcGxhY2UgYSBsZWFmLWxp c3Qgd2l0aCBpdHNlbGYgKHRoZQ0KaW5zdGFuY2UgY29udGFpbmluZyB0aGU8YnI+DQomZ3Q7IGVt cHR5IG5vZGUsIGlmIGFueSkuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5JZiBsZWFmLWxpc3QgY2FuIGJlIHJlcGxhY2Ugd2l0aCBpdHNlbGYsIHRoZW4gdGhlDQpsaXN0 IGNhbiBiZSByZXBsYWNlIHdpdGggaXRzZWxmIGFsc28uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5UaGVuIGFsbCBub2RlcyBjb250YWluZXIgZW1wdHkgbm9kZSBzaG91bGQgYmUg Y29uc2lkZXJlZA0KdG8gYmUgYSB2YWxpZCBjb25maWd1cmF0aW9uPzwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSB0aGluayBXRyBzaG91bGQgZ2l2ZSBhIG1vcmUgY2xl YXIgY2xhcmlmaWNhdGlvbi4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+SU1PIEkgdGhpbmsgb25seSBOUC1jb250YWluZXIsZW1wdHkgbGVhZiwgYW55eG1sLA0KemVy by1sZW5ndGggc3RyaW5nIG9yIGJpbmFyeSwgYml0cyBjYW4gYmUgYSB2YWxpZCBjb25maWd1cmF0 aW9uIGl0c2VsZi4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7ICZndDsgL2ZyYW5rPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IDxicj4NCiZndDsgQW5keTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7INC009ogMjAx NC0wNi0wOSAxMDozNjoxNjo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQW5k eSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 IDIwMTQtMDYtMDkgMTA6MzYgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgytW8/sjLIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGZlbmcu Y2hvbmczM0B6dGUuY29tLmNuLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyCzrcvNIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGRvdS53 ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCA8YnI+DQom Z3Q7ICZndDsgJmd0OyB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbiA8 YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyDW98ziIDxicj4NCiZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlv bnMgYWJvdXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyBh dHRyaWJ1dGUgaW4gZWRpdC1jb25maWcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIFN1biwgSnVu IDgsIDIwMTQgYXQgNjoxOCBQTSwgJmx0O2ZlbmcuY2hvbmczM0B6dGUuY29tLmNuJmd0Ow0Kd3Jv dGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFuZHmjrCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJz cDsgJm5ic3A7IEkgaGF2ZSBsb29rZWQgdGhyb3VnaCB0aGlzIHNlY3Rpb24gZm9yIG1hbnkNCnRp bWVzLiBJbiBteSA8YnI+DQomZ3Q7ICZndDsgb3BpbmlvbiwgSSB0aGluayA8YnI+DQomZ3Q7ICZn dDsgJmd0OyB0aGUgZWxlbWVudCBjb250YWlucyBhdHRyaWJ1dGUgJ3JlcGxhY2UnIG11c3QgaGF2 ZSBzdWJ0cmVlLA0KYW5kIDxicj4NCiZndDsgJmd0OyB0aGlzIHN1YnRyZWUgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgc2hvdWxkIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbi4gQnV0IG15IGNvbGxlYWd1 ZXMgZG9uJ3QNCnRoaW5rIHNvLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGV5IGFyZ3VlZCA8YnI+ DQomZ3Q7ICZndDsgJmd0OyB0aGF0IHRoZSBlbXB0eSBjb25maWd1cmF0aW9uIGlzIGFsc28gY29u ZmlndXJhdGlvbiwgdGhleQ0Kd2FudCB0byA8YnI+DQomZ3Q7ICZndDsgdXNlJ3JlcGxhY2UnIDxi cj4NCiZndDsgJmd0OyAmZ3Q7IGFzICdyZW1vdmUnLCBJIGNhbid0IHBlcnN1YWRlIHRoZW0sIDop IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgU28sSSB3YW50IHRvIGdldCBhIGNs YXJpZmljYXRpb24sIHRoYW5rcy4NCjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmZ3Q7IHlvdSBhcmUgYm90aCByaWdodCA7LSkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgdGhlIHJlcGxhY2UgYXR0cmlidXRlIGRvZXMgaGF2ZSB0byBhcHBlYXIg aW4gYSBzdWJ0cmVlLA0KYnV0IGEgPGJyPg0KJmd0OyBzdWJ0cmVlIG1heSBiZTxicj4NCiZndDsg Jmd0OyAmZ3Q7IGFuIGVtcHR5IG5vZGUgKGlmIGl0IGlzIHNjaGVtYSB2YWxpZCkuIDxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IHN0YXJ0OiA8YnI+DQomZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJmx0O2NvbmZpZyZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Zm9vJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2EmZ3Q7NDImbHQ7L2EmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9mb28mZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbHQ7L2NvbmZpZyZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVwbGFjZSBmb286IDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyZsdDtjb25maWcmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ZvbyBvcGVyYXRpb249JnF1b3Q7cmVw bGFjZSZxdW90Ow0KLyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDsvY29uZmln Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXN1bHQ6IDxi cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbHQ7Y29uZmln Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtmb28gLyZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDsvY29uZmlnJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgdGV4dCBzZWVtcyB2ZXJ5IGNsZWFy IHRvIG1lLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAvZnJhbmsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQW5keSA8YnI+DQomZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEluIHlvdXIgZXhhbXBs ZSwgdGhlICdmb28nIE1VU1QgYmUgYSBwcmVzZW5jZSBjb250YWluZXI/IDxicj4NCiZndDsgJmd0 OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQW5keSBC aWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7INC009ogMjAxNC0wNi0wNw0KMDI6NDM6 Mjg6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBbmR5IEJp ZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAyMDE0LTA2LTA3IDAyOjQzIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyDK1bz+yMsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZG91LndlaTFAenRlLmNvbS5jbiwg TmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDssDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24sIHllLnh1MUB6dGUuY29tLmNuIDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyDW98ziIDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZTogW05ldGNvbmZdIFNv bWUgcXVlc3Rpb25zIGFib3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJw0KPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgT24gVGh1LCBKdW4gNSwgMjAxNCBhdCAxMToxOCBQTSwg Jmx0O2ZlbmcuY2hvbmczM0B6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgYW5keSwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7VGhh bmtzIGEgbG90LiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtDYW4geW91 IGFuc3dlciB0aGUgZmlyc3QgcXVlc3Rpb24/ICdyZXBsYWNlJw0KY2FuIGJlIHVzZWQgYXMncmVt b3ZlJz8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFJlYWQgUkZDIDYyNDEsIHNlYy4gNy4yIEF0dHJpYnV0ZXMgc2VjdGlvbi4gPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBJdCBleHBsYWlucyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBORVRD T05GICZsdDtlZGl0LWNvbmZpZyZndDsNCjxicj4NCiZndDsgb3BlcmF0aW9ucy4gPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IC9mcmFuayA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgQW5keSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQW5k eSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7INC009ogMjAxNC0wNi0wNQ0KMjM6 NDY6NTM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAyMDE0LTA2LTA1IDIzOjQ2IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgytW8/sjLIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZmVu Zy5jaG9uZzMzQHp0ZS5jb20uY24sIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5ldGNvbmYgJmx0O25ldGNvbmZA aWV0Zi5vcmcmZ3Q7LCB5ZS54dTFAenRlLmNvbS5jbiwNCmRvdS53ZWkxQHp0ZS5jb20uY24sIDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB4aWFvLnl1cWluZ0B6dGUuY29tLmNuIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg 1vfM4iA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9m DQonb3BlcmF0aW9uJyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYXR0cmlidXRlIGlu IGVkaXQtY29uZmlnIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgT24gV2VkLCBKdW4gNCwgMjAxNCBhdCA2OjM1IFBNLCAmbHQ7ZmVu Zy5jaG9uZzMzQHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEhpIGFsbCwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDtJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlDQpvZiAmbmJzcDsnb3BlcmF0 aW9uJyBhdHRyaWJ1dGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluIGVkaXQtY29u ZmlnLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOzEuICdyZXBs YWNlJyBhdHRyaWJ1dGUgY2FuIG9ubHkgYmUNCnVzZWQgdG8gcmVtb3ZlIGNvbmZpZ3VyYXRpb24/ IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGb3Ig ZXhhbXBsZSwgdGhlIHJwYyByZXF1ZXN0DQpsaXN0ZWQgYmVsb3cgaXMgdmFsaWQ/IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7cnBjIG1lc3Nh Z2UtaWQgPSAmcXVvdDsxMDEmcXVvdDsmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZWRpdC1jb25m aWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsmbHQ7dGFyZ2V0Jmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZsdDtydW5uaW5nLyZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7Jmx0Oy90YXJnZXQmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyZsdDtjb25maWcmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJmx0O2ludGVyZmFjZXMgb3BlcmF0aW9uPSAmcXVvdDtyZXBsYWNlJnF1b3Q7LyZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7Jmx0Oy9jb25maWcmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZsdDsvZWRpdC1jb25maWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9ycGMmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsyLkhvdyB0byBwcm9jZXNzIG5lc3RlZCBvcGVy YXRpb24NCmF0dHJpYnV0ZT8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Rm9yIGV4YW1wbGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtycGMNCm1lc3NhZ2Ut aWQgPSAmcXVvdDsxMDEmcXVvdDsmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtlZGl0LWNvbmZpZyZn dDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyZsdDt0YXJnZXQmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJmx0O3J1bm5pbmcvJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsmbHQ7L3RhcmdldCZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7Jmx0O2NvbmZpZyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbHQ7aW50ZXJmYWNlcyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtpbnRlcmZhY2Ugb3BlcmF0aW9uPSAmcXVvdDttZXJnZSZx dW90OyZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtuYW1lJmd0O2V0aDAvMC8wJmx0Oy9uYW1lJmd0 Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0O210dSBvcGVyYXRpb249ICZxdW90O3JlbW92ZSZxdW90OyZn dDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtlbmFibGVkJmd0O3RydWUmbHQ7L2VuYWxibGVkJmd0Ow0K PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsv aW50ZXJmYWNlJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZsdDsv aW50ZXJmYWNlcyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7Jmx0Oy9jb25maWcm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZWRpdC1jb25maWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9ycGMmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtUaGUgc2VxdWVuY2Ugb2YgcHJvY2VzcyBpcw0KbWVyZ2UgaW50ZXJm YWNlIG5hbWUgJ2V0aDAvMC8wJyBhbmQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJl bW92ZSBtdHUgYW5kIG1lcmdlIGVuYWJsZWQgdG8gJ3RydWUnIDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtvciBtZXJnZSBpbnRlcmZhY2UNCm5hbWUgJ2V0aDAvMC8wJyBhbmQgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IG1lcmdlIGVuYWJsZWQgdG8gJ3RydWUnIGFuZCByZW1vdmUgbXR1PyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbiBvdGhl ciB3b3JkcywgTkVUQ09ORiB3aWxsDQpwcm9jZXNzIG91dGVyIGxheWVyIG9wZXJhdGlvbiA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZmlyc3RseSBhbmQgcHJvY2VzcyBpbm5lciBsYXll ciBvcGVyYXRpb24gbGF0ZXIsDQpvciBwcm9jZXNzIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBvcGVyYXRpb25zIGluIGFjY29yZGFuY2Ugd2l0aCBYTUwgdHJlZSB0cmF2ZXJzYWwNCm9y ZGVyPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMg bm8gcmVxdWlyZWQgcHJvY2Vzc2luZyBvcmRlci4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IEl0IGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IFNvbWUgdGhpbmdzIHRvIGNvbnNpZGVyOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJm5ic3A7IDEpIGFsbCBvcGVyYXRpb25zIGFyZSBhZ2FpbnN0IHRoZSB0YXJnZXQN CmRhdGFzdG9yZSBhdCB0aGUgc3RhcnQgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg dGhlIG9wZXJhdGlvbiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDIpIHRo ZSBvcGVyYXRpb25zIGFyZSBhbGwtb3Itbm9uZSwgbm90DQppbmNyZW1lbnRhbCA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDJhKSB0aGlzIGltcGxpZXMgdGhhdCBjcmVhdGUg d2l0aGluIGRlbGV0ZSwNCm9yIGRlbGV0ZSB3aXRoaW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGNyZWF0ZSwgaXMgYWx3YXlzIGFuIGVycm9yIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZWNhdXNlICdkYXRhLWV4aXN0cycN Cm9yICdkYXRhLW1pc3NpbmcnIG11c3QgYmUgdHJ1ZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEluIHlvdXIgZXhhbXBsZSB0aGVy ZSBpcyBubyBwcm9ibGVtIGJlY2F1c2UgJ3JlbW92ZScNCndvcmtzIGV2ZW4gaWYgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBkYXRhIGlzIG1pc3NpbmcuIDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMy4gSWYgb3RoZXIgb3BlcmF0aW9uIGF0dHJp YnV0ZSBuZXN0ZWQgaW4gb3BlcmF0aW9uDQphdHRyaWJ1dGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICdyZW1vdmUnLHdoYXQgc2hvdWxkIE5FVENPTkYgc2VydmVyIGRvPyBPbmx5IHBy b2Nlc3MNCnJlbW92ZSA8YnI+DQomZ3Q7IG9wZXJhdGlvbj8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgNC4gQ2FuIE5F VENPTkYgc3VwcG9ydCB0aGUgbmVzdGVkIG9wZXJhdGlvbg0KYXR0cmlidXRlIGVxdWFscyB0byA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgcGFyZW50IG9wZXJhdGlvbiBhdHRyaWJ1dGU/ IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgL2ZyYW5rIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQW5keSA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uDQpjb250 YWluZWQgaW4gdGhpcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgbWFpbCAoYW5kIGFu eSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKQ0KaXMgcHJpdmlsZWdlZCBhbmQgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUNCnVzZSBvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBp ZW50LA0KYW55IGRpc2Nsb3N1cmUsIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXBy b2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uDQpvciB1c2Ugb2Yg dGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4NCiZuYnNwO0lmIHlvdSBoYXZlIHJlY2VpdmVkIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxl dGUgaXQgYW5kIG5vdGlmeQ0KdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgTmV0Y29uZkBpZXRmLm9yZzxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZA0KaW4gdGhp cyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFu c21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZA0KYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2UN Cm9mIHRoZSBhZGRyZXNzZWU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IChzKS4gJm5ic3A7SWYg eW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkNCmRpc2Nsb3N1cmUsIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIg ZGlzc2VtaW5hdGlvbiBvcg0KdXNlIG9mIHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAmbmJzcDtJZg0KeW91 IGhhdmUgcmVjZWl2ZWQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIG1haWwgaW4gZXJy b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cw0KaW1tZWRpYXRlbHkuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkDQppbiB0aGlzIDxicj4NCiZn dDsgJmd0OyAmZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZA0KYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBh bmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KYWRkcmVzc2VlPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLA0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2UNCm9mIHRoZSA8 YnI+DQomZ3Q7ICZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gJm5ic3A7SWYgeW91DQpoYXZlIHJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyAmZ3Q7 IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVk aWF0ZWx5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluDQp0aGlzIDxicj4NCiZndDsgJmd0OyBt YWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVn ZWQNCmFuZCA8YnI+DQomZ3Q7ICZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3Ig dGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZTxicj4NCiZndDsgJmd0OyAocykuICZu YnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUs DQo8YnI+DQomZ3Q7ICZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlz c2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlDQo8YnI+DQomZ3Q7ICZndDsgaW5mb3JtYXRpb24gY29u dGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlDQpyZWNlaXZl ZCA8YnI+DQomZ3Q7ICZndDsgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFu ZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMNCjxicj4NCiZndDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3 aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCA8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50 ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWU8YnI+DQomZ3Q7IChz KS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xv c3VyZSwgPGJyPg0KJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNz ZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQNCjxicj4N CiZndDsgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZv bnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJh bnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMg aW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5 b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1 Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlm eSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 0004466348257CF3_=-- From nobody Mon Jun 9 18:01:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EF21A0326 for ; Mon, 9 Jun 2014 18:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.272 X-Spam-Level: ** X-Spam-Status: No, score=2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_37=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7aMsjl3loRH for ; Mon, 9 Jun 2014 18:01:18 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4DC1A0322 for ; Mon, 9 Jun 2014 18:01:17 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so1516029qcz.14 for ; Mon, 09 Jun 2014 18:01:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DlCA+L/l1TuyQX30nywI0XZVk89623SmufsCX5US0Ds=; b=kCgJstV5g5S9yQDdrOLdbckgJcMGAQ5FTPzu12Kk+O1/HoZfpcYF88cTJqrfsGveSC lhbmuniwNWHTCw5WP2Sob4TqZSVzj9JljYP5CZWqy8InY7uhmrsYUYtyKsfvstx1kzZH 2BVb/bSpZvb8LZO4vG4yPBK0u/eEGWZhVUjHP2KMvXMESBgQgu2DamWTRfpwU/Wpk9I1 nE6nC9NP73BqMdzqhOTQwnt8YNch6XdjZ7qbHcH+CTijAiqt8ciNZDBKPoPy+NuE76U/ T+luyuO2xYS/N94hg2c04UwyI6BzW9/ZnlWSkrbAkDsG34i0KHQLmgSOuuoPz5iSWBdo DKlw== X-Gm-Message-State: ALoCoQnp2XMUIcREG0GxPcn8QCqbCODuqqY8evRX8oBjnuG7HtuScag0G/X7Qus0zSoIOHk4j+zV MIME-Version: 1.0 X-Received: by 10.224.165.70 with SMTP id h6mr37850483qay.78.1402362076569; Mon, 09 Jun 2014 18:01:16 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 9 Jun 2014 18:01:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 18:01:16 -0700 Message-ID: From: Andy Bierman To: feng.chong33@zte.com.cn Content-Type: multipart/alternative; boundary=089e0149c3a46bd98704fb70dd7a Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/M4vSFPjFX4-FmKM9ajt-Cbx-NOo Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 01:01:21 -0000 --089e0149c3a46bd98704fb70dd7a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Mon, Jun 9, 2014 at 5:46 PM, wrote: > /frank > > Andy Bierman =D0=B4=D3=DA 2014-06-09 22:19:25: > > > Andy Bierman > > 2014-06-09 22:19 > > > > =CA=D5=BC=FE=C8=CB > > > > feng.chong33@zte.com.cn, > > > > =B3=AD=CB=CD > > > > dou.wei1@zte.com.cn, Netconf , > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > =D6=F7=CC=E2 > > > > Re: [Netconf] Some questions about the usage of 'operation' > > attribute in edit-config > > > > > > > On Sun, Jun 8, 2014 at 10:40 PM, wrote: > > /frank > > > > Andy Bierman =D0=B4=D3=DA 2014-06-09 11:44:58: > > > > > Andy Bierman > > > 2014-06-09 11:44 > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > feng.chong33@zte.com.cn, > > > > > > =B3=AD=CB=CD > > > > > > dou.wei1@zte.com.cn, Netconf , > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > =D6=F7=CC=E2 > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > attribute in edit-config > > > > > > > > > > > On Sun, Jun 8, 2014 at 8:18 PM, wrote: > > > Andy, > > > thanks,:) > > > I understand only presence container or leaf node with empty type > > > can be placed 'replace' attribute > > > and have a empty node subtree. Is it right? > > > > > > > > > no. any container. anyxml. empty leaf. zero-length string leaf. > > > > > Really? a NP container can be a valid configuration itself? > > > > > Yes -- there is some confusion because it is widely believed that > NPcontainers > > have no semantics -- but this is false. They are collections. > > must-stmt validation > > that fails on an NP-container will cause the edit/commit to fail > > just like any other node. > > > > I don't agree. I think NP-container MUST not be a valid configuration if > it has no children, > even if NP-container has some semantics, in that case, NP-container just > act as a unit can be > evaluated or validated. > > If a NP-container can be a valid configuration itself, what's the > difference between NP-container and presence container? > > A presence container's existence has some data model semantics described in the text value for that statement. A non-presence container is a collection without additional semantics for the existence of an empty container. There is no text that supports your claim. Note this text in sec. 7.5.8: If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container. Note MAY instead of SHOULD or MUST. You can treat an empty replace operation as a delete of an NP container in your implementation. Other servers can keep them in the data model. > > They are not as standard as other YANG data nodes because a server MAY > choose > > to delete these nodes. Some server implementations even create them, > > although the > > spec is silent on this point. > > > > As Lada pointed out, the server flexibility for NP-containers is > > more of a bug than a feature. > > > > BTW, empty bits is another empty node that is legal (for replace > operation). > > You can replace a leaf-list with itself (the instance containing the > > empty node, if any). > > If leaf-list can be replace with itself, then the list can be replace wit= h > itself also. > Then all nodes container empty node should be considered to be a valid > configuration? > > But then you would be providing list keys, and the container would not be empty. Replacing a list entry with just the keys is the same as deleting all the non-key child nodes. > I think WG should give a more clear clarification. Sec. 7.5.8 could be clearer because it implies that this behavior only applies to the "delete" operation. It should be explicit that "remove" and "replace" can also cause the last child in an NP container to be deleted. > > IMO I think only NP-container,empty leaf, anyxml, zero-length string or > binary, bits can be a valid configuration itself. > > > > /frank > > > > Andy > Andy > > > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-09 10:36:16: > > > > > > > Andy Bierman > > > > 2014-06-09 10:36 > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > =B3=AD=CB=CD > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > =D6=F7=CC=E2 > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > attribute in edit-config > > > > > > > > > > > > > > > On Sun, Jun 8, 2014 at 6:18 PM, wrote: > > > > Andy=A3=AC > > > > I have looked through this section for many times. In my > > > opinion, I think > > > > the element contains attribute 'replace' must have subtree, and > > > this subtree > > > > should be a valid configuration. But my colleagues don't think so, > > > > they argued > > > > that the empty configuration is also configuration, they want to > > > use'replace' > > > > as 'remove', I can't persuade them, :) > > > > So,I want to get a clarification, thanks. > > > > > > > > you are both right ;-) > > > > > > > > the replace attribute does have to appear in a subtree, but a > > subtree may be > > > > an empty node (if it is schema valid). > > > > > > > > start: > > > > > > > > > > > > > > > > 42 > > > > > > > > > > > > > > > > replace foo: > > > > > > > > > > > > > > > > > > > > > > > > result: > > > > > > > > > > > > > > > > > > > > > > > > The text seems very clear to me. > > > > > > > > /frank > > > > > > > > Andy > > > > > > > > > > In your example, the 'foo' MUST be a presence container? > > > > > > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-07 02:43:28: > > > > > > > > > Andy Bierman > > > > > 2014-06-07 02:43 > > > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > =B3=AD=CB=CD > > > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > > > =D6=F7=CC=E2 > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > On Thu, Jun 5, 2014 at 11:18 PM, wrote: > > > > > andy, > > > > > Thanks a lot. > > > > > Can you answer the first question? 'replace' can be used > as'remove'? > > > > > > > > > > Read RFC 6241, sec. 7.2 Attributes section. > > > > > It explains the difference between the NETCONF > > operations. > > > > > > > > > > > > > > > /frank > > > > > > > > > > Andy > > > > > > > > > > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-05 23:46:5= 3: > > > > > > > > > > > Andy Bierman > > > > > > 2014-06-05 23:46 > > > > > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > > > =B3=AD=CB=CD > > > > > > > > > > > > Netconf , ye.xu1@zte.com.cn, > dou.wei1@zte.com.cn, > > > > > > xiao.yuqing@zte.com.cn > > > > > > > > > > > > =D6=F7=CC=E2 > > > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 4, 2014 at 6:35 PM, > wrote: > > > > > > Hi all, > > > > > > I have some questions about the usage of 'operation' > attribute > > > > > > in edit-config. > > > > > > 1. 'replace' attribute can only be used to remove > configuration? > > > > > > For example, the rpc request listed below is valid? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.How to process nested operation attribute? > > > > > > For example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eth0/0/0 > > > > > > > > > > > > true > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The sequence of process is merge interface name 'eth0/0/0' > and > > > > > > remove mtu and merge enabled to 'true' > > > > > > or merge interface name 'eth0/0/0' > and > > > > > > merge enabled to 'true' and remove mtu? > > > > > > In other words, NETCONF will process outer layer operation > > > > > > firstly and process inner layer operation later, or process > > > > > > operations in accordance with XML tree traversal order? > > > > > > > > > > > > > > > > > > There is no required processing order. > > > > > > It is an implementation detail. > > > > > > Some things to consider: > > > > > > 1) all operations are against the target datastore at the > start of > > > > > > the operation > > > > > > 2) the operations are all-or-none, not incremental > > > > > > 2a) this implies that create within delete, or delete within > > > > > > create, is always an error > > > > > > because 'data-exists' or 'data-missing' must be true > > > > > > > > > > > > In your example there is no problem because 'remove' works even > if > > > > > > the data is missing. > > > > > > > > > > > > > > > > > > > > > > > > 3. If other operation attribute nested in operation attribute > > > > > > 'remove',what should NETCONF server do? Only process remove > > operation? > > > > > > > > > > > > 4. Can NETCONF support the nested operation attribute equals > to > > > > > > parent operation attribute? > > > > > > > > > > > > /frank > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > > ZTE Information Security Notice: The information contained in > this > > > > > > mail (and any attachment transmitted herewith) is privileged an= d > > > > > > confidential and is intended for the exclusive use of the > addressee > > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > > reproduction, distribution or other dissemination or use of the > > > > > > information contained is strictly prohibited. If you have > received > > > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Netconf mailing list > > > > > > Netconf@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > ZTE Information Security Notice: The information contained in thi= s > > > > > mail (and any attachment transmitted herewith) is privileged and > > > > > confidential and is intended for the exclusive use of the address= ee > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > reproduction, distribution or other dissemination or use of the > > > > > information contained is strictly prohibited. If you have > received > > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > ZTE Information Security Notice: The information contained in this > > > > mail (and any attachment transmitted herewith) is privileged and > > > > confidential and is intended for the exclusive use of the addressee > > > > (s). If you are not an intended recipient, any disclosure, > > > > reproduction, distribution or other dissemination or use of the > > > > information contained is strictly prohibited. If you have received > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail (and any attachment transmitted herewith) is privileged and > > > confidential and is intended for the exclusive use of the addressee > > > (s). If you are not an intended recipient, any disclosure, > > > reproduction, distribution or other dissemination or use of the > > > information contained is strictly prohibited. If you have received > > > this mail in error, please delete it and notify us immediately. > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail (and any attachment transmitted herewith) is privileged and > > confidential and is intended for the exclusive use of the addressee > > (s). If you are not an intended recipient, any disclosure, > > reproduction, distribution or other dissemination or use of the > > information contained is strictly prohibited. If you have received > > this mail in error, please delete it and notify us immediately. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > --089e0149c3a46bd98704fb70dd7a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 9, 2014 at 5:46 PM, <feng.chong33@zte.com.cn> wrote:
/frank

Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-09 22:19:25:

> Andy Bierman <andy@yumaworks.com>
> 2014-06-09 22:19
>
> =CA=D5=BC=FE=C8=CB
>
> feng.chon= g33@zte.com.cn,
>
> =B3=AD=CB=CD
>
> dou.wei1@zte.= com.cn, Netconf <netconf@ietf.org>,
> xiao.yuqin= g@zte.com.cn, ye= .xu1@zte.com.cn
>
> =D6=F7=CC=E2
>
> Re: [Netconf] Some questions about the usage of 'operation' > attribute in edit-config
>
>

> On Sun, Jun 8, 2014 at 10:40 PM, <feng.chong33@zte.com.cn> wrote:
> /frank
>
> Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-09 11:44:58:
>
> > Andy Bierman <andy@yumaworks.com>
> > 2014-06-09 11:44
> >
> > =CA=D5=BC=FE=C8=CB
> >
> > feng= .chong33@zte.com.cn,
> >
> > =B3=AD=CB=CD
> >
> > dou.wei1= @zte.com.cn, Netconf <netconf@ietf.org>,
> > xiao.= yuqing@zte.com.cn, ye.xu1@zte.com.cn
> >
> > =D6=F7=CC=E2
> >
> > Re: [Netconf] Some questions about the usage of 'operation= 9;
> > attribute in edit-config
> >
> >
>
> > On Sun, Jun 8, 2014 at 8:18 PM, <feng.chong33@zte.com.cn> wrote:
> > Andy,
> >    thanks,:)
> >    I understand only presence container or leaf node with empty type
> > can be placed 'replace' attribute
> > and have a empty node subtree. Is it right?
> >  
> >
> > no. any container. anyxml. empty leaf. zero-length string leaf.
> >
> Really? a NP container can be a valid configuration itself?

>
> Yes -- there is some confusion because it is widely believed that NPcontainers
> have no semantics -- but this is false.  They are collections.  
> must-stmt validation
> that fails on an NP-container will cause the edit/commit to fail
> just like any other node.
>

I don't agree. I think NP-container MUST not be a valid configuration if it has no children,
even if NP-container has some semantics, in that case, NP-container just act as a unit can be
evaluated or validated.

If a NP-container can be a valid configuration itself, what's the difference between NP-container and presence container?


A presence c= ontainer's existence has some data model semantics described in
the text value for that statement.  A non-presence container is a c= ollection without
additional semantics for the existence of an empty container.

There is no text that supports your claim.

<= /div>
Note this text in sec. 7.5.8:

  If a container does not have a "presence" statement and the las=
t
  child node is deleted, the NETCONF serv=
er MAY delete the container.
Note MAY instead of SHOULD or= MUST.
You can treat an empty replace operation as a delete of an= NP container
in your implementation.  Other servers can keep them in the data = model.

 
> They are not as standard as other YANG data nodes because a server MAY choose
> to delete these nodes. Some server implementations even create them,
> although the
> spec is silent on this point.
>
> As Lada pointed out, the server flexibility for NP-containers is
> more of a bug than a feature.
>
> BTW, empty bits is another empty node that is legal (for replace opera= tion).
> You can replace a leaf-list with itself (the instance containing the
> empty node, if any).

If leaf-list can be replace with itself, then the list can be replace with itself also.
Then all nodes container empty node should be considered to be a valid configuration?


But then you would be providing list k= eys, and the container would not be empty.
Replacing a list entry= with just the keys is the same as deleting all the non-key child nodes.

 
I think WG shoul= d give a more clear clarification.

Sec. 7.5.8 could be clearer because it implies that thi= s behavior
only applies to the "delete" operation. &nbs= p;It should be explicit that "remove" and "replace"
can also cause the last child in an NP container to be deleted.
<= div>



IMO I think only NP-container,empty leaf, anyxml, zero-length string or binary, bits can be a valid configuration itself.
>  
> > /frank
>
> Andy


Andy
 
>  
> >
> > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-09 10:36:16:
> >
> > > Andy Bierman <andy@yumaworks.com>
> > > 2014-06-09 10:36
> > >
> > > =CA=D5=BC=FE=C8=CB
> > >
> > > feng.chong33@zte.com.cn,
> > >
> > > =B3=AD=CB=CD
> > >
> > > dou= .wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > = xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > >
> > > =D6=F7=CC=E2
> > >
> > > Re: [Netconf] Some questions about the usage of 'operati= on'
> > > attribute in edit-config
> > >
> > >
> >
> > > On Sun, Jun 8, 2014 at 6:18 PM, <feng.chong33@zte.com.cn> wrote:
> > > Andy=A3=AC
> > >     I have looked through this section for many times. In my
> > opinion, I think
> > > the element contains attribute 'replace' must have s= ubtree, and
> > this subtree
> > > should be a valid configuration. But my colleagues don't think so,
> > > they argued
> > > that the empty configuration is also configuration, they want to
> > use'replace'
> > > as 'remove', I can't persuade them, :)
> > >     So,I want to get a clarification, thanks.
> > >
> > > you are both right ;-)
> > >
> > > the replace attribute does have to appear in a subtree, but a
> subtree may be
> > > an empty node (if it is schema valid).
> > >
> > > start:
> > >
> > >   <config>
> > >      <foo>
> > >         <a>42</a>
> > >      </foo>
> > >   </config>
> > >
> > > replace foo:
> > >
> > >  <config>
> > >      <foo operation=3D"replace" />
> > >   </config>
> > >
> > > result:
> > >
> > >   <config>
> > >      <foo />
> > >   </config>
> > >
> > > The text seems very clear to me.
> > >
> > > /frank
> > >
> > > Andy
> > >
> >
> > In your example, the 'foo' MUST be a presence container? =
> >  
> > >
> > > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-07 02:43:28:
> > >
> > > > Andy Bierman <andy@yumaworks.com>
> > > > 2014-06-07 02:43
> > > >
> > > > =CA=D5=BC=FE=C8=CB
> > > >
> > > > feng.chong33@zte.com.cn,
> > > >
> > > > =B3=AD=CB=CD
> > > >
> > > > dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > > >
> > > > =D6=F7=CC=E2
> > > >
> > > > Re: [Netconf] Some questions about the usage of 'op= eration'
> > > > attribute in edit-config
> > > >
> > > >
> > >
> > > > On Thu, Jun 5, 2014 at 11:18 PM, <feng.chong33@zte.com.cn> wrote:
> > > > andy,
> > > >    Thanks a lot.
> > > >    Can you answer the first question? 're= place' can be used as'remove'?
> > > >
> > > > Read RFC 6241, sec. 7.2 Attributes section.
> > > > It explains the difference between the NETCONF <edit= -config>
> operations.
> > > >
> > > >  
> > > > /frank
> > > >
> > > > Andy
> > > >  
> > > >
> > > > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-05 23:46:53:
> > > >
> > > > > Andy Bierman <andy@yumaworks.com>
> > > > > 2014-06-05 23:46
> > > > >
> > > > > =CA=D5=BC=FE=C8=CB
> > > > >
> > > > > feng.chong33@zte.com.cn,
> > > > >
> > > > > =B3=AD=CB=CD
> > > > >
> > > > > Netconf <netconf@ietf.org>, ye.xu1@zte.com.cn, dou.wei1@zte.com.c= n,
> > > > > xiao.yuqing@zte.com.cn
> > > > >
> > > > > =D6=F7=CC=E2
> > > > >
> > > > > Re: [Netconf] Some questions about the usage of 'operation'
> > > > > attribute in edit-config
> > > > >
> > > > >
> > > >
> > > > > On Wed, Jun 4, 2014 at 6:35 PM, <feng.chong33@zte.com.cn&= gt; wrote:
> > > > > Hi all,
> > > > >    I have some questions about the usage of  'operation' attribute
> > > > > in edit-config.
> > > > >    1. 'replace' attribute can on= ly be used to remove configuration?
> > > > >       For example, the rpc request listed below is valid?
> > > > >       <rpc message-id =3D "= 101">
> > > > >            <edit-= config>
> > > > >                <target>
> > > > >                   <running/>
> > > > >                </target>
> > > > >                <config>
> > > > >                   <interfaces operation=3D "replace"/>
> > > > >                </config>
> > > > >            </edit= -config>
> > > > >       </rpc>
> > > > >
> > > > >
> > > > >    2.How to process nested operation attribute?
> > > > >      For example:
> > > > >            <rpc message-id =3D "101">
> > > > >            <edit-= config>
> > > > >                <target>
> > > > >                   <running/>
> > > > >                </target>
> > > > >                <config>
> > > > >                   <interfaces>
> > > > >                       <interface operation=3D "merge">= ;
> > > > >                            <name>eth0/0/0</na= me>
> > > > >                            <mtu operation=3D "= remove">
> > > > >                            <enabled>true</ena= lbled>
> > > > >                       </interface>
> > > > >                   </interfaces>
> > > > >                </config>
> > > > >            </edit= -config>
> > > > >       </rpc>
> > > > >
> > > > >      The sequence of process is merge interface name 'eth0/0/0' and
> > > > > remove mtu and merge enabled to 'true' > > > > >                              or merge interface name 'eth0/0/0' and
> > > > > merge enabled to 'true' and remove mtu? > > > > >      In other words, NETCONF will process outer layer operation
> > > > > firstly and process inner layer operation later, or process
> > > > > operations in accordance with XML tree traversal order?
> > > > >  
> > > > >
> > > > > There is no required processing order.
> > > > > It is an implementation detail.
> > > > > Some things to consider:
> > > > >   1) all operations are against the target datastore at the start of
> > > > > the operation
> > > > >   2) the operations are all-or-none, not incremental
> > > > >   2a) this implies that create within delete, or delete within
> > > > > create, is always an error
> > > > >        because 'data-exist= s' or 'data-missing' must be true
> > > > >
> > > > > In your example there is no problem because 'r= emove' works even if
> > > > > the data is missing.
> > > > >
> > > > >          
> > > > >
> > > > > 3. If other operation attribute nested in operatio= n attribute
> > > > > 'remove',what should NETCONF server do? On= ly process remove
> operation?
> > > > >
> > > > >   4. Can NETCONF support the nested operation attribute equals to
> > > > > parent operation attribute?
> > > > >      
> > > > > /frank
> > > > >
> > > > > Andy
> > > > >  
> > > > >
> > > > > --------------------------------------------------= ------
> > > > > ZTE Information Security Notice: The information contained in this
> > > > > mail (and any attachment transmitted herewith) is privileged and
> > > > > confidential and is intended for the exclusive use of the addressee
> > > > > (s).  If you are not an intended recipient, any disclosure,
> > > > > reproduction, distribution or other dissemination or use of the
> > > > > information contained is strictly prohibited.  If you have received
> > > > > this mail in error, please delete it and notify us immediately.
> > > > >
> > > >
> > > > >
> > > > >
> > > > > _______________________________________________ > > > > > Netconf mailing list
> > > > > Netconf@ietf.org
> > > > > https://www.ietf.org/mailma= n/listinfo/netconf
> > >
> > > >
> > > > -------------------------------------------------------= -
> > > > ZTE Information Security Notice: The information contai= ned in this
> > > > mail (and any attachment transmitted herewith) is privi= leged and
> > > > confidential and is intended for the exclusive use of the addressee
> > > > (s).  If you are not an intended recipient, any disclosure,
> > > > reproduction, distribution or other dissemination or use of the
> > > > information contained is strictly prohibited.  If you have received
> > > > this mail in error, please delete it and notify us immediately.
> > > >
> >
> > >
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > > mail (and any attachment transmitted herewith) is privileged and
> > > confidential and is intended for the exclusive use of the addressee
> > > (s).  If you are not an intended recipient, any disclos= ure,
> > > reproduction, distribution or other dissemination or use of the
> > > information contained is strictly prohibited.  If you have received
> > > this mail in error, please delete it and notify us immediate= ly.
> > >
>
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the address= ee
> > (s).  If you are not an intended recipient, any disclosure,
> > reproduction, distribution or other dissemination or use of the
> > information contained is strictly prohibited.  If you have received
> > this mail in error, please delete it and notify us immediately. > >

>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail (and any attachment transmitted herewith) is privileged and
> confidential and is intended for the exclusive use of the addressee > (s).  If you are not an intended recipient, any disclosure,
> reproduction, distribution or other dissemination or use of the
> information contained is strictly prohibited.  If you have receiv= ed
> this mail in error, please delete it and notify us immediately.
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


--089e0149c3a46bd98704fb70dd7a-- From nobody Mon Jun 9 19:20:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163541A034F for ; Mon, 9 Jun 2014 19:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.29 X-Spam-Level: X-Spam-Status: No, score=-98.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_37=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hdGC_FTNl7c for ; Mon, 9 Jun 2014 19:20:19 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5944E1A0348 for ; Mon, 9 Jun 2014 19:20:18 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4B9931941990 for ; Tue, 10 Jun 2014 10:20:07 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id BDA3A717F0E; Tue, 10 Jun 2014 10:20:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s5A2K4gK032433; Tue, 10 Jun 2014 10:20:04 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: References: To: Andy Bierman MIME-Version: 1.0 X-KeepSent: 4B1B1DC1:66EF4D93-48257CF3:000C6988; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Tue, 10 Jun 2014 10:20:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-10 10:20:05, Serialize complete at 2014-06-10 10:20:05 Content-Type: multipart/alternative; boundary="=_alternative 000CD20C48257CF3_=" X-MAIL: mse02.zte.com.cn s5A2K4gK032433 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8hYfTjtjq_cMLSJy295Z9rJE0Ik Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 02:20:23 -0000 This is a multipart message in MIME format. --=_alternative 000CD20C48257CF3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 L2ZyYW5rDQoNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYt MTAgMDk6MDE6MTY6DQoNCj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiAy MDE0LTA2LTEwIDA5OjAxDQo+IA0KPiDK1bz+yMsNCj4gDQo+IGZlbmcuY2hvbmczM0B6dGUuY29t LmNuLCANCj4gDQo+ILOty80NCj4gDQo+IGRvdS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgPG5l dGNvbmZAaWV0Zi5vcmc+LCANCj4geGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5j b20uY24NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJv dXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0KPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcN Cj4gDQo+IA0KDQo+IE9uIE1vbiwgSnVuIDksIDIwMTQgYXQgNTo0NiBQTSwgPGZlbmcuY2hvbmcz M0B6dGUuY29tLmNuPiB3cm90ZToNCj4gL2ZyYW5rIA0KPiANCj4gQW5keSBCaWVybWFuIDxhbmR5 QHl1bWF3b3Jrcy5jb20+INC009ogMjAxNC0wNi0wOSAyMjoxOToyNToNCj4gDQo+ID4gQW5keSBC aWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiA+IDIwMTQtMDYtMDkgMjI6MTkgDQo+ID4g DQo+ID4gytW8/sjLIA0KPiA+IA0KPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gPiAN Cj4gPiCzrcvNIA0KPiA+IA0KPiA+IGRvdS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgPG5ldGNv bmZAaWV0Zi5vcmc+LCANCj4gPiB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNv bS5jbiANCj4gPiANCj4gPiDW98ziIA0KPiA+IA0KPiA+IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVz dGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0KPiA+IGF0dHJpYnV0ZSBpbiBl ZGl0LWNvbmZpZyANCj4gPiANCj4gPiANCj4gDQo+ID4gT24gU3VuLCBKdW4gOCwgMjAxNCBhdCAx MDo0MCBQTSwgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiB3cm90ZTogDQo+ID4gL2ZyYW5rIA0K PiA+IA0KPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYt MDkgMTE6NDQ6NTg6DQo+ID4gDQo+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNv bT4gDQo+ID4gPiAyMDE0LTA2LTA5IDExOjQ0IA0KPiA+ID4gDQo+ID4gPiDK1bz+yMsgDQo+ID4g PiANCj4gPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gPiA+IA0KPiA+ID4gs63LzSAN Cj4gPiA+IA0KPiA+ID4gZG91LndlaTFAenRlLmNvbS5jbiwgTmV0Y29uZiA8bmV0Y29uZkBpZXRm Lm9yZz4sIA0KPiA+ID4geGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5jb20uY24g DQo+ID4gPiANCj4gPiA+INb3zOIgDQo+ID4gPiANCj4gPiA+IFJlOiBbTmV0Y29uZl0gU29tZSBx dWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0KPiA+ID4gYXR0cmlidXRl IGluIGVkaXQtY29uZmlnIA0KPiA+ID4gDQo+ID4gPiANCj4gPiANCj4gPiA+IE9uIFN1biwgSnVu IDgsIDIwMTQgYXQgODoxOCBQTSwgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiB3cm90ZTogDQo+ ID4gPiBBbmR5LCANCj4gPiA+ICAgIHRoYW5rcyw6KSANCj4gPiA+ICAgIEkgdW5kZXJzdGFuZCBv bmx5IHByZXNlbmNlIGNvbnRhaW5lciBvciBsZWFmIG5vZGUgd2l0aCBlbXB0eSB0eXBlDQo+ID4g PiBjYW4gYmUgcGxhY2VkICdyZXBsYWNlJyBhdHRyaWJ1dGUgDQo+ID4gPiBhbmQgaGF2ZSBhIGVt cHR5IG5vZGUgc3VidHJlZS4gSXMgaXQgcmlnaHQ/IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IG5v LiBhbnkgY29udGFpbmVyLiBhbnl4bWwuIGVtcHR5IGxlYWYuIHplcm8tbGVuZ3RoIHN0cmluZyBs ZWFmLiANCj4gPiA+IA0KPiA+IFJlYWxseT8gYSBOUCBjb250YWluZXIgY2FuIGJlIGEgdmFsaWQg Y29uZmlndXJhdGlvbiBpdHNlbGY/IA0KPiANCj4gPiANCj4gPiBZZXMgLS0gdGhlcmUgaXMgc29t ZSBjb25mdXNpb24gYmVjYXVzZSBpdCBpcyB3aWRlbHkgYmVsaWV2ZWQgdGhhdCANCj4gTlBjb250 YWluZXJzIA0KPiA+IGhhdmUgbm8gc2VtYW50aWNzIC0tIGJ1dCB0aGlzIGlzIGZhbHNlLiAgVGhl eSBhcmUgY29sbGVjdGlvbnMuIA0KPiA+IG11c3Qtc3RtdCB2YWxpZGF0aW9uIA0KPiA+IHRoYXQg ZmFpbHMgb24gYW4gTlAtY29udGFpbmVyIHdpbGwgY2F1c2UgdGhlIGVkaXQvY29tbWl0IHRvIGZh aWwgDQo+ID4ganVzdCBsaWtlIGFueSBvdGhlciBub2RlLiANCj4gPiANCj4gDQo+IEkgZG9uJ3Qg YWdyZWUuIEkgdGhpbmsgTlAtY29udGFpbmVyIE1VU1Qgbm90IGJlIGEgdmFsaWQgDQo+IGNvbmZp Z3VyYXRpb24gaWYgaXQgaGFzIG5vIGNoaWxkcmVuLCANCj4gZXZlbiBpZiBOUC1jb250YWluZXIg aGFzIHNvbWUgc2VtYW50aWNzLCBpbiB0aGF0IGNhc2UsIE5QLWNvbnRhaW5lciANCj4ganVzdCBh Y3QgYXMgYSB1bml0IGNhbiBiZSANCj4gZXZhbHVhdGVkIG9yIHZhbGlkYXRlZC4gDQo+IA0KPiBJ ZiBhIE5QLWNvbnRhaW5lciBjYW4gYmUgYSB2YWxpZCBjb25maWd1cmF0aW9uIGl0c2VsZiwgd2hh dCdzIHRoZSANCj4gZGlmZmVyZW5jZSBiZXR3ZWVuIE5QLWNvbnRhaW5lciBhbmQgcHJlc2VuY2Ug Y29udGFpbmVyPyANCg0KPiANCj4gQSBwcmVzZW5jZSBjb250YWluZXIncyBleGlzdGVuY2UgaGFz IHNvbWUgZGF0YSBtb2RlbCBzZW1hbnRpY3MgZGVzY3JpYmVkIA0KaW4NCj4gdGhlIHRleHQgdmFs dWUgZm9yIHRoYXQgc3RhdGVtZW50LiAgQSBub24tcHJlc2VuY2UgY29udGFpbmVyIGlzIGEgDQo+ IGNvbGxlY3Rpb24gd2l0aG91dA0KPiBhZGRpdGlvbmFsIHNlbWFudGljcyBmb3IgdGhlIGV4aXN0 ZW5jZSBvZiBhbiBlbXB0eSBjb250YWluZXIuDQo+IA0KPiBUaGVyZSBpcyBubyB0ZXh0IHRoYXQg c3VwcG9ydHMgeW91ciBjbGFpbS4NCj4gDQo+IE5vdGUgdGhpcyB0ZXh0IGluIHNlYy4gNy41Ljg6 DQo+IA0KPiANCj4gICBJZiBhIGNvbnRhaW5lciBkb2VzIG5vdCBoYXZlIGEgInByZXNlbmNlIiBz dGF0ZW1lbnQgYW5kIHRoZSBsYXN0DQo+ICAgY2hpbGQgbm9kZSBpcyBkZWxldGVkLCB0aGUgTkVU Q09ORiBzZXJ2ZXIgTUFZIGRlbGV0ZSB0aGUgY29udGFpbmVyLg0KPiBOb3RlIE1BWSBpbnN0ZWFk IG9mIFNIT1VMRCBvciBNVVNULg0KPiBZb3UgY2FuIHRyZWF0IGFuIGVtcHR5IHJlcGxhY2Ugb3Bl cmF0aW9uIGFzIGEgZGVsZXRlIG9mIGFuIE5QIGNvbnRhaW5lcg0KPiBpbiB5b3VyIGltcGxlbWVu dGF0aW9uLiAgT3RoZXIgc2VydmVycyBjYW4ga2VlcCB0aGVtIGluIHRoZSBkYXRhIG1vZGVsLg0K PiANCg0KSW4gc2VjdGlvbiA3LjUuMToNCiJJbiB0aGUgZmlyc3Qgc3R5bGUsIHRoZSBjb250YWlu ZXIgaGFzIG5vIG1lYW5pbmcgb2YgaXRzIG93biwgZXhpc3RpbmcNCiAgIG9ubHkgdG8gY29udGFp biBjaGlsZCBub2Rlcy4gIFRoaXMgaXMgdGhlIGRlZmF1bHQgc3R5bGUuIg0KDQpJZiBhIE5QIGNv bnRhaW5lciBleGlzdHMgb25seSB0byBjb250YWluIGNoaWxkIG5vZGVzLCB3aHkgaXRzZWxmIGNh biBiZSANCmFjY2VwdGVkIA0KYXMgYSB2YWxpZCBjb25maWd1cmF0aW9uPw0KDQoNCj4gDQo+ID4g VGhleSBhcmUgbm90IGFzIHN0YW5kYXJkIGFzIG90aGVyIFlBTkcgZGF0YSBub2RlcyBiZWNhdXNl IGEgc2VydmVyTUFZIA0KY2hvb3NlDQo+ID4gdG8gZGVsZXRlIHRoZXNlIG5vZGVzLiBTb21lIHNl cnZlciBpbXBsZW1lbnRhdGlvbnMgZXZlbiBjcmVhdGUgdGhlbSwNCj4gPiBhbHRob3VnaCB0aGUg DQo+ID4gc3BlYyBpcyBzaWxlbnQgb24gdGhpcyBwb2ludC4gDQo+ID4gDQo+ID4gQXMgTGFkYSBw b2ludGVkIG91dCwgdGhlIHNlcnZlciBmbGV4aWJpbGl0eSBmb3IgTlAtY29udGFpbmVycyBpcyAN Cj4gPiBtb3JlIG9mIGEgYnVnIHRoYW4gYSBmZWF0dXJlLiANCj4gPiANCj4gPiBCVFcsIGVtcHR5 IGJpdHMgaXMgYW5vdGhlciBlbXB0eSBub2RlIHRoYXQgaXMgbGVnYWwgKGZvciByZXBsYWNlIA0K b3BlcmF0aW9uKS4NCj4gPiBZb3UgY2FuIHJlcGxhY2UgYSBsZWFmLWxpc3Qgd2l0aCBpdHNlbGYg KHRoZSBpbnN0YW5jZSBjb250YWluaW5nIHRoZQ0KPiA+IGVtcHR5IG5vZGUsIGlmIGFueSkuIA0K PiANCj4gSWYgbGVhZi1saXN0IGNhbiBiZSByZXBsYWNlIHdpdGggaXRzZWxmLCB0aGVuIHRoZSBs aXN0IGNhbiBiZSANCj4gcmVwbGFjZSB3aXRoIGl0c2VsZiBhbHNvLiANCj4gVGhlbiBhbGwgbm9k ZXMgY29udGFpbmVyIGVtcHR5IG5vZGUgc2hvdWxkIGJlIGNvbnNpZGVyZWQgdG8gYmUgYSANCj4g dmFsaWQgY29uZmlndXJhdGlvbj8gDQoNCj4gDQo+IEJ1dCB0aGVuIHlvdSB3b3VsZCBiZSBwcm92 aWRpbmcgbGlzdCBrZXlzLCBhbmQgdGhlIGNvbnRhaW5lciB3b3VsZCANCj4gbm90IGJlIGVtcHR5 Lg0KPiBSZXBsYWNpbmcgYSBsaXN0IGVudHJ5IHdpdGgganVzdCB0aGUga2V5cyBpcyB0aGUgc2Ft ZSBhcyBkZWxldGluZyANCj4gYWxsIHRoZSBub24ta2V5IGNoaWxkIG5vZGVzLg0KPiANCj4gDQo+ IEkgdGhpbmsgV0cgc2hvdWxkIGdpdmUgYSBtb3JlIGNsZWFyIGNsYXJpZmljYXRpb24uDQo+IA0K PiBTZWMuIDcuNS44IGNvdWxkIGJlIGNsZWFyZXIgYmVjYXVzZSBpdCBpbXBsaWVzIHRoYXQgdGhp cyBiZWhhdmlvcg0KPiBvbmx5IGFwcGxpZXMgdG8gdGhlICJkZWxldGUiIG9wZXJhdGlvbi4gIEl0 IHNob3VsZCBiZSBleHBsaWNpdCB0aGF0IA0KPiAicmVtb3ZlIiBhbmQgInJlcGxhY2UiDQo+IGNh biBhbHNvIGNhdXNlIHRoZSBsYXN0IGNoaWxkIGluIGFuIE5QIGNvbnRhaW5lciB0byBiZSBkZWxl dGVkLg0KPiANCj4gDQo+IA0KPiBJTU8gSSB0aGluayBvbmx5IE5QLWNvbnRhaW5lcixlbXB0eSBs ZWFmLCBhbnl4bWwsIHplcm8tbGVuZ3RoIHN0cmluZw0KPiBvciBiaW5hcnksIGJpdHMgY2FuIGJl IGEgdmFsaWQgY29uZmlndXJhdGlvbiBpdHNlbGYuIA0KPiA+IA0KPiA+ID4gL2ZyYW5rIA0KPiA+ IA0KPiA+IEFuZHkgDQo+IA0KPiBBbmR5DQo+IA0KPiA+IA0KPiA+ID4gDQo+ID4gPiBBbmR5IEJp ZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4g0LTT2iAyMDE0LTA2LTA5IDEwOjM2OjE2Og0KPiA+ ID4gDQo+ID4gPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4gPiA+ID4g MjAxNC0wNi0wOSAxMDozNiANCj4gPiA+ID4gDQo+ID4gPiA+IMrVvP7IyyANCj4gPiA+ID4gDQo+ ID4gPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gPiA+ID4gDQo+ID4gPiA+ILOty80g DQo+ID4gPiA+IA0KPiA+ID4gPiBkb3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mIDxuZXRjb25m QGlldGYub3JnPiwgDQo+ID4gPiA+IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24sIHllLnh1MUB6dGUu Y29tLmNuIA0KPiA+ID4gPiANCj4gPiA+ID4g1vfM4iANCj4gPiA+ID4gDQo+ID4gPiA+IFJlOiBb TmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0K PiA+ID4gPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcgDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4g PiA+IA0KPiA+ID4gPiBPbiBTdW4sIEp1biA4LCAyMDE0IGF0IDY6MTggUE0sIDxmZW5nLmNob25n MzNAenRlLmNvbS5jbj4gd3JvdGU6IA0KPiA+ID4gPiBBbmR5o6wgDQo+ID4gPiA+ICAgICBJIGhh dmUgbG9va2VkIHRocm91Z2ggdGhpcyBzZWN0aW9uIGZvciBtYW55IHRpbWVzLiBJbiBteSANCj4g PiA+IG9waW5pb24sIEkgdGhpbmsgDQo+ID4gPiA+IHRoZSBlbGVtZW50IGNvbnRhaW5zIGF0dHJp YnV0ZSAncmVwbGFjZScgbXVzdCBoYXZlIHN1YnRyZWUsIGFuZCANCj4gPiA+IHRoaXMgc3VidHJl ZSANCj4gPiA+ID4gc2hvdWxkIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbi4gQnV0IG15IGNvbGxl YWd1ZXMgZG9uJ3QgdGhpbmsgc28sIA0KDQo+ID4gPiA+IHRoZXkgYXJndWVkIA0KPiA+ID4gPiB0 aGF0IHRoZSBlbXB0eSBjb25maWd1cmF0aW9uIGlzIGFsc28gY29uZmlndXJhdGlvbiwgdGhleSB3 YW50IHRvIA0KPiA+ID4gdXNlJ3JlcGxhY2UnIA0KPiA+ID4gPiBhcyAncmVtb3ZlJywgSSBjYW4n dCBwZXJzdWFkZSB0aGVtLCA6KSANCj4gPiA+ID4gICAgIFNvLEkgd2FudCB0byBnZXQgYSBjbGFy aWZpY2F0aW9uLCB0aGFua3MuIA0KPiA+ID4gPiANCj4gPiA+ID4geW91IGFyZSBib3RoIHJpZ2h0 IDstKSANCj4gPiA+ID4gDQo+ID4gPiA+IHRoZSByZXBsYWNlIGF0dHJpYnV0ZSBkb2VzIGhhdmUg dG8gYXBwZWFyIGluIGEgc3VidHJlZSwgYnV0IGEgDQo+ID4gc3VidHJlZSBtYXkgYmUNCj4gPiA+ ID4gYW4gZW1wdHkgbm9kZSAoaWYgaXQgaXMgc2NoZW1hIHZhbGlkKS4gDQo+ID4gPiA+IA0KPiA+ ID4gPiBzdGFydDogDQo+ID4gPiA+IA0KPiA+ID4gPiAgIDxjb25maWc+IA0KPiA+ID4gPiAgICAg IDxmb28+IA0KPiA+ID4gPiAgICAgICAgIDxhPjQyPC9hPiANCj4gPiA+ID4gICAgICA8L2Zvbz4g DQo+ID4gPiA+ICAgPC9jb25maWc+IA0KPiA+ID4gPiANCj4gPiA+ID4gcmVwbGFjZSBmb286IA0K PiA+ID4gPiANCj4gPiA+ID4gIDxjb25maWc+IA0KPiA+ID4gPiAgICAgIDxmb28gb3BlcmF0aW9u PSJyZXBsYWNlIiAvPiANCj4gPiA+ID4gICA8L2NvbmZpZz4gDQo+ID4gPiA+IA0KPiA+ID4gPiBy ZXN1bHQ6IA0KPiA+ID4gPiANCj4gPiA+ID4gICA8Y29uZmlnPiANCj4gPiA+ID4gICAgICA8Zm9v IC8+IA0KPiA+ID4gPiAgIDwvY29uZmlnPiANCj4gPiA+ID4gDQo+ID4gPiA+IFRoZSB0ZXh0IHNl ZW1zIHZlcnkgY2xlYXIgdG8gbWUuIA0KPiA+ID4gPiANCj4gPiA+ID4gL2ZyYW5rIA0KPiA+ID4g PiANCj4gPiA+ID4gQW5keSANCj4gPiA+ID4gDQo+ID4gPiANCj4gPiA+IEluIHlvdXIgZXhhbXBs ZSwgdGhlICdmb28nIE1VU1QgYmUgYSBwcmVzZW5jZSBjb250YWluZXI/IA0KPiA+ID4gDQo+ID4g PiA+IA0KPiA+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4g0LTT2iAyMDE0 LTA2LTA3IDAyOjQzOjI4Og0KPiA+ID4gPiANCj4gPiA+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlA eXVtYXdvcmtzLmNvbT4gDQo+ID4gPiA+ID4gMjAxNC0wNi0wNyAwMjo0MyANCj4gPiA+ID4gPiAN Cj4gPiA+ID4gPiDK1bz+yMsgDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gZmVuZy5jaG9uZzMzQHp0 ZS5jb20uY24sIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ILOty80gDQo+ID4gPiA+ID4gDQo+ID4g PiA+ID4gZG91LndlaTFAenRlLmNvbS5jbiwgTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4sIA0K PiA+ID4gPiA+IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24sIHllLnh1MUB6dGUuY29tLmNuIA0KPiA+ ID4gPiA+IA0KPiA+ID4gPiA+INb3zOIgDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gUmU6IFtOZXRj b25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgDQo+ID4g PiA+ID4gYXR0cmlidXRlIGluIGVkaXQtY29uZmlnIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0K PiA+ID4gPiANCj4gPiA+ID4gPiBPbiBUaHUsIEp1biA1LCAyMDE0IGF0IDExOjE4IFBNLCA8ZmVu Zy5jaG9uZzMzQHp0ZS5jb20uY24+IA0Kd3JvdGU6IA0KPiA+ID4gPiA+IGFuZHksIA0KPiA+ID4g PiA+ICAgIFRoYW5rcyBhIGxvdC4gDQo+ID4gPiA+ID4gICAgQ2FuIHlvdSBhbnN3ZXIgdGhlIGZp cnN0IHF1ZXN0aW9uPyAncmVwbGFjZScgY2FuIGJlIHVzZWQgDQo+IGFzJ3JlbW92ZSc/IA0KPiA+ ID4gPiA+IA0KPiA+ID4gPiA+IFJlYWQgUkZDIDYyNDEsIHNlYy4gNy4yIEF0dHJpYnV0ZXMgc2Vj dGlvbi4gDQo+ID4gPiA+ID4gSXQgZXhwbGFpbnMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUg TkVUQ09ORiA8ZWRpdC1jb25maWc+IA0KPiA+IG9wZXJhdGlvbnMuIA0KPiA+ID4gPiA+IA0KPiA+ ID4gPiA+IA0KPiA+ID4gPiA+IC9mcmFuayANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBBbmR5IA0K PiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1h d29ya3MuY29tPiDQtNPaIDIwMTQtMDYtMDUgMjM6NDY6NTM6DQo+ID4gPiA+ID4gDQo+ID4gPiA+ ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gDQo+ID4gPiA+ID4gPiAyMDE0 LTA2LTA1IDIzOjQ2IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiDK1bz+yMsgDQo+ID4gPiA+ ID4gPiANCj4gPiA+ID4gPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gPiA+ID4gPiA+ IA0KPiA+ID4gPiA+ID4gs63LzSANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gTmV0Y29uZiA8 bmV0Y29uZkBpZXRmLm9yZz4sIHllLnh1MUB6dGUuY29tLmNuLCANCmRvdS53ZWkxQHp0ZS5jb20u Y24sIA0KPiA+ID4gPiA+ID4geGlhby55dXFpbmdAenRlLmNvbS5jbiANCj4gPiA+ID4gPiA+IA0K PiA+ID4gPiA+ID4g1vfM4iANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gUmU6IFtOZXRjb25m XSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgDQo+ID4gPiA+ ID4gPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcgDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gT24gV2VkLCBKdW4gNCwgMjAxNCBhdCA2OjM1IFBN LCA8ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24+IA0Kd3JvdGU6IA0KPiA+ID4gPiA+ID4gSGkgYWxs LCANCj4gPiA+ID4gPiA+ICAgIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ug b2YgICdvcGVyYXRpb24nIA0KYXR0cmlidXRlIA0KPiA+ID4gPiA+ID4gaW4gZWRpdC1jb25maWcu IA0KPiA+ID4gPiA+ID4gICAgMS4gJ3JlcGxhY2UnIGF0dHJpYnV0ZSBjYW4gb25seSBiZSB1c2Vk IHRvIHJlbW92ZSANCmNvbmZpZ3VyYXRpb24/IA0KPiA+ID4gPiA+ID4gICAgICAgRm9yIGV4YW1w bGUsIHRoZSBycGMgcmVxdWVzdCBsaXN0ZWQgYmVsb3cgaXMgdmFsaWQ/IA0KPiA+ID4gPiA+ID4g ICAgICAgPHJwYyBtZXNzYWdlLWlkID0gIjEwMSI+IA0KPiA+ID4gPiA+ID4gICAgICAgICAgICA8 ZWRpdC1jb25maWc+IA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgPHRhcmdldD4gDQo+ID4g PiA+ID4gPiAgICAgICAgICAgICAgICAgICA8cnVubmluZy8+IA0KPiA+ID4gPiA+ID4gICAgICAg ICAgICAgICAgPC90YXJnZXQ+IA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgPGNvbmZpZz4g DQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICA8aW50ZXJmYWNlcyBvcGVyYXRpb249ICJy ZXBsYWNlIi8+IA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgPC9jb25maWc+IA0KPiA+ID4g PiA+ID4gICAgICAgICAgICA8L2VkaXQtY29uZmlnPiANCj4gPiA+ID4gPiA+ICAgICAgIDwvcnBj PiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiAgICAyLkhvdyB0byBw cm9jZXNzIG5lc3RlZCBvcGVyYXRpb24gYXR0cmlidXRlPyANCj4gPiA+ID4gPiA+ICAgICAgRm9y IGV4YW1wbGU6IA0KPiA+ID4gPiA+ID4gICAgICAgICAgICA8cnBjIG1lc3NhZ2UtaWQgPSAiMTAx Ij4gDQo+ID4gPiA+ID4gPiAgICAgICAgICAgIDxlZGl0LWNvbmZpZz4gDQo+ID4gPiA+ID4gPiAg ICAgICAgICAgICAgICA8dGFyZ2V0PiANCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgIDxy dW5uaW5nLz4gDQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICA8L3RhcmdldD4gDQo+ID4gPiA+ ID4gPiAgICAgICAgICAgICAgICA8Y29uZmlnPiANCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAg ICAgIDxpbnRlcmZhY2VzPiANCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICA8aW50 ZXJmYWNlIG9wZXJhdGlvbj0gIm1lcmdlIj4gDQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8bmFtZT5ldGgwLzAvMDwvbmFtZT4gDQo+ID4gPiA+ID4gPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8bXR1IG9wZXJhdGlvbj0gInJlbW92ZSI+IA0KPiA+ID4gPiA+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGVuYWJsZWQ+dHJ1ZTwvZW5hbGJsZWQ+IA0KPiA+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgIDwvaW50ZXJmYWNlPiANCj4gPiA+ID4gPiA+ ICAgICAgICAgICAgICAgICAgIDwvaW50ZXJmYWNlcz4gDQo+ID4gPiA+ID4gPiAgICAgICAgICAg ICAgICA8L2NvbmZpZz4gDQo+ID4gPiA+ID4gPiAgICAgICAgICAgIDwvZWRpdC1jb25maWc+IA0K PiA+ID4gPiA+ID4gICAgICAgPC9ycGM+IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiAgICAg IFRoZSBzZXF1ZW5jZSBvZiBwcm9jZXNzIGlzIG1lcmdlIGludGVyZmFjZSBuYW1lIA0KJ2V0aDAv MC8wJyBhbmQgDQo+ID4gPiA+ID4gPiByZW1vdmUgbXR1IGFuZCBtZXJnZSBlbmFibGVkIHRvICd0 cnVlJyANCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3IgbWVyZ2Ug aW50ZXJmYWNlIG5hbWUgDQonZXRoMC8wLzAnIGFuZCANCj4gPiA+ID4gPiA+IG1lcmdlIGVuYWJs ZWQgdG8gJ3RydWUnIGFuZCByZW1vdmUgbXR1PyANCj4gPiA+ID4gPiA+ICAgICAgSW4gb3RoZXIg d29yZHMsIE5FVENPTkYgd2lsbCBwcm9jZXNzIG91dGVyIGxheWVyIA0Kb3BlcmF0aW9uIA0KPiA+ ID4gPiA+ID4gZmlyc3RseSBhbmQgcHJvY2VzcyBpbm5lciBsYXllciBvcGVyYXRpb24gbGF0ZXIs IG9yIHByb2Nlc3MgDQo+ID4gPiA+ID4gPiBvcGVyYXRpb25zIGluIGFjY29yZGFuY2Ugd2l0aCBY TUwgdHJlZSB0cmF2ZXJzYWwgb3JkZXI/IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiANCj4g PiA+ID4gPiA+IFRoZXJlIGlzIG5vIHJlcXVpcmVkIHByb2Nlc3Npbmcgb3JkZXIuIA0KPiA+ID4g PiA+ID4gSXQgaXMgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLiANCj4gPiA+ID4gPiA+IFNvbWUg dGhpbmdzIHRvIGNvbnNpZGVyOiANCj4gPiA+ID4gPiA+ICAgMSkgYWxsIG9wZXJhdGlvbnMgYXJl IGFnYWluc3QgdGhlIHRhcmdldCBkYXRhc3RvcmUgYXQgdGhlIA0Kc3RhcnQgb2YNCj4gPiA+ID4g PiA+IHRoZSBvcGVyYXRpb24gDQo+ID4gPiA+ID4gPiAgIDIpIHRoZSBvcGVyYXRpb25zIGFyZSBh bGwtb3Itbm9uZSwgbm90IGluY3JlbWVudGFsIA0KPiA+ID4gPiA+ID4gICAyYSkgdGhpcyBpbXBs aWVzIHRoYXQgY3JlYXRlIHdpdGhpbiBkZWxldGUsIG9yIGRlbGV0ZSB3aXRoaW4gDQoNCj4gPiA+ ID4gPiA+IGNyZWF0ZSwgaXMgYWx3YXlzIGFuIGVycm9yIA0KPiA+ID4gPiA+ID4gICAgICAgIGJl Y2F1c2UgJ2RhdGEtZXhpc3RzJyBvciAnZGF0YS1taXNzaW5nJyBtdXN0IGJlIHRydWUgDQo+ID4g PiA+ID4gPiANCj4gPiA+ID4gPiA+IEluIHlvdXIgZXhhbXBsZSB0aGVyZSBpcyBubyBwcm9ibGVt IGJlY2F1c2UgJ3JlbW92ZScgd29ya3MgDQpldmVuIGlmIA0KPiA+ID4gPiA+ID4gdGhlIGRhdGEg aXMgbWlzc2luZy4gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gDQo+ ID4gPiA+ID4gPiAzLiBJZiBvdGhlciBvcGVyYXRpb24gYXR0cmlidXRlIG5lc3RlZCBpbiBvcGVy YXRpb24gYXR0cmlidXRlIA0KPiA+ID4gPiA+ID4gJ3JlbW92ZScsd2hhdCBzaG91bGQgTkVUQ09O RiBzZXJ2ZXIgZG8/IE9ubHkgcHJvY2VzcyByZW1vdmUgDQo+ID4gb3BlcmF0aW9uPyANCj4gPiA+ ID4gPiA+IA0KPiA+ID4gPiA+ID4gICA0LiBDYW4gTkVUQ09ORiBzdXBwb3J0IHRoZSBuZXN0ZWQg b3BlcmF0aW9uIGF0dHJpYnV0ZSBlcXVhbHMgDQp0byANCj4gPiA+ID4gPiA+IHBhcmVudCBvcGVy YXRpb24gYXR0cmlidXRlPyANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gL2ZyYW5rIA0KPiA+ ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBBbmR5IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiAN Cj4gPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIA0KdGhpcyANCj4gPiA+ID4gPiA+IG1haWwg KGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCAN CmFuZCANCj4gPiA+ID4gPiA+IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBl eGNsdXNpdmUgdXNlIG9mIHRoZSANCmFkZHJlc3NlZQ0KPiA+ID4gPiA+ID4gKHMpLiAgSWYgeW91 IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+ID4gPiA+ ID4gPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9y IHVzZSBvZiANCnRoZSANCj4gPiA+ID4gPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IA0KaGF2ZXJlY2VpdmVkIA0KPiA+ID4gPiA+ID4gdGhp cyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgDQppbW1lZGlh dGVseS4NCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4g PiANCj4gPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gPiA+ID4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+ID4gTmV0 Y29uZkBpZXRmLm9yZw0KPiA+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mDQo+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ ID4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiANCnRoaXMgDQo+ID4gPiA+ID4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5z bWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCg0KPiA+ID4gPiA+IGNvbmZpZGVu dGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSANCmFkZHJl c3NlZQ0KPiA+ID4gPiA+IChzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVu dCwgYW55IGRpc2Nsb3N1cmUsIA0KPiA+ID4gPiA+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9u IG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gPiA+ID4gPiBpbmZvcm1h dGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIA0KcmVj ZWl2ZWQgDQo+ID4gPiA+ID4gdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFu ZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+ID4gPiA+ID4gDQo+ID4gPiANCj4gPiA+ID4gDQo+ ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4gPiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyANCg0KPiA+ID4gPiBtYWlsIChhbmQgYW55IGF0dGFj aG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiA+ID4gPiBj b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUg DQphZGRyZXNzZWUNCj4gPiA+ID4gKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVj aXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+ID4gPiA+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gPiA+ID4gaW5mb3Jt YXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSANCnJl Y2VpdmVkIA0KPiA+ID4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5k IG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiA+ID4gDQo+ID4gDQo+ID4gPiANCj4gPiA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgDQo+ID4gPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0 ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiA+ID4gY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiA+ID4g KHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3Vy ZSwgDQo+ID4gPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0 aW9uIG9yIHVzZSBvZiB0aGUgDQo+ID4gPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiA+ID4gdGhpcyBtYWlsIGlu IGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+ID4g PiANCj4gDQo+ID4gDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgDQo+ID4gbWFpbCAoYW5kIGFueSBhdHRh Y2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCj4gPiBjb25m aWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRk cmVzc2VlDQo+ID4gKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBh bnkgZGlzY2xvc3VyZSwgDQo+ID4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIg ZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgDQo+ID4gdGhpcyBt YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHku DQo+ID4gDQoNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyANCj4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50 IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCj4gY29uZmlkZW50aWFs IGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0K PiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9z dXJlLCANCj4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlv biBvciB1c2Ugb2YgdGhlIA0KPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2 aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZl IHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVj aXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3Ro ZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVy cm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJp dmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJl Y2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90 aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBl cnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 000CD20C48257CF3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPkFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQ tNPaIDIwMTQtMDYtMTANCjA5OjAxOjE2Ojxicj4NCjxicj4NCiZndDsgQW5keSBCaWVybWFuICZs dDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAyMDE0LTA2LTEwIDA5OjAxPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBkb3Uud2VpMUB6dGUuY29tLmNuLCBO ZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgPGJyPg0KJmd0OyB4aWFvLnl1cWluZ0B6 dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyA8YnI+DQomZ3Q7INb3zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KJmd0OyBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25zIGFib3V0IHRo ZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyA8YnI+DQomZ3Q7IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZp ZzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4N CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBPbiBNb24sIEp1biA5LCAy MDE0IGF0IDU6NDYgUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5jbiZndDsNCndyb3RlOjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAvZnJhbmsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQtNPaIDIw MTQtMDYtMDkgMjI6MTk6MjU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgQW5keSBCaWVybWFu ICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDxicj4NCiZndDsgJmd0OyAyMDE0LTA2LTA5IDIy OjE5IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgytW8/sjLIDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGRv dS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCA8YnI+ DQomZ3Q7ICZndDsgeGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5jb20uY24gPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDW98ziIDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2Yg J29wZXJhdGlvbicgPGJyPg0KJmd0OyAmZ3Q7IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZpZyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9u IFN1biwgSnVuIDgsIDIwMTQgYXQgMTA6NDAgUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5j biZndDsNCndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgL2ZyYW5rIDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7INC009og MjAxNC0wNi0wOSAxMTo0NDo1ODo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg QW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IDIwMTQtMDYtMDkgMTE6NDQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgytW8/sjLIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGZl bmcuY2hvbmczM0B6dGUuY29tLmNuLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyCzrcvNIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGRv dS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCA8YnI+ DQomZ3Q7ICZndDsgJmd0OyB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5j biA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyDW98ziIDxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVz dGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nDQo8YnI+DQomZ3Q7ICZndDsgJmd0 OyBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIFN1biwg SnVuIDgsIDIwMTQgYXQgODoxOCBQTSwgJmx0O2ZlbmcuY2hvbmczM0B6dGUuY29tLmNuJmd0Ow0K d3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFuZHksIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDt0aGFua3MsOikgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0kg dW5kZXJzdGFuZCBvbmx5IHByZXNlbmNlIGNvbnRhaW5lciBvciBsZWFmDQpub2RlIHdpdGggZW1w dHkgdHlwZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGNhbiBiZSBwbGFjZWQgJ3JlcGxhY2UnIGF0dHJp YnV0ZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBhbmQgaGF2ZSBhIGVtcHR5IG5vZGUgc3VidHJlZS4g SXMgaXQgcmlnaHQ/IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBuby4gYW55IGNvbnRhaW5lci4gYW55eG1sLiBlbXB0 eSBsZWFmLiB6ZXJvLWxlbmd0aCBzdHJpbmcNCmxlYWYuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyBSZWFsbHk/IGEgTlAgY29udGFpbmVyIGNhbiBiZSBhIHZhbGlkIGNvbmZp Z3VyYXRpb24gaXRzZWxmPyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgWWVzIC0tIHRoZXJlIGlzIHNvbWUgY29uZnVzaW9uIGJlY2F1c2UgaXQgaXMgd2lkZWx5IGJl bGlldmVkDQp0aGF0IDxicj4NCiZndDsgTlBjb250YWluZXJzIDxicj4NCiZndDsgJmd0OyBoYXZl IG5vIHNlbWFudGljcyAtLSBidXQgdGhpcyBpcyBmYWxzZS4gJm5ic3A7VGhleSBhcmUgY29sbGVj dGlvbnMuDQombmJzcDs8YnI+DQomZ3Q7ICZndDsgbXVzdC1zdG10IHZhbGlkYXRpb24gPGJyPg0K Jmd0OyAmZ3Q7IHRoYXQgZmFpbHMgb24gYW4gTlAtY29udGFpbmVyIHdpbGwgY2F1c2UgdGhlIGVk aXQvY29tbWl0IHRvIGZhaWwNCjxicj4NCiZndDsgJmd0OyBqdXN0IGxpa2UgYW55IG90aGVyIG5v ZGUuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBkb24ndCBhZ3JlZS4g SSB0aGluayBOUC1jb250YWluZXIgTVVTVCBub3QgYmUgYSB2YWxpZCA8YnI+DQomZ3Q7IGNvbmZp Z3VyYXRpb24gaWYgaXQgaGFzIG5vIGNoaWxkcmVuLCA8YnI+DQomZ3Q7IGV2ZW4gaWYgTlAtY29u dGFpbmVyIGhhcyBzb21lIHNlbWFudGljcywgaW4gdGhhdCBjYXNlLCBOUC1jb250YWluZXINCjxi cj4NCiZndDsganVzdCBhY3QgYXMgYSB1bml0IGNhbiBiZSA8YnI+DQomZ3Q7IGV2YWx1YXRlZCBv ciB2YWxpZGF0ZWQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBhIE5QLWNvbnRhaW5lciBjYW4g YmUgYSB2YWxpZCBjb25maWd1cmF0aW9uIGl0c2VsZiwgd2hhdCdzIHRoZQ0KPGJyPg0KJmd0OyBk aWZmZXJlbmNlIGJldHdlZW4gTlAtY29udGFpbmVyIGFuZCBwcmVzZW5jZSBjb250YWluZXI/IDxi cj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEEg cHJlc2VuY2UgY29udGFpbmVyJ3MgZXhpc3RlbmNlIGhhcyBzb21lIGRhdGEgbW9kZWwgc2VtYW50 aWNzIGRlc2NyaWJlZA0KaW48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg dGhlIHRleHQgdmFsdWUgZm9yIHRoYXQgc3RhdGVtZW50LiAmbmJzcDtBIG5vbi1wcmVzZW5jZQ0K Y29udGFpbmVyIGlzIGEgPGJyPg0KJmd0OyBjb2xsZWN0aW9uIHdpdGhvdXQ8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgYWRkaXRpb25hbCBzZW1hbnRpY3MgZm9yIHRoZSBl eGlzdGVuY2Ugb2YgYW4NCmVtcHR5IGNvbnRhaW5lci48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGVyZSBpcyBubyB0ZXh0IHRoYXQgc3VwcG9ydHMg eW91ciBjbGFpbS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K Jmd0OyBOb3RlIHRoaXMgdGV4dCBpbiBzZWMuIDcuNS44OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7IElmIGEgY29udGFp bmVyIGRvZXMgbm90IGhhdmUgYSAmcXVvdDtwcmVzZW5jZSZxdW90OyBzdGF0ZW1lbnQNCmFuZCB0 aGUgbGFzdDxicj4NCiZndDsgJm5ic3A7IGNoaWxkIG5vZGUgaXMgZGVsZXRlZCwgdGhlIE5FVENP TkYgc2VydmVyIE1BWSBkZWxldGUgdGhlIGNvbnRhaW5lci48L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgTm90ZSBNQVkgaW5zdGVhZCBvZiBTSE9VTEQgb3IgTVVTVC48L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgWW91IGNhbiB0cmVhdCBhbiBlbXB0 eSByZXBsYWNlIG9wZXJhdGlvbiBhcyBhDQpkZWxldGUgb2YgYW4gTlAgY29udGFpbmVyPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGluIHlvdXIgaW1wbGVtZW50YXRpb24u ICZuYnNwO090aGVyIHNlcnZlcnMgY2FuDQprZWVwIHRoZW0gaW4gdGhlIGRhdGEgbW9kZWwuPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+SW4gc2VjdGlvbiA3LjUuMTo8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O0luIHRoZSBmaXJzdCBzdHlsZSwgdGhlIGNvbnRhaW5lciBo YXMgbm8gbWVhbmluZw0Kb2YgaXRzIG93biwgZXhpc3Rpbmc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDtvbmx5IHRvIGNvbnRhaW4gY2hpbGQgbm9kZXMuICZu YnNwO1RoaXMNCmlzIHRoZSBkZWZhdWx0IHN0eWxlLiZxdW90OzwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+SWYgYSBOUCBjb250YWluZXIgZXhpc3RzIG9ubHkgdG8gY29u dGFpbiBjaGlsZCBub2RlcywNCndoeSBpdHNlbGYgY2FuIGJlIGFjY2VwdGVkIDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+YXMgYSB2YWxpZCBjb25maWd1cmF0aW9uPzwvZm9udD48 L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmbmJzcDs8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyBUaGV5IGFyZSBub3QgYXMgc3Rh bmRhcmQgYXMgb3RoZXIgWUFORyBkYXRhDQpub2RlcyBiZWNhdXNlIGEgc2VydmVyTUFZIGNob29z ZTxicj4NCiZndDsgJmd0OyB0byBkZWxldGUgdGhlc2Ugbm9kZXMuIFNvbWUgc2VydmVyIGltcGxl bWVudGF0aW9ucyBldmVuIGNyZWF0ZQ0KdGhlbSw8YnI+DQomZ3Q7ICZndDsgYWx0aG91Z2ggdGhl IDxicj4NCiZndDsgJmd0OyBzcGVjIGlzIHNpbGVudCBvbiB0aGlzIHBvaW50LiA8YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFzIExhZGEgcG9pbnRlZCBvdXQsIHRoZSBzZXJ2ZXIgZmxl eGliaWxpdHkgZm9yIE5QLWNvbnRhaW5lcnMNCmlzIDxicj4NCiZndDsgJmd0OyBtb3JlIG9mIGEg YnVnIHRoYW4gYSBmZWF0dXJlLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEJUVywg ZW1wdHkgYml0cyBpcyBhbm90aGVyIGVtcHR5IG5vZGUgdGhhdCBpcyBsZWdhbCAoZm9yIHJlcGxh Y2UNCm9wZXJhdGlvbikuPGJyPg0KJmd0OyAmZ3Q7IFlvdSBjYW4gcmVwbGFjZSBhIGxlYWYtbGlz dCB3aXRoIGl0c2VsZiAodGhlIGluc3RhbmNlIGNvbnRhaW5pbmcNCnRoZTxicj4NCiZndDsgJmd0 OyBlbXB0eSBub2RlLCBpZiBhbnkpLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgbGVhZi1saXN0 IGNhbiBiZSByZXBsYWNlIHdpdGggaXRzZWxmLCB0aGVuIHRoZSBsaXN0IGNhbiBiZSA8YnI+DQom Z3Q7IHJlcGxhY2Ugd2l0aCBpdHNlbGYgYWxzby4gPGJyPg0KJmd0OyBUaGVuIGFsbCBub2RlcyBj b250YWluZXIgZW1wdHkgbm9kZSBzaG91bGQgYmUgY29uc2lkZXJlZCB0byBiZSBhIDxicj4NCiZn dDsgdmFsaWQgY29uZmlndXJhdGlvbj8gPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQnV0IHRoZW4geW91IHdvdWxkIGJlIHByb3ZpZGluZyBs aXN0IGtleXMsIGFuZCB0aGUgY29udGFpbmVyIHdvdWxkDQo8YnI+DQomZ3Q7IG5vdCBiZSBlbXB0 eS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgUmVwbGFjaW5nIGEgbGlz dCBlbnRyeSB3aXRoIGp1c3QgdGhlIGtleXMgaXMNCnRoZSBzYW1lIGFzIGRlbGV0aW5nIDxicj4N CiZndDsgYWxsIHRoZSBub24ta2V5IGNoaWxkIG5vZGVzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyBJIHRoaW5rIFdHIHNob3VsZCBnaXZlIGEgbW9yZSBjbGVhciBjbGFy aWZpY2F0aW9uLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IFNlYy4gNy41LjggY291bGQgYmUgY2xlYXJlciBiZWNhdXNlIGl0IGltcGxpZXMgdGhhdCB0 aGlzIGJlaGF2aW9yPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IG9ubHkg YXBwbGllcyB0byB0aGUgJnF1b3Q7ZGVsZXRlJnF1b3Q7IG9wZXJhdGlvbi4NCiZuYnNwO0l0IHNo b3VsZCBiZSBleHBsaWNpdCB0aGF0IDxicj4NCiZndDsgJnF1b3Q7cmVtb3ZlJnF1b3Q7IGFuZCAm cXVvdDtyZXBsYWNlJnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IGNhbiBhbHNvIGNhdXNlIHRoZSBsYXN0IGNoaWxkIGluIGFuIE5QIGNvbnRhaW5lcg0KdG8gYmUg ZGVsZXRlZC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSU1PIEkgdGhpbmsgb25seSBOUC1jb250YWluZXIsZW1w dHkgbGVhZiwgYW55eG1sLCB6ZXJvLWxlbmd0aCBzdHJpbmc8YnI+DQomZ3Q7IG9yIGJpbmFyeSwg Yml0cyBjYW4gYmUgYSB2YWxpZCBjb25maWd1cmF0aW9uIGl0c2VsZi4gPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7ICZndDsg L2ZyYW5rIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQW5keSA8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBBbmR5PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsg0LTT2iAy MDE0LTA2LTA5DQoxMDozNjoxNjo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IDIwMTQtMDYtMDkgMTA6MzYgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IMrVvP7IyyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24s IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyCzrcvN IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBkb3Uu d2VpMUB6dGUuY29tLmNuLCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywNCjxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgeGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5j b20uY24gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 INb3zOIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9mICdvcGVyYXRp b24nDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZpZyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiBTdW4sIEp1biA4LCAy MDE0IGF0IDY6MTggUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5jbiZndDsNCndyb3RlOiA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFuZHmjrCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgSSBoYXZlIGxvb2tlZCB0aHJvdWdoIHRoaXMgc2VjdGlvbiBmb3INCm1h bnkgdGltZXMuIEluIG15IDxicj4NCiZndDsgJmd0OyAmZ3Q7IG9waW5pb24sIEkgdGhpbmsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgZWxlbWVudCBjb250YWlucyBhdHRyaWJ1dGUgJ3Jl cGxhY2UnIG11c3QgaGF2ZQ0Kc3VidHJlZSwgYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoaXMg c3VidHJlZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNob3VsZCBiZSBhIHZhbGlkIGNvbmZp Z3VyYXRpb24uIEJ1dCBteSBjb2xsZWFndWVzDQpkb24ndCB0aGluayBzbywgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyB0aGV5IGFyZ3VlZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoYXQg dGhlIGVtcHR5IGNvbmZpZ3VyYXRpb24gaXMgYWxzbyBjb25maWd1cmF0aW9uLA0KdGhleSB3YW50 IHRvIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHVzZSdyZXBsYWNlJyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGFzICdyZW1vdmUnLCBJIGNhbid0IHBlcnN1YWRlIHRoZW0sIDopIDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBTbyxJIHdhbnQgdG8gZ2V0IGEgY2xhcmlmaWNh dGlvbiwgdGhhbmtzLg0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IHlvdSBhcmUgYm90aCByaWdodCA7LSkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSByZXBsYWNlIGF0dHJpYnV0ZSBkb2VzIGhh dmUgdG8gYXBwZWFyIGluIGEgc3VidHJlZSwNCmJ1dCBhIDxicj4NCiZndDsgJmd0OyBzdWJ0cmVl IG1heSBiZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYW4gZW1wdHkgbm9kZSAoaWYgaXQgaXMg c2NoZW1hIHZhbGlkKS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IHN0YXJ0OiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDtjb25maWcmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Zm9vJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7YSZndDs0MiZsdDsvYSZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZm9vJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbHQ7L2NvbmZpZyZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcGxhY2UgZm9vOiA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 Jmx0O2NvbmZpZyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZsdDtmb28gb3BlcmF0aW9uPSZxdW90O3JlcGxhY2UmcXVvdDsNCi8mZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDsvY29uZmlnJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVzdWx0OiA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDtjb25maWcm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Zm9v IC8mZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDsvY29uZmlnJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIHRl eHQgc2VlbXMgdmVyeSBjbGVhciB0byBtZS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IC9mcmFuayA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQW5keSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEluIHlvdXIgZXhhbXBsZSwg dGhlICdmb28nIE1VU1QgYmUgYSBwcmVzZW5jZSBjb250YWluZXI/DQo8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQtNPaIDIwMTQt MDYtMDcNCjAyOjQzOjI4Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMjAxNC0wNi0wNyAwMjo0MyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IMrVvP7I yyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ILOty80gPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBkb3Uud2VpMUB6 dGUuY29tLmNuLCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywNCjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNv bS5jbiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7INb3zOIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25zIGFib3V0IHRo ZSB1c2FnZSBvZg0KJ29wZXJhdGlvbicgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF0 dHJpYnV0ZSBpbiBlZGl0LWNvbmZpZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9uIFRodSwgSnVuIDUsIDIwMTQgYXQgMTE6MTgg UE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5jbiZndDsNCndyb3RlOiA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgYW5keSwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDtUaGFua3MgYSBsb3QuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7Q2FuIHlvdSBhbnN3ZXIgdGhlIGZpcnN0IHF1ZXN0aW9uPw0KJ3JlcGxhY2Un IGNhbiBiZSB1c2VkIDxicj4NCiZndDsgYXMncmVtb3ZlJz8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZWFkIFJGQyA2MjQxLCBz ZWMuIDcuMiBBdHRyaWJ1dGVzIHNlY3Rpb24uIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyBJdCBleHBsYWlucyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBORVRDT05GDQombHQ7ZWRp dC1jb25maWcmZ3Q7IDxicj4NCiZndDsgJmd0OyBvcGVyYXRpb25zLiA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgL2ZyYW5rIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQW5keSA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3 b3Jrcy5jb20mZ3Q7INC009oNCjIwMTQtMDYtMDUgMjM6NDY6NTM6PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFuZHkgQmll cm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyAyMDE0LTA2LTA1IDIzOjQ2IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IMrVvP7IyyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgs63LzSA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgeWUueHUxQHp0ZS5j b20uY24sDQpkb3Uud2VpMUB6dGUuY29tLmNuLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyB4aWFvLnl1cWluZ0B6dGUuY29tLmNuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7INb3zOIgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2UNCm9m ICdvcGVyYXRpb24nIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF0dHJpYnV0 ZSBpbiBlZGl0LWNvbmZpZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT24gV2VkLCBKdW4gNCwg MjAxNCBhdCA2OjM1IFBNLCAmbHQ7ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTog PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSGkgYWxsLCA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7SSBoYXZlIHNvbWUgcXVlc3Rpb25z IGFib3V0DQp0aGUgdXNhZ2Ugb2YgJm5ic3A7J29wZXJhdGlvbicgYXR0cmlidXRlIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluIGVkaXQtY29uZmlnLiA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7MS4gJ3JlcGxhY2UnIGF0dHJpYnV0 ZSBjYW4gb25seQ0KYmUgdXNlZCB0byByZW1vdmUgY29uZmlndXJhdGlvbj8gPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRm9yIGV4YW1wbGUs IHRoZSBycGMNCnJlcXVlc3QgbGlzdGVkIGJlbG93IGlzIHZhbGlkPyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7cnBjIG1lc3NhZ2Ut aWQgPQ0KJnF1b3Q7MTAxJnF1b3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtlZGl0LWNv bmZpZyZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7Jmx0O3RhcmdldCZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtydW5uaW5n LyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsmbHQ7L3RhcmdldCZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsmbHQ7Y29uZmlnJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2ludGVyZmFjZXMgb3BlcmF0 aW9uPSAmcXVvdDtyZXBsYWNlJnF1b3Q7LyZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7Jmx0Oy9jb25maWcmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9lZGl0LWNv bmZpZyZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDsvcnBjJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7Mi5Ib3cgdG8gcHJvY2VzcyBuZXN0ZWQgb3Bl cmF0aW9uDQphdHRyaWJ1dGU/IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Rm9yIGV4YW1wbGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3Jw Yw0KbWVzc2FnZS1pZCA9ICZxdW90OzEwMSZxdW90OyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm bHQ7ZWRpdC1jb25maWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyZs dDt0YXJnZXQmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7cnVubmluZy8mZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7Jmx0Oy90 YXJnZXQmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7Jmx0O2NvbmZpZyZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtpbnRlcmZh Y2VzJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7aW50ZXJmYWNlIG9wZXJhdGlvbj0gJnF1b3Q7bWVyZ2UmcXVvdDsmZ3Q7DQo8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtuYW1lJmd0O2V0aDAvMC8wJmx0Oy9uYW1lJmd0Ow0KPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbHQ7bXR1IG9wZXJhdGlvbj0NCiZxdW90O3JlbW92ZSZxdW90OyZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZW5hYmxlZCZndDt0cnVlJmx0Oy9lbmFsYmxlZCZn dDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDsvaW50ZXJmYWNlJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJmx0Oy9pbnRlcmZhY2VzJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyZsdDsvY29uZmlnJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZWRpdC1jb25m aWcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7L3JwYyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtU aGUgc2VxdWVuY2Ugb2YgcHJvY2Vzcw0KaXMgbWVyZ2UgaW50ZXJmYWNlIG5hbWUgJ2V0aDAvMC8w JyBhbmQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgcmVtb3ZlIG10dSBhbmQg bWVyZ2UgZW5hYmxlZCB0byAndHJ1ZScgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3IgbWVy Z2UNCmludGVyZmFjZSBuYW1lICdldGgwLzAvMCcgYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IG1lcmdlIGVuYWJsZWQgdG8gJ3RydWUnIGFuZCByZW1vdmUgbXR1PyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luIG90 aGVyIHdvcmRzLCBORVRDT05GDQp3aWxsIHByb2Nlc3Mgb3V0ZXIgbGF5ZXIgb3BlcmF0aW9uIDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGZpcnN0bHkgYW5kIHByb2Nlc3MgaW5u ZXIgbGF5ZXIgb3BlcmF0aW9uDQpsYXRlciwgb3IgcHJvY2VzcyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyBvcGVyYXRpb25zIGluIGFjY29yZGFuY2Ugd2l0aCBYTUwgdHJlZSB0 cmF2ZXJzYWwNCm9yZGVyPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz cDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm8gcmVxdWlyZWQgcHJvY2Vzc2luZyBvcmRlci4g PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSXQgaXMgYW4gaW1wbGVtZW50YXRp b24gZGV0YWlsLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBTb21lIHRoaW5n cyB0byBjb25zaWRlcjogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 IDEpIGFsbCBvcGVyYXRpb25zIGFyZSBhZ2FpbnN0IHRoZQ0KdGFyZ2V0IGRhdGFzdG9yZSBhdCB0 aGUgc3RhcnQgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgb3BlcmF0 aW9uIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAyKSB0aGUgb3Bl cmF0aW9ucyBhcmUgYWxsLW9yLW5vbmUsDQpub3QgaW5jcmVtZW50YWwgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDJhKSB0aGlzIGltcGxpZXMgdGhhdCBjcmVhdGUg d2l0aGluDQpkZWxldGUsIG9yIGRlbGV0ZSB3aXRoaW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgY3JlYXRlLCBpcyBhbHdheXMgYW4gZXJyb3IgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmVjYXVzZSAnZGF0 YS1leGlzdHMnDQpvciAnZGF0YS1taXNzaW5nJyBtdXN0IGJlIHRydWUgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg SW4geW91ciBleGFtcGxlIHRoZXJlIGlzIG5vIHByb2JsZW0gYmVjYXVzZQ0KJ3JlbW92ZScgd29y a3MgZXZlbiBpZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgZGF0YSBp cyBtaXNzaW5nLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgMy4gSWYgb3RoZXIgb3BlcmF0aW9uIGF0dHJpYnV0ZSBuZXN0ZWQg aW4NCm9wZXJhdGlvbiBhdHRyaWJ1dGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJ3JlbW92ZScsd2hhdCBzaG91bGQgTkVUQ09ORiBzZXJ2ZXIgZG8/IE9ubHkNCnByb2Nlc3Mg cmVtb3ZlIDxicj4NCiZndDsgJmd0OyBvcGVyYXRpb24/IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA0 LiBDYW4gTkVUQ09ORiBzdXBwb3J0IHRoZSBuZXN0ZWQNCm9wZXJhdGlvbiBhdHRyaWJ1dGUgZXF1 YWxzIHRvIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHBhcmVudCBvcGVyYXRp b24gYXR0cmlidXRlPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAvZnJhbmsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgQW5keSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24NCmNvbnRhaW5l ZCBpbiB0aGlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1haWwgKGFuZCBh bnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkNCmlzIHByaXZpbGVnZWQgYW5kIDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50 ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUNCnVzZSBvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRl bmRlZCByZWNpcGllbnQsDQphbnkgZGlzY2xvc3VyZSwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5h dGlvbg0Kb3IgdXNlIG9mIHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBp bmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4NCiZuYnNwO0lmIHlv dSBoYXZlcmVjZWl2ZWQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdGhpcyBt YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZA0Kbm90aWZ5IHVzIGltbWVkaWF0ZWx5 Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgTmV0Y29uZkBpZXRmLm9yZzxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9mb250PjwvdHQ+PC9hPjx0 dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbg0KY29udGFpbmVkIGluIHRoaXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkNCmlzIHBy aXZpbGVnZWQgYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBjb25maWRlbnRpYWwg YW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlDQp1c2Ugb2YgdGhlIGFkZHJlc3NlZTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFu IGludGVuZGVkIHJlY2lwaWVudCwNCmFueSBkaXNjbG9zdXJlLCA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5h dGlvbg0Kb3IgdXNlIG9mIHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgaW5mb3Jt YXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuDQombmJzcDtJZiB5b3UgaGF2 ZSByZWNlaXZlZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdGhpcyBtYWlsIGluIGVy cm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkNCnVzIGltbWVkaWF0ZWx5Ljxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQNCmluIHRoaXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBtYWlsIChhbmQgYW55 IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQNCmFuZCA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRo ZSBleGNsdXNpdmUgdXNlDQpvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55DQpk aXNjbG9zdXJlLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcHJvZHVjdGlvbiwgZGlzdHJp YnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3INCnVzZSBvZiB0aGUgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4gJm5ic3A7SWYNCnlvdSBoYXZlIHJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg dGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMNCmltbWVk aWF0ZWx5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZA0K aW4gdGhpcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJh bnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQNCmFuZCA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0 aGUNCmFkZHJlc3NlZTxicj4NCiZndDsgJmd0OyAmZ3Q7IChzKS4gJm5ic3A7SWYgeW91IGFyZSBu b3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwNCjxicj4NCiZndDsgJmd0 OyAmZ3Q7IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24g b3IgdXNlDQpvZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW5mb3JtYXRpb24gY29udGFpbmVk IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdQ0KaGF2ZSByZWNlaXZlZCA8YnI+ DQomZ3Q7ICZndDsgJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5k IG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbg0KdGhpcyA8 YnI+DQomZ3Q7ICZndDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3 aXRoKSBpcyBwcml2aWxlZ2VkDQphbmQgPGJyPg0KJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQg aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWU8YnI+DQom Z3Q7ICZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQs IGFueSBkaXNjbG9zdXJlLA0KPGJyPg0KJmd0OyAmZ3Q7IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZQ0KPGJyPg0KJmd0OyAmZ3Q7 IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAmbmJzcDtJZiB5 b3UgaGF2ZQ0KcmVjZWl2ZWQgPGJyPg0KJmd0OyAmZ3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxl YXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCiZndDsgJmd0OyA8 YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzDQo8YnI+DQomZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0 cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgPGJyPg0KJmd0OyBjb25maWRl bnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVz c2VlPGJyPg0KJmd0OyAocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lw aWVudCwgYW55IGRpc2Nsb3N1cmUsIDxicj4NCiZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIDxicj4NCiZndDsgaW5mb3Jt YXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZl IHJlY2VpdmVkDQo8YnI+DQomZ3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBp dCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+ DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFu eSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25m aWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRk cmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlz Y2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlv biBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVs ZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQoN Cjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBh dHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRl bnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVz c2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xv c3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBv ciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk LiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRl IGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 000CD20C48257CF3_=-- From nobody Mon Jun 9 20:12:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0820C1A038D for ; Mon, 9 Jun 2014 20:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.272 X-Spam-Level: ** X-Spam-Status: No, score=2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_37=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8A2KGo662KU for ; Mon, 9 Jun 2014 20:12:06 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1C61A038B for ; Mon, 9 Jun 2014 20:12:05 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id dc16so550144qab.29 for ; Mon, 09 Jun 2014 20:12:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jzdxIweET+DW3LPLtrN9Yq2jfQGqecp+bpyHTrc9H2o=; b=RQgc68RzqnkcbmN/1mBgWn+87GiLzsBIM/ni6DmjSaBggXw81yMXrJ1IHDgBtsRlRd 8nlgmY3y2rcACnH0kFZULEDcP5R0Tw99uy5OJgbuBCXWFhV+wme60NPxaz2KUjEXpfns +fEX8cR6Mkql1EK5mzyt5qX493aee3ZT3ym52zeuEjntlTPQMRT9CntTKGoJ19vIV6J7 SEu2dJyU8tgSPDdbR5BUnch56k9oGylS6zBqAFkU7mgnEIIfxBo8pBmcA1gSHn0cET6s 0h/mjWAxe0Ad4/hW8/0feJhX451W6s+ks2mF77lfKRW79n3uLndrCIEcqTCVN6SH/1n0 709Q== X-Gm-Message-State: ALoCoQkdUsnR3Bl9O5KTywAnxto+wrCZg8U2ApQ879ENRyXm6yiPdGIZBbltC7QCF8I7lvPYY7IC MIME-Version: 1.0 X-Received: by 10.224.55.6 with SMTP id s6mr37693299qag.7.1402369924847; Mon, 09 Jun 2014 20:12:04 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 9 Jun 2014 20:12:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 20:12:04 -0700 Message-ID: From: Andy Bierman To: feng.chong33@zte.com.cn Content-Type: multipart/alternative; boundary=089e0153705e36f70e04fb72b120 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7GL5KU6657N3woQba6f3lEEczBo Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] Some questions about the usage of 'operation' attribute in edit-config X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 03:12:10 -0000 --089e0153705e36f70e04fb72b120 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Mon, Jun 9, 2014 at 7:20 PM, wrote: > /frank > > Andy Bierman =D0=B4=D3=DA 2014-06-10 09:01:16: > > > Andy Bierman > > 2014-06-10 09:01 > > > > =CA=D5=BC=FE=C8=CB > > > > feng.chong33@zte.com.cn, > > > > =B3=AD=CB=CD > > > > dou.wei1@zte.com.cn, Netconf , > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > =D6=F7=CC=E2 > > > > Re: [Netconf] Some questions about the usage of 'operation' > > attribute in edit-config > > > > > > > On Mon, Jun 9, 2014 at 5:46 PM, wrote: > > /frank > > > > Andy Bierman =D0=B4=D3=DA 2014-06-09 22:19:25: > > > > > Andy Bierman > > > 2014-06-09 22:19 > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > feng.chong33@zte.com.cn, > > > > > > =B3=AD=CB=CD > > > > > > dou.wei1@zte.com.cn, Netconf , > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > =D6=F7=CC=E2 > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > attribute in edit-config > > > > > > > > > > > On Sun, Jun 8, 2014 at 10:40 PM, wrote: > > > /frank > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-09 11:44:58: > > > > > > > Andy Bierman > > > > 2014-06-09 11:44 > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > =B3=AD=CB=CD > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > =D6=F7=CC=E2 > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > attribute in edit-config > > > > > > > > > > > > > > > On Sun, Jun 8, 2014 at 8:18 PM, wrote: > > > > Andy, > > > > thanks,:) > > > > I understand only presence container or leaf node with empty typ= e > > > > can be placed 'replace' attribute > > > > and have a empty node subtree. Is it right? > > > > > > > > > > > > no. any container. anyxml. empty leaf. zero-length string leaf. > > > > > > > Really? a NP container can be a valid configuration itself? > > > > > > > > Yes -- there is some confusion because it is widely believed that > > NPcontainers > > > have no semantics -- but this is false. They are collections. > > > must-stmt validation > > > that fails on an NP-container will cause the edit/commit to fail > > > just like any other node. > > > > > > > I don't agree. I think NP-container MUST not be a valid > > configuration if it has no children, > > even if NP-container has some semantics, in that case, NP-container > > just act as a unit can be > > evaluated or validated. > > > > If a NP-container can be a valid configuration itself, what's the > > difference between NP-container and presence container? > > > > > A presence container's existence has some data model semantics describe= d > in > > the text value for that statement. A non-presence container is a > > collection without > > additional semantics for the existence of an empty container. > > > > There is no text that supports your claim. > > > > Note this text in sec. 7.5.8: > > > > > > If a container does not have a "presence" statement and the last > > child node is deleted, the NETCONF server MAY delete the container. > > Note MAY instead of SHOULD or MUST. > > You can treat an empty replace operation as a delete of an NP container > > in your implementation. Other servers can keep them in the data model. > > > > In section 7.5.1: > "In the first style, the container has no meaning of its own, existing > only to contain child nodes. This is the default style." > > If a NP container exists only to contain child nodes, why itself can be > accepted > as a valid configuration? > > I can't find any text in any RFC that says to reject an empty NP container as invalid config. I can find text that says you MAY delete them. So do what you want in your implementation. Andy > > > > > > They are not as standard as other YANG data nodes because a serverMAY > choose > > > to delete these nodes. Some server implementations even create them, > > > although the > > > spec is silent on this point. > > > > > > As Lada pointed out, the server flexibility for NP-containers is > > > more of a bug than a feature. > > > > > > BTW, empty bits is another empty node that is legal (for replace > operation). > > > You can replace a leaf-list with itself (the instance containing the > > > empty node, if any). > > > > If leaf-list can be replace with itself, then the list can be > > replace with itself also. > > Then all nodes container empty node should be considered to be a > > valid configuration? > > > > > But then you would be providing list keys, and the container would > > not be empty. > > Replacing a list entry with just the keys is the same as deleting > > all the non-key child nodes. > > > > > > I think WG should give a more clear clarification. > > > > Sec. 7.5.8 could be clearer because it implies that this behavior > > only applies to the "delete" operation. It should be explicit that > > "remove" and "replace" > > can also cause the last child in an NP container to be deleted. > > > > > > > > IMO I think only NP-container,empty leaf, anyxml, zero-length string > > or binary, bits can be a valid configuration itself. > > > > > > > /frank > > > > > > Andy > > > > Andy > > > > > > > > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-09 10:36:16: > > > > > > > > > Andy Bierman > > > > > 2014-06-09 10:36 > > > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > =B3=AD=CB=CD > > > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > > > =D6=F7=CC=E2 > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > On Sun, Jun 8, 2014 at 6:18 PM, wrote: > > > > > Andy=A3=AC > > > > > I have looked through this section for many times. In my > > > > opinion, I think > > > > > the element contains attribute 'replace' must have subtree, and > > > > this subtree > > > > > should be a valid configuration. But my colleagues don't think so= , > > > > > they argued > > > > > that the empty configuration is also configuration, they want to > > > > use'replace' > > > > > as 'remove', I can't persuade them, :) > > > > > So,I want to get a clarification, thanks. > > > > > > > > > > you are both right ;-) > > > > > > > > > > the replace attribute does have to appear in a subtree, but a > > > subtree may be > > > > > an empty node (if it is schema valid). > > > > > > > > > > start: > > > > > > > > > > > > > > > > > > > > 42 > > > > > > > > > > > > > > > > > > > > replace foo: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > result: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The text seems very clear to me. > > > > > > > > > > /frank > > > > > > > > > > Andy > > > > > > > > > > > > > In your example, the 'foo' MUST be a presence container? > > > > > > > > > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-07 02:43:2= 8: > > > > > > > > > > > Andy Bierman > > > > > > 2014-06-07 02:43 > > > > > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > > > =B3=AD=CB=CD > > > > > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > > > > > =D6=F7=CC=E2 > > > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 5, 2014 at 11:18 PM, > wrote: > > > > > > andy, > > > > > > Thanks a lot. > > > > > > Can you answer the first question? 'replace' can be used > > as'remove'? > > > > > > > > > > > > Read RFC 6241, sec. 7.2 Attributes section. > > > > > > It explains the difference between the NETCONF > > > operations. > > > > > > > > > > > > > > > > > > /frank > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > Andy Bierman =D0=B4=D3=DA 2014-06-05 23:46= :53: > > > > > > > > > > > > > Andy Bierman > > > > > > > 2014-06-05 23:46 > > > > > > > > > > > > > > =CA=D5=BC=FE=C8=CB > > > > > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > > > > > =B3=AD=CB=CD > > > > > > > > > > > > > > Netconf , ye.xu1@zte.com.cn, > dou.wei1@zte.com.cn, > > > > > > > xiao.yuqing@zte.com.cn > > > > > > > > > > > > > > =D6=F7=CC=E2 > > > > > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 4, 2014 at 6:35 PM, > wrote: > > > > > > > Hi all, > > > > > > > I have some questions about the usage of 'operation' > attribute > > > > > > > in edit-config. > > > > > > > 1. 'replace' attribute can only be used to remove > configuration? > > > > > > > For example, the rpc request listed below is valid? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.How to process nested operation attribute? > > > > > > > For example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eth0/0/0 > > > > > > > > > > > > > > true > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The sequence of process is merge interface name > 'eth0/0/0' and > > > > > > > remove mtu and merge enabled to 'true' > > > > > > > or merge interface name > 'eth0/0/0' and > > > > > > > merge enabled to 'true' and remove mtu? > > > > > > > In other words, NETCONF will process outer layer > operation > > > > > > > firstly and process inner layer operation later, or process > > > > > > > operations in accordance with XML tree traversal order? > > > > > > > > > > > > > > > > > > > > > There is no required processing order. > > > > > > > It is an implementation detail. > > > > > > > Some things to consider: > > > > > > > 1) all operations are against the target datastore at the > start of > > > > > > > the operation > > > > > > > 2) the operations are all-or-none, not incremental > > > > > > > 2a) this implies that create within delete, or delete withi= n > > > > > > > create, is always an error > > > > > > > because 'data-exists' or 'data-missing' must be true > > > > > > > > > > > > > > In your example there is no problem because 'remove' works > even if > > > > > > > the data is missing. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3. If other operation attribute nested in operation attribute > > > > > > > 'remove',what should NETCONF server do? Only process remove > > > operation? > > > > > > > > > > > > > > 4. Can NETCONF support the nested operation attribute equal= s > to > > > > > > > parent operation attribute? > > > > > > > > > > > > > > /frank > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > > > ZTE Information Security Notice: The information contained in > this > > > > > > > mail (and any attachment transmitted herewith) is privileged > and > > > > > > > confidential and is intended for the exclusive use of the > addressee > > > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > > > reproduction, distribution or other dissemination or use of > the > > > > > > > information contained is strictly prohibited. If you > havereceived > > > > > > > this mail in error, please delete it and notify us immediatel= y. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Netconf mailing list > > > > > > > Netconf@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > > ZTE Information Security Notice: The information contained in > this > > > > > > mail (and any attachment transmitted herewith) is privileged an= d > > > > > > confidential and is intended for the exclusive use of the > addressee > > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > > reproduction, distribution or other dissemination or use of the > > > > > > information contained is strictly prohibited. If you have > received > > > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > ZTE Information Security Notice: The information contained in thi= s > > > > > mail (and any attachment transmitted herewith) is privileged and > > > > > confidential and is intended for the exclusive use of the address= ee > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > reproduction, distribution or other dissemination or use of the > > > > > information contained is strictly prohibited. If you have > received > > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > ZTE Information Security Notice: The information contained in this > > > > mail (and any attachment transmitted herewith) is privileged and > > > > confidential and is intended for the exclusive use of the addressee > > > > (s). If you are not an intended recipient, any disclosure, > > > > reproduction, distribution or other dissemination or use of the > > > > information contained is strictly prohibited. If you have received > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail (and any attachment transmitted herewith) is privileged and > > > confidential and is intended for the exclusive use of the addressee > > > (s). If you are not an intended recipient, any disclosure, > > > reproduction, distribution or other dissemination or use of the > > > information contained is strictly prohibited. If you have received > > > this mail in error, please delete it and notify us immediately. > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail (and any attachment transmitted herewith) is privileged and > > confidential and is intended for the exclusive use of the addressee > > (s). If you are not an intended recipient, any disclosure, > > reproduction, distribution or other dissemination or use of the > > information contained is strictly prohibited. If you have received > > this mail in error, please delete it and notify us immediately. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > --089e0153705e36f70e04fb72b120 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 9, 2014 at 7:20 PM, <feng.chong33@zte.com.cn> wrote:
/frank

Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-10 09:01:16:

> Andy Bierman <andy@yumaworks.com>
> 2014-06-10 09:01
>
> =CA=D5=BC=FE=C8=CB
>
> feng.chon= g33@zte.com.cn,
>
> =B3=AD=CB=CD
>
> dou.wei1@zte.= com.cn, Netconf <netconf@ietf.org>,
> xiao.yuqin= g@zte.com.cn, ye= .xu1@zte.com.cn
>
> =D6=F7=CC=E2
>
> Re: [Netconf] Some questions about the usage of 'operation' > attribute in edit-config
>
>

> On Mon, Jun 9, 2014 at 5:46 PM, <feng.chong33@zte.com.cn> wrote:
> /frank
>
> Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-09 22:19:25:
>
> > Andy Bierman <andy@yumaworks.com>
> > 2014-06-09 22:19
> >
> > =CA=D5=BC=FE=C8=CB
> >
> > feng= .chong33@zte.com.cn,
> >
> > =B3=AD=CB=CD
> >
> > dou.wei1= @zte.com.cn, Netconf <netconf@ietf.org>,
> > xiao.= yuqing@zte.com.cn, ye.xu1@zte.com.cn
> >
> > =D6=F7=CC=E2
> >
> > Re: [Netconf] Some questions about the usage of 'operation= 9;
> > attribute in edit-config
> >
> >
>
> > On Sun, Jun 8, 2014 at 10:40 PM, <feng.chong33@zte.com.cn> wrote:
> > /frank
> >
> > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-09 11:44:58:
> >
> > > Andy Bierman <andy@yumaworks.com>
> > > 2014-06-09 11:44
> > >
> > > =CA=D5=BC=FE=C8=CB
> > >
> > > feng.chong33@zte.com.cn,
> > >
> > > =B3=AD=CB=CD
> > >
> > > dou= .wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > = xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > >
> > > =D6=F7=CC=E2
> > >
> > > Re: [Netconf] Some questions about the usage of 'operati= on'
> > > attribute in edit-config
> > >
> > >
> >
> > > On Sun, Jun 8, 2014 at 8:18 PM, <feng.chong33@zte.com.cn> wrote:
> > > Andy,
> > >    thanks,:)
> > >    I understand only presence container or leaf node with empty type
> > > can be placed 'replace' attribute
> > > and have a empty node subtree. Is it right?
> > >  
> > >
> > > no. any container. anyxml. empty leaf. zero-length string leaf.
> > >
> > Really? a NP container can be a valid configuration itself?
>
> >
> > Yes -- there is some confusion because it is widely believed that
> NPcontainers
> > have no semantics -- but this is false.  They are collection= s.  
> > must-stmt validation
> > that fails on an NP-container will cause the edit/commit to fail
> > just like any other node.
> >
>
> I don't agree. I think NP-container MUST not be a valid
> configuration if it has no children,
> even if NP-container has some semantics, in that case, NP-container
> just act as a unit can be
> evaluated or validated.
>
> If a NP-container can be a valid configuration itself, what's the
> difference between NP-container and presence container?

>
> A presence container's existence has some data model semantics des= cribed in
> the text value for that statement.  A non-presence container is a
> collection without
> additional semantics for the existence of an empty container.
>
> There is no text that supports your claim.
>
> Note this text in sec. 7.5.8:
>
>
>   If a container does not have a "presence" statement and the last
>   child node is deleted, the NETCONF server MAY delete the contai= ner.
> Note MAY instead of SHOULD or MUST.
> You can treat an empty replace operation as a delete of an NP container
> in your implementation.  Other servers can keep them in the data model.
>

In section 7.5.1:
"In the first style, the container has no meaning of its own, existing
   only to contain child nodes.  This is the default style."

If a NP container exists only to contain child nodes, why itself can be accepted
as a valid configuration?



I can't find any te= xt in any RFC that says to reject an empty NP container as invalid config.<= /div>
I can find text that says you MAY delete them. So do what you wan= t in
your implementation.

Andy
 

>  
> > They are not as standard as other YANG data nodes because a serverMAY choose
> > to delete these nodes. Some server implementations even create them,
> > although the
> > spec is silent on this point.
> >
> > As Lada pointed out, the server flexibility for NP-containers is
> > more of a bug than a feature.
> >
> > BTW, empty bits is another empty node that is legal (for replace operation).
> > You can replace a leaf-list with itself (the instance containing the
> > empty node, if any).
>
> If leaf-list can be replace with itself, then the list can be
> replace with itself also.
> Then all nodes container empty node should be considered to be a
> valid configuration?

>
> But then you would be providing list keys, and the container would
> not be empty.
> Replacing a list entry with just the keys is the same as deleting
> all the non-key child nodes.
>
>  
> I think WG should give a more clear clarification.
>
> Sec. 7.5.8 could be clearer because it implies that this behavior
> only applies to the "delete" operation.  It should be explicit that
> "remove" and "replace"
> can also cause the last child in an NP container to be deleted.
>
>
>
> IMO I think only NP-container,empty leaf, anyxml, zero-length string > or binary, bits can be a valid configuration itself.
> >  
> > > /frank
> >
> > Andy
>
> Andy
>  
> >  
> > >
> > > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-09 10:36:16:
> > >
> > > > Andy Bierman <andy@yumaworks.com>
> > > > 2014-06-09 10:36
> > > >
> > > > =CA=D5=BC=FE=C8=CB
> > > >
> > > > feng.chong33@zte.com.cn,
> > > >
> > > > =B3=AD=CB=CD
> > > >
> > > > dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > > >
> > > > =D6=F7=CC=E2
> > > >
> > > > Re: [Netconf] Some questions about the usage of 'op= eration'
> > > > attribute in edit-config
> > > >
> > > >
> > >
> > > > On Sun, Jun 8, 2014 at 6:18 PM, <feng.chong33@zte.com.cn> wrote:
> > > > Andy=A3=AC
> > > >     I have looked through this section for many times. In my
> > > opinion, I think
> > > > the element contains attribute 'replace' must h= ave subtree, and
> > > this subtree
> > > > should be a valid configuration. But my colleagues don't think so,
> > > > they argued
> > > > that the empty configuration is also configuration, they want to
> > > use'replace'
> > > > as 'remove', I can't persuade them, :)
> > > >     So,I want to get a clarification, thanks.
> > > >
> > > > you are both right ;-)
> > > >
> > > > the replace attribute does have to appear in a subtree, but a
> > subtree may be
> > > > an empty node (if it is schema valid).
> > > >
> > > > start:
> > > >
> > > >   <config>
> > > >      <foo>
> > > >         <a>42</a>
> > > >      </foo>
> > > >   </config>
> > > >
> > > > replace foo:
> > > >
> > > >  <config>
> > > >      <foo operation=3D"replace&q= uot; />
> > > >   </config>
> > > >
> > > > result:
> > > >
> > > >   <config>
> > > >      <foo />
> > > >   </config>
> > > >
> > > > The text seems very clear to me.
> > > >
> > > > /frank
> > > >
> > > > Andy
> > > >
> > >
> > > In your example, the 'foo' MUST be a presence contai= ner?
> > >  
> > > >
> > > > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-07 02:43:28:
> > > >
> > > > > Andy Bierman <andy@yumaworks.com>
> > > > > 2014-06-07 02:43
> > > > >
> > > > > =CA=D5=BC=FE=C8=CB
> > > > >
> > > > > feng.chong33@zte.com.cn,
> > > > >
> > > > > =B3=AD=CB=CD
> > > > >
> > > > > dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > > > >
> > > > > =D6=F7=CC=E2
> > > > >
> > > > > Re: [Netconf] Some questions about the usage of 'operation'
> > > > > attribute in edit-config
> > > > >
> > > > >
> > > >
> > > > > On Thu, Jun 5, 2014 at 11:18 PM, <feng.chong33@zte.com.cn= > wrote:
> > > > > andy,
> > > > >    Thanks a lot.
> > > > >    Can you answer the first question? 'replace' can be used
> as'remove'?
> > > > >
> > > > > Read RFC 6241, sec. 7.2 Attributes section.
> > > > > It explains the difference between the NETCONF <edit-config>
> > operations.
> > > > >
> > > > >  
> > > > > /frank
> > > > >
> > > > > Andy
> > > > >  
> > > > >
> > > > > Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-06-05 23:46:53:
> > > > >
> > > > > > Andy Bierman <andy@yumaworks.com>
> > > > > > 2014-06-05 23:46
> > > > > >
> > > > > > =CA=D5=BC=FE=C8=CB
> > > > > >
> > > > > > feng.chong33@zte.com.cn,
> > > > > >
> > > > > > =B3=AD=CB=CD
> > > > > >
> > > > > > Netconf <netconf@ietf.org>, ye.xu1@zte.com.cn, dou.wei1@zte.com.c= n,
> > > > > > xiao.yuqing@zte.com.cn
> > > > > >
> > > > > > =D6=F7=CC=E2
> > > > > >
> > > > > > Re: [Netconf] Some questions about the usage of 'operation'
> > > > > > attribute in edit-config
> > > > > >
> > > > > >
> > > > >
> > > > > > On Wed, Jun 4, 2014 at 6:35 PM, <feng.chong33@zte.com.= cn> wrote:
> > > > > > Hi all,
> > > > > >    I have some questions about the usage of  'operation' attribute
> > > > > > in edit-config.
> > > > > >    1. 'replace' attribute c= an only be used to remove configuration?
> > > > > >       For example, the rpc request listed below is valid?
> > > > > >       <rpc message-id =3D "101">
> > > > > >            <= edit-config>
> > > > > >                <target>
> > > > > >                   <running/>
> > > > > >                </target>
> > > > > >                <config>
> > > > > >                   <interfaces operation=3D "replace"/>
> > > > > >                </config>
> > > > > >            <= /edit-config>
> > > > > >       </rpc>
> > > > > >
> > > > > >
> > > > > >    2.How to process nested operatio= n attribute?
> > > > > >      For example:
> > > > > >            <= rpc message-id =3D "101">
> > > > > >            <= edit-config>
> > > > > >                <target>
> > > > > >                   <running/>
> > > > > >                </target>
> > > > > >                <config>
> > > > > >                   <interfaces>
> > > > > >                       <interface operation=3D "merge&q= uot;>
> > > > > >                            <name>eth0/0/0= </name>
> > > > > >                            <mtu operation=3D "remove">
> > > > > >                            <enabled>true&= lt;/enalbled>
> > > > > >                       </interface>
> > > > > >                   </interfaces>
> > > > > >                </config>
> > > > > >            <= /edit-config>
> > > > > >       </rpc>
> > > > > >
> > > > > >      The sequence of process is merge interface name 'eth0/0/0' and
> > > > > > remove mtu and merge enabled to 'true'= ;
> > > > > >                              or merge interface name 'eth0/0/0' and
> > > > > > merge enabled to 'true' and remove mt= u?
> > > > > >      In other words, NETCONF will process outer layer operation
> > > > > > firstly and process inner layer operation later, or process
> > > > > > operations in accordance with XML tree traver= sal order?
> > > > > >  
> > > > > >
> > > > > > There is no required processing order.
> > > > > > It is an implementation detail.
> > > > > > Some things to consider:
> > > > > >   1) all operations are against the target datastore at the start of
> > > > > > the operation
> > > > > >   2) the operations are all-or-none, not incremental
> > > > > >   2a) this implies that create within delete, or delete within
> > > > > > create, is always an error
> > > > > >        because 'data-= exists' or 'data-missing' must be true
> > > > > >
> > > > > > In your example there is no problem because 'remove' works even if
> > > > > > the data is missing.
> > > > > >
> > > > > >          
> > > > > >
> > > > > > 3. If other operation attribute nested in operation attribute
> > > > > > 'remove',what should NETCONF server d= o? Only process remove
> > operation?
> > > > > >
> > > > > >   4. Can NETCONF support the nested operation attribute equals to
> > > > > > parent operation attribute?
> > > > > >      
> > > > > > /frank
> > > > > >
> > > > > > Andy
> > > > > >  
> > > > > >
> > > > > > ---------------------------------------------= -----------
> > > > > > ZTE Information Security Notice: The informat= ion contained in this
> > > > > > mail (and any attachment transmitted herewith= ) is privileged and
> > > > > > confidential and is intended for the exclusiv= e use of the addressee
> > > > > > (s).  If you are not an intended recipie= nt, any disclosure,
> > > > > > reproduction, distribution or other dissemina= tion or use of the
> > > > > > information contained is strictly prohibited.  If you havereceived
> > > > > > this mail in error, please delete it and notify us immediately.
> > > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > _____________________________________________= __
> > > > > > Netconf mailing list
> > > > > > Netconf@ietf.org
> > > > > > https://www.ietf.org/m= ailman/listinfo/netconf
> > > >
> > > > >
> > > > > --------------------------------------------------= ------
> > > > > ZTE Information Security Notice: The information contained in this
> > > > > mail (and any attachment transmitted herewith) is privileged and
> > > > > confidential and is intended for the exclusive use of the addressee
> > > > > (s).  If you are not an intended recipient, any disclosure,
> > > > > reproduction, distribution or other dissemination or use of the
> > > > > information contained is strictly prohibited.  If you have received
> > > > > this mail in error, please delete it and notify us immediately.
> > > > >
> > >
> > > >
> > > > -------------------------------------------------------= -
> > > > ZTE Information Security Notice: The information contai= ned in this
> > > > mail (and any attachment transmitted herewith) is privi= leged and
> > > > confidential and is intended for the exclusive use of the addressee
> > > > (s).  If you are not an intended recipient, any disclosure,
> > > > reproduction, distribution or other dissemination or use of the
> > > > information contained is strictly prohibited.  If you have received
> > > > this mail in error, please delete it and notify us immediately.
> > > >
> >
> > >
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > > mail (and any attachment transmitted herewith) is privileged and
> > > confidential and is intended for the exclusive use of the addressee
> > > (s).  If you are not an intended recipient, any disclos= ure,
> > > reproduction, distribution or other dissemination or use of the
> > > information contained is strictly prohibited.  If you have received
> > > this mail in error, please delete it and notify us immediate= ly.
> > >
>
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the address= ee
> > (s).  If you are not an intended recipient, any disclosure,
> > reproduction, distribution or other dissemination or use of the
> > information contained is strictly prohibited.  If you have received
> > this mail in error, please delete it and notify us immediately. > >

>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail (and any attachment transmitted herewith) is privileged and
> confidential and is intended for the exclusive use of the addressee > (s).  If you are not an intended recipient, any disclosure,
> reproduction, distribution or other dissemination or use of the
> information contained is strictly prohibited.  If you have receiv= ed
> this mail in error, please delete it and notify us immediately.
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


--089e0153705e36f70e04fb72b120-- From nobody Mon Jun 9 23:15:39 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74731A03DC for ; Mon, 9 Jun 2014 23:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.79 X-Spam-Level: X-Spam-Status: No, score=-94.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpWOY2IFk-pk for ; Mon, 9 Jun 2014 23:15:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6651A03DB for ; Mon, 9 Jun 2014 23:15:19 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 8A2B5126AE54; Tue, 10 Jun 2014 14:15:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s5A6F76f031596; Tue, 10 Jun 2014 14:15:07 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: References: To: Andy Bierman MIME-Version: 1.0 X-KeepSent: F07BFB4A:09385D86-48257CF3:00213031; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Tue, 10 Jun 2014 14:15:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-10 14:15:09, Serialize complete at 2014-06-10 14:15:09 Content-Type: multipart/alternative; boundary="=_alternative 002257ED48257CF3_=" X-MAIL: mse02.zte.com.cn s5A6F76f031596 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WbIFHzM6Bcx4qrj_jyIYh0iGXoY Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: [Netconf] =?gb2312?b?tPC4tDogUmU6ICBTb21lIHF1ZXN0aW9ucyBhYm91dCB0?= =?gb2312?b?aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgYXR0cmlidXRlIGluIGVkaXQtY29u?= =?gb2312?b?Zmln?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:15:26 -0000 This is a multipart message in MIME format. --=_alternative 002257ED48257CF3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 L2ZyYW5rDQoNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYt MTAgMTE6MTI6MDQ6DQoNCj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiAy MDE0LTA2LTEwIDExOjEyDQo+IA0KPiDK1bz+yMsNCj4gDQo+IGZlbmcuY2hvbmczM0B6dGUuY29t LmNuLCANCj4gDQo+ILOty80NCj4gDQo+IGRvdS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgPG5l dGNvbmZAaWV0Zi5vcmc+LCANCj4geGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5j b20uY24NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJv dXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0KPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcN Cj4gDQo+IA0KDQo+IE9uIE1vbiwgSnVuIDksIDIwMTQgYXQgNzoyMCBQTSwgPGZlbmcuY2hvbmcz M0B6dGUuY29tLmNuPiB3cm90ZToNCj4gL2ZyYW5rIA0KPiANCj4gQW5keSBCaWVybWFuIDxhbmR5 QHl1bWF3b3Jrcy5jb20+INC009ogMjAxNC0wNi0xMCAwOTowMToxNjoNCj4gDQo+ID4gQW5keSBC aWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiA+IDIwMTQtMDYtMTAgMDk6MDEgDQo+ID4g DQo+ID4gytW8/sjLIA0KPiA+IA0KPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gPiAN Cj4gPiCzrcvNIA0KPiA+IA0KPiA+IGRvdS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgPG5ldGNv bmZAaWV0Zi5vcmc+LCANCj4gPiB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNv bS5jbiANCj4gPiANCj4gPiDW98ziIA0KPiA+IA0KPiA+IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVz dGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0KPiA+IGF0dHJpYnV0ZSBpbiBl ZGl0LWNvbmZpZyANCj4gPiANCj4gPiANCj4gDQo+ID4gT24gTW9uLCBKdW4gOSwgMjAxNCBhdCA1 OjQ2IFBNLCA8ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24+IHdyb3RlOiANCj4gPiAvZnJhbmsgDQo+ ID4gDQo+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+INC009ogMjAxNC0wNi0w OSAyMjoxOToyNToNCj4gPiANCj4gPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29t PiANCj4gPiA+IDIwMTQtMDYtMDkgMjI6MTkgDQo+ID4gPiANCj4gPiA+IMrVvP7IyyANCj4gPiA+ IA0KPiA+ID4gZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIA0KPiA+ID4gDQo+ID4gPiCzrcvNIA0K PiA+ID4gDQo+ID4gPiBkb3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mIDxuZXRjb25mQGlldGYu b3JnPiwgDQo+ID4gPiB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbiAN Cj4gPiA+IA0KPiA+ID4g1vfM4iANCj4gPiA+IA0KPiA+ID4gUmU6IFtOZXRjb25mXSBTb21lIHF1 ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgDQo+ID4gPiBhdHRyaWJ1dGUg aW4gZWRpdC1jb25maWcgDQo+ID4gPiANCj4gPiA+IA0KPiA+IA0KPiA+ID4gT24gU3VuLCBKdW4g OCwgMjAxNCBhdCAxMDo0MCBQTSwgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiB3cm90ZTogDQo+ ID4gPiAvZnJhbmsgDQo+ID4gPiANCj4gPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3Mu Y29tPiDQtNPaIDIwMTQtMDYtMDkgMTE6NDQ6NTg6DQo+ID4gPiANCj4gPiA+ID4gQW5keSBCaWVy bWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiA+ID4gPiAyMDE0LTA2LTA5IDExOjQ0IA0KPiA+ ID4gPiANCj4gPiA+ID4gytW8/sjLIA0KPiA+ID4gPiANCj4gPiA+ID4gZmVuZy5jaG9uZzMzQHp0 ZS5jb20uY24sIA0KPiA+ID4gPiANCj4gPiA+ID4gs63LzSANCj4gPiA+ID4gDQo+ID4gPiA+IGRv dS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+LCANCj4gPiA+ID4g eGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5jb20uY24gDQo+ID4gPiA+IA0KPiA+ ID4gPiDW98ziIA0KPiA+ID4gPiANCj4gPiA+ID4gUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9u cyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicgDQo+ID4gPiA+IGF0dHJpYnV0ZSBpbiBl ZGl0LWNvbmZpZyANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IE9uIFN1biwg SnVuIDgsIDIwMTQgYXQgODoxOCBQTSwgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiB3cm90ZTog DQo+ID4gPiA+IEFuZHksIA0KPiA+ID4gPiAgICB0aGFua3MsOikgDQo+ID4gPiA+ICAgIEkgdW5k ZXJzdGFuZCBvbmx5IHByZXNlbmNlIGNvbnRhaW5lciBvciBsZWFmIG5vZGUgd2l0aCBlbXB0eSAN CnR5cGUNCj4gPiA+ID4gY2FuIGJlIHBsYWNlZCAncmVwbGFjZScgYXR0cmlidXRlIA0KPiA+ID4g PiBhbmQgaGF2ZSBhIGVtcHR5IG5vZGUgc3VidHJlZS4gSXMgaXQgcmlnaHQ/IA0KPiA+ID4gPiAN Cj4gPiA+ID4gDQo+ID4gPiA+IG5vLiBhbnkgY29udGFpbmVyLiBhbnl4bWwuIGVtcHR5IGxlYWYu IHplcm8tbGVuZ3RoIHN0cmluZyBsZWFmLiANCj4gPiA+ID4gDQo+ID4gPiBSZWFsbHk/IGEgTlAg Y29udGFpbmVyIGNhbiBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gaXRzZWxmPyANCj4gPiANCj4g PiA+IA0KPiA+ID4gWWVzIC0tIHRoZXJlIGlzIHNvbWUgY29uZnVzaW9uIGJlY2F1c2UgaXQgaXMg d2lkZWx5IGJlbGlldmVkIHRoYXQgDQo+ID4gTlBjb250YWluZXJzIA0KPiA+ID4gaGF2ZSBubyBz ZW1hbnRpY3MgLS0gYnV0IHRoaXMgaXMgZmFsc2UuICBUaGV5IGFyZSBjb2xsZWN0aW9ucy4gDQo+ ID4gPiBtdXN0LXN0bXQgdmFsaWRhdGlvbiANCj4gPiA+IHRoYXQgZmFpbHMgb24gYW4gTlAtY29u dGFpbmVyIHdpbGwgY2F1c2UgdGhlIGVkaXQvY29tbWl0IHRvIGZhaWwgDQo+ID4gPiBqdXN0IGxp a2UgYW55IG90aGVyIG5vZGUuIA0KPiA+ID4gDQo+ID4gDQo+ID4gSSBkb24ndCBhZ3JlZS4gSSB0 aGluayBOUC1jb250YWluZXIgTVVTVCBub3QgYmUgYSB2YWxpZCANCj4gPiBjb25maWd1cmF0aW9u IGlmIGl0IGhhcyBubyBjaGlsZHJlbiwgDQo+ID4gZXZlbiBpZiBOUC1jb250YWluZXIgaGFzIHNv bWUgc2VtYW50aWNzLCBpbiB0aGF0IGNhc2UsIE5QLWNvbnRhaW5lciANCj4gPiBqdXN0IGFjdCBh cyBhIHVuaXQgY2FuIGJlIA0KPiA+IGV2YWx1YXRlZCBvciB2YWxpZGF0ZWQuIA0KPiA+IA0KPiA+ IElmIGEgTlAtY29udGFpbmVyIGNhbiBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gaXRzZWxmLCB3 aGF0J3MgdGhlIA0KPiA+IGRpZmZlcmVuY2UgYmV0d2VlbiBOUC1jb250YWluZXIgYW5kIHByZXNl bmNlIGNvbnRhaW5lcj8gDQo+IA0KPiA+IA0KPiA+IEEgcHJlc2VuY2UgY29udGFpbmVyJ3MgZXhp c3RlbmNlIGhhcyBzb21lIGRhdGEgbW9kZWwgc2VtYW50aWNzIA0KZGVzY3JpYmVkIGluDQo+ID4g dGhlIHRleHQgdmFsdWUgZm9yIHRoYXQgc3RhdGVtZW50LiAgQSBub24tcHJlc2VuY2UgY29udGFp bmVyIGlzIGEgDQo+ID4gY29sbGVjdGlvbiB3aXRob3V0IA0KPiA+IGFkZGl0aW9uYWwgc2VtYW50 aWNzIGZvciB0aGUgZXhpc3RlbmNlIG9mIGFuIGVtcHR5IGNvbnRhaW5lci4gDQo+ID4gDQo+ID4g VGhlcmUgaXMgbm8gdGV4dCB0aGF0IHN1cHBvcnRzIHlvdXIgY2xhaW0uIA0KPiA+IA0KPiA+IE5v dGUgdGhpcyB0ZXh0IGluIHNlYy4gNy41Ljg6IA0KPiA+IA0KPiA+IA0KPiA+ICAgSWYgYSBjb250 YWluZXIgZG9lcyBub3QgaGF2ZSBhICJwcmVzZW5jZSIgc3RhdGVtZW50IGFuZCB0aGUgbGFzdA0K PiA+ICAgY2hpbGQgbm9kZSBpcyBkZWxldGVkLCB0aGUgTkVUQ09ORiBzZXJ2ZXIgTUFZIGRlbGV0 ZSB0aGUgY29udGFpbmVyLiANCj4gPiBOb3RlIE1BWSBpbnN0ZWFkIG9mIFNIT1VMRCBvciBNVVNU LiANCj4gPiBZb3UgY2FuIHRyZWF0IGFuIGVtcHR5IHJlcGxhY2Ugb3BlcmF0aW9uIGFzIGEgZGVs ZXRlIG9mIGFuIE5QIA0KY29udGFpbmVyIA0KPiA+IGluIHlvdXIgaW1wbGVtZW50YXRpb24uICBP dGhlciBzZXJ2ZXJzIGNhbiBrZWVwIHRoZW0gaW4gdGhlIGRhdGEgDQptb2RlbC4gDQo+ID4gDQo+ IA0KPiBJbiBzZWN0aW9uIDcuNS4xOiANCj4gIkluIHRoZSBmaXJzdCBzdHlsZSwgdGhlIGNvbnRh aW5lciBoYXMgbm8gbWVhbmluZyBvZiBpdHMgb3duLCBleGlzdGluZyANCj4gICAgb25seSB0byBj b250YWluIGNoaWxkIG5vZGVzLiAgVGhpcyBpcyB0aGUgZGVmYXVsdCBzdHlsZS4iIA0KPiANCj4g SWYgYSBOUCBjb250YWluZXIgZXhpc3RzIG9ubHkgdG8gY29udGFpbiBjaGlsZCBub2Rlcywgd2h5 IGl0c2VsZiBjYW4NCj4gYmUgYWNjZXB0ZWQgDQo+IGFzIGEgdmFsaWQgY29uZmlndXJhdGlvbj8g DQoNCj4gDQo+IEkgY2FuJ3QgZmluZCBhbnkgdGV4dCBpbiBhbnkgUkZDIHRoYXQgc2F5cyB0byBy ZWplY3QgYW4gZW1wdHkgTlAgDQo+IGNvbnRhaW5lciBhcyBpbnZhbGlkIGNvbmZpZy4NCj4gSSBj YW4gZmluZCB0ZXh0IHRoYXQgc2F5cyB5b3UgTUFZIGRlbGV0ZSB0aGVtLiBTbyBkbyB3aGF0IHlv dSB3YW50IGluDQo+IHlvdXIgaW1wbGVtZW50YXRpb24uDQo+IA0KDQpObywgaWYgYSBOUCBjb250 YWluZXIgaXRzZWxmIGNhbiBiZSBhY2NlcHRlZCBhcyB2YWxpZCBjb25maWd1cmF0aW9uLCBhbmQN CnNldmVyIGRlbGV0ZSBpdCwgY2xpZW50IGNhbiB1c2UgJ3JlcGxhY2UnIGFzIHJlbW92ZSwgJ21l cmdlJyBhcyByZW1vdmUuDQoNCklmIHNldmVyIGNhbiBkZWNpZGUgd2hldGhlciBzdXBwb3J0IGl0 LiB3aGF0IGNsaWVudCBjYW4gZG8/IElmIGNsaWVudCBzZW5kDQphIHJlcXVlc3QgdG8gcmVwbGFj ZSBhIE5QIGNvbnRhaW5lciB3aXRoIGEgZWxlbWVudCBjb250YWlucyBlbXB0eSBub2RlLCANCnRo ZSANCnJlc3BvbnNlIGlzIHVuY2VydGFpbi4NCg0KSSB0aGluayBpdCdzIHNvIGJhZCBmb3IgaW50 ZXJvcGVyYWJpbGl0eS4gSSBzdWdnZXN0IE5FVENPTkYvTkVUTU9EIFdHcyANCnJlamVjdA0KdGhl IE5QIGNvbnRhaW5lciBpdHNlbGYgYXMgaW52YWxpZCBjb25maWd1cmF0aW9uLiBJdCdzIG5vIGFu eSB2YWx1ZSBhbmQgDQp3b3VsZCANCmNhdXNlIGNvbmZ1c2lvbi4NCg0KDQo+IEFuZHkNCj4gDQo+ IA0KPiA+IA0KPiA+ID4gVGhleSBhcmUgbm90IGFzIHN0YW5kYXJkIGFzIG90aGVyIFlBTkcgZGF0 YSBub2RlcyBiZWNhdXNlIGEgDQo+IHNlcnZlck1BWSBjaG9vc2UNCj4gPiA+IHRvIGRlbGV0ZSB0 aGVzZSBub2Rlcy4gU29tZSBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIGV2ZW4gY3JlYXRlIHRoZW0s DQo+ID4gPiBhbHRob3VnaCB0aGUgDQo+ID4gPiBzcGVjIGlzIHNpbGVudCBvbiB0aGlzIHBvaW50 LiANCj4gPiA+IA0KPiA+ID4gQXMgTGFkYSBwb2ludGVkIG91dCwgdGhlIHNlcnZlciBmbGV4aWJp bGl0eSBmb3IgTlAtY29udGFpbmVycyBpcyANCj4gPiA+IG1vcmUgb2YgYSBidWcgdGhhbiBhIGZl YXR1cmUuIA0KPiA+ID4gDQo+ID4gPiBCVFcsIGVtcHR5IGJpdHMgaXMgYW5vdGhlciBlbXB0eSBu b2RlIHRoYXQgaXMgbGVnYWwgKGZvciByZXBsYWNlDQo+IG9wZXJhdGlvbikuDQo+ID4gPiBZb3Ug Y2FuIHJlcGxhY2UgYSBsZWFmLWxpc3Qgd2l0aCBpdHNlbGYgKHRoZSBpbnN0YW5jZSBjb250YWlu aW5nIHRoZQ0KPiA+ID4gZW1wdHkgbm9kZSwgaWYgYW55KS4gDQo+ID4gDQo+ID4gSWYgbGVhZi1s aXN0IGNhbiBiZSByZXBsYWNlIHdpdGggaXRzZWxmLCB0aGVuIHRoZSBsaXN0IGNhbiBiZSANCj4g PiByZXBsYWNlIHdpdGggaXRzZWxmIGFsc28uIA0KPiA+IFRoZW4gYWxsIG5vZGVzIGNvbnRhaW5l ciBlbXB0eSBub2RlIHNob3VsZCBiZSBjb25zaWRlcmVkIHRvIGJlIGEgDQo+ID4gdmFsaWQgY29u ZmlndXJhdGlvbj8gDQo+IA0KPiA+IA0KPiA+IEJ1dCB0aGVuIHlvdSB3b3VsZCBiZSBwcm92aWRp bmcgbGlzdCBrZXlzLCBhbmQgdGhlIGNvbnRhaW5lciB3b3VsZCANCj4gPiBub3QgYmUgZW1wdHku IA0KPiA+IFJlcGxhY2luZyBhIGxpc3QgZW50cnkgd2l0aCBqdXN0IHRoZSBrZXlzIGlzIHRoZSBz YW1lIGFzIGRlbGV0aW5nIA0KPiA+IGFsbCB0aGUgbm9uLWtleSBjaGlsZCBub2Rlcy4gDQo+ID4g DQo+ID4gDQo+ID4gSSB0aGluayBXRyBzaG91bGQgZ2l2ZSBhIG1vcmUgY2xlYXIgY2xhcmlmaWNh dGlvbi4gDQo+ID4gDQo+ID4gU2VjLiA3LjUuOCBjb3VsZCBiZSBjbGVhcmVyIGJlY2F1c2UgaXQg aW1wbGllcyB0aGF0IHRoaXMgYmVoYXZpb3IgDQo+ID4gb25seSBhcHBsaWVzIHRvIHRoZSAiZGVs ZXRlIiBvcGVyYXRpb24uICBJdCBzaG91bGQgYmUgZXhwbGljaXQgdGhhdCANCj4gPiAicmVtb3Zl IiBhbmQgInJlcGxhY2UiIA0KPiA+IGNhbiBhbHNvIGNhdXNlIHRoZSBsYXN0IGNoaWxkIGluIGFu IE5QIGNvbnRhaW5lciB0byBiZSBkZWxldGVkLiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBJTU8g SSB0aGluayBvbmx5IE5QLWNvbnRhaW5lcixlbXB0eSBsZWFmLCBhbnl4bWwsIHplcm8tbGVuZ3Ro IHN0cmluZw0KPiA+IG9yIGJpbmFyeSwgYml0cyBjYW4gYmUgYSB2YWxpZCBjb25maWd1cmF0aW9u IGl0c2VsZi4gDQo+ID4gPiANCj4gPiA+ID4gL2ZyYW5rIA0KPiA+ID4gDQo+ID4gPiBBbmR5IA0K PiA+IA0KPiA+IEFuZHkgDQo+ID4gDQo+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYtMDkgMTA6MzY6MTY6DQo+ID4g PiA+IA0KPiA+ID4gPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4gPiA+ ID4gPiAyMDE0LTA2LTA5IDEwOjM2IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IMrVvP7IyyANCj4g PiA+ID4gPiANCj4gPiA+ID4gPiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgDQo+ID4gPiA+ID4g DQo+ID4gPiA+ID4gs63LzSANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBkb3Uud2VpMUB6dGUuY29t LmNuLCBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgDQo+ID4gPiA+ID4geGlhby55dXFpbmdA enRlLmNvbS5jbiwgeWUueHUxQHp0ZS5jb20uY24gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4g1vfM 4iANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25zIGFi b3V0IHRoZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyANCj4gPiA+ID4gPiBhdHRyaWJ1dGUgaW4gZWRp dC1jb25maWcgDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiA+IE9u IFN1biwgSnVuIDgsIDIwMTQgYXQgNjoxOCBQTSwgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiB3 cm90ZTogDQoNCj4gPiA+ID4gPiBBbmR5o6wgDQo+ID4gPiA+ID4gICAgIEkgaGF2ZSBsb29rZWQg dGhyb3VnaCB0aGlzIHNlY3Rpb24gZm9yIG1hbnkgdGltZXMuIEluIG15IA0KPiA+ID4gPiBvcGlu aW9uLCBJIHRoaW5rIA0KPiA+ID4gPiA+IHRoZSBlbGVtZW50IGNvbnRhaW5zIGF0dHJpYnV0ZSAn cmVwbGFjZScgbXVzdCBoYXZlIHN1YnRyZWUsIGFuZCANCj4gPiA+ID4gdGhpcyBzdWJ0cmVlIA0K PiA+ID4gPiA+IHNob3VsZCBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24uIEJ1dCBteSBjb2xsZWFn dWVzIGRvbid0IHRoaW5rIA0Kc28sIA0KPiA+ID4gPiA+IHRoZXkgYXJndWVkIA0KPiA+ID4gPiA+ IHRoYXQgdGhlIGVtcHR5IGNvbmZpZ3VyYXRpb24gaXMgYWxzbyBjb25maWd1cmF0aW9uLCB0aGV5 IHdhbnQgdG8gDQoNCj4gPiA+ID4gdXNlJ3JlcGxhY2UnIA0KPiA+ID4gPiA+IGFzICdyZW1vdmUn LCBJIGNhbid0IHBlcnN1YWRlIHRoZW0sIDopIA0KPiA+ID4gPiA+ICAgICBTbyxJIHdhbnQgdG8g Z2V0IGEgY2xhcmlmaWNhdGlvbiwgdGhhbmtzLiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiB5b3Ug YXJlIGJvdGggcmlnaHQgOy0pIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IHRoZSByZXBsYWNlIGF0 dHJpYnV0ZSBkb2VzIGhhdmUgdG8gYXBwZWFyIGluIGEgc3VidHJlZSwgYnV0IGEgDQo+ID4gPiBz dWJ0cmVlIG1heSBiZQ0KPiA+ID4gPiA+IGFuIGVtcHR5IG5vZGUgKGlmIGl0IGlzIHNjaGVtYSB2 YWxpZCkuIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IHN0YXJ0OiANCj4gPiA+ID4gPiANCj4gPiA+ ID4gPiAgIDxjb25maWc+IA0KPiA+ID4gPiA+ICAgICAgPGZvbz4gDQo+ID4gPiA+ID4gICAgICAg ICA8YT40MjwvYT4gDQo+ID4gPiA+ID4gICAgICA8L2Zvbz4gDQo+ID4gPiA+ID4gICA8L2NvbmZp Zz4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gcmVwbGFjZSBmb286IA0KPiA+ID4gPiA+IA0KPiA+ ID4gPiA+ICA8Y29uZmlnPiANCj4gPiA+ID4gPiAgICAgIDxmb28gb3BlcmF0aW9uPSJyZXBsYWNl IiAvPiANCj4gPiA+ID4gPiAgIDwvY29uZmlnPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiByZXN1 bHQ6IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ICAgPGNvbmZpZz4gDQo+ID4gPiA+ID4gICAgICA8 Zm9vIC8+IA0KPiA+ID4gPiA+ICAgPC9jb25maWc+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IFRo ZSB0ZXh0IHNlZW1zIHZlcnkgY2xlYXIgdG8gbWUuIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IC9m cmFuayANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBBbmR5IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiAN Cj4gPiA+ID4gSW4geW91ciBleGFtcGxlLCB0aGUgJ2ZvbycgTVVTVCBiZSBhIHByZXNlbmNlIGNv bnRhaW5lcj8gDQo+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEFuZHkgQmllcm1hbiA8 YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDYtMDcgMDI6NDM6Mjg6DQo+ID4gPiA+ID4g DQo+ID4gPiA+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gDQo+ID4gPiA+ ID4gPiAyMDE0LTA2LTA3IDAyOjQzIA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiDK1bz+yMsg DQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4g PiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gs63LzSANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4g ZG91LndlaTFAenRlLmNvbS5jbiwgTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4sIA0KPiA+ID4g PiA+ID4geGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5jb20uY24gDQo+ID4gPiA+ ID4gPiANCj4gPiA+ID4gPiA+INb3zOIgDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IFJlOiBb TmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9mICdvcGVyYXRpb24nIA0K PiA+ID4gPiA+ID4gYXR0cmlidXRlIGluIGVkaXQtY29uZmlnIA0KPiA+ID4gPiA+ID4gDQo+ID4g PiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IE9uIFRodSwgSnVuIDUsIDIwMTQgYXQg MTE6MTggUE0sIDxmZW5nLmNob25nMzNAenRlLmNvbS5jbj4gDQp3cm90ZTogDQo+ID4gPiA+ID4g PiBhbmR5LCANCj4gPiA+ID4gPiA+ICAgIFRoYW5rcyBhIGxvdC4gDQo+ID4gPiA+ID4gPiAgICBD YW4geW91IGFuc3dlciB0aGUgZmlyc3QgcXVlc3Rpb24/ICdyZXBsYWNlJyBjYW4gYmUgdXNlZCAN Cj4gPiBhcydyZW1vdmUnPyANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gUmVhZCBSRkMgNjI0 MSwgc2VjLiA3LjIgQXR0cmlidXRlcyBzZWN0aW9uLiANCj4gPiA+ID4gPiA+IEl0IGV4cGxhaW5z IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIE5FVENPTkYgPGVkaXQtY29uZmlnPiANCj4gPiA+ IG9wZXJhdGlvbnMuIA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IC9m cmFuayANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gQW5keSANCj4gPiA+ID4gPiA+IA0KPiA+ ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4g 0LTT2iAyMDE0LTA2LTA1IDIzOjQ2OjUzOg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IEFu ZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiANCj4gPiA+ID4gPiA+ID4gMjAxNC0wNi0w NSAyMzo0NiANCj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IMrVvP7IyyANCj4gPiA+ID4g PiA+ID4gDQo+ID4gPiA+ID4gPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gPiA+ID4g PiA+ID4gDQo+ID4gPiA+ID4gPiA+ILOty80gDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4g PiBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgeWUueHUxQHp0ZS5jb20uY24sIA0KZG91Lndl aTFAenRlLmNvbS5jbg0KPiAsIA0KPiA+ID4gPiA+ID4gPiB4aWFvLnl1cWluZ0B6dGUuY29tLmNu IA0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4g1vfM4iANCj4gPiA+ID4gPiA+ID4gDQo+ ID4gPiA+ID4gPiA+IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdl IG9mICdvcGVyYXRpb24nIA0KPiA+ID4gPiA+ID4gPiBhdHRyaWJ1dGUgaW4gZWRpdC1jb25maWcg DQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ ID4gPiBPbiBXZWQsIEp1biA0LCAyMDE0IGF0IDY6MzUgUE0sIDxmZW5nLmNob25nMzNAenRlLmNv bS5jbj4gDQp3cm90ZTogDQo+ID4gPiA+ID4gPiA+IEhpIGFsbCwgDQo+ID4gPiA+ID4gPiA+ICAg IEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgDQonb3BlcmF0aW9uJ2F0 dHJpYnV0ZSANCj4gPiA+ID4gPiA+ID4gaW4gZWRpdC1jb25maWcuIA0KPiA+ID4gPiA+ID4gPiAg ICAxLiAncmVwbGFjZScgYXR0cmlidXRlIGNhbiBvbmx5IGJlIHVzZWQgdG8gcmVtb3ZlIA0KPiBj b25maWd1cmF0aW9uPyANCj4gPiA+ID4gPiA+ID4gICAgICAgRm9yIGV4YW1wbGUsIHRoZSBycGMg cmVxdWVzdCBsaXN0ZWQgYmVsb3cgaXMgdmFsaWQ/IA0KPiA+ID4gPiA+ID4gPiAgICAgICA8cnBj IG1lc3NhZ2UtaWQgPSAiMTAxIj4gDQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgPGVkaXQtY29u ZmlnPiANCj4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgPHRhcmdldD4gDQo+ID4gPiA+ID4g PiA+ICAgICAgICAgICAgICAgICAgIDxydW5uaW5nLz4gDQo+ID4gPiA+ID4gPiA+ICAgICAgICAg ICAgICAgIDwvdGFyZ2V0PiANCj4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgPGNvbmZpZz4g DQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgIDxpbnRlcmZhY2VzIG9wZXJhdGlvbj0g InJlcGxhY2UiLz4gDQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgIDwvY29uZmlnPiANCj4g PiA+ID4gPiA+ID4gICAgICAgICAgICA8L2VkaXQtY29uZmlnPiANCj4gPiA+ID4gPiA+ID4gICAg ICAgPC9ycGM+IA0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+ ICAgIDIuSG93IHRvIHByb2Nlc3MgbmVzdGVkIG9wZXJhdGlvbiBhdHRyaWJ1dGU/IA0KPiA+ID4g PiA+ID4gPiAgICAgIEZvciBleGFtcGxlOiANCj4gPiA+ID4gPiA+ID4gICAgICAgICAgICA8cnBj IG1lc3NhZ2UtaWQgPSAiMTAxIj4gDQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgPGVkaXQtY29u ZmlnPiANCj4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgPHRhcmdldD4gDQo+ID4gPiA+ID4g PiA+ICAgICAgICAgICAgICAgICAgIDxydW5uaW5nLz4gDQo+ID4gPiA+ID4gPiA+ICAgICAgICAg ICAgICAgIDwvdGFyZ2V0PiANCj4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgPGNvbmZpZz4g DQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgIDxpbnRlcmZhY2VzPiANCj4gPiA+ID4g PiA+ID4gICAgICAgICAgICAgICAgICAgICAgIDxpbnRlcmZhY2Ugb3BlcmF0aW9uPSAibWVyZ2Ui PiANCj4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPG5hbWU+ZXRoMC8w LzA8L25hbWU+IA0KPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bXR1 IG9wZXJhdGlvbj0gInJlbW92ZSI+IA0KPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8ZW5hYmxlZD50cnVlPC9lbmFsYmxlZD4gDQo+ID4gPiA+ID4gPiA+ICAgICAgICAg ICAgICAgICAgICAgICA8L2ludGVyZmFjZT4gDQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAg ICAgIDwvaW50ZXJmYWNlcz4gDQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgIDwvY29uZmln PiANCj4gPiA+ID4gPiA+ID4gICAgICAgICAgICA8L2VkaXQtY29uZmlnPiANCj4gPiA+ID4gPiA+ ID4gICAgICAgPC9ycGM+IA0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gICAgICBUaGUg c2VxdWVuY2Ugb2YgcHJvY2VzcyBpcyBtZXJnZSBpbnRlcmZhY2UgbmFtZSANCj4gJ2V0aDAvMC8w JyBhbmQgDQo+ID4gPiA+ID4gPiA+IHJlbW92ZSBtdHUgYW5kIG1lcmdlIGVuYWJsZWQgdG8gJ3Ry dWUnIA0KPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9yIG1lcmdl IGludGVyZmFjZSBuYW1lIA0KPiAnZXRoMC8wLzAnIGFuZCANCj4gPiA+ID4gPiA+ID4gbWVyZ2Ug ZW5hYmxlZCB0byAndHJ1ZScgYW5kIHJlbW92ZSBtdHU/IA0KPiA+ID4gPiA+ID4gPiAgICAgIElu IG90aGVyIHdvcmRzLCBORVRDT05GIHdpbGwgcHJvY2VzcyBvdXRlciBsYXllciANCm9wZXJhdGlv biANCj4gPiA+ID4gPiA+ID4gZmlyc3RseSBhbmQgcHJvY2VzcyBpbm5lciBsYXllciBvcGVyYXRp b24gbGF0ZXIsIG9yIHByb2Nlc3MgDQo+ID4gPiA+ID4gPiA+IG9wZXJhdGlvbnMgaW4gYWNjb3Jk YW5jZSB3aXRoIFhNTCB0cmVlIHRyYXZlcnNhbCBvcmRlcj8gDQo+ID4gPiA+ID4gPiA+IA0KPiA+ ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gVGhlcmUgaXMgbm8gcmVxdWlyZWQgcHJvY2Vzc2lu ZyBvcmRlci4gDQo+ID4gPiA+ID4gPiA+IEl0IGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4g DQo+ID4gPiA+ID4gPiA+IFNvbWUgdGhpbmdzIHRvIGNvbnNpZGVyOiANCj4gPiA+ID4gPiA+ID4g ICAxKSBhbGwgb3BlcmF0aW9ucyBhcmUgYWdhaW5zdCB0aGUgdGFyZ2V0IGRhdGFzdG9yZSBhdCAN Cj4gdGhlIHN0YXJ0IG9mDQo+ID4gPiA+ID4gPiA+IHRoZSBvcGVyYXRpb24gDQo+ID4gPiA+ID4g PiA+ICAgMikgdGhlIG9wZXJhdGlvbnMgYXJlIGFsbC1vci1ub25lLCBub3QgaW5jcmVtZW50YWwg DQo+ID4gPiA+ID4gPiA+ICAgMmEpIHRoaXMgaW1wbGllcyB0aGF0IGNyZWF0ZSB3aXRoaW4gZGVs ZXRlLCBvciBkZWxldGUgDQp3aXRoaW4gDQo+ID4gPiA+ID4gPiA+IGNyZWF0ZSwgaXMgYWx3YXlz IGFuIGVycm9yIA0KPiA+ID4gPiA+ID4gPiAgICAgICAgYmVjYXVzZSAnZGF0YS1leGlzdHMnIG9y ICdkYXRhLW1pc3NpbmcnIG11c3QgYmUgdHJ1ZSANCj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4g PiA+IEluIHlvdXIgZXhhbXBsZSB0aGVyZSBpcyBubyBwcm9ibGVtIGJlY2F1c2UgJ3JlbW92ZScg DQo+IHdvcmtzIGV2ZW4gaWYgDQo+ID4gPiA+ID4gPiA+IHRoZSBkYXRhIGlzIG1pc3NpbmcuIA0K PiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ ID4gPiAzLiBJZiBvdGhlciBvcGVyYXRpb24gYXR0cmlidXRlIG5lc3RlZCBpbiBvcGVyYXRpb24g DQphdHRyaWJ1dGUgDQo+ID4gPiA+ID4gPiA+ICdyZW1vdmUnLHdoYXQgc2hvdWxkIE5FVENPTkYg c2VydmVyIGRvPyBPbmx5IHByb2Nlc3MgcmVtb3ZlIA0KPiA+ID4gb3BlcmF0aW9uPyANCj4gPiA+ ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+ICAgNC4gQ2FuIE5FVENPTkYgc3VwcG9ydCB0aGUgbmVz dGVkIG9wZXJhdGlvbiBhdHRyaWJ1dGUgDQplcXVhbHMgdG8gDQo+ID4gPiA+ID4gPiA+IHBhcmVu dCBvcGVyYXRpb24gYXR0cmlidXRlPyANCj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IC9m cmFuayANCj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IEFuZHkgDQo+ID4gPiA+ID4gPiA+ IA0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiA+ID4gWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIA0KPiBjb250YWluZWQgaW4g dGhpcyANCj4gPiA+ID4gPiA+ID4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVk IGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIA0KYW5kIA0KPiA+ID4gPiA+ID4gPiBjb25maWRlbnRp YWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiANCj4gdGhlIGFkZHJl c3NlZQ0KPiA+ID4gPiA+ID4gPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNp cGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gPiA+ID4gPiA+ID4gcmVwcm9kdWN0aW9uLCBkaXN0 cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgDQp0aGUgDQo+ID4gPiA+ ID4gPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYg eW91IA0KPiBoYXZlcmVjZWl2ZWQgDQo+ID4gPiA+ID4gPiA+IHRoaXMgbWFpbCBpbiBlcnJvciwg cGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIA0KaW1tZWRpYXRlbHkuDQo+ID4gPiA+ID4g PiA+IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+ID4gPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ID4gTmV0Y29u ZkBpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmYNCj4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g PiA+ID4gPiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gDQp0aGlzIA0KPiA+ID4gPiA+ID4gbWFpbCAoYW5kIGFueSBhdHRhY2ht ZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIA0KYW5kIA0KPiA+ID4gPiA+ ID4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg dGhlIA0KYWRkcmVzc2VlDQo+ID4gPiA+ID4gPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRl bmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gPiA+ID4gPiA+IHJlcHJvZHVjdGlv biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIA0KdGhlIA0K PiA+ID4gPiA+ID4gaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu ICBJZiB5b3UgDQpoYXZlcmVjZWl2ZWQgDQo+ID4gPiA+ID4gPiB0aGlzIG1haWwgaW4gZXJyb3Is IHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyANCmltbWVkaWF0ZWx5Lg0KPiA+ID4gPiA+ ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiANCnRo aXMgDQo+ID4gPiA+ID4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3 aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCg0KPiA+ID4gPiA+IGNvbmZpZGVudGlhbCBhbmQgaXMg aW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSANCmFkZHJlc3NlZQ0KPiA+ID4g PiA+IChzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Ns b3N1cmUsIA0KPiA+ID4gPiA+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRp c3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gPiA+ID4gPiBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIA0KcmVjZWl2ZWQgDQo+ID4g PiA+ID4gdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuDQo+ID4gPiA+ID4gDQo+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g PiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyANCg0KPiA+ID4gPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNt aXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiA+ID4gPiBjb25maWRlbnRpYWwg YW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgDQphZGRyZXNzZWUN Cj4gPiA+ID4gKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkg ZGlzY2xvc3VyZSwgDQo+ID4gPiA+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVy IGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gPiA+ID4gaW5mb3JtYXRpb24gY29udGFp bmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSANCnJlY2VpdmVkIA0KPiA+ ID4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBp bW1lZGlhdGVseS4NCj4gPiA+ID4gDQo+ID4gDQo+ID4gPiANCj4gPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiBaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgDQo+ID4gPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgp IGlzIHByaXZpbGVnZWQgYW5kIA0KPiA+ID4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBm b3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiA+ID4gKHMpLiAgSWYgeW91 IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+ID4gPiBy ZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBv ZiB0aGUgDQo+ID4gPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiA+ID4gdGhpcyBtYWlsIGluIGVycm9yLCBwbGVh c2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+ID4gPiANCj4gDQo+ID4g DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgDQo+ID4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5z bWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCj4gPiBjb25maWRlbnRpYWwgYW5k IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+ID4g KHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3Vy ZSwgDQo+ID4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlv biBvciB1c2Ugb2YgdGhlIA0KPiA+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgDQo+ID4gdGhpcyBtYWlsIGluIGVycm9y LCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+ID4gDQoNCj4g DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyANCj4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVk IGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCj4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiAocykuICBJZiB5 b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gcmVw cm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2Yg dGhlIA0KPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElm IHlvdSBoYXZlIHJlY2VpdmVkIA0KPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUg aXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5k IGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBj b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUg YWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkg ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5h dGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2Ug ZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo= --=_alternative 002257ED48257CF3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPkFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQ tNPaIDIwMTQtMDYtMTANCjExOjEyOjA0Ojxicj4NCjxicj4NCiZndDsgQW5keSBCaWVybWFuICZs dDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAyMDE0LTA2LTEwIDExOjEyPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBkb3Uud2VpMUB6dGUuY29tLmNuLCBO ZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgPGJyPg0KJmd0OyB4aWFvLnl1cWluZ0B6 dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyA8YnI+DQomZ3Q7INb3zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KJmd0OyBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rpb25zIGFib3V0IHRo ZSB1c2FnZSBvZiAnb3BlcmF0aW9uJyA8YnI+DQomZ3Q7IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZp ZzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4N CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBPbiBNb24sIEp1biA5LCAy MDE0IGF0IDc6MjAgUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5jbiZndDsNCndyb3RlOjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAvZnJhbmsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQtNPaIDIw MTQtMDYtMTAgMDk6MDE6MTY6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgQW5keSBCaWVybWFu ICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDxicj4NCiZndDsgJmd0OyAyMDE0LTA2LTEwIDA5 OjAxIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgytW8/sjLIDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGRv dS53ZWkxQHp0ZS5jb20uY24sIE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCA8YnI+ DQomZ3Q7ICZndDsgeGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5jb20uY24gPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDW98ziIDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2Yg J29wZXJhdGlvbicgPGJyPg0KJmd0OyAmZ3Q7IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZpZyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9u IE1vbiwgSnVuIDksIDIwMTQgYXQgNTo0NiBQTSwgJmx0O2ZlbmcuY2hvbmczM0B6dGUuY29tLmNu Jmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyAvZnJhbmsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsg0LTT2iAy MDE0LTA2LTA5IDIyOjE5OjI1Ojxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBB bmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgMjAxNC0wNi0wOSAyMjoxOSA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyDK1bz+yMsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZmVu Zy5jaG9uZzMzQHp0ZS5jb20uY24sIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmZ3Q7ILOty80gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZG91 LndlaTFAenRlLmNvbS5jbiwgTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDssIDxicj4N CiZndDsgJmd0OyAmZ3Q7IHhpYW8ueXVxaW5nQHp0ZS5jb20uY24sIHllLnh1MUB6dGUuY29tLmNu IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7INb3zOIgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0 aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YgJ29wZXJhdGlvbicNCjxicj4NCiZndDsgJmd0OyAmZ3Q7 IGF0dHJpYnV0ZSBpbiBlZGl0LWNvbmZpZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT24gU3VuLCBK dW4gOCwgMjAxNCBhdCAxMDo0MCBQTSwgJmx0O2ZlbmcuY2hvbmczM0B6dGUuY29tLmNuJmd0Ow0K d3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IC9mcmFuayA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZn dDsg0LTT2iAyMDE0LTA2LTA5DQoxMTo0NDo1ODo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDIwMTQtMDYtMDkgMTE6NDQgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IMrVvP7IyyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZmVuZy5jaG9uZzMzQHp0 ZS5jb20uY24sIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyCzrcvNIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBkb3Uud2VpMUB6dGUuY29tLmNuLCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0 OywNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgeGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUu eHUxQHp0ZS5jb20uY24gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7INb3zOIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IFJlOiBbTmV0Y29uZl0gU29tZSBxdWVzdGlvbnMgYWJvdXQgdGhlIHVzYWdlIG9m ICdvcGVyYXRpb24nDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF0dHJpYnV0ZSBpbiBlZGl0 LWNvbmZpZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiBTdW4s IEp1biA4LCAyMDE0IGF0IDg6MTggUE0sICZsdDtmZW5nLmNob25nMzNAenRlLmNvbS5jbiZndDsN Cndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFuZHksIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO3RoYW5rcyw6KSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDtJIHVuZGVyc3RhbmQgb25seSBwcmVzZW5jZSBjb250YWluZXIgb3INCmxl YWYgbm9kZSB3aXRoIGVtcHR5IHR5cGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNhbiBiZSBw bGFjZWQgJ3JlcGxhY2UnIGF0dHJpYnV0ZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFuZCBo YXZlIGEgZW1wdHkgbm9kZSBzdWJ0cmVlLiBJcyBpdCByaWdodD8gPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IG5vLiBhbnkgY29udGFpbmVyLiBhbnl4bWwuIGVtcHR5IGxlYWYuIHplcm8tbGVu Z3RoDQpzdHJpbmcgbGVhZi4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyBSZWFsbHk/IGEgTlAgY29udGFpbmVyIGNhbiBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRp b24gaXRzZWxmPw0KPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7IFllcyAtLSB0aGVyZSBpcyBzb21lIGNvbmZ1c2lvbiBiZWNhdXNlIGl0IGlz IHdpZGVseSBiZWxpZXZlZA0KdGhhdCA8YnI+DQomZ3Q7ICZndDsgTlBjb250YWluZXJzIDxicj4N CiZndDsgJmd0OyAmZ3Q7IGhhdmUgbm8gc2VtYW50aWNzIC0tIGJ1dCB0aGlzIGlzIGZhbHNlLiAm bmJzcDtUaGV5IGFyZSBjb2xsZWN0aW9ucy4NCiZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7IG11 c3Qtc3RtdCB2YWxpZGF0aW9uIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoYXQgZmFpbHMgb24gYW4g TlAtY29udGFpbmVyIHdpbGwgY2F1c2UgdGhlIGVkaXQvY29tbWl0DQp0byBmYWlsIDxicj4NCiZn dDsgJmd0OyAmZ3Q7IGp1c3QgbGlrZSBhbnkgb3RoZXIgbm9kZS4gPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIGRvbid0IGFncmVlLiBJIHRoaW5r IE5QLWNvbnRhaW5lciBNVVNUIG5vdCBiZSBhIHZhbGlkIDxicj4NCiZndDsgJmd0OyBjb25maWd1 cmF0aW9uIGlmIGl0IGhhcyBubyBjaGlsZHJlbiwgPGJyPg0KJmd0OyAmZ3Q7IGV2ZW4gaWYgTlAt Y29udGFpbmVyIGhhcyBzb21lIHNlbWFudGljcywgaW4gdGhhdCBjYXNlLCBOUC1jb250YWluZXIN Cjxicj4NCiZndDsgJmd0OyBqdXN0IGFjdCBhcyBhIHVuaXQgY2FuIGJlIDxicj4NCiZndDsgJmd0 OyBldmFsdWF0ZWQgb3IgdmFsaWRhdGVkLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IElmIGEgTlAtY29udGFpbmVyIGNhbiBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gaXRzZWxmLCB3 aGF0J3MNCnRoZSA8YnI+DQomZ3Q7ICZndDsgZGlmZmVyZW5jZSBiZXR3ZWVuIE5QLWNvbnRhaW5l ciBhbmQgcHJlc2VuY2UgY29udGFpbmVyPyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgQSBwcmVzZW5jZSBjb250YWluZXIncyBleGlzdGVuY2UgaGFzIHNvbWUgZGF0 YSBtb2RlbCBzZW1hbnRpY3MNCmRlc2NyaWJlZCBpbjxicj4NCiZndDsgJmd0OyB0aGUgdGV4dCB2 YWx1ZSBmb3IgdGhhdCBzdGF0ZW1lbnQuICZuYnNwO0Egbm9uLXByZXNlbmNlIGNvbnRhaW5lcg0K aXMgYSA8YnI+DQomZ3Q7ICZndDsgY29sbGVjdGlvbiB3aXRob3V0IDxicj4NCiZndDsgJmd0OyBh ZGRpdGlvbmFsIHNlbWFudGljcyBmb3IgdGhlIGV4aXN0ZW5jZSBvZiBhbiBlbXB0eSBjb250YWlu ZXIuDQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZXJlIGlzIG5vIHRleHQgdGhh dCBzdXBwb3J0cyB5b3VyIGNsYWltLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE5v dGUgdGhpcyB0ZXh0IGluIHNlYy4gNy41Ljg6IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyBJZiBhIGNvbnRhaW5lciBkb2VzIG5vdCBoYXZlIGEg JnF1b3Q7cHJlc2VuY2UmcXVvdDsgc3RhdGVtZW50DQphbmQgdGhlIGxhc3Q8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7IGNoaWxkIG5vZGUgaXMgZGVsZXRlZCwgdGhlIE5FVENPTkYgc2VydmVyIE1BWSBk ZWxldGUgdGhlDQpjb250YWluZXIuIDxicj4NCiZndDsgJmd0OyBOb3RlIE1BWSBpbnN0ZWFkIG9m IFNIT1VMRCBvciBNVVNULiA8YnI+DQomZ3Q7ICZndDsgWW91IGNhbiB0cmVhdCBhbiBlbXB0eSBy ZXBsYWNlIG9wZXJhdGlvbiBhcyBhIGRlbGV0ZSBvZiBhbiBOUA0KY29udGFpbmVyIDxicj4NCiZn dDsgJmd0OyBpbiB5b3VyIGltcGxlbWVudGF0aW9uLiAmbmJzcDtPdGhlciBzZXJ2ZXJzIGNhbiBr ZWVwIHRoZW0gaW4NCnRoZSBkYXRhIG1vZGVsLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEluIHNlY3Rpb24gNy41LjE6IDxicj4NCiZndDsgJnF1b3Q7SW4gdGhlIGZpcnN0 IHN0eWxlLCB0aGUgY29udGFpbmVyIGhhcyBubyBtZWFuaW5nIG9mIGl0cyBvd24sDQpleGlzdGlu ZyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtvbmx5IHRvIGNvbnRhaW4gY2hpbGQgbm9kZXMuICZu YnNwO1RoaXMgaXMgdGhlIGRlZmF1bHQNCnN0eWxlLiZxdW90OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgSWYgYSBOUCBjb250YWluZXIgZXhpc3RzIG9ubHkgdG8gY29udGFpbiBjaGlsZCBub2Rlcywg d2h5IGl0c2VsZiBjYW48YnI+DQomZ3Q7IGJlIGFjY2VwdGVkIDxicj4NCiZndDsgYXMgYSB2YWxp ZCBjb25maWd1cmF0aW9uPyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgPGJyPg0KJmd0OyBJIGNhbid0IGZpbmQgYW55IHRleHQgaW4gYW55IFJGQyB0aGF0IHNh eXMgdG8gcmVqZWN0IGFuIGVtcHR5IE5QIDxicj4NCiZndDsgY29udGFpbmVyIGFzIGludmFsaWQg Y29uZmlnLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJIGNhbiBmaW5k IHRleHQgdGhhdCBzYXlzIHlvdSBNQVkgZGVsZXRlIHRoZW0uDQpTbyBkbyB3aGF0IHlvdSB3YW50 IGluPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHlvdXIgaW1wbGVtZW50 YXRpb24uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Tm8sIGlmIGEgTlAgY29udGFpbmVyIGl0c2Vs ZiBjYW4gYmUgYWNjZXB0ZWQgYXMgdmFsaWQNCmNvbmZpZ3VyYXRpb24sIGFuZDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+c2V2ZXIgZGVsZXRlIGl0LCBjbGllbnQgY2FuIHVzZSAn cmVwbGFjZScgYXMgcmVtb3ZlLA0KJ21lcmdlJyBhcyByZW1vdmUuPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JZiBzZXZlciBjYW4gZGVjaWRlIHdoZXRoZXIgc3VwcG9y dCBpdC4gd2hhdCBjbGllbnQNCmNhbiBkbz8gSWYgY2xpZW50IHNlbmQ8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPmEgcmVxdWVzdCB0byByZXBsYWNlIGEgTlAgY29udGFpbmVyIHdp dGggYSBlbGVtZW50DQpjb250YWlucyBlbXB0eSBub2RlLCB0aGUgPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5yZXNwb25zZSBpcyB1bmNlcnRhaW4uPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIHRoaW5rIGl0J3Mgc28gYmFkIGZvciBpbnRlcm9wZXJh YmlsaXR5LiBJIHN1Z2dlc3QNCk5FVENPTkYvTkVUTU9EIFdHcyByZWplY3Q8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPnRoZSBOUCBjb250YWluZXIgaXRzZWxmIGFzIGludmFsaWQg Y29uZmlndXJhdGlvbi4NCkl0J3Mgbm8gYW55IHZhbHVlIGFuZCB3b3VsZCA8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPmNhdXNlIGNvbmZ1c2lvbi48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgQW5keTwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGV5 IGFyZSBub3QgYXMgc3RhbmRhcmQgYXMgb3RoZXIgWUFORyBkYXRhIG5vZGVzIGJlY2F1c2UNCmEg PGJyPg0KJmd0OyBzZXJ2ZXJNQVkgY2hvb3NlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdG8gZGVsZXRl IHRoZXNlIG5vZGVzLiBTb21lIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgZXZlbg0KY3JlYXRlIHRo ZW0sPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYWx0aG91Z2ggdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7 IHNwZWMgaXMgc2lsZW50IG9uIHRoaXMgcG9pbnQuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7IEFzIExhZGEgcG9pbnRlZCBvdXQsIHRoZSBzZXJ2ZXIgZmxleGliaWxp dHkgZm9yIE5QLWNvbnRhaW5lcnMNCmlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7IG1vcmUgb2YgYSBi dWcgdGhhbiBhIGZlYXR1cmUuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IEJUVywgZW1wdHkgYml0cyBpcyBhbm90aGVyIGVtcHR5IG5vZGUgdGhhdCBpcyBsZWdhbCAo Zm9yDQpyZXBsYWNlPGJyPg0KJmd0OyBvcGVyYXRpb24pLjxicj4NCiZndDsgJmd0OyAmZ3Q7IFlv dSBjYW4gcmVwbGFjZSBhIGxlYWYtbGlzdCB3aXRoIGl0c2VsZiAodGhlIGluc3RhbmNlIGNvbnRh aW5pbmcNCnRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGVtcHR5IG5vZGUsIGlmIGFueSkuIDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSWYgbGVhZi1saXN0IGNhbiBiZSByZXBsYWNlIHdp dGggaXRzZWxmLCB0aGVuIHRoZSBsaXN0IGNhbiBiZQ0KPGJyPg0KJmd0OyAmZ3Q7IHJlcGxhY2Ug d2l0aCBpdHNlbGYgYWxzby4gPGJyPg0KJmd0OyAmZ3Q7IFRoZW4gYWxsIG5vZGVzIGNvbnRhaW5l ciBlbXB0eSBub2RlIHNob3VsZCBiZSBjb25zaWRlcmVkIHRvIGJlDQphIDxicj4NCiZndDsgJmd0 OyB2YWxpZCBjb25maWd1cmF0aW9uPyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgQnV0IHRoZW4geW91IHdvdWxkIGJlIHByb3ZpZGluZyBsaXN0IGtleXMsIGFuZCB0 aGUgY29udGFpbmVyDQp3b3VsZCA8YnI+DQomZ3Q7ICZndDsgbm90IGJlIGVtcHR5LiA8YnI+DQom Z3Q7ICZndDsgUmVwbGFjaW5nIGEgbGlzdCBlbnRyeSB3aXRoIGp1c3QgdGhlIGtleXMgaXMgdGhl IHNhbWUgYXMgZGVsZXRpbmcNCjxicj4NCiZndDsgJmd0OyBhbGwgdGhlIG5vbi1rZXkgY2hpbGQg bm9kZXMuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsg Jmd0OyBJIHRoaW5rIFdHIHNob3VsZCBnaXZlIGEgbW9yZSBjbGVhciBjbGFyaWZpY2F0aW9uLiA8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNlYy4gNy41LjggY291bGQgYmUgY2xlYXJl ciBiZWNhdXNlIGl0IGltcGxpZXMgdGhhdCB0aGlzIGJlaGF2aW9yDQo8YnI+DQomZ3Q7ICZndDsg b25seSBhcHBsaWVzIHRvIHRoZSAmcXVvdDtkZWxldGUmcXVvdDsgb3BlcmF0aW9uLiAmbmJzcDtJ dCBzaG91bGQNCmJlIGV4cGxpY2l0IHRoYXQgPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O3JlbW92ZSZx dW90OyBhbmQgJnF1b3Q7cmVwbGFjZSZxdW90OyA8YnI+DQomZ3Q7ICZndDsgY2FuIGFsc28gY2F1 c2UgdGhlIGxhc3QgY2hpbGQgaW4gYW4gTlAgY29udGFpbmVyIHRvIGJlIGRlbGV0ZWQuDQo8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgSU1PIEkgdGhpbmsgb25seSBOUC1jb250YWluZXIsZW1wdHkgbGVhZiwgYW55eG1sLCB6ZXJv LWxlbmd0aA0Kc3RyaW5nPGJyPg0KJmd0OyAmZ3Q7IG9yIGJpbmFyeSwgYml0cyBjYW4gYmUgYSB2 YWxpZCBjb25maWd1cmF0aW9uIGl0c2VsZi4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgL2ZyYW5rIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7IEFuZHkgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBbmR5 IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBbmR5IEJpZXJt YW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsg0LTT2iAyMDE0LTA2LTA5DQoxMDozNjoxNjo8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBB bmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDIwMTQtMDYtMDkgMTA6MzYgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyDK1bz+yMsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBmZW5nLmNob25n MzNAenRlLmNvbS5jbiwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyCzrcvNIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZG91LndlaTFAenRlLmNvbS5jbiwgTmV0Y29u ZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDssDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgeGlhby55dXFpbmdAenRlLmNvbS5jbiwgeWUueHUxQHp0ZS5jb20uY24gPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyDW98ziIDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgUmU6IFtOZXRjb25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNhZ2Ugb2YNCidvcGVy YXRpb24nIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBhdHRyaWJ1dGUgaW4gZWRpdC1j b25maWcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyBPbiBTdW4sIEp1biA4LCAyMDE0IGF0IDY6MTggUE0sICZsdDtmZW5nLmNob25n MzNAenRlLmNvbS5jbiZndDsNCndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg QW5keaOsIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEkgaGF2 ZSBsb29rZWQgdGhyb3VnaCB0aGlzIHNlY3Rpb24NCmZvciBtYW55IHRpbWVzLiBJbiBteSA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9waW5pb24sIEkgdGhpbmsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IHRoZSBlbGVtZW50IGNvbnRhaW5zIGF0dHJpYnV0ZSAncmVwbGFjZScgbXVz dA0KaGF2ZSBzdWJ0cmVlLCBhbmQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIHN1YnRy ZWUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNob3VsZCBiZSBhIHZhbGlkIGNvbmZp Z3VyYXRpb24uIEJ1dCBteSBjb2xsZWFndWVzDQpkb24ndCB0aGluayBzbywgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZXkgYXJndWVkIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyB0aGF0IHRoZSBlbXB0eSBjb25maWd1cmF0aW9uIGlzIGFsc28gY29uZmlndXJhdGlvbiwN CnRoZXkgd2FudCB0byA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHVzZSdyZXBsYWNlJyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYXMgJ3JlbW92ZScsIEkgY2FuJ3QgcGVyc3VhZGUg dGhlbSwgOikgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgU28s SSB3YW50IHRvIGdldCBhIGNsYXJpZmljYXRpb24sDQp0aGFua3MuIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgeW91IGFyZSBib3Ro IHJpZ2h0IDstKSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IHRoZSByZXBsYWNlIGF0dHJpYnV0ZSBkb2VzIGhhdmUgdG8gYXBwZWFy IGluIGENCnN1YnRyZWUsIGJ1dCBhIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHN1YnRyZWUgbWF5IGJl PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFuIGVtcHR5IG5vZGUgKGlmIGl0IGlzIHNj aGVtYSB2YWxpZCkuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgc3RhcnQ6IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDtjb25maWcmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtmb28mZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmx0O2EmZ3Q7NDImbHQ7L2EmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2ZvbyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZuYnNwOyAmbHQ7L2NvbmZpZyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXBsYWNlIGZvbzogPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz cDsmbHQ7Y29uZmlnJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7Zm9vIG9wZXJhdGlvbj0mcXVvdDtyZXBsYWNlJnF1b3Q7DQovJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDsvY29uZmlnJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHJlc3VsdDogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJmx0O2NvbmZpZyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ZvbyAvJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDsvY29uZmlnJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSB0ZXh0IHNl ZW1zIHZlcnkgY2xlYXIgdG8gbWUuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgL2ZyYW5rIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQW5keSA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IEluIHlvdXIgZXhhbXBsZSwgdGhlICdmb28nIE1VU1QgYmUgYSBwcmVzZW5j ZSBjb250YWluZXI/DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFuZHkg Qmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQtNPaDQoyMDE0LTA2LTA3IDAyOjQz OjI4Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMjAxNC0wNi0wNyAwMjo0MyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyDK1bz+yMsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ILOty80gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZG91LndlaTFAenRlLmNvbS5jbiwgTmV0 Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDssDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyB4aWFvLnl1cWluZ0B6dGUuY29tLmNuLCB5ZS54dTFAenRlLmNvbS5jbg0KPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsg1vfM4iA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZTogW05ldGNvbmZdIFNvbWUgcXVlc3Rp b25zIGFib3V0IHRoZSB1c2FnZQ0Kb2YgJ29wZXJhdGlvbicgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgYXR0cmlidXRlIGluIGVkaXQtY29uZmlnIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBPbiBUaHUsIEp1biA1LCAyMDE0IGF0IDExOjE4IFBNLCAmbHQ7ZmVuZy5jaG9uZzMz QHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgYW5keSwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw O1RoYW5rcyBhIGxvdC4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwO0NhbiB5b3UgYW5zd2VyIHRoZSBmaXJzdCBxdWVzdGlvbj8NCidyZXBsYWNlJyBjYW4g YmUgdXNlZCA8YnI+DQomZ3Q7ICZndDsgYXMncmVtb3ZlJz8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgUmVhZCBS RkMgNjI0MSwgc2VjLiA3LjIgQXR0cmlidXRlcyBzZWN0aW9uLg0KPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgSXQgZXhwbGFpbnMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUg TkVUQ09ORg0KJmx0O2VkaXQtY29uZmlnJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBvcGVyYXRp b25zLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgL2ZyYW5rIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFuZHkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5 dW1hd29ya3MuY29tJmd0OyDQtNPaDQoyMDE0LTA2LTA1IDIzOjQ2OjUzOjxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7DQo8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDIwMTQtMDYtMDUgMjM6NDYgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IMrVvP7IyyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZmVuZy5jaG9u ZzMzQHp0ZS5jb20uY24sIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyCzrcvNIDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgeWUueHUxQHp0 ZS5jb20uY24sDQpkb3Uud2VpMUB6dGUuY29tLmNuPGJyPg0KJmd0OyAsIDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgeGlhby55dXFpbmdAenRlLmNvbS5jbiA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsg1vfM4iA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgUmU6IFtOZXRj b25mXSBTb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUNCnVzYWdlIG9mICdvcGVyYXRpb24nIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYXR0cmlidXRlIGluIGVkaXQtY29u ZmlnIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9uIFdlZCwg SnVuIDQsIDIwMTQgYXQgNjozNSBQTSwgJmx0O2ZlbmcuY2hvbmczM0B6dGUuY29tLmNuJmd0Ow0K d3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSGkgYWxsLCA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtJIGhh dmUgc29tZSBxdWVzdGlvbnMgYWJvdXQNCnRoZSB1c2FnZSBvZiAmbmJzcDsnb3BlcmF0aW9uJ2F0 dHJpYnV0ZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluIGVkaXQt Y29uZmlnLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsxLiAncmVwbGFjZScgYXR0cmlidXRlDQpjYW4gb25seSBiZSB1c2VkIHRvIHJlbW92ZSA8 YnI+DQomZ3Q7IGNvbmZpZ3VyYXRpb24/IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRm9yIGV4YW1wbGUsIHRoZQ0KcnBjIHJlcXVl c3QgbGlzdGVkIGJlbG93IGlzIHZhbGlkPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtycGMgbWVzc2FnZS1pZA0KPSAmcXVv dDsxMDEmcXVvdDsmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZWRpdC1jb25maWcm Z3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7Jmx0O3RhcmdldCZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3J1 bm5pbmcvJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7Jmx0Oy90 YXJnZXQmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsmbHQ7Y29u ZmlnJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7aW50ZXJmYWNlcyBvcGVyYXRpb249ICZxdW90O3JlcGxhY2UmcXVvdDsvJmd0Ow0KPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyZsdDsvY29uZmlnJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9lZGl0LWNvbmZpZyZndDsNCjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9ycGMmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsyLkhvdyB0byBwcm9jZXNzIG5lc3RlZA0Kb3BlcmF0aW9u IGF0dHJpYnV0ZT8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwO0ZvciBleGFtcGxlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0 O3JwYw0KbWVzc2FnZS1pZCA9ICZxdW90OzEwMSZxdW90OyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZsdDtlZGl0LWNvbmZpZyZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsmbHQ7dGFyZ2V0Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbHQ7cnVubmluZy8mZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsmbHQ7L3RhcmdldCZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyZsdDtjb25maWcmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtpbnRlcmZhY2VzJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtpbnRlcmZh Y2Ugb3BlcmF0aW9uPSAmcXVvdDttZXJnZSZxdW90OyZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7bmFtZSZndDtldGgwLzAvMCZsdDsvbmFtZSZndDsNCjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmbHQ7bXR1IG9wZXJhdGlvbj0NCiZxdW90O3JlbW92ZSZxdW90OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtlbmFibGVkJmd0O3RydWUmbHQ7L2VuYWxibGVkJmd0Ow0K PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbHQ7L2ludGVyZmFjZSZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0Oy9pbnRlcmZhY2VzJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7Jmx0Oy9jb25maWcmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7L2VkaXQtY29uZmlnJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3JwYyZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHNlcXVlbmNlIG9mDQpwcm9jZXNzIGlz IG1lcmdlIGludGVyZmFjZSBuYW1lIDxicj4NCiZndDsgJ2V0aDAvMC8wJyBhbmQgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyByZW1vdmUgbXR1IGFuZCBtZXJnZSBlbmFi bGVkIHRvICd0cnVlJw0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvciBtZXJnZQ0K aW50ZXJmYWNlIG5hbWUgPGJyPg0KJmd0OyAnZXRoMC8wLzAnIGFuZCA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1lcmdlIGVuYWJsZWQgdG8gJ3RydWUnIGFuZCByZW1v dmUgbXR1Pw0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0luIG90aGVyIHdvcmRzLA0KTkVUQ09ORiB3aWxsIHByb2Nlc3Mgb3V0ZXIg bGF5ZXIgb3BlcmF0aW9uIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Zmlyc3RseSBhbmQgcHJvY2VzcyBpbm5lciBsYXllciBvcGVyYXRpb24NCmxhdGVyLCBvciBwcm9j ZXNzIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgb3BlcmF0aW9ucyBp biBhY2NvcmRhbmNlIHdpdGggWE1MIHRyZWUNCnRyYXZlcnNhbCBvcmRlcj8gPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IFRoZXJlIGlzIG5vIHJlcXVpcmVkIHByb2Nlc3Npbmcgb3JkZXIuDQo8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEl0IGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFp bC4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBTb21lIHRoaW5ncyB0 byBjb25zaWRlcjogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz cDsgMSkgYWxsIG9wZXJhdGlvbnMgYXJlIGFnYWluc3QNCnRoZSB0YXJnZXQgZGF0YXN0b3JlIGF0 IDxicj4NCiZndDsgdGhlIHN0YXJ0IG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyB0aGUgb3BlcmF0aW9uIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7IDIpIHRoZSBvcGVyYXRpb25zIGFyZSBhbGwtb3Itbm9uZSwNCm5vdCBpbmNy ZW1lbnRhbCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAy YSkgdGhpcyBpbXBsaWVzIHRoYXQgY3JlYXRlDQp3aXRoaW4gZGVsZXRlLCBvciBkZWxldGUgd2l0 aGluIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgY3JlYXRlLCBpcyBh bHdheXMgYW4gZXJyb3IgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZWNhdXNlICdkYXRhLWV4aXN0cycNCm9yICdkYXRh LW1pc3NpbmcnIG11c3QgYmUgdHJ1ZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSW4geW91ciBl eGFtcGxlIHRoZXJlIGlzIG5vIHByb2JsZW0NCmJlY2F1c2UgJ3JlbW92ZScgPGJyPg0KJmd0OyB3 b3JrcyBldmVuIGlmIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgdGhl IGRhdGEgaXMgbWlzc2luZy4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMy4gSWYgb3RoZXIg b3BlcmF0aW9uIGF0dHJpYnV0ZSBuZXN0ZWQNCmluIG9wZXJhdGlvbiBhdHRyaWJ1dGUgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAncmVtb3ZlJyx3aGF0IHNob3VsZCBO RVRDT05GIHNlcnZlcg0KZG8/IE9ubHkgcHJvY2VzcyByZW1vdmUgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgb3BlcmF0aW9uPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDQuIENhbiBORVRD T05GIHN1cHBvcnQgdGhlIG5lc3RlZA0Kb3BlcmF0aW9uIGF0dHJpYnV0ZSBlcXVhbHMgdG8gPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBwYXJlbnQgb3BlcmF0aW9uIGF0 dHJpYnV0ZT8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IC9m cmFuayA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQW5keSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZQ0KaW5mb3JtYXRpb24gPGJyPg0KJmd0OyBjb250YWluZWQgaW4gdGhpcyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1haWwgKGFuZCBhbnkgYXR0 YWNobWVudCB0cmFuc21pdHRlZA0KaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlDQpleGNsdXNpdmUgdXNlIG9mIDxicj4NCiZndDsgdGhlIGFkZHJlc3NlZTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgKHMpLiAmbmJzcDtJZiB5b3Ug YXJlIG5vdCBhbiBpbnRlbmRlZA0KcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlv biBvciBvdGhlcg0KZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuDQombmJzcDtJZiB5b3UgPGJyPg0KJmd0OyBoYXZlcmVjZWl2ZWQgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQNCmFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgTmV0Y29uZiBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5ldGNvbmZA aWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvZm9udD48 L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m Pjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uDQpj b250YWluZWQgaW4gdGhpcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBtYWls IChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpDQppcyBwcml2aWxlZ2Vk IGFuZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBjb25maWRlbnRpYWwgYW5k IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlDQp1c2Ugb2YgdGhlIGFkZHJlc3NlZTxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3Qg YW4gaW50ZW5kZWQgcmVjaXBpZW50LA0KYW55IGRpc2Nsb3N1cmUsIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRp c3NlbWluYXRpb24NCm9yIHVzZSBvZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuDQombmJz cDtJZiB5b3UgaGF2ZXJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQNCm5vdGlmeSB1cyBpbW1l ZGlhdGVseS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uDQpjb250YWluZWQgaW4gdGhp cyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50 IHRyYW5zbWl0dGVkIGhlcmV3aXRoKQ0KaXMgcHJpdmlsZWdlZCBhbmQgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNs dXNpdmUNCnVzZSBvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LA0KYW55IGRp c2Nsb3N1cmUsIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXByb2R1Y3Rpb24sIGRp c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uDQpvciB1c2Ugb2YgdGhlIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4NCiZuYnNwO0lmIHlvdSBoYXZlIHJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5v dGlmeQ0KdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZA0KaW4gdGhpcyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJl d2l0aCkgaXMgcHJpdmlsZWdlZA0KYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgY29uZmlk ZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2UNCm9mIHRoZSBhZGRy ZXNzZWU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3Qg YW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkNCmRpc2Nsb3N1cmUsIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlv biBvcg0KdXNlIG9mIHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAmbmJzcDtJZg0KeW91IGhhdmUgcmVjZWl2 ZWQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBk ZWxldGUgaXQgYW5kIG5vdGlmeSB1cw0KaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkDQppbiB0aGlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7 IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmls ZWdlZA0KYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5k ZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLA0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmli dXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2UNCm9mIHRoZSA8YnI+DQomZ3Q7ICZn dDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gJm5i c3A7SWYgeW91DQpoYXZlIHJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoaXMgbWFpbCBp biBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCiZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluDQp0aGlzIDxicj4NCiZndDsgJmd0OyBtYWlsIChhbmQgYW55 IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQNCmFuZCA8YnI+ DQomZ3Q7ICZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZTxicj4NCiZndDsgJmd0OyAocykuICZuYnNwO0lmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsDQo8YnI+DQomZ3Q7 ICZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBv ciB1c2Ugb2YgdGhlDQo8YnI+DQomZ3Q7ICZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlDQpyZWNlaXZlZCA8YnI+DQomZ3Q7 ICZndDsgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCjxicj4NCiZn dDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2 aWxlZ2VkIGFuZCA8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWU8YnI+DQomZ3Q7IChzKS4gJm5ic3A7SWYg eW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgPGJyPg0K Jmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9y IHVzZSBvZiB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQNCjxicj4NCiZndDsgdGhpcyBt YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHku PGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJs dWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBh biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlh dGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 002257ED48257CF3_=-- From nobody Tue Jun 10 03:26:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C331A0503; Tue, 10 Jun 2014 03:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj6bTkPykOxs; Tue, 10 Jun 2014 03:26:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BF51A0035; Tue, 10 Jun 2014 03:26:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFG50078; Tue, 10 Jun 2014 10:26:45 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 11:26:28 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 18:26:24 +0800 From: Qin Wu To: "netmod@ietf.org" , "netconf@ietf.org" Thread-Topic: Introduction to TIME Mailing List Thread-Index: Ac+Ed/EqiWfsJ33vSgy5XLhDzjJJGgAHeClg Date: Tue, 10 Jun 2014 10:26:23 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/isAkNG8XjtBS6o7j9EefSa05_q0 Subject: Re: [Netconf] Introduction to TIME Mailing List X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 10:26:49 -0000 --_004_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_ Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_" --_000_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RllJLg0KDQq3orz+yMs6IFRpbWUgW21haWx0bzp0aW1lLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g UWluIFd1DQq3osvNyrG85DogMjAxNMTqNtTCMTDI1SAxNDo0OA0KytW8/sjLOiB0aW1lQGlldGYu b3JnDQqzrcvNOiBSb21hc2NhbnUsIERhbiAoRGFuKTsgTWlzaGFlbCBXZXhsZXINCtb3zOI6IFtU aW1lXSBJbnRyb2R1Y3Rpb24gdG8gVElNRSBNYWlsaW5nIExpc3QNCg0KRGVhciBhbGwsDQoNCg0K VGhpcyBpcyB0byBpbnRyb2R1Y2UgdGhlIFRJTUUgbWFpbGluZyBsaXN0LiBUSU1FIHN0YW5kcyBm b3IgobBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgT0FNIGluIE11bHRpLUxheWVyIE5ldHdvcmsgRW50 aXR5obEgLg0KDQoNClRoaXMgbWFpbGluZyBsaXN0IGlzIG5ld2x5IGNyZWF0ZWQgYXMgYSByZXN1 bHQgb2YgYSBCT0YgcmVxdWVzdCBwcm9wb3NhbCB0byBPUFMgQXJlYSByZWNlbnRseS4gSGVyZSBp cyBhbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtIGluDQoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDAN CmFuZCB3ZSBhcmUgbG9va2luZyBmb3IgZGlzY3Vzc2lvbiBhbmQgZmVlZGJhY2sgb24gdGhpcyBs aXN0LCBhcyB3ZWxsIGFzIGV4cGVjdGluZyB0byBoYW1tZXIgb3V0IGEgY29uY3JldGUgc2NvcGUg YW5kIGdldCB0aGUgZmlyc3QgdmVyc2lvbiBvZiBkcmFmdA0KY2hhcnRlciBjb21pbmcgb3V0IHRo cm91Z2ggdGhpcyBkaXNjdXNzaW9uIC4NCg0KQmFja2dyb3VuZDoNCg0KICBUaGUgYmFzaWMgY29u Y2VwdHMgb2YgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZCBNYWludGVuYW5jZSAoT0FN KSBhbmQgdGhlDQogICBmdW5jdGlvbmFsIHJvbGVzIGluIG1vbml0b3JpbmcgYW5kIGRpYWdub3Np bmcgdGhlIGJlaGF2aW9yIG9mIHRlbGVjb21tdW5pY2F0aW9ucyBuZXR3b3Jrcw0KICAgaGF2ZSBi ZWVuIGxvbmcgdGVybSBzdHVkaWVkIGF0IHRoZSBMYXllciAxJjIgJiBMYXllciAzIGxldmVscy4g IFRoZSBjdXJyZW50IHByYWN0aWNlIGlzIHRoYXQNCiAgIG1hbnkgdGVjaG5vbG9naWVzIGFuZCBs YXllcnMgaGF2ZSB0aGVpciBvd24gT0FNIHByb3RvY29scy4gICBUaGVyZSBpcyBsaXR0bGUgb3Ig bm8NCiAgIHJlLXVzZSBvZiBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUgZm9yIGVhY2ggZXhpc3Rpbmcg T0FNIHByb3RvY29sLiBWZW5kb3JzIGFuZCBvcGVyYXRvcnMgd2FzdGUNCmEgbG90IHRocm91Z2gg dGhlIHdob2xlIE9BTSBsaWZlLWN5Y2xlIHdoZW4gYSBuZXcgdGVjaG5vbG9neSBpcyBpbnRyb2R1 Y2VkLiBJbnRlZ3JhdGlvbiBvZiBPQU0NCmFjcm9zcyBtdWx0aXBsZSB0ZWNobm9sb2dpZXMgaXMg ZXh0cmVtZWx5IGRpZmZpY3VsdC4gV2hlbiBoYXZpbmcgbmV0d29ya3Mgd2l0aCBtb3JlIHRoYW4g b25lIHRlY2hub2xvZ3ksDQptYWludGVuYW5jZSBhbmQgdHJvdWJsZXNob290aW5nIGFyZSBkb25l IHBlciB0ZWNobm9sb2d5DQogICBhbmQgbGF5ZXIsIG9wZXJhdGlvbiBwcm9jZXNzIGNhbiBiZSB2 ZXJ5IGN1bWJlcnNvbWUuIEluIG1hbnkgY2FzZXMgaXQgaXMgZGVzaXJhYmxlIHRvIGhhdmUgYQ0K ICAgZ2VuZXJpYyBPQU0gdG8gY292ZXIgaGV0ZXJvZ2VuZW91cyBuZXR3b3JraW5nIHRlY2hub2xv Z2llcy4gR2VuZXJpYyBPQU0gdG9vbHMgc2hvdWxkIGJlDQogICBkZXBsb3llZCBvdmVyIHZhcmlv dXMgZW5jYXBzdWxhdGluZyBwcm90b2NvbHMsIGFuZCBpbiB2YXJpb3VzIG1lZGl1bSB0eXBlcy4N Cg0KICAgQW4gZXhhbXBsZSBvZiBhbiBlbnZpcm9ubWVudCBpbiB3aGljaCBhIGdlbmVyaWMgYW5k IGludGVncmF0ZWQgT0FNIHByb3RvY29sIHdvdWxkIGJlDQogICB2YWx1YWJsZSBpcyBTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5nLiBBIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgaXMgY29tcG9z ZWQgYnkgYSBzZXJpZXMgb2YNCiAgIHNlcnZpY2UgRnVuY3Rpb25zLCB0aGF0IGNhbiBhY3QgaW4g ZGlmZmVyZW50IGxheWVycyBidXQgcHJvdmlkaW5nIGFuIGVuZC10by1lbmQgY2hhaW4gb3IgcGF0 aA0KICAgZnJvbSBhIHNvdXJjZSB0byBkZXN0aW5hdGlvbiBpbiBhIGdpdmVuIG9yZGVyLiAgSW4g c2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBFbnZpcm9ubWVudCwgaXQgaXMNCiAgIG5lY2Vzc2Fy eSB0byBwcm92aWRlIGVuZCB0byBlbmQgT0FNIGFjcm9zcyBjZXJ0YWluIG9yIGFsbCBlbnRpdGll cyBhbmQgaW52b2x2aW5nIG1hbnkgbGF5ZXJzLg0KICAgT0FNIGluZm9ybWF0aW9uIHNob3VsZCBi ZSBleGNoYW5nZWQgYmV0d2VlbiBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgbGF5ZXJz IHdoaWxlDQogICB1c2luZyB2YXJpb3VzIGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2xzLiAgSW4gc29t ZSBjYXNlcyBPQU0gc2hvdWxkIGNyb3NzIGRpZmZlcmVudA0KICAgYWRtaW5pc3RyYXRpb24gYW5k L29yIG1haW50ZW5hbmNlIGRvbWFpbnMuDQoNClRoZSBwdXJwb3NlIG9mIHRoZSBsaXN0Og0KDQog ICAxLnVuZGVyc3RhbmRpbmcgYW5kIGRpc2N1c3NpbmcgdGhlIHRpbWVzIHdoZW4gYW4gT0FNDQog ICBwcm90b2NvbCBjYW4gYmUgdHVuZWQgYW5kIG9wdGltaXNlZCBmb3IgYSBzcGVjaWZpYyBkYXRh IHBsYW5lIChmb3IgZXhhbXBsZSwgT0FNIGluIGEgcGFja2V0DQogICBuZXR3b3JrIGNhbiBiZSB2 ZXJ5IGRpZmZlcmVudCBmcm9tIE9BTSBpbiBhIGNpcmN1aXQgc3dpdGNoZWQgbmV0d29yayBiZWNh dXNlIG9mIHRoZQ0KICAgZGlmZmVyZW50IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbmV0d29yaykN Cg0KMi5hbmQgc2Vla2luZyB0aGUgYmVzdCB3YXlzOg0KDQogICAgICAgIE8gRXhjaGFuZ2UgT0FN IGluZm9ybWF0aW9uIGF0IHRoZSBzZXJ2aWNlIGxheWVyIGF0b3Agb2YgbGF5ZXIgMw0KDQpPIEFi c3RyYWN0IE9BTSBpbmZvcm1hdGlvbiBjb21tb24gdG8gZGlmZmVyZW50IGxheWVyDQoNCk8gUHJv dmlkZSB0aGVtIHZpYSB1bmlmaWVkIGludGVyZmFjZSB0byBtYW5hZ2VtZW50IGVudGl0aWVzLg0K DQpPIFNldCB1cCBNYWludGVuYW5jZSBEb21haW5zIChNRCkgYW5kIE1haW50ZW5hbmNlIEludGVy bWVkaWF0ZSBQb2ludHMgKE1JUCkNCg0KTyBFbmFibGUgT0FNIGZ1bmN0aW9uIGF0IGRpZmZlcmVu dCBsYXllciBpbiB0aGUgbXVsdGktbGF5ZXIgbmV0d29yaw0KDQpPIEFjdGl2YXRlIE9BTSBmdW5j dGlvbiBhIGRpZmZlcmVudCBsYXllciBhbmQgcHJvdmlkZSByZXN1bHRzIHRvIG1hbmFnZW1lbnQg ZW50aXR5DQoNClRoaXMgbWFpbGluZyBsaXN0IGlzIGludGVuZGVkIHRvIGVuYWJsZSBkaXNjdXNz aW9uIG9mIHRoZSBhcmNoaXRlY3R1cmUsIHVzZS1jYXNlcy9hcHBsaWNhYmlsaXR5LCBhbmQNCnJl cXVpcmVtZW50cyB0aGF0IHByb3ZpZGUgZ2VuZXJpYyBhbmQgaW50ZWdyYXRlZCBPQU0gY292ZXJp bmcgdmFyaW91cyBoZXRlcm9nZW5lb3VzIG5ldHdvcmsgdGVjaG5vbG9naWVzLg0KDQpPIEFuYWx5 c2UgYW5kIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudCBtb3RpdmF0aW9ucyBhbmQgb3Bwb3J0dW5p dGllcyBmb3Igb3B0aW1pc2F0aW9uIG9mIE9BTSBpbiBkaWZmZXJlbnQNCnRlY2hub2xvZ3kgbmV0 d29ya3MsIGFuZCB0aGUgdHJhZGUtb2ZmcyBiZXR3ZWVuIHRob3NlIG9wdGltaXNhdGlvbnMgYW5k IHRoZQ0KIG92ZXJhbGwgYWR2YW50YWdlIG9mIGEgZ2VuZXJpYyBPQU0gbWVjaGFuaXNtLg0KDQpP IFNldCBvdXQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCBhcmNoaXRlY3R1cmUgZm9yIHRoZQ0K ICAgICBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgT0FNIGluIHRoZSBtdWx0aS1sYXllciBuZXR3b3Jr IGFuZCBvdXRsaW5lcyB0aGUgcHJvYmxlbXMNCiAgICAgZW5jb3VudGVyZWQgd2l0aCBleGlzdGlu ZyBPQU0gcHJvdG9jb2wgdmFyaWV0eSBhbmQgdGhlaXIgaW1wYWN0IG9uIGludHJvZHVjdGlvbiBv ZiBuZXcgdGVjaG5vbG9naWVzLg0KDQpZb3UgY2FuIHN1YnNjcmliZSB0byB0aGUgbGlzdCBhdDog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aW1lLg0KDQoNClRvIHBvc3Qg YSBtZXNzYWdlIHRvIGFsbCB0aGUgbGlzdCBtZW1iZXJzLCBzZW5kIGVtYWlsIHRvIHRpbWUgYXQg aWV0Zi5vcmcuDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpRaW4mRGFuDQo= --_000_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

FYI.

&n= bsp;

=B7=A2=BC=FE=C8=CB: Time [mailto:time-bounces@ietf.org] =B4=FA= =B1=ED Qin Wu
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C210=C8=D5 14:48
=CA=D5=BC=FE=C8=CB: time@ietf.org
=B3=AD=CB=CD: Romascanu, Dan (Dan); Mishael Wexler
=D6=F7=CC=E2: [Time] Introduction to TIME Mailing List

 

Dear all,

 

 

This is to introduce the TIME m= ailing list. TIME stands for =A1=B0Transport Independent OAM in Multi-Layer= Network Entity=A1=B1 .

 

This mailing list is newly c= reated as a result of a BOF request proposal to OPS Area recently. Here is = an initial description of the problem in

https://datatracker.iet= f.org/doc/draft-ww-opsawg-multi-layer-oam-00

and we are looking for discussi= on and feedback on this list, as well as expecting to hammer out a concrete= scope and get the first version of draft

charter coming out through this= discussion .

 

Background:

 

  The basic concepts of Op= erations, Administration, and Maintenance (OAM) and the

   functional roles i= n monitoring and diagnosing the behavior of telecommunications networks

   have been lon= g term studied at the Layer 1&2 & Layer 3 levels.  The current= practice is that

   many technolo= gies and layers have their own OAM protocols.   There is little o= r no

   re-use of software= and hardware for each existing OAM protocol. Vendors and operators waste

a= lot through the whole OAM life-cycle when a new technology is introduced. = Integration of OAM

a= cross multiple technologies is extremely difficult. When having networks wi= th more than one technology,

m= aintenance and troubleshooting are done per technology

   and layer, operati= on process can be very cumbersome. In many cases it is desirable to have a

   generic OAM t= o cover heterogeneous networking technologies. Generic OAM tools should be<= o:p>

   deployed over vari= ous encapsulating protocols, and in various medium types.=

 

   An example of an e= nvironment in which a generic and integrated OAM protocol would be

   valuable is S= ervice Function Chaining. A Service Function Chaining is composed by a seri= es of

   service Functions,= that can act in different layers but providing an end-to-end chain or path=

   from a source to d= estination in a given order.  In service function chaining Environment= , it is

   necessary to provi= de end to end OAM across certain or all entities and involving many layers.=  

   OAM informati= on should be exchanged between service functions in different layers while

   using various= encapsulating protocols.  In some cases OAM should cross different

   administratio= n and/or maintenance domains.

 

The purpose of the list:

 

   1.understanding an= d discussing the times when an OAM

   protocol can = be tuned and optimised for a specific data plane (for example, OAM in a pac= ket

   network can b= e very different from OAM in a circuit switched network because of the

   different cha= racteristics of the network)

 

2= .and seeking the best ways:

<= o:p> 

      =   O Exchange OAM information at the service layer atop of layer 3

 

O = Abstract OAM information common to different layer

 

O = Provide them via unified interface to management entities.

 

O = Set up Maintenance Domains (MD) and Maintenance Intermediate Points (MIP)

 

O = Enable OAM function at different layer in the multi-layer network

 

O = Activate OAM function a different layer and provide results to management e= ntity

 

This mailing list is intended t= o enable discussion of the architecture, use-cases/applicability, and

requirements that provide gener= ic and integrated OAM covering various heterogeneous network technologies.<= o:p>

 

O = Analyse and understand the different motivations and opportunities for opti= misation of OAM in different

te= chnology networks, and the trade-offs between those optimisations and the

&n= bsp;overall advantage of a generic OAM mechanism.

 

O = Set out the problem statement and architecture for the

     Transp= ort Independent OAM in the multi-layer network and outlines the problems

     encoun= tered with existing OAM protocol variety and their impact on introduction o= f new technologies.

 

You can subscribe to the list a= t: https://www.ietf.org/mailman/listinfo/time.

 

 

To post a message to all the li= st members, send email to time at ietf.org.

 

 

Best Regards,=

 

Qin&Dan

--_000_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_-- --_004_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Tue, 10 Jun 2014 07:00:08 GMT"; modification-date="Tue, 10 Jun 2014 07:00:08 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRpbWUgbWFp bGluZyBsaXN0DQpUaW1lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RpbWUNCg== --_004_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_-- From nobody Tue Jun 10 18:25:11 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752061A0252 for ; Tue, 10 Jun 2014 18:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPjkgX_xj-wG for ; Tue, 10 Jun 2014 18:25:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293111A0296 for ; Tue, 10 Jun 2014 18:25:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIH15749; Wed, 11 Jun 2014 01:25:03 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 02:25:02 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 11 Jun 2014 09:24:51 +0800 From: "Liubing (Leo)" To: "feng.chong33@zte.com.cn" Thread-Topic: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt Thread-Index: AQHPf97ZguH8jW6EdUWevnlZT6o6DptgjqiAgAEk+lCABhkfgIADVtgA Date: Wed, 11 Jun 2014 01:24:51 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25Fnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/87PAsjFMqSWkK9HNblqd6fXsv_4 Cc: Zhengguangying , Yangshouchuan , Netconf , Yangang Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 01:25:09 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25Fnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQ2hvbmcgJiBhbGwsDQoNCj5XaGF0J3MgeW91ciBwcm9ibGVtPyBOTVMgd2FudHMgdG8gZ2V0 IGEgcGFydGljdWxhciByZXN1bHQsDQo+YnV0IHNlcnZlciByZXR1cm5zIHRvbyBsYXJnZSByZXN1 bHQ/DQo+V2h5IG5vdCB1c2Ugc3VidHJlZSBmaWx0ZXIsIFhQQVRIIGZpbHRlciBvciBjbGllbnQn cyAiaXRlcmF0b3IiIGluIGFuZHkncyBwcm9wb3NhbD8NCg0KPkkgdGhpbmsgdGhlIHByb2JsZW0g aXMgdGhhdCBOTVMgd2FudHMgdG8gZ2V0IGEgdmVyeSBsYXJnZSBkYXRhLCBidXQgdGhleSBkb24n dCB3YW50IHRvIG9yIGNhbid0IHBhcnNlIHRvbyBsYXJnZSB4bWwgcmVwc29uc2UuDQoNClBsZWFz ZSBwYXJkb24gbWUgcmVwZWF0aW5nIHRoZSBpc3N1ZXMuDQpMZXQgbWUgY2xlYXJseSBzZXBhcmF0 ZSB0aGUgUHJvYmxlbSBhbmQgU29sdXRpb25zIGFzIHRoZSBmb2xsb3dpbmcuDQoNCi0gUHJvYmxl bSB0byBiZSBzb2x2ZWQ6DQplaXRoZXIgdGhlIE5NUyB3YW50cyB0byBnZXQgYSBwYXJ0aWN1bGFy IHJlc3VsdCwgb3IgZ2V0IGEgdmVyeSBsYXJnZSBkYXRhIHN0b3JlLCB0aGUgcHJvYmxlbSBpcyB0 aGUgc2FtZTogaG93IGRvIHRoZSBjbGllbnQgYW5kIHNlcnZlciBoYW5kbGUgdGhlIGxhcmdlIHJl c3BvbnNlPyBIb3dldmVyLCB0aGUgbGF0dGVyIHNob3VsZCBiZSB0aGUgdHlwaWNhbCB1c2UgY2Fz ZS4NCg0KLSBFeGlzdGluZyBzb2x1dGlvbnM6DQoxLiBTdHJlYW0tb3JpZW50ZWQgcHJvY2Vzc2lu Zy4gQXMgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCwgb25lIGJpZyBpc3N1ZSBpcyB0aGF0IGl0IGxh Y2tzIHRoZSBhYmlsaXR5IG9mIGNhbmNlbGluZyB0aGUgb25nb2luZyBwcm9jZXNzaW5nLg0KMi4g U3VidHJlZS9YUGF0aCBmaWx0ZXJpbmcuIFRoZSBwcm9ibGVtIGlzLCB0aGUgZmlsdGVyZWQgcmVz dWx0cyBtaWdodCBzdGlsbCBsYXJnZS4NCg0KLSBOZXcgcHJvcG9zZWQgc29sdXRpb25zOg0KMS4g PGdldC1ibG9jaz4gZXh0ZW5zaW9uLCB3aGljaCBpcyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQNCjIu IDxnZXQtbGlzdD4gZXh0ZW5zaW9uLCB3aGljaCBpcyBwcm9wb3NlZCBkdXJpbmcgcmVjZW50IG1h aWxpbmcgbGlzdCBkaXNjdXNzaW9uDQoNClNvIG1heSBJIGFzayBDaG9uZyBhbmQgdGhlIFdHLCBk byB5b3UgYWdyZWUgdGhlIKGwRXhpc3Rpbmcgc29sdXRpb25zobEgYXJlIE5PVCBzdWZmaWNpZW50 IGVub3VnaCB0byBzb2x2ZSB0aGUgcHJvYmxlbSwgc28gdGhhdCB3ZSBuZWVkIGEgTkVXIHNvbHV0 aW9uIChyZWdhcmRsZXNzIG9mIHdoaWNoIHNvbHV0aW9uIHRvIGNob29zZSk/DQoNCkZvciB0aGUg c29sdXRpb24sIG5vdyB0aGUgcG9pbnQgaXMgc3RhdGVmdWwgb3Igc3RhdGVsZXNzLCB3ZaGvZCBi ZSBnbGFkIHRvIGhhdmUgZnVydGhlciBkaXNjdXNzaW9uIGluIGRlcHRoLCBidXQgd2Whr2QgbGlr ZSB0byBjb25maXJtIHRoZSBwcm9ibGVtIGZpcnN0Lg0KDQpNYW55IHRoYW5rcy4NCg0KQmVzdCBy ZWdhcmRzLA0KQmluZw0KDQpGcm9tOiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiBbbWFpbHRvOmZl bmcuY2hvbmczM0B6dGUuY29tLmNuXQ0KU2VudDogTW9uZGF5LCBKdW5lIDA5LCAyMDE0IDI6MDkg UE0NClRvOiBMaXViaW5nIChMZW8pDQpDYzogY2hvbmcgZmVuZzsgTmV0Y29uZjsgTmV0Y29uZjsg WWFuZ2FuZzsgWWFuZ3Nob3VjaHVhbjsgWmhlbmdndWFuZ3lpbmcNClN1YmplY3Q6IFJlOiBbTmV0 Y29uZl0gTmV0Y29uZiBmcmFnbWVudGF0aW9uLS8vRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0wMC50eHQNCg0KSGksDQogIFdo YXQncyB5b3VyIHByb2JsZW0/IE5NUyB3YW50cyB0byBnZXQgYSBwYXJ0aWN1bGFyIHJlc3VsdCwg YnV0IHNlcnZlciByZXR1cm5zIHRvbyBsYXJnZSByZXN1bHQ/DQogIFdoeSBub3QgdXNlIHN1YnRy ZWUgZmlsdGVyLCBYUEFUSCBmaWx0ZXIgb3IgY2xpZW50J3MgIml0ZXJhdG9yIiBpbiBhbmR5J3Mg cHJvcG9zYWw/DQoNCiAgSSB0aGluayB0aGUgcHJvYmxlbSBpcyB0aGF0IE5NUyB3YW50cyB0byBn ZXQgYSB2ZXJ5IGxhcmdlIGRhdGEsIGJ1dCB0aGV5IGRvbid0IHdhbnQgdG8gb3IgY2FuJ3QgcGFy c2UgdG9vIGxhcmdlIHhtbCByZXBzb25zZS4NCg0KICBUaGVyZSBhcmUgMiBzb2x1dGlvbnMgdG8g c29sdmUgaXQuIChJIGhhdmUgZGV2ZWxvcGVkIHRoZSBib3RoIG1hbnkgeWVhcnMgYWdvLDotKSkN Cg0KICBUaGUgZmlyc3QgaXMgeW91ciBzb2x1dGlvbi4gc2VydmVyIGtlZXAgYnJlYWsgcG9pbnRz IGFuZCB3YWl0IGZvciBjbGllbnQncyByZXF1ZXN0IHRvIGdldCB0aGUgbmV4dCBmcmFnbWVudC4g VGhpcyBzb2x1dGlvbiBoYXZlDQogIDIgbWFpbiBwcm9ibGVtcy4gVGhlIGZvcm1lciBpcyB0aGUg c2V2ZXIgbXVzdCBiZSBzdGF0ZWZ1bCBhbmQgdGhlIHN0YXRlIGlzIGhlbGQgYnkgY2xpZW50LiBJ dCdzIG5vdCBhIGdvb2QgZGVzaWduIHBhdHRlcm4gaW4gQy9TIGFyY2hpdGVjdHVyZS4NCiAgVGhl IGxhdHRlciBpcyBpZiBjbGllbnQgc2VuZCBtYW55IHJlcXVlc3RzIHRvIHJldHJpZXZlIGxhcmdl IGRhdGEsIHRoZSBzZXZlciBoYXZlIHRvIGtlZXAgbWFueSBicmVhayBwb2ludHMsIGl0J3MgdG9v IGhlYXZ5IGZvciBzZXJ2ZXIuDQoNCiAgVGhlIHNlY29uZCBpcyAiaXRlcmF0b3IiIHRoYXQgYW5k eSBwcm9wb3NlLiBJZiByZXNwb25zZSBkYXRhIGlzIHRvbyBsYXJnZSwgY2xpZW50IGNhbiBzZW5k IGEgcmVxdWVzdCB0byBnZXQgdGhlIHNwZWNpYWwgcGFydCBvZiB0aGUgZGF0YSxlLmcgMjUgaW5z dGFuY2VzIG9mIHRoZSBsaXN0LA0KICBhbmQgc2VuZCBhIG5leHQgcmVxdWVzdCB0byBnZXQgdGhl IG5leHQgcGFydC4gU2V2ZXIgZG9lcyBub3QgbmVlZCB0byBrZWVwIGFueSBicmVhayBwb2ludHMu DQogIEkgdGhpbmsgdGhpcyBzb2x1dGlvbiBpcyBiZXR0ZXIgdGhhbiB5b3Vycy4gQnV0IGlmIHRo ZXJlIGlzIG5lc3RlZCBsaXN0LCB0aGUgcHJvY2VzcyBpcyBub3Qgc2ltcGxlIGFzIGFuZHkncyBl eGFtcGxlLg0KDQovZnJhbmsNCg0KIk5ldGNvbmYiIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4+INC009ogMjAxNC0wNi0wNSAxNzo1ODo1 NjoNCg0KPiAiTGl1YmluZyAoTGVvKSIgPGxlby5saXViaW5nQGh1YXdlaS5jb208bWFpbHRvOmxl by5saXViaW5nQGh1YXdlaS5jb20+Pg0KPiC3orz+yMs6ICAiTmV0Y29uZiIgPG5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPj4NCj4NCj4gMjAx NC0wNi0wNSAxNzo1OA0KPg0KPiDK1bz+yMsNCj4NCj4gY2hvbmcgZmVuZyA8ZmVuZ2Nob25nbGxs eUBnbWFpbC5jb208bWFpbHRvOmZlbmdjaG9uZ2xsbHlAZ21haWwuY29tPj4sDQo+DQo+ILOty80N Cj4NCj4gWmhlbmdndWFuZ3lpbmcgPHpoZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb208bWFpbHRvOnpo ZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb20+PiwgWWFuZ3Nob3VjaHVhbg0KPiA8eWFuZ3Nob3VjaHVh bkBodWF3ZWkuY29tPG1haWx0bzp5YW5nc2hvdWNodWFuQGh1YXdlaS5jb20+PiwgTmV0Y29uZiA8 bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+LCBZYW5nYW5nDQo+IDx5 YW5nYW5nQGh1YXdlaS5jb208bWFpbHRvOnlhbmdhbmdAaHVhd2VpLmNvbT4+DQo+DQo+INb3zOIN Cj4NCj4gUmU6IFtOZXRjb25mXSBOZXRjb25mIGZyYWdtZW50YXRpb24tLy9GVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uDQo+IGZvciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAw LnR4dA0KPg0KPiBIaSBDaG9uZywNCj4NCj4gVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29t bWVudHMuIFBsZWFzZSBzZWUgcmVwbGllcyBpbmxpbmUuDQo+DQo+IEZyb206IGNob25nIGZlbmcg W21haWx0bzpmZW5nY2hvbmdsbGx5QGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBKdW5l IDA0LCAyMDE0IDExOjMzIFBNDQo+IFRvOiBMaXViaW5nIChMZW8pDQo+IENjOiBOZXRjb25mOyBa aGVuZ2d1YW5neWluZzsgWWFuZ2FuZw0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIE5ldGNvbmYg ZnJhZ21lbnRhdGlvbi0vL0ZXOiBOZXcgVmVyc2lvbg0KPiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWxpdS1uZXRjb25mLWZyYWdtZW50YXRpb24tMDAudHh0DQo+DQo+IEhpLA0KPiAgICBJIGhhdmUg cmV2aWV3ZWQgdGhpcyBuZXcgZHJhZnQuDQo+ICAgIEkgdW5kZXJzdGFuZCB5b3VyIHNvbHV0aW9u IGlzIHRoYXQgTkVUQ09ORiBzZXJ2ZXIgcmVzZXJ2ZSBicmVhaw0KPiBwb2ludHMgYW5kIHdhaXQg Zm9yIGNsaWVudCB0byByZXRyaWV2ZSB0aGUgbmV4dCByZXNwb25zZS4NCj4gSSB0aGluayBpdCdz IG5vdCBhIGdvb2Qgc29sdXRpb24sIGJlY2F1c2Ugc2VydmVyIG1heSBuZWVkIHRvIHJlc2VydmUN Cj4gbWFueSBicmVhayBwb2ludHMgaWYgdGhlcmUgYSBsYXJnZSBudW1iZXIgb2YgY29uY3VycmVu dCByZXF1ZXN0cy4NCj4gSXQncyB0b28gaGVhdnkgZm9yIHNlcnZlci4gQW5kLCB0aGUgc2VydmVy IG11c3QgYmUgc3RhdGVmdWwgaWYgaXQNCj4gc3VwcG9ydCBnZXQtYmxvY2sgY2FwYWJpbGl0eS4N Cj4gW0JpbmddIFRoZSBicmVhayBwb2ludCBkZXNpZ24gaXMgbWFpbmx5IGZvciB0aGUgaXNzdWUg b2YgdGVybWluYXRpbmcNCj4gdGhlIHJldHJpZXZpbmcgb3BlcmF0aW9uIGluc3RhbnRseS4gU28g YmVmb3JlIHRoaW5raW5nIG9mIHRoZSBkZXNpZ24NCj4gYXMgdG9vIGhlYXZ5IG9yIHdoYXQsIG1h eSBJIGFzayBkbyB5b3UgYWdyZWUgaXQgaXMgYSByZXF1aXJlbWVudA0KPiBuZWVkIHRvIGJlIHNv bHZlZD8NCj4NCj4gVGhlbiBmb3IgdGhlIKGwdG9vIGhlYXZ5obEgY29uc2lkZXJhdGlvbiwgSSBk b26hr3QgdGhpbmsgPGdldC1ibG9jaz4NCj4gd291bGQgYmUgd2lkZSB1c2VkIGFtb25nIG9wZXJh dGlvbnMsIG9ubHkgaWYgdGhlIHJldHJpZXZpbmcgZGF0YSBpcw0KPiB0b28gYmlnLiBTbyBiYXNp Y2FsbHkgSSBkb26hr3QgdGhpbmsgdGhlcmUgd291bGQgYmUgYSBsYXJnZSBudW1iZXIgb2YNCj4g Y29uY3VycmVudCByZXF1ZXN0cy4NCj4NCj4gVGhlIG90aGVyIHF1ZXN0aW9ucyBhbmQgY29tbWVu dHMgYXJlIGxpc3RlZCBiZWxvdzoNCj4gMS4gR2V0LWJsb2NrIGNhcGFiaWxpdHkgc2hvdWxkIG5v dCBjaGFuZ2UgdGhlIGdldC1jb25maWcgb3BlcmF0aW9uJ3MNCj4gYmVoYXZpb3IuIElmIGNsaWVu dCB1c2UgZ2V0LWNvbmZpZyBvcGVyYXRpb24gdG8gcmV0cmlldmUgZGF0YSwNCj4gYWxsIGRhdGEg bXVzdCBiZSBzZW50IGluIG9uZSByZXNwb25zZSBvciBnZXQtYmxvY2sgY2FwYWJpbGl0eSBzaG91 bGQNCj4gYWRkIGEgcGFyYW1ldGVyIHRvIGdldC1jb25maWcgb3BlcmF0aW9uIHRvIGluZGljYXRl IHRoZQ0KPiByZXNwb25zZSBkYXRhIHdpbGwgYmUgZnJhZ21lbnRlZC4NCj4gW0JpbmddIFllcywg Z2V0LWJsb2NrIGNhcGFiaWxpdHkgaXMgaW4gdXNlIG9ubHkgaWYgYm90aCBvZiB0aGUNCj4gY2xp ZW50IGFuZCBzZXJ2ZXIgc3VwcG9ydCB0aGUgY2FwYWJpbGl0eS4gQW5kIGluIGN1cnJlbnQgZGVz aWduLA0KPiA8Z2V0LWJsb2NrPiBpcyBkZWZpbmVkIGFzIGEgbmV3IG9wZXJhdGlvbiBhbG9uZyB3 aXRoIDxnZXQtY29uZmlnPi4NCj4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IGhhZCB0 aGUgYXNzdW1wdGlvbiB0aGF0IGl0IGlzIHRoZQ0KPiBzZXJ2ZXIgd2hvIHRyaWdnZXJzIHRoZSA8 Z2V0LWJsb2NrPiBvcGVyYXRpb24gaW4gYSByZXNwb25zZSB0byA8Z2V0LQ0KPiBjb25maWc+PyBJ ZiBzbywgSSB0aGluayBpdCBpcyBhIGdvb2QgcG9pbnQgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIu DQo+DQo+IDIuIEEgc2V0LWlkIGNhbiBiZSBhZ2VkPyB3aGVuIGNsaWVudCBuZXZlciBzZW5kIGEg cmVxdWVzdCB0bw0KPiByZXRyaWV2ZSB0aGUgbmV4dCBmcmFnbWVudCBmb3IgYSBsb25nIHRpbWUs IEkgdGhpbmsgdGhpcyBzZXQtaWQNCj4gc2hvdWxkIGJlIGFnZWQsDQo+IG90aGVyd2lzZSwgc2Vy dmVyIHdpbGwgYmUgcmVzZXJ2ZSBtb3JlIGFuZCBtb3JlIHNldC1pZHMuDQo+IDMuIEEgc2V0LWlk IGlzIHVuaXF1ZSBpbiBzZXNzaW9uIGxldmVsIG9yIHNlcnZlciBsZXZlbD8NCj4gNC4gSWYgYSBz ZXNzaW9uIGlzIGtpbGxlZCBvciBjbG9zZWQsIG90aGVyIHNlc3Npb24gY2FuIHJldHJpZXZlZCB0 aGUNCj4gbmV4dCBmcmFnbWVudCBpZiB0aGUgY2xpZW50IHByb3ZpZGUgdGhlIGNvcnJlY3Qgc2V0 LWlkPw0KPiBbQmluZ10gU2V0LWlkIGlzIHVzZWQgZm9yIGRpc3Rpbmd1aXNoaW5nIGZyYWdtZW50 cyBpbiBhIHNwZWNpZmljDQo+IHNlc3Npb24uIFNvIHdoZW4gdGhlIHNlc3Npb24gaXMga2lsbGVk LCB0aGUgc2V0LWlkcyBhcmUgaW52YWxpZCBhcyB3ZWxsLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+ IEJpbmcNCj4NCj4gL2ZyYW5rDQo+DQo+IDIwMTQtMDYtMDQgMTg6MjIgR01UKzA4OjAwIExpdWJp bmcgKExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb208bWFpbHRvOmxlby5saXViaW5nQGh1YXdl aS5jb20+PjoNCj4gSGkgYWxsLA0KPg0KPiBXZSd2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQsIHdoaWNo IGlzIGFib3V0IE5FVENPTkYgZGF0YSBmcmFnbWVudGF0aW9uLg0KPg0KPiBUaGUgYmFzaWMgaWRl YSBpcywgd2hlbiBOTVMgaXMgcmV0cmlldmluZyBhIGxhcmdlIHNpemUgb2YgZGF0YSBpbg0KPiB0 aGUgZGV2aWNlLCB0aGUgPHJwYy1yZXBseT4gbWlnaHQgYmUgdmVyeSBiaWcgKGUuZy4gdGhlIHJv dXRlcyBpbiBhDQo+IGNvcmUgcm91dGVyKS4NCj4gQ3VycmVudGx5IHRoZXJlIGFyZSBtYWlubHkg dHdvIG1ldGhvZHMgb2YgaGFuZGxpbmcgdGhlIGJpZyA8cnBjLQ0KPiByZXBseT46IG9uZSBpcyBz dHJlYW0tb3JpZW50ZWQgaGFuZGxpbmc7IHRoZSBvdGhlciBpcyBqdXN0IHJlcXVlc3QgYQ0KPiBw b3J0aW9uIG9mIHRoZSBkYXRhLg0KPg0KPiBUaGlzIGRyYWZ0IGNvbnNpZGVycyBib3RoIHRoZSB0 d28gbWV0aG9kcyBhcmUgcHJvYmxlbWF0aWMgaW4gc29tZQ0KPiBzaXR1YXRpb25zLCBhbmQgcHJv cG9zZXMgYSBuZXcgbWV0aG9kIHdoaWNoIGFsbG93cyB0aGUgbGFyZ2Ugc2l6ZQ0KPiA8cnBjLXJl cGx5PiB0byBiZSBmcmFnbWVudGVkIGluIE5FVENPTkYgbGV2ZWwuDQo+DQo+IFBsZWFzZSByZWFk IHRoZSBkcmFmdCBhbmQgY29tbWVudC4NCj4gTWFueSB0aGFua3MhDQo+DQo+IEJlc3QgcmVnYXJk cywNCj4gQmluZw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAw NCwgMjAxNCA1OjI3IFBNDQo+IFRvOiBMaXViaW5nIChMZW8pOyBMaXViaW5nIChMZW8pOyBaaGVu Z2d1YW5neWluZzsgWmhlbmdndWFuZ3lpbmcNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uLTAwLnR4dA0KPg0KPg0K PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LW5ldGNvbmYtZnJhZ21lbnRhdGlvbi0w MC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5nIExpdSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+DQo+IE5hbWU6ICAgICAgICAgICBkcmFm dC1saXUtbmV0Y29uZi1mcmFnbWVudGF0aW9uDQo+IFJldmlzaW9uOiAgICAgICAwMA0KPiBUaXRs ZTogICAgICAgICAgQSBORVRDT05GIEV4dGVuc2lvbiBmb3IgRGF0YSBGcmFnbWVudGF0aW9uDQo+ IERvY3VtZW50IGRhdGU6ICAyMDE0LTA2LTA0DQo+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCj4gUGFnZXM6ICAgICAgICAgIDEyDQo+IFVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtDQo+IG5ldGNvbmYtZnJh Z21lbnRhdGlvbi0wMC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1uZXRjb25mLQ0KPiBmcmFnbWVudGF0aW9uLw0KPiBIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LW5ldGNvbmYt ZnJhZ21lbnRhdGlvbi0wMA0KPg0KPg0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBp bnRyb2R1Y2VzIGFuIGV4dGVuc2lvbiB0byBORVRDT05GIChOZXR3b3JrDQo+ICAgIENvbmZpZ3Vy YXRpb24pIHByb3RvY29sLiBUaGUgZXh0ZW5zaW9uIGFsbG93cyBORVRDT05GIHRvIGhhbmRsZSBs YXJnZQ0KPiAgICBzaXplIGRhdGEgYXMgZnJhZ21lbnRlZCBSUEMgbWVzc2FnZXMuIFNwZWNpZmlj YWxseSwgdGhpcyBkb2N1bWVudA0KPiAgICBkZWZpbmVzIGEgbmV3IDxnZXQtYmxvY2s+IGNhcGFi aWxpdHkgYW5kIHJlbGV2YW50IG9wZXJhdGlvbnMgdG8NCj4gICAgaGFuZGxlIHRoZSBmcmFnbWVu dGF0aW9ucy4NCj4NCj4NCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn DQo+IC4NCj4NCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4g TmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiBO ZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQg YW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9m IHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQs IGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNz ZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KDQoNCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25Fnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Chong &= amp; all,

 = ;

>What's your problem? N= MS wants to get a particular result,

>but server returns too= large result?

>Why not use subtree fi= lter, XPATH filter or client's "iterator" in andy's proposal?

 

>I think the problem is= that NMS wants to get a very large data, but they don't want to or can't p= arse too large xml repsonse.

 = ;

Please par= don me repeating the issues.

Let me cle= arly separate the Problem and Solutions as the following.

 = ;

- Problem = to be solved:

either the= NMS wants to get a particular result, or get a very large data store, the = problem is the same: how do the client and server handle the large response? However, the latter should be the typical use case.

 = ;

- Existing= solutions:

1. Stream-= oriented processing. As discussed in the draft, one big issue is that it la= cks the ability of canceling the ongoing processing.

2. Subtree= /XPath filtering. The problem is, the filtered results might still large.

 = ;

- New prop= osed solutions:

1. <get= -block> extension, which is proposed in the draft

2. <get= -list> extension, which is proposed during recent mailing list discussio= n

 = ;

So may I a= sk Chong and the WG, do you agree the =A1=B0Existing solutions=A1=B1 are NO= T sufficient enough to solve the problem, so that we need a NEW solution (regardless of which solution to choose)?

 = ;

For the so= lution, now the point is stateful or stateless, we=A1=AFd be glad to have f= urther discussion in depth, but we=A1=AFd like to confirm the problem first.

 = ;

Many thank= s.

 = ;

Best regar= ds,

Bing

 = ;

From: feng.chong33@zte.com.cn [mailto:feng.chong33@zte.com.= cn]
Sent: Monday, June 09, 2014 2:09 PM
To: Liubing (Leo)
Cc: chong feng; Netconf; Netconf; Yangang; Yangshouchuan; Zhengguang= ying
Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notif= ication for draft-liu-netconf-fragmentation-00.txt

 

Hi,
  What's your problem? NMS wants to g= et a particular result, but server returns too large result?
  Why not use subtree filter, XPATH f= ilter or client's "iterator" in andy's proposal?

  I think the problem is that NMS wan= ts to get a very large data, but they don't want to or can't parse too larg= e xml repsonse.
 
  There are 2 solutions to solve it. = (I have developed the both many years ago,:-))
 
  The first is your solution. server = keep break points and wait for client's request to get the next fragment. T= his solution have
  2 main problems. The former is the = sever must be stateful and the state is held by client. It's not a good des= ign pattern in C/S architecture.
  The latter is if client send many r= equests to retrieve large data, the sever have to keep many break points, i= t's too heavy for server.

  The second is "iterator" = that andy propose. If response data is too large, client can send a request= to get the special part of the data,e.g 25 instances of the list,
  and send a next request to get the = next part. Sever does not need to keep any break points.
  I think this solution is better tha= n yours. But if there is nested list, the process is not simple as andy's e= xample.
 
/frank

"Netconf&qu= ot; <netconf-bounces@ietf.or= g> =D0=B4=D3=DA 2014-06-05 17:58:56:

> "Liubing (Leo)" <leo.liubing@huawei.com>
> =B7=A2=BC=FE=C8=CB:  "Netconf" <netconf-bounces@ietf.org>
>
> 2014-06-05 = 17:58
>
> =CA=D5=BC=FE=C8= =CB
>
> chong feng <fengchon= gllly@gmail.com>,
>
> =B3=AD=CB=CD
>
> Zhengguangying <zh= engguangying@huawei.com>, Yangshouchuan
> <yangshouchuan@huaw= ei.com>, Netconf <netconf@iet= f.org>, Yangang
> <yangang@huawei.com&g= t;
>
> =D6=F7=CC=E2
>
> Re: [Netconf] Netconf fragmentation-//FW: New Version Notification=
> for draft-liu-netconf-fragmentation-00.txt
>
> Hi Chong,
>  
> Thanks for = your review and comments. Please see replies inline.
>  
> From: chong= feng [mailto:fengchongllly@gmail.com= = ]
> Sent: Wednesday, June 04, 2014 11:33 PM
> To: Liubing (Leo)
> Cc: Netconf; Zhengguangying; Yangang
> Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version
> Notification for draft-liu-netconf-fragmentation-00.txt
>  
> Hi,<= /tt>
>   &nbs= p;I have reviewed this new draft.
>   &nbs= p;I understand your solution is that NETCONF server reserve break
> points and wait for client to retrieve the next response.
> I think it'= s not a good solution, because server may need to reserve
> many break points if there a large number of concurrent requests.<= /tt>
> It's too he= avy for server. And, the server must be stateful if it
> support get-block capability. > [Bing] The = break point design is mainly for the issue of terminating
> the retrieving operation instantly. So before thinking of the desi= gn
> as too heavy or what, may I ask do you agree it is a requirement <= /tt>
> need to be solved?
>  
> Then for th= e =A1=B0too heavy=A1=B1 consideration, I don=A1=AFt think <get-block>
> would be wide used among operations, only if the retrieving data i= s
> too big. So basically I don=A1=AFt think there would be a large nu= mber of
> concurrent requests.
>  
> The other q= uestions and comments are listed below:
> 1. Get-bloc= k capability should not change the get-config operation's
> behavior. If client use get-config operation to retrieve data,
> all data mu= st be sent in one response or get-block capability should
> add a parameter to get-config operation to indicate the
> response da= ta will be fragmented.
> [Bing] Yes,= get-block capability is in use only if both of the
> client and server support the capability. And in current design, <= /tt>
> <get-block> is defined as a new operation along with <get= -config>.
> If I unders= tand correctly, you had the assumption that it is the
> server who triggers the <get-block> operation in a response = to <get-
> config>? If so, I think it is a good point that we should consi= der.
>  
> 2. A set-id= can be aged? when client never send a request to
> retrieve the next fragment for a long time, I think this set-id
> should be aged,
> otherwise, = server will be reserve more and more set-ids.
> 3. A set-id= is unique in session level or server level?
> 4. If a ses= sion is killed or closed, other session can retrieved the
> next fragment if the client provide the correct set-id?
> [Bing] Set-= id is used for distinguishing fragments in a specific
> session. So when the session is killed, the set-ids are invalid as= well.
>  
> Best regard= s,
> Bing=
>  
> /frank
>  
> 2014-06-04 = 18:22 GMT+08:00 Liubing (Leo) <leo.liubing@huawei.com>:
> Hi all,
>
> We've posted a new draft, which is about NETCONF data fragmentatio= n.
>
> The basic idea is, when NMS is retrieving a large size of data in =
> the device, the <rpc-reply> might be very big (e.g. the rout= es in a
> core router).
> Currently there are mainly two methods of handling the big <rpc= -
> reply>: one is stream-oriented handling; the other is just requ= est a
> portion of the data.
>
> This draft considers both the two methods are problematic in some =
> situations, and proposes a new method which allows the large size =
> <rpc-reply> to be fragmented in NETCONF level.
>
> Please read the draft and comment.
> Many thanks!
>
> Best regards,
> Bing
>
> -----Original Message-----
> From: internet-drafts@= ietf.org [mailto:internet-drafts= @ietf.org]
> Sent: Wednesday, June 04, 2014 5:27 PM
> To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying
> Subject: New Version Notification for draft-liu-netconf-fragmentat= ion-00.txt
>
>
> A new version of I-D, draft-liu-netconf-fragmentation-00.txt<= br> > has been successfully submitted by Bing Liu and posted to the IETF= repository.
>
> Name:           draft-liu-netconf-fragmen= tation
> Revision:       00
> Title:          A NETCONF Extension for D= ata Fragmentation
> Document date:  2014-06-04
> Group:          Individual Submission
> Pages:          12
> URL:            http://www.ietf.org/internet-drafts/draft= -liu-
> netconf-fragmentation-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-liu-net= conf-
> fragmentation/
> Htmlized:       http://tools.ietf.org/html/draft-liu-netc= onf-fragmentation-00
>
>
> Abstract:
>    This document introduces an extension to NETCONF (Net= work
>    Configuration) protocol. The extension allows NETCONF= to handle large
>    size data as fragmented RPC messages. Specifically, t= his document
>    defines a new <get-block> capability and releva= nt operations to
>    handle the fragmentations.
>
>
>
>
> Please note that it may take a couple of minutes from the time of =
> submission until the htmlized version and diff are available at to= ols.ietf.org
> .
>
> The IETF Secretariat
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.i= etf.org/mailman/listinfo/netconf
>  _____= __________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.i= etf.org/mailman/listinfo/netconf

 

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


ZTE Information Security Not=
ice: The information contained in this mail (and any attachment transmitted=
 herewith) is privileged and confidential and is intended for the exclusive=
 use of the addressee(s).  If you are not an intended recipient, any d=
isclosure, reproduction, distribution or other dissemination or use of the =
information contained is strictly prohibited.  If you have received th=
is mail in error, please delete it and notify us immediately.


 

 
--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25Fnkgeml506mbxchi_-- From nobody Tue Jun 10 18:49:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50281A02E3 for ; Tue, 10 Jun 2014 18:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.472 X-Spam-Level: X-Spam-Status: No, score=0.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi7EdbF-0Ski for ; Tue, 10 Jun 2014 18:49:14 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD2B1A0277 for ; Tue, 10 Jun 2014 18:49:14 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id w8so3303784qac.22 for ; Tue, 10 Jun 2014 18:49:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OyjSf3WvYrV7EZSHiDWiEXghRAn8EY50PhE7W5RvzQM=; b=kCYOcpoAm8dyblq1RedqjinvYh6WoMuZhi4FrEsb8VlsfIHCRno/eLvdF41CAfjNJE 2gtZPc4A1JDnQO6S2obuXdMXUjctRF1d/p1LJ992kwKS+ihawLKLC/8mh1T9caWt2BG3 vbGu/16N4/+1m+12rfzjpsuxV9Ij5oj5EvNHmUhmdIkFSYpZakbJijjZdt/MxkDKnGcu ZkmcUwXVx7gltPPl65KMUeaTW5XB7k153tvjodSBEWYUMFnST8s3ODgRWBl5Twwl7q48 LpInE2cra9A5PtE1MyDEbHj1ItR+cXRMwfbmx04WwiEAE15qNxH2g0o0SFzYVrn6FbYN 3ubA== X-Gm-Message-State: ALoCoQmUCfpvTMhAIi0fXOXFXUz7ZU34B9Ev0l9eTmPbat1rb2/xPABTmL+mR3iwEmtoVyy4eXgT MIME-Version: 1.0 X-Received: by 10.140.27.245 with SMTP id 108mr43651808qgx.18.1402451353621; Tue, 10 Jun 2014 18:49:13 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Tue, 10 Jun 2014 18:49:13 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> Date: Tue, 10 Jun 2014 18:49:13 -0700 Message-ID: From: Andy Bierman To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c15260bf8e3904fb85a6db Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0JQ1UFCgArvN_lc9v-_iv1VR83w Cc: Zhengguangying , Yangang , Yangshouchuan , Netconf Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 01:49:21 -0000 --001a11c15260bf8e3904fb85a6db Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Tue, Jun 10, 2014 at 6:24 PM, Liubing (Leo) wrote: > Hi Chong & all, > > > > >What's your problem? NMS wants to get a particular result, > > >but server returns too large result? > > >Why not use subtree filter, XPATH filter or client's "iterator" in > andy's proposal? > > > > >I think the problem is that NMS wants to get a very large data, but they > don't want to or can't parse too large xml repsonse. > > > > Please pardon me repeating the issues. > > Let me clearly separate the Problem and Solutions as the following. > > > > - Problem to be solved: > > either the NMS wants to get a particular result, or get a very large data > store, the problem is the same: how do the client and server handle the > large response? However, the latter should be the typical use case. > > > > - Existing solutions: > > 1. Stream-oriented processing. As discussed in the draft, one big issue i= s > that it lacks the ability of canceling the ongoing processing. > > 2. Subtree/XPath filtering. The problem is, the filtered results might > still large. > > > > - New proposed solutions: > > 1. extension, which is proposed in the draft > > 2. extension, which is proposed during recent mailing list > discussion > > > > So may I ask Chong and the WG, do you agree the =A1=B0Existing solutions= =A1=B1 are > NOT sufficient enough to solve the problem, so that we need a NEW solutio= n > (regardless of which solution to choose)? > I do not agree that the server should hold any state at all for subtree iteration. In your solution the client has no idea how the server is going to break up the subtrees into responses. The client cannot even ask for a "plain" instead of fragments. There is a current solution for iteration. The keys do not need to be known to iterate with XPath (e.g. position() function). =3D 0= and position() < 25]" /> =3D 2= 5 and position() < 50]" /> IMO it is a very low priority to create yet another optional feature in NETCONF. Replacing 1 solution because it is not implemented on every server with another optional solution will not accomplish anything. IMO it would require a new protocol version to force every server to support new RPCs. > > For the solution, now the point is stateful or stateless, we=A1=AFd be gl= ad to > have further discussion in depth, but we=A1=AFd like to confirm the probl= em > first. > > > > Many thanks. > > > > Best regards, > > Bing > Andy > > > *From:* feng.chong33@zte.com.cn [mailto:feng.chong33@zte.com.cn] > *Sent:* Monday, June 09, 2014 2:09 PM > *To:* Liubing (Leo) > *Cc:* chong feng; Netconf; Netconf; Yangang; Yangshouchuan; Zhengguangyin= g > *Subject:* Re: [Netconf] Netconf fragmentation-//FW: New Version > Notification for draft-liu-netconf-fragmentation-00.txt > > > > Hi, > What's your problem? NMS wants to get a particular result, but server > returns too large result? > Why not use subtree filter, XPATH filter or client's "iterator" in > andy's proposal? > > I think the problem is that NMS wants to get a very large data, but the= y > don't want to or can't parse too large xml repsonse. > > There are 2 solutions to solve it. (I have developed the both many year= s > ago,:-)) > > The first is your solution. server keep break points and wait for > client's request to get the next fragment. This solution have > 2 main problems. The former is the sever must be stateful and the state > is held by client. It's not a good design pattern in C/S architecture. > The latter is if client send many requests to retrieve large data, the > sever have to keep many break points, it's too heavy for server. > > The second is "iterator" that andy propose. If response data is too > large, client can send a request to get the special part of the data,e.g = 25 > instances of the list, > and send a next request to get the next part. Sever does not need to > keep any break points. > I think this solution is better than yours. But if there is nested list= , > the process is not simple as andy's example. > > /frank > > "Netconf" =D0=B4=D3=DA 2014-06-05 17:58:56: > > > "Liubing (Leo)" > > =B7=A2=BC=FE=C8=CB: "Netconf" > > > > 2014-06-05 17:58 > > > > =CA=D5=BC=FE=C8=CB > > > > chong feng , > > > > =B3=AD=CB=CD > > > > Zhengguangying , Yangshouchuan > > , Netconf , Yangang > > > > > > =D6=F7=CC=E2 > > > > Re: [Netconf] Netconf fragmentation-//FW: New Version Notification > > for draft-liu-netconf-fragmentation-00.txt > > > > Hi Chong, > > > > Thanks for your review and comments. Please see replies inline. > > > > From: chong feng [mailto:fengchongllly@gmail.com > ] > > Sent: Wednesday, June 04, 2014 11:33 PM > > To: Liubing (Leo) > > Cc: Netconf; Zhengguangying; Yangang > > Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version > > Notification for draft-liu-netconf-fragmentation-00.txt > > > > Hi, > > I have reviewed this new draft. > > I understand your solution is that NETCONF server reserve break > > points and wait for client to retrieve the next response. > > I think it's not a good solution, because server may need to reserve > > many break points if there a large number of concurrent requests. > > It's too heavy for server. And, the server must be stateful if it > > support get-block capability. > > [Bing] The break point design is mainly for the issue of terminating > > the retrieving operation instantly. So before thinking of the design > > as too heavy or what, may I ask do you agree it is a requirement > > need to be solved? > > > > Then for the =A1=B0too heavy=A1=B1 consideration, I don=A1=AFt think > > would be wide used among operations, only if the retrieving data is > > too big. So basically I don=A1=AFt think there would be a large number = of > > concurrent requests. > > > > The other questions and comments are listed below: > > 1. Get-block capability should not change the get-config operation's > > behavior. If client use get-config operation to retrieve data, > > all data must be sent in one response or get-block capability should > > add a parameter to get-config operation to indicate the > > response data will be fragmented. > > [Bing] Yes, get-block capability is in use only if both of the > > client and server support the capability. And in current design, > > is defined as a new operation along with . > > If I understand correctly, you had the assumption that it is the > > server who triggers the operation in a response to > config>? If so, I think it is a good point that we should consider. > > > > 2. A set-id can be aged? when client never send a request to > > retrieve the next fragment for a long time, I think this set-id > > should be aged, > > otherwise, server will be reserve more and more set-ids. > > 3. A set-id is unique in session level or server level? > > 4. If a session is killed or closed, other session can retrieved the > > next fragment if the client provide the correct set-id? > > [Bing] Set-id is used for distinguishing fragments in a specific > > session. So when the session is killed, the set-ids are invalid as well= . > > > > Best regards, > > Bing > > > > /frank > > > > 2014-06-04 18:22 GMT+08:00 Liubing (Leo) : > > Hi all, > > > > We've posted a new draft, which is about NETCONF data fragmentation. > > > > The basic idea is, when NMS is retrieving a large size of data in > > the device, the might be very big (e.g. the routes in a > > core router). > > Currently there are mainly two methods of handling the big > reply>: one is stream-oriented handling; the other is just request a > > portion of the data. > > > > This draft considers both the two methods are problematic in some > > situations, and proposes a new method which allows the large size > > to be fragmented in NETCONF level. > > > > Please read the draft and comment. > > Many thanks! > > > > Best regards, > > Bing > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org > ] > > Sent: Wednesday, June 04, 2014 5:27 PM > > To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying > > Subject: New Version Notification for > draft-liu-netconf-fragmentation-00.txt > > > > > > A new version of I-D, draft-liu-netconf-fragmentation-00.txt > > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > > > Name: draft-liu-netconf-fragmentation > > Revision: 00 > > Title: A NETCONF Extension for Data Fragmentation > > Document date: 2014-06-04 > > Group: Individual Submission > > Pages: 12 > > URL: http://www.ietf.org/internet-drafts/draft-liu- > > netconf-fragmentation-00.txt > > Status: https://datatracker.ietf.org/doc/draft-liu-netconf- > > fragmentation/ > > Htmlized: > http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00 > > > > > > Abstract: > > This document introduces an extension to NETCONF (Network > > Configuration) protocol. The extension allows NETCONF to handle larg= e > > size data as fragmented RPC messages. Specifically, this document > > defines a new capability and relevant operations to > > handle the fragmentations. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org > > . > > > > The IETF Secretariat > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c15260bf8e3904fb85a6db Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Tue, Jun 10, 2014 at 6:24 PM, Liubing (Leo) &l= t;leo.liubing@h= uawei.com> wrote:

Hi Chong & all,<= u>

 =

>What's your problem? NMS wants to get a part= icular result,

>but server returns too large result?

>Why not use subtree filter, XPATH filter or clie= nt's "iterator" in andy's proposal? <= /p>

 

>I think the problem is that NMS wants to get a v= ery large data, but they don't want to or can't parse too large xml= repsonse.

 =

Please pardon me repeating = the issues.

Let me clearly separate the= Problem and Solutions as the following.

 =

- Problem to be solved:

either the NMS wants to get= a particular result, or get a very large data store, the problem is the sa= me: how do the client and server handle the large response? However, the latter should be the typical use case.=

 =

- Existing solutions:

1. Stream-oriented processi= ng. As discussed in the draft, one big issue is that it lacks the ability o= f canceling the ongoing processing.

2. Subtree/XPath filtering.= The problem is, the filtered results might still large.

 =

- New proposed solutions:

1. <get-block> extens= ion, which is proposed in the draft

2. <get-list> extensi= on, which is proposed during recent mailing list discussion

 =

So may I ask Chong and the = WG, do you agree the “Existing solutions” are NOT sufficient en= ough to solve the problem, so that we need a NEW solution (regardless of which solution to choose)?


I do not agree that the server should hold any state= at all for subtree iteration.
In your solution the client has no= idea how the server is going to break up the subtrees
into responses.  The client cannot even ask for a "plain&quo= t; <get-config> instead of fragments.

There = is a current solution for iteration.
The keys do not need to be k= nown to iterate with XPath (e.g. position() function).

   <filter type=3D"xpath" select= =3D"/interfaces/interface[position() >=3D 0 and position() < 25]= " />

   <filter type=3D"= xpath" select=3D"/interfaces/interface[position() >=3D 25 and = position() < 50]" />

IMO it is a very low priority to create yet anoth= er optional feature in NETCONF.
Replacing 1 solution because it i= s not implemented on every server with another
optional solution = will not accomplish anything.

IMO it would require a new protocol version to force ev= ery server to support new RPCs.


 =

For the solution, now the p= oint is stateful or stateless, we’d be glad to have further discussio= n in depth, but we’d like to confirm the problem first.

 =

Many thanks.<= /span>

 =

Best regards,=

Bing

=


Andy
 
=

 =

From: feng.chong33@zte.com.cn [mailto:feng.chong33@zte.com.= cn]
Sent: Monday, June 09, 2014 2:09 PM
To: Liubing (Leo)
Cc: chong feng; Netconf; Netconf; Yangang; Yangshouchuan; Zhengguang= ying
Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notif= ication for draft-liu-netconf-fragmentation-00.txt

 

Hi,
  What's your problem? NMS wants to get a particular result= , but server returns too large result?
  Why not use subtree filter, XPATH filter or client's &quo= t;iterat= or" in andy's proposal?

  I think the problem is that NMS wants to get a very large dat= a, but they don't want to or can't parse too large xml repsonse.
 
  There are 2 solutions to solve it. (I have developed the both= many years ago,:-))
 
  The first is your solution. server keep break points and wait= for client's request to get the next fragment. This solution have
  2 main problems. The former is the sever must be stateful and= the state is held by client. It's not a good design pattern in C/S arc= hitecture.
  The latter is if client send many requests to retrieve large = data, the sever have to keep many break points, it's too heavy for serv= er.

  The second is "iterator" that andy propose. If resp= onse data is too large, client can send a request to get the special part o= f the data,e.g 25 instances of the list,
  and send a next request to get the next part. Sever does not = need to keep any break points.
  I think this solution is better than yours. But if there is n= ested list, the process is not simple as andy's example.
 
/frank

"Netconf"= ; <netconf= -bounces@ietf.org> =D0=B4=D3=DA 2014-06-05 17:58:56:

> "Liubing (Leo)" <leo.liubing@huawei.com>
> <= tt>=B7=A2=BC=FE=C8=CB: =  "Netconf" <netconf-bounces@ietf.org>
>
> 2014-06-05 17= :58
> <= span lang=3D"EN-US" style=3D"font-size:10pt">
> =CA=D5=BC=FE=C8=CB<= /span>
> <= span lang=3D"EN-US" style=3D"font-size:10pt">
> chong feng <fengchongllly@gmail.com>,
> <= span lang=3D"EN-US" style=3D"font-size:10pt">
> =B3=AD=CB=CD=
> <= span lang=3D"EN-US" style=3D"font-size:10pt">
> Zhengguangying <zhengguangying@huawei.com>, Yangshouchuan
> <= yangshouchuan@huawei.com>, Netconf <netconf@ietf.org>, Yangang
> <yangan= g@huawei.com>
> <= span lang=3D"EN-US" style=3D"font-size:10pt">
> =D6=F7=CC=E2=
> <= span lang=3D"EN-US" style=3D"font-size:10pt">
> Re: [Netconf] Netconf fragmentation-//FW: New Version Notification=
> for draft-liu-netconf-fragmentation-00.txt
> <= span lang=3D"EN-US" style=3D"font-size:10pt">
> Hi Chong,
>  =
> Thanks for yo= ur review and comments. Please see replies inline.
>  =
> From: chong f= eng [mailto:fengchong= llly@gmail.com]
> Sent: Wednesday, June 04, 2014 11:33 PM
> To: Liubing (Leo)
> Cc: Netconf; Zhengguangying; Yangang
> Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version
> Notification for draft-liu-netconf-fragmentation-00.txt
>  =
> Hi,
>    = I have reviewed this new draft.
>    = I understand your solution is that NETCONF server reserve break
> points and wait for client to retrieve the next response.
> I think it= 9;s not a good solution, because server may need to reserve
> many break points if there a large number of concurrent requests.<= /tt>
> It's too = heavy for server. And, the server must be stateful if it
> support get-block capability. > [Bing] The br= eak point design is mainly for the issue of terminating
> the retrieving operation instantly. So before thinking of the desi= gn
> as too heavy or what, may I ask do you agree it is a requirement <= /tt>
> need to be solved?
>  =
> Then for the = “too heavy” consideration, I don’t think <get-block>= ;
> would be wide used among operations, only if the retrieving data i= s
> too big. So basically I don’t think there would be a large n= umber of
> concurrent requests.
>  =
> The other que= stions and comments are listed below:
> 1. Get-block = capability should not change the get-config operation's
> behavior. If client use get-config operation to retrieve data,
> all data must= be sent in one response or get-block capability should
> add a parameter to get-config operation to indicate the
> response data= will be fragmented.
> [Bing] Yes, g= et-block capability is in use only if both of the
> client and server support the capability. And in current design, <= /tt>
> <get-block> is defined as a new operation along with <get= -config>.
> If I understa= nd correctly, you had the assumption that it is the
> server who triggers the <get-block> operation in a response = to <get-
> config>? If so, I think it is a good point that we should consi= der.
>  =
> 2. A set-id c= an be aged? when client never send a request to
> retrieve the next fragment for a long time, I think this set-id
> should be aged,
> otherwise, se= rver will be reserve more and more set-ids.
> 3. A set-id i= s unique in session level or server level?
> 4. If a sessi= on is killed or closed, other session can retrieved the
> next fragment if the client provide the correct set-id?
> [Bing] Set-id= is used for distinguishing fragments in a specific
> session. So when the session is killed, the set-ids are invalid as= well.
>  =
> Best regards,=
> Bing
>  =
> /frank=
>  =
> 2014-06-04 18= :22 GMT+08:00 Liubing (Leo) <leo.liubing@huawei.com>:
> Hi all,
>
> We've posted a new draft, which is about NETCONF data fragment= ation.
>
> The basic idea is, when NMS is retrieving a large size of data in =
> the device, the <rpc-reply> might be very big (e.g. the rout= es in a
> core router).
> Currently there are mainly two methods of handling the big <rpc= -
> reply>: one is stream-oriented handling; the other is just requ= est a
> portion of the data.
>
> This draft considers both the two methods are problematic in some =
> situations, and proposes a new method which allows the large size =
> <rpc-reply> to be fragmented in NETCONF level.
>
> Please read the draft and comment.
> Many thanks!
>
> Best regards,
> Bing
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Wednesday, June 04, 2014 5:27 PM
> To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying
> Subject: New Version Notification for draft-liu-netconf-fragmentat= ion-00.txt
>
>
> A new version of I-D, draft-liu-netconf-fragmentation-00.txt<= br> > has been successfully submitted by Bing Liu and posted to the IETF= repository.
>
> Name:           draft-liu-netconf-fragmen= tation
> Revision:       00
> Title:          A NETCONF Extension for D= ata Fragmentation
> Document date:  2014-06-04
> Group:          Individual Submission
> Pages:          12
> URL:            http://www.ietf.org/inter= net-drafts/draft-liu-
> netconf-fragmentation-00.txt
> Status:         https://datatracker.ietf.org= /doc/draft-liu-netconf-
> fragmentation/
> Htmlized:       http://tools.ietf.org/htm= l/draft-liu-netconf-fragmentation-00
>
>
> Abstract:
>    This document introduces an extension to NETCONF (Net= work
>    Configuration) protocol. The extension allows NETCONF= to handle large
>    size data as fragmented RPC messages. Specifically, t= his document
>    defines a new <get-block> capability and releva= nt operations to
>    handle the fragmentations.
>
>
>
>
> Please note that it may take a couple of minutes from the time of =
> submission until the htmlized version and diff are available at tools.ietf.org > .
>
> The IETF Secretariat
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf= .org
> https://www.ietf.org/mailman/listinfo/netconf
>  _______= ________________________________________
> Netconf mailing list
> Netconf@ietf= .org
> https://www.ietf.org/mailman/listinfo/netconf<= /u>

 <=
/pre>

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


ZTE Information Security Not=
ice: The information contained in this mail (and any attachment transmitted=
 herewith) is privileged and confidential and is intended for the exclusive=
 use of the addressee(s).  If you are not an intended recipient, any d=
isclosure, reproduction, distribution or other dissemination or use of the =
information contained is strictly prohibited.  If you have received th=
is mail in error, please delete it and notify us immediately.=




 <=
/pre>

 

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


--001a11c15260bf8e3904fb85a6db-- From nobody Tue Jun 10 23:33:19 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24C01A063F for ; Tue, 10 Jun 2014 23:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUEFaY2c_9MW for ; Tue, 10 Jun 2014 23:33:17 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB371A0422 for ; Tue, 10 Jun 2014 23:33:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BEE2B9A; Wed, 11 Jun 2014 08:33:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pGhFsLQx3hFG; Wed, 11 Jun 2014 08:33:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 Jun 2014 08:33:14 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95E0C20017; Wed, 11 Jun 2014 08:33:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2oSQTkbKapHG; Wed, 11 Jun 2014 08:33:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A78020013; Wed, 11 Jun 2014 08:33:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 38DD62D61BD3; Wed, 11 Jun 2014 08:33:12 +0200 (CEST) Date: Wed, 11 Jun 2014 08:33:12 +0200 From: Juergen Schoenwaelder To: "Liubing (Leo)" Message-ID: <20140611063312.GC32389@elstar.local> Mail-Followup-To: "Liubing (Leo)" , "feng.chong33@zte.com.cn" , Zhengguangying , Yangshouchuan , Netconf , Yangang References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ARA-sbiQJmIOEz7OpuC_muxhn6M Cc: Zhengguangying , Yangang , Yangshouchuan , Netconf Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 06:33:19 -0000 On Wed, Jun 11, 2014 at 01:24:51AM +0000, Liubing (Leo) wrote: > > - New proposed solutions: > 1. extension, which is proposed in the draft > 2. extension, which is proposed during recent mailing list discussion > As mentioned in a different context, another solution is to change or augment NETCONF at some point in time such that an can lead to a sequence of s with a suitable cancel mechanism. This would address the concern of large data retrievals but would also allow long running asynchronous rpcs (the ping or traceroute example). The benefit of such a solution would be that it can be utilized in many contexts. But this is of course new protocol work and perhaps we need to focus on finishing the currently chartered work items before taking on new work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jun 11 02:59:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6C71A0467 for ; Wed, 11 Jun 2014 02:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhE6oxkJ5pqk for ; Wed, 11 Jun 2014 02:59:13 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4691A045B for ; Wed, 11 Jun 2014 02:59:10 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so3571330wes.12 for ; Wed, 11 Jun 2014 02:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G0F+A88T4k+W7krTi4ZGtg82E0o/SHbAdrnzKqtt4tU=; b=EQaVlpx01kbnT5uezjrCIJbrUbt0v8A5X6wl+IbLRDQZDDYQGz004iuTBZwlkw+DtO IZcKRHks8aUDdoUlFR+oxjLsdmV4KZpoBX5/fP89YIDzrvy3rEZsNIeMxHz3TPqNpiV7 tXnj6e369d6e/YoU9tacgt1b50TAWZ+N73x500ezMIQYEumkzFWY7MVNkpHPL41yLe00 mOfyL6KR0GTwgaYflGI0/Ro/U8ix/qesj4VmVLPwaAlNkrjPQMbglsUgcol0GCppxuE8 /P7T6TEW8PuFyRN5/HoIV7828iXnPN0X1pfrrpIwpcuPe8SzPf8xhnPaXfDcPeQbRNMG +ttw== X-Received: by 10.180.98.163 with SMTP id ej3mr48864189wib.9.1402480749248; Wed, 11 Jun 2014 02:59:09 -0700 (PDT) Received: from [10.61.174.29] (173-38-208-170.cisco.com. [173.38.208.170]) by mx.google.com with ESMTPSA id l49sm58543891eef.27.2014.06.11.02.59.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 02:59:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Giles Heron In-Reply-To: <20140611063312.GC32389@elstar.local> Date: Wed, 11 Jun 2014 10:59:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/PVSjMCaiURT9JHLCvx6gTr_oguY Cc: Zhengguangying , Netconf , Yangshouchuan , Yangang Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 09:59:15 -0000 On 11 Jun 2014, at 07:33, Juergen Schoenwaelder = wrote: > On Wed, Jun 11, 2014 at 01:24:51AM +0000, Liubing (Leo) wrote: >>=20 >> - New proposed solutions: >> 1. extension, which is proposed in the draft >> 2. extension, which is proposed during recent mailing list = discussion >>=20 >=20 > As mentioned in a different context, another solution is to change or > augment NETCONF at some point in time such that an can lead to a > sequence of s with a suitable cancel mechanism. This would > address the concern of large data retrievals but would also allow long > running asynchronous rpcs (the ping or traceroute example). The > benefit of such a solution would be that it can be utilized in many > contexts. But this is of course new protocol work and perhaps we need > to focus on finishing the currently chartered work items before taking > on new work. understood. though isn't the issue to some extent that unless/until we have good = solutions for such requirements then SPs will continue to use = CLI-scripting and hence NETCONF will fail to offer a comprehensive = management solution (and if you use CLI-scripting for one thing you = might as well use it for everything - or so the argument might go)? my preference would be to add the sequence of to NETCONF = 1.1. Giles > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jun 11 03:12:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0611A001B for ; Wed, 11 Jun 2014 03:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLjs8GUJX0kD for ; Wed, 11 Jun 2014 03:12:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CCBB1A044D for ; Wed, 11 Jun 2014 03:12:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A09DFFDE; Wed, 11 Jun 2014 12:12:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qUezFcSLvDZo; Wed, 11 Jun 2014 12:11:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 Jun 2014 12:12:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 583BC2002C; Wed, 11 Jun 2014 12:12:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xeJqZwlRY3KA; Wed, 11 Jun 2014 12:12:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0708920013; Wed, 11 Jun 2014 12:12:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EE03B2D62007; Wed, 11 Jun 2014 12:11:59 +0200 (CEST) Date: Wed, 11 Jun 2014 12:11:58 +0200 From: Juergen Schoenwaelder To: Giles Heron Message-ID: <20140611101157.GA32889@elstar.local> Mail-Followup-To: Giles Heron , "Liubing (Leo)" , Zhengguangying , Yangang , Yangshouchuan , Netconf References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/IC3wwL0uTM11uoBNZUbiKiNzbfE Cc: Zhengguangying , Netconf , Yangshouchuan , Yangang Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 10:12:07 -0000 On Wed, Jun 11, 2014 at 10:59:05AM +0100, Giles Heron wrote: > On 11 Jun 2014, at 07:33, Juergen Schoenwaelder wrote: > > > On Wed, Jun 11, 2014 at 01:24:51AM +0000, Liubing (Leo) wrote: > >> > >> - New proposed solutions: > >> 1. extension, which is proposed in the draft > >> 2. extension, which is proposed during recent mailing list discussion > >> > > > > As mentioned in a different context, another solution is to change or > > augment NETCONF at some point in time such that an can lead to a > > sequence of s with a suitable cancel mechanism. This would > > address the concern of large data retrievals but would also allow long > > running asynchronous rpcs (the ping or traceroute example). The > > benefit of such a solution would be that it can be utilized in many > > contexts. But this is of course new protocol work and perhaps we need > > to focus on finishing the currently chartered work items before taking > > on new work. > > understood. > > though isn't the issue to some extent that unless/until we have good > solutions for such requirements then SPs will continue to use > CLI-scripting and hence NETCONF will fail to offer a comprehensive > management solution (and if you use CLI-scripting for one thing you > might as well use it for everything - or so the argument might go)? > > my preference would be to add the sequence of to > NETCONF 1.1. NETCONF 1.1 is defined in RFC 6241 so it is difficult to add something to it. It may be possible to engineer this as an extension of NETCONF 1.1., i.e., a protocol capability that does not require to revise RFC 6241. But I have not worked this through and so this is more wild guessing at the moment. At the end, someone has to invest time and sit down to work out a concrete solution proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jun 11 03:13:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9CF1A0340 for ; Wed, 11 Jun 2014 03:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4q36bGafwjI for ; Wed, 11 Jun 2014 03:13:18 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D861A001B for ; Wed, 11 Jun 2014 03:13:18 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so5021790wiv.15 for ; Wed, 11 Jun 2014 03:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ECBCPrdEf8WjNjSH1xMOkthEv7IGSs0qR5LQFJFMUhE=; b=b6IREfKyErrfWvOKXytSCMZEvkp1ba+9Kith07ypb14SgCkJP0IGMQ1l6S2HSwz1Bh Mf5/xlsGtN++D4mrIAnPIEY/pwJcUSniH9Q4fbrGeEYUfOu9O6ul7n9JxQD2SxlMAkzg 4JKxumm8Y69eLJYEa1JkTiGnBbNp8N6vCnUMynrlHjZNcBH8sYfH9vOAk/+SkweZkQQm l3Oy3wpOZ182n5ahYoeueod18OvTYklDCE6fDEXCK2G8EqQiSR6k2fgRTO9PG20qlCpA XdjUP7r4bY3439hJz4B3rQGFsvXqE4zjGmSW0ivY4aHsuipahN1ZG3Fgp2WjQtjszQOU 4J3Q== X-Received: by 10.180.92.69 with SMTP id ck5mr49010773wib.15.1402481592854; Wed, 11 Jun 2014 03:13:12 -0700 (PDT) Received: from [10.61.174.29] (173-38-208-170.cisco.com. [173.38.208.170]) by mx.google.com with ESMTPSA id w6sm58611657eej.7.2014.06.11.03.13.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 03:13:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Giles Heron In-Reply-To: <20140611101157.GA32889@elstar.local> Date: Wed, 11 Jun 2014 11:13:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4OpULhvROVLU_wwicXJom5LAWBU Cc: Zhengguangying , Netconf , Yangshouchuan , Yangang Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 10:13:19 -0000 On 11 Jun 2014, at 11:11, Juergen Schoenwaelder = wrote: > On Wed, Jun 11, 2014 at 10:59:05AM +0100, Giles Heron wrote: >> On 11 Jun 2014, at 07:33, Juergen Schoenwaelder = wrote: >>=20 >>> On Wed, Jun 11, 2014 at 01:24:51AM +0000, Liubing (Leo) wrote: >>>>=20 >>>> - New proposed solutions: >>>> 1. extension, which is proposed in the draft >>>> 2. extension, which is proposed during recent mailing = list discussion >>>>=20 >>>=20 >>> As mentioned in a different context, another solution is to change = or >>> augment NETCONF at some point in time such that an can lead to = a >>> sequence of s with a suitable cancel mechanism. This = would >>> address the concern of large data retrievals but would also allow = long >>> running asynchronous rpcs (the ping or traceroute example). The >>> benefit of such a solution would be that it can be utilized in many >>> contexts. But this is of course new protocol work and perhaps we = need >>> to focus on finishing the currently chartered work items before = taking >>> on new work. >>=20 >> understood. >>=20 >> though isn't the issue to some extent that unless/until we have good >> solutions for such requirements then SPs will continue to use >> CLI-scripting and hence NETCONF will fail to offer a comprehensive >> management solution (and if you use CLI-scripting for one thing you >> might as well use it for everything - or so the argument might go)? >>=20 >> my preference would be to add the sequence of to >> NETCONF 1.1. >=20 > NETCONF 1.1 is defined in RFC 6241 so it is difficult to add something > to it. It may be possible to engineer this as an extension of NETCONF > 1.1., i.e., a protocol capability that does not require to revise RFC > 6241. But I have not worked this through and so this is more wild > guessing at the moment. At the end, someone has to invest time and sit > down to work out a concrete solution proposal. sorry - brain out of gear. Was thinking YANG rather than NETCONF. But yes, it'd be nice to work out how to do this. Giles > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Wed Jun 11 05:26:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8609B1B2885 for ; Wed, 11 Jun 2014 05:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGPHOPqh37xF for ; Wed, 11 Jun 2014 05:26:27 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605EC1B286D for ; Wed, 11 Jun 2014 05:26:27 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id i8so4258646qcq.34 for ; Wed, 11 Jun 2014 05:26:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SIWB04rXZ2yPYE3MzfLIpbAjV2hrvpc1jroQYfGGzIU=; b=JDkkfArdpNXa6L4yU66yeVMVsn2mHFzVPMjrUxEVSOXNIPr6uCBmny7zFujnPVlpDL lHvU5WEZuiLMq9xZcqmVNCDIU/LdhWngxvU3A/oHGt+A2GWGMYhFMUGq92KYj1PXXTsb /7CEbsraEVJnsnjU96pO/DaKTjGjvJsgVfQNiZoRO7OPKfacbym7Mo/Qat3rakQGA/Mm vOKxInH4RRBKJ90cUMVCWTvAoUa5uO7zA8uasdSujtv09PmG9d0uvzyiT8jGdhMVsC4B YdxWT8pVam9aSHsEW20w5/DgunjK2rlU9JTUPAHAHCPH2scmBcws0tGNMHfZ8tvErFwr qWHA== X-Gm-Message-State: ALoCoQlXYAICs4MnNkRTxVZeDPC4p/k/jwWejtV8P6rwfm7Fogy1vo6ipufpidzoF/pz/wHyxbWW MIME-Version: 1.0 X-Received: by 10.224.24.134 with SMTP id v6mr51407762qab.88.1402489586284; Wed, 11 Jun 2014 05:26:26 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 11 Jun 2014 05:26:26 -0700 (PDT) In-Reply-To: <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> Date: Wed, 11 Jun 2014 05:26:26 -0700 Message-ID: From: Andy Bierman To: Giles Heron Content-Type: multipart/alternative; boundary=001a11c252c698103b04fb8e8da8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9v3VjjNfMNLkn5Qr_9UnKfuAA74 Cc: Zhengguangying , Yangang , Netconf , Yangshouchuan Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:26:29 -0000 --001a11c252c698103b04fb8e8da8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 11, 2014 at 3:13 AM, Giles Heron wrote: > On 11 Jun 2014, at 11:11, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Wed, Jun 11, 2014 at 10:59:05AM +0100, Giles Heron wrote: > >> On 11 Jun 2014, at 07:33, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> > >>> On Wed, Jun 11, 2014 at 01:24:51AM +0000, Liubing (Leo) wrote: > >>>> > >>>> - New proposed solutions: > >>>> 1. extension, which is proposed in the draft > >>>> 2. extension, which is proposed during recent mailing list > discussion > >>>> > >>> > >>> As mentioned in a different context, another solution is to change or > >>> augment NETCONF at some point in time such that an can lead to a > >>> sequence of s with a suitable cancel mechanism. This would > >>> address the concern of large data retrievals but would also allow long > >>> running asynchronous rpcs (the ping or traceroute example). The > >>> benefit of such a solution would be that it can be utilized in many > >>> contexts. But this is of course new protocol work and perhaps we need > >>> to focus on finishing the currently chartered work items before taking > >>> on new work. > >> > >> understood. > >> > >> though isn't the issue to some extent that unless/until we have good > >> solutions for such requirements then SPs will continue to use > >> CLI-scripting and hence NETCONF will fail to offer a comprehensive > >> management solution (and if you use CLI-scripting for one thing you > >> might as well use it for everything - or so the argument might go)? > >> > This is a really weak argument. Many vendors are adopting NETCONF. A vendor can add all the RPCs they want to the protocol instead of blaming complete inaction on the lack of a standard YANG module. Most MIB modules were proprietary, not standard, so lack of standard modules has never been a real concern of vendors. > >> my preference oyuld be to add the sequence of to > >> NETCONF 1.1. > Why did you dismiss notifications? Seems like NETCONF already supports multiple messages from server to client that can be sent at any time. > > > NETCONF 1.1 is defined in RFC 6241 so it is difficult to add something > > to it. It may be possible to engineer this as an extension of NETCONF > > 1.1., i.e., a protocol capability that does not require to revise RFC > > 6241. But I have not worked this through and so this is more wild > > guessing at the moment. At the end, someone has to invest time and sit > > down to work out a concrete solution proposal. > > sorry - brain out of gear. Was thinking YANG rather than NETCONF. > > But yes, it'd be nice to work out how to do this. > > I am concerned about the NETMOD WG's perception that it can change NETCONF normative behavior by changing YANG. I do not see how "extra" RPC replies can be considered backward compatible. If the message-id doesn't change they will look like duplicate replies. If the message-id is new the client won't have a request to match against it. I do not think it would be good design to change the NETCONF RPC model with a sentence or 2 in a YANG description-stmt. Giles > > > /js > Andy > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c252c698103b04fb8e8da8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 11, 2014 at 3:13 AM, Giles Heron <= giles.heron@gmai= l.com> wrote:
On 11 Jun 2014, at 11:11, Juergen Schoenwael= der <j.schoenwae= lder@jacobs-university.de> wrote:

> On Wed, Jun 11, 2014 at 10:59:05AM +0100, Giles Heron wrote:
>> On 11 Jun 2014, at 07:33, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university= .de> wrote:
>>
>>> On Wed, Jun 11, 2014 at 01:24:51AM +0000, Liubing (Leo) wrote:=
>>>>
>>>> - New proposed solutions:
>>>> 1. <get-block> extension, which is proposed in the d= raft
>>>> 2. <get-list> extension, which is proposed during re= cent mailing list discussion
>>>>
>>>
>>> As mentioned in a different context, another solution is to ch= ange or
>>> augment NETCONF at some point in time such that an <rpc>= can lead to a
>>> sequence of <rpc-reply/>s with a suitable cancel mechani= sm. This would
>>> address the concern of large data retrievals but would also al= low long
>>> running asynchronous rpcs (the ping or traceroute example). Th= e
>>> benefit of such a solution would be that it can be utilized in= many
>>> contexts. But this is of course new protocol work and perhaps = we need
>>> to focus on finishing the currently chartered work items befor= e taking
>>> on new work.
>>
>> understood.
>>
>> though isn't the issue to some extent that unless/until we hav= e good
>> solutions for such requirements then SPs will continue to use
>> CLI-scripting and hence NETCONF will fail to offer a comprehensive=
>> management solution (and if you use CLI-scripting for one thing yo= u
>> might as well use it for everything - or so the argument might go)= ?
>>

This is a really weak argument= . Many vendors are adopting NETCONF.
A vendor can add all the RPC= s they want to the protocol instead of
blaming complete inaction = on the lack of a standard YANG module.
Most MIB modules were proprietary, not standard, so lack of standard m= odules
has never been a real concern of vendors.

=A0
>> my preference oyuld be to add the sequence of <rpc-reply/> t= o
>> NETCONF 1.1.

Why did you dismi= ss notifications?
Seems like NETCONF already supports multiple me= ssages from server to client
that can be sent at any time.


>
> NETCONF 1.1 is defined in RFC 6241 so it is difficult to add something=
> to it. It may be possible to engineer this as an extension of NETCONF<= br> > 1.1., i.e., a protocol capability that does not require to revise RFC<= br> > 6241. But I have not worked this through and so this is more wild
> guessing at the moment. At the end, someone has to invest time and sit=
> down to work out a concrete solution proposal.

sorry - brain out of gear. =A0Was thinking YANG rather than NETCONF.

But yes, it'd be nice to work out how to do this.


I am concerned about the NETMOD WG'= ;s perception that it can
change NETCONF normative behavior by ch= anging YANG.=A0

I do not see how "extra"= RPC replies can be considered backward compatible.
If the message-id doesn't change they will look like duplicate rep= lies.
If the message-id is new the client won't have a reques= t to match against it.
I do not think it would be good design to = change the NETCONF RPC model with
a sentence or 2 in a YANG description-stmt.

<= br>
Giles

> /js

Andy
=A0
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >

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

--001a11c252c698103b04fb8e8da8-- From nobody Wed Jun 11 05:50:47 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505791A0278 for ; Wed, 11 Jun 2014 05:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5IKO7q4zuL3 for ; Wed, 11 Jun 2014 05:50:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C657F1A0263 for ; Wed, 11 Jun 2014 05:50:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E783F9D6; Wed, 11 Jun 2014 14:50:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id DL9h7N5fU-sl; Wed, 11 Jun 2014 14:50:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 Jun 2014 14:50:30 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7FB920017; Wed, 11 Jun 2014 14:50:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HC8OHIKe2Yob; Wed, 11 Jun 2014 14:50:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E426020013; Wed, 11 Jun 2014 14:50:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 76CB72D621E8; Wed, 11 Jun 2014 14:50:27 +0200 (CEST) Date: Wed, 11 Jun 2014 14:50:27 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140611125025.GA33218@elstar.local> Mail-Followup-To: Andy Bierman , Giles Heron , Zhengguangying , Netconf , Yangshouchuan , Yangang References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/If4A389IoxyH3WREVNNW2vUygiU Cc: Zhengguangying , Yangang , Netconf , Yangshouchuan Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:50:44 -0000 On Wed, Jun 11, 2014 at 05:26:26AM -0700, Andy Bierman wrote: > I do not think it would be good design to change the NETCONF RPC model with > a sentence or 2 in a YANG description-stmt. Nobody proposed that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jun 11 05:58:43 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3151A0085 for ; Wed, 11 Jun 2014 05:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfGsOsHkifrG for ; Wed, 11 Jun 2014 05:58:39 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1061A009C for ; Wed, 11 Jun 2014 05:58:39 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id i8so4324557qcq.34 for ; Wed, 11 Jun 2014 05:58:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=qimd1D+nCz2cIxbyeSYnpWZPQldAZ8wiv7HOSccZK/0=; b=OBgjiaMurOnYNZVahLyBl229QHWHFjO/51Zrx2B3euFqGMCLpp/Uw1g7093DklnC1d Ay4C8PplFq3gMOmS1/NuAGDiVJMptVd3OwFunA1PGUr90yJ5dmFFJZgsAesnTRBe1/yD mYYUj1B6vzwuqFT3ysFIydpJPVr6J3WD6TLjh2RPYq7Nzqkkhz1hcd74AfPoEhpTuqZp sdk+0TvtUa35f2iq7ZObTwnCnu8jA6UwXtTGLaN8iXQgUPeZRJjWArKytrLbbUoI6aU0 zTs4OKciW6DhHKS9kBd1jSGVqMxJ5V8XKin9M3WqH4J5RnKjCaHgTytqA2DhY+BL2w6M HdPw== X-Gm-Message-State: ALoCoQm7elQ3szW4DZFHXPRODtRaa6kVyS3LjVbdtp8v8JlsbO5eExVMVeJDCvUZSMOSPqV/MdBu MIME-Version: 1.0 X-Received: by 10.140.41.75 with SMTP id y69mr47805249qgy.34.1402491518260; Wed, 11 Jun 2014 05:58:38 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 11 Jun 2014 05:58:38 -0700 (PDT) In-Reply-To: <20140611125025.GA33218@elstar.local> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> <20140611125025.GA33218@elstar.local> Date: Wed, 11 Jun 2014 05:58:38 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Giles Heron , Zhengguangying , Netconf , Yangshouchuan , Yangang Content-Type: multipart/alternative; boundary=001a11c126babf530904fb8f00cf Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/tYGiEnjfk7pic9waH1QRFc0hyog Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:58:41 -0000 --001a11c126babf530904fb8f00cf Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 11, 2014 at 5:50 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 11, 2014 at 05:26:26AM -0700, Andy Bierman wrote: > > > I do not think it would be good design to change the NETCONF RPC model > with > > a sentence or 2 in a YANG description-stmt. > > Nobody proposed that. > Sorry. So this would be a new protocol version for NETCONF? We would obsolete base:1.1 and create a base:1.2 or something like that? There will be no attempt to alter the RPC layer by any other means. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c126babf530904fb8f00cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 11, 2014 at 5:50 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 11, 2014 at 05:26:26AM -0700, An= dy Bierman wrote:

> I do not think it would be good design to change the NETCONF RPC model= with
> a sentence or 2 in a YANG description-stmt.

Nobody proposed that.
=A0

Sor= ry. =A0So this would be a new protocol version for NETCONF?
We wo= uld obsolete base:1.1 and create a base:1.2 or something like that?
There will be no attempt to alter the RPC layer by any other means.


/js


Andy
=A0
=
--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--001a11c126babf530904fb8f00cf-- From nobody Wed Jun 11 06:45:49 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3253A1A00E7 for ; Wed, 11 Jun 2014 06:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PhanYK6eqSV for ; Wed, 11 Jun 2014 06:45:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7242B1A00DA for ; Wed, 11 Jun 2014 06:45:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 97037742; Wed, 11 Jun 2014 15:45:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ocL_5tXa5s5e; Wed, 11 Jun 2014 15:45:31 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 Jun 2014 15:45:41 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57E2E2002F; Wed, 11 Jun 2014 15:45:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2UY9rwepVUad; Wed, 11 Jun 2014 15:45:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C94BC20013; Wed, 11 Jun 2014 15:45:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7FCAE2D636B9; Wed, 11 Jun 2014 15:45:40 +0200 (CEST) Date: Wed, 11 Jun 2014 15:45:39 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140611134539.GA33346@elstar.local> Mail-Followup-To: Andy Bierman , Giles Heron , Zhengguangying , Netconf , Yangshouchuan , Yangang References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> <20140611125025.GA33218@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/oRwCtkcg9G2D2Ogt-xgCpo2vmKU Cc: Zhengguangying , Yangang , Netconf , Yangshouchuan Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:45:48 -0000 On Wed, Jun 11, 2014 at 05:58:38AM -0700, Andy Bierman wrote: > On Wed, Jun 11, 2014 at 5:50 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Wed, Jun 11, 2014 at 05:26:26AM -0700, Andy Bierman wrote: > > > > > I do not think it would be good design to change the NETCONF RPC model > > with > > > a sentence or 2 in a YANG description-stmt. > > > > Nobody proposed that. > > > > > Sorry. So this would be a new protocol version for NETCONF? > We would obsolete base:1.1 and create a base:1.2 or something like that? > There will be no attempt to alter the RPC layer by any other means. > I think even a capability could be sufficient. Here is a very rough sketch: If a server announces :linked-replies and the client supports it as well, the client can add an additional parameter to an rpc to indicate the possible use of linked-replies. An old client will of course never do this. Here is what a new client might do if it wants to use linked replies: The server can either simply send an rpc-reply or it starts sending linked replies, e.g.: Of course, there are lots of unclear questions concerning data merging, error handling, how to send a cancel for a given link-id (e.g., by sending a new message with a matching link-id) and so on. I do not see that this would cause an interoperability problem. Even if an old client would accidentally send a link-id, it would simply pick the first rpc-reply and drop the rest because of unknown message-ids. Anyway, there are tons of details to work out (also whether it is necessary to negotiate linked rpc-reply sizes or whether it is good enough for the server to decide freely as it likes). This is really just a very very rough idea. However, it believe that thinking in this direction may lead to better support for asynchronous rpcs and rpcs that potentially return very large chunks of data than trying to solve this problem without enhancements of the rpc layer. To me, it seems a capability is sufficient to achieve interoperability. Of course, some people may argue that changes of the message layer go too far for a capability. But then RFC 5277 also added a new message using essentially just a capability - so there is already a precendence. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jun 11 06:53:34 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA531A00EC for ; Wed, 11 Jun 2014 06:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhFVkz6ZHJtw for ; Wed, 11 Jun 2014 06:53:31 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5DB31A00DD for ; Wed, 11 Jun 2014 06:53:30 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x12so6312059wgg.22 for ; Wed, 11 Jun 2014 06:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h+Gh+tBo58ogbCvZLUjsbwn2Airbf8lQHmrXCbiUNTY=; b=jjAa95TEgTO5TYObsi4JAOTGcgZ1C3nYw238s4AGohvSRpv2dW92KgbZ6dGi1apzy8 Z0i09ubx2q/oML0JqZkR+gV2caIF5LGC8c5xMBXlkvzV6/6yovU5fqAI8KPrBXeRPNZ2 cpo4GYtf9JKLdZDfm3DdDJZOTLQY+uT6dfanTaGyGhZI4cacsTcG6ke7Oalh8sPRSa66 yINsuwNllUGtQiLsmlyih6rJj+xY4RcXx/4fyiPLYoeTDuG6qtMuL9FwY0C8RHMWBnvE qTz2j5SQwndDuPw6dWk4YJzQwfN7I7tA6qRk1qWRai2XpxpGQrVt4GokO4/xNUEJzmRO 03ww== X-Received: by 10.194.80.161 with SMTP id s1mr52405936wjx.47.1402494807914; Wed, 11 Jun 2014 06:53:27 -0700 (PDT) Received: from [10.61.174.29] (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id fh5sm27381170wic.9.2014.06.11.06.53.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 06:53:26 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Giles Heron In-Reply-To: Date: Wed, 11 Jun 2014 14:53:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9F01@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/K9HnWMfnUhPt7F3DqFgPWYBfGTY Cc: Zhengguangying , Yangang , Netconf , Yangshouchuan Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:53:33 -0000 Hi Andy, On 11 Jun 2014, at 13:26, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jun 11, 2014 at 3:13 AM, Giles Heron = wrote: > On 11 Jun 2014, at 11:11, Juergen Schoenwaelder = wrote: >=20 > > On Wed, Jun 11, 2014 at 10:59:05AM +0100, Giles Heron wrote: > >> On 11 Jun 2014, at 07:33, Juergen Schoenwaelder = wrote: > >> > >>> On Wed, Jun 11, 2014 at 01:24:51AM +0000, Liubing (Leo) wrote: > >>>> > >>>> - New proposed solutions: > >>>> 1. extension, which is proposed in the draft > >>>> 2. extension, which is proposed during recent mailing = list discussion > >>>> > >>> > >>> As mentioned in a different context, another solution is to change = or > >>> augment NETCONF at some point in time such that an can lead = to a > >>> sequence of s with a suitable cancel mechanism. This = would > >>> address the concern of large data retrievals but would also allow = long > >>> running asynchronous rpcs (the ping or traceroute example). The > >>> benefit of such a solution would be that it can be utilized in = many > >>> contexts. But this is of course new protocol work and perhaps we = need > >>> to focus on finishing the currently chartered work items before = taking > >>> on new work. > >> > >> understood. > >> > >> though isn't the issue to some extent that unless/until we have = good > >> solutions for such requirements then SPs will continue to use > >> CLI-scripting and hence NETCONF will fail to offer a comprehensive > >> management solution (and if you use CLI-scripting for one thing you > >> might as well use it for everything - or so the argument might go)? > >> >=20 > This is a really weak argument. Many vendors are adopting NETCONF. > A vendor can add all the RPCs they want to the protocol instead of > blaming complete inaction on the lack of a standard YANG module. > Most MIB modules were proprietary, not standard, so lack of standard = modules > has never been a real concern of vendors. agreed - it's weak. But I can see people taking that view :( At any rate I wasn't saying "NETCONF won't be adopted until there are = standardised YANG modules for everything". I was rather saying that if NETCONF can only be used for configuration = and for a subset of operations (e.g. a subset that excludes things like = ping/traceroute) then even if all vendors adopt NETCONF it will leave = SPs still needing CLI scripts to do ping/traceroute/etc. > =20 > >> my preference oyuld be to add the sequence of to > >> NETCONF 1.1. >=20 > Why did you dismiss notifications? > Seems like NETCONF already supports multiple messages from server to = client > that can be sent at any time. Yes - but it seems a bit ugly to me to have to, for example, send an RPC = to start e.g. a ping and be told in the RPC reply that I then need to = subscribe to temporary stream "foo" to get the responses. Also if we follow your logic that the NETCONF stream will carry all = NETCONF Notifications then wouldn't those notifications also end up in = that stream? >=20 > > > > NETCONF 1.1 is defined in RFC 6241 so it is difficult to add = something > > to it. It may be possible to engineer this as an extension of = NETCONF > > 1.1., i.e., a protocol capability that does not require to revise = RFC > > 6241. But I have not worked this through and so this is more wild > > guessing at the moment. At the end, someone has to invest time and = sit > > down to work out a concrete solution proposal. >=20 > sorry - brain out of gear. Was thinking YANG rather than NETCONF. >=20 > But yes, it'd be nice to work out how to do this. >=20 >=20 > I am concerned about the NETMOD WG's perception that it can > change NETCONF normative behavior by changing YANG.=20 I never suggested changing YANG (and I don't think Juergen did either). = I meant that my "1.1" comment was because I was thinking of the YANG 1.1 = process. Giles > I do not see how "extra" RPC replies can be considered backward = compatible. > If the message-id doesn't change they will look like duplicate = replies. > If the message-id is new the client won't have a request to match = against it. > I do not think it would be good design to change the NETCONF RPC model = with > a sentence or 2 in a YANG description-stmt. >=20 > Giles >=20 > > /js >=20 > Andy > =20 > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From nobody Wed Jun 11 06:54:10 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E151A0123 for ; Wed, 11 Jun 2014 06:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBu8OUEnbZnt for ; Wed, 11 Jun 2014 06:53:54 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F261A00FC for ; Wed, 11 Jun 2014 06:53:52 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so4442088qcz.37 for ; Wed, 11 Jun 2014 06:53:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3YlcqL5B6iTRwWcbtKyJx2DZJuuiom6p8lMWez15oWw=; b=EjXaE78dNJjDnUBNbqodjCqlqIrK1ovk9mAHQuwBfr02J5t4aYJ7cgUztYpq6FIBGB ecztNFj0z78hksDzMupu1lXq2+dISLTmMir5dXcWtm1J7lPAMR3TFoqi8AdwF8HYJGVA L1N8fSTIgEPRL+BfapbNXEffg8WiBd4XWrRiLy05/KVrGP9dPWigzMFdb3auRT7uUlIb xOqjgWT4BtL7JwhV8QVGeBGCWdNxOQeN9u32eVEJDPetLDRNTTZ+XcvViGEjVl7YA53H 8OCc8TR6GzcMzwFDe7wbiS+ZCcmLkvIq2gS6Xn2Y+HDSVC9YbrrahX48mrOGJce0nktB 9xJQ== X-Gm-Message-State: ALoCoQmqqHgo/uZkuckH36aaj2Yk58XPMTzTxY/ohgLBYfNXmoNsJ8cKNEKqFDwsVWmIR6NxWTLO MIME-Version: 1.0 X-Received: by 10.140.36.105 with SMTP id o96mr48519291qgo.25.1402494832060; Wed, 11 Jun 2014 06:53:52 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 11 Jun 2014 06:53:51 -0700 (PDT) In-Reply-To: <20140611134539.GA33346@elstar.local> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BA3AB@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> <20140611125025.GA33218@elstar.local> <20140611134539.GA33346@elstar.local> Date: Wed, 11 Jun 2014 06:53:51 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Giles Heron , Zhengguangying , Netconf , Yangshouchuan , Yangang Content-Type: multipart/alternative; boundary=001a11c1733443cb1b04fb8fc6f5 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/cQXxwBH0_sirHtcKnWpMudSvbUY Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:54:01 -0000 --001a11c1733443cb1b04fb8fc6f5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 11, 2014 at 6:45 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 11, 2014 at 05:58:38AM -0700, Andy Bierman wrote: > > On Wed, Jun 11, 2014 at 5:50 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Wed, Jun 11, 2014 at 05:26:26AM -0700, Andy Bierman wrote: > > > > > > > I do not think it would be good design to change the NETCONF RPC > model > > > with > > > > a sentence or 2 in a YANG description-stmt. > > > > > > Nobody proposed that. > > > > > > > > > Sorry. So this would be a new protocol version for NETCONF? > > We would obsolete base:1.1 and create a base:1.2 or something like that? > > There will be no attempt to alter the RPC layer by any other means. > > > > I think even a capability could be sufficient. Here is a very rough > sketch: > > If a server announces :linked-replies and the client supports it as > well, the client can add an additional parameter to an rpc to > indicate the possible use of linked-replies. An old client will of > course never do this. Here is what a new client might do if it > wants to use linked replies: > > > > > The server can either simply send an rpc-reply or it starts sending > linked replies, e.g.: > > xmlns="..."> > > > xmlns="..."> > > > > > > Of course, there are lots of unclear questions concerning data > merging, error handling, how to send a cancel for a given link-id > (e.g., by sending a new message with a matching link-id) > and so on. I do not see that this would cause an interoperability > problem. Even if an old client would accidentally send a link-id, it > would simply pick the first rpc-reply and drop the rest because of > unknown message-ids. > > Anyway, there are tons of details to work out (also whether it is > necessary to negotiate linked rpc-reply sizes or whether it is good > enough for the server to decide freely as it likes). This is really > just a very very rough idea. However, it believe that thinking in this > direction may lead to better support for asynchronous rpcs and rpcs > that potentially return very large chunks of data than trying to solve > this problem without enhancements of the rpc layer. > > To me, it seems a capability is sufficient to achieve interoperability. > Of course, some people may argue that changes of the message layer go > too far for a capability. But then RFC 5277 also added a new message > using essentially just a capability - so there is already a precendence. > > OK - If the client and server both advertised the capability (ala base:1.1) then a new capability could work. The client is going to send message-id=103 so if the server sends a reply out of order, your solution will break. It would work better if the original message-id was retained and just the link-id kept changing. Not sure why a next-link-id is needed. Increment a uint32. { message-id, link-id } forms a set of unique tuples fo a given linked reply. Andy > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c1733443cb1b04fb8fc6f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 11, 2014 at 6:45 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 11, 2014 at 05:58:38AM -0700, An= dy Bierman wrote:
> On Wed, Jun 11, 2014 at 5:50 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Wed, Jun 11, 2014 at 05:26:26AM -0700, Andy Bierman wrote:
> >
> > > I do not think it would be good design to change the NETCONF= RPC model
> > with
> > > a sentence or 2 in a YANG description-stmt.
> >
> > Nobody proposed that.
> >
>
>
> Sorry. =A0So this would be a new protocol version for NETCONF?
> We would obsolete base:1.1 and create a base:1.2 or something like tha= t?
> There will be no attempt to alter the RPC layer by any other means. >

I think even a capability could be sufficient. Here is a very rough
sketch:

=A0 If a server announces :linked-replies and the client supports it as
=A0 well, the client can add an additional parameter to an rpc to
=A0 indicate the possible use of linked-replies. An old client will of
=A0 course never do this. Here is what a new client might do if it
=A0 wants to use linked replies:

=A0 <rpc message-id=3D"101" link-id=3D"123" xmlns=3D= "...">
=A0 </rpc>

=A0 The server can either simply send an rpc-reply or it starts sending
=A0 linked replies, e.g.:

=A0 <rpc-reply message-id=3D"101" next-message-id=3D"102&= quot; link-id=3D"123" xmlns=3D"...">
=A0 </rpc-reply>

=A0 <rpc-reply message-id=3D"102" next-message-id=3D"103&= quot; link-id=3D"123" xmlns=3D"...">
=A0 </rpc-reply>

=A0 <rpc-reply message-id=3D"103" link-id=3D"123" xm= lns=3D"...">
=A0 </rpc-reply>

Of course, there are lots of unclear questions concerning data
merging, error handling, how to send a cancel for a given link-id
(e.g., by sending a new <rpc-cancel> message with a matching link-id)=
and so on. I do not see that this would cause an interoperability
problem. Even if an old client would accidentally send a link-id, it
would simply pick the first rpc-reply and drop the rest because of
unknown message-ids.

Anyway, there are tons of details to work out (also whether it is
necessary to negotiate linked rpc-reply sizes or whether it is good
enough for the server to decide freely as it likes). This is really
just a very very rough idea. However, it believe that thinking in this
direction may lead to better support for asynchronous rpcs and rpcs
that potentially return very large chunks of data than trying to solve
this problem without enhancements of the rpc layer.

To me, it seems a capability is sufficient to achieve interoperability.
Of course, some people may argue that changes of the message layer go
too far for a capability. But then RFC 5277 also added a new message
using essentially just a capability - so there is already a precendence.

OK - If the client and server both advertised the ca= pability (ala base:1.1)
then a new capability could work. =A0The = client is going to send message-id=3D103 so
if the server sends a reply out of order, your solution will break.
It would work better if the original message-id was retained and ju= st the link-id
kept changing. Not sure why a next-link-id is need= ed. =A0Increment a uint32.

=A0 { message-id, link-id } forms a set of unique tuple= s fo a given linked reply.

Andy


=A0
/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--001a11c1733443cb1b04fb8fc6f5-- From nobody Fri Jun 13 02:32:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E331A039B for ; Fri, 13 Jun 2014 02:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7BxNtmuMG5b for ; Fri, 13 Jun 2014 02:32:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFB21A038C for ; Fri, 13 Jun 2014 02:32:24 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 8F1F9ECB041; Fri, 13 Jun 2014 11:32:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1402651941; bh=GKx8SugrRrfEXNhx2SA9Vj3bKjpw5n7e95pClQS62kA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=BbIEL1K7CP5nj9RCwVuUUdlaJoKcKiRj8h/tRrvSAJYQmekxoS5nzWhwvnbC6s3zS kC+lfwYAKGTfP0JpAoXrpqF6PDAfXvrNc15iWiPI6cBcQd9CUenj4Cy++e6IH+Kv3n c1UQwNyLkWf9NTusVYLXKpiz3eu+aG9pQw2bulAA= Message-ID: <539AC4D5.2040804@cesnet.cz> Date: Fri, 13 Jun 2014 11:31:01 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: feng.chong33@zte.com.cn, Andy Bierman References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040906010709070102040702" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-ycMeV9Y8eJ6Ktw66M6e3dk-WY4 Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xiao.yuqing@zte.com.cn Subject: Re: [Netconf] =?utf-8?b?562U5aSNOiBSZTogIFNvbWUgcXVlc3Rpb25zIGFib3V0?= =?utf-8?q?_the_usage_of_=27operation=27_attribute_in_edit-config?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 09:32:29 -0000 This is a multi-part message in MIME format. --------------040906010709070102040702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, Dne 10.6.2014 08:15, feng.chong33@zte.com.cn napsal(a): > /frank > > Andy Bierman 写于 2014-06-10 11:12:04: > > > Andy Bierman > > 2014-06-10 11:12 > > > > 收件人 > > > > feng.chong33@zte.com.cn, > > > > 抄送 > > > > dou.wei1@zte.com.cn, Netconf , > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > 主题 > > > > Re: [Netconf] Some questions about the usage of 'operation' > > attribute in edit-config > > > > > > > On Mon, Jun 9, 2014 at 7:20 PM, wrote: > > /frank > > > > Andy Bierman 写于 2014-06-10 09:01:16: > > > > > Andy Bierman > > > 2014-06-10 09:01 > > > > > > 收件人 > > > > > > feng.chong33@zte.com.cn, > > > > > > 抄送 > > > > > > dou.wei1@zte.com.cn, Netconf , > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > 主题 > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > attribute in edit-config > > > > > > > > > > > On Mon, Jun 9, 2014 at 5:46 PM, wrote: > > > /frank > > > > > > Andy Bierman 写于 2014-06-09 22:19:25: > > > > > > > Andy Bierman > > > > 2014-06-09 22:19 > > > > > > > > 收件人 > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > 抄送 > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > 主题 > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > attribute in edit-config > > > > > > > > > > > > > > > On Sun, Jun 8, 2014 at 10:40 PM, wrote: > > > > /frank > > > > > > > > Andy Bierman 写于 2014-06-09 11:44:58: > > > > > > > > > Andy Bierman > > > > > 2014-06-09 11:44 > > > > > > > > > > 收件人 > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > 抄送 > > > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > > > 主题 > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > On Sun, Jun 8, 2014 at 8:18 PM, wrote: > > > > > Andy, > > > > > thanks,:) > > > > > I understand only presence container or leaf node with > empty type > > > > > can be placed 'replace' attribute > > > > > and have a empty node subtree. Is it right? > > > > > > > > > > > > > > > no. any container. anyxml. empty leaf. zero-length string leaf. > > > > > > > > > Really? a NP container can be a valid configuration itself? > > > > > > > > > > > Yes -- there is some confusion because it is widely believed that > > > NPcontainers > > > > have no semantics -- but this is false. They are collections. > > > > must-stmt validation > > > > that fails on an NP-container will cause the edit/commit to fail > > > > just like any other node. > > > > > > > > > > I don't agree. I think NP-container MUST not be a valid > > > configuration if it has no children, > > > even if NP-container has some semantics, in that case, NP-container > > > just act as a unit can be > > > evaluated or validated. > > > > > > If a NP-container can be a valid configuration itself, what's the > > > difference between NP-container and presence container? > > > > > > > > A presence container's existence has some data model semantics > described in > > > the text value for that statement. A non-presence container is a > > > collection without > > > additional semantics for the existence of an empty container. > > > > > > There is no text that supports your claim. > > > > > > Note this text in sec. 7.5.8: > > > > > > > > > If a container does not have a "presence" statement and the last > > > child node is deleted, the NETCONF server MAY delete the container. > > > Note MAY instead of SHOULD or MUST. > > > You can treat an empty replace operation as a delete of an NP > container > > > in your implementation. Other servers can keep them in the data > model. > > > > > > > In section 7.5.1: > > "In the first style, the container has no meaning of its own, existing > > only to contain child nodes. This is the default style." > > > > If a NP container exists only to contain child nodes, why itself can > > be accepted > > as a valid configuration? > > > > > I can't find any text in any RFC that says to reject an empty NP > > container as invalid config. > > I can find text that says you MAY delete them. So do what you want in > > your implementation. > > > > No, if a NP container itself can be accepted as valid configuration, and > sever delete it, client can use 'replace' as remove, 'merge' as remove. > > If sever can decide whether support it. what client can do? If client > send > a request to replace a NP container with a element contains empty > node, the > response is uncertain. > but the empty NP container has no information value. It doesn't matter if the server deletes it or not. If you want to be sure, that the container will be removed, use 'remove' operation. > I think it's so bad for interoperability. I suggest NETCONF/NETMOD WGs > reject > the NP container itself as invalid configuration. It's no any value > and would > cause confusion. > I don't think this is an issue. Radek > > > Andy > > > > > > > > > > > They are not as standard as other YANG data nodes because a > > serverMAY choose > > > > to delete these nodes. Some server implementations even create them, > > > > although the > > > > spec is silent on this point. > > > > > > > > As Lada pointed out, the server flexibility for NP-containers is > > > > more of a bug than a feature. > > > > > > > > BTW, empty bits is another empty node that is legal (for replace > > operation). > > > > You can replace a leaf-list with itself (the instance containing the > > > > empty node, if any). > > > > > > If leaf-list can be replace with itself, then the list can be > > > replace with itself also. > > > Then all nodes container empty node should be considered to be a > > > valid configuration? > > > > > > > > But then you would be providing list keys, and the container would > > > not be empty. > > > Replacing a list entry with just the keys is the same as deleting > > > all the non-key child nodes. > > > > > > > > > I think WG should give a more clear clarification. > > > > > > Sec. 7.5.8 could be clearer because it implies that this behavior > > > only applies to the "delete" operation. It should be explicit that > > > "remove" and "replace" > > > can also cause the last child in an NP container to be deleted. > > > > > > > > > > > > IMO I think only NP-container,empty leaf, anyxml, zero-length string > > > or binary, bits can be a valid configuration itself. > > > > > > > > > /frank > > > > > > > > Andy > > > > > > Andy > > > > > > > > > > > > > > > > > Andy Bierman 写于 2014-06-09 10:36:16: > > > > > > > > > > > Andy Bierman > > > > > > 2014-06-09 10:36 > > > > > > > > > > > > 收件人 > > > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > > > 抄送 > > > > > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > > > > > 主题 > > > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jun 8, 2014 at 6:18 PM, > wrote: > > > > > > Andy， > > > > > > I have looked through this section for many times. In my > > > > > opinion, I think > > > > > > the element contains attribute 'replace' must have subtree, and > > > > > this subtree > > > > > > should be a valid configuration. But my colleagues don't > think so, > > > > > > they argued > > > > > > that the empty configuration is also configuration, they > want to > > > > > use'replace' > > > > > > as 'remove', I can't persuade them, :) > > > > > > So,I want to get a clarification, thanks. > > > > > > > > > > > > you are both right ;-) > > > > > > > > > > > > the replace attribute does have to appear in a subtree, but a > > > > subtree may be > > > > > > an empty node (if it is schema valid). > > > > > > > > > > > > start: > > > > > > > > > > > > > > > > > > > > > > > > 42 > > > > > > > > > > > > > > > > > > > > > > > > replace foo: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > result: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The text seems very clear to me. > > > > > > > > > > > > /frank > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > In your example, the 'foo' MUST be a presence container? > > > > > > > > > > > > > > > > > Andy Bierman 写于 2014-06-07 02:43:28: > > > > > > > > > > > > > Andy Bierman > > > > > > > 2014-06-07 02:43 > > > > > > > > > > > > > > 收件人 > > > > > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > > > > > 抄送 > > > > > > > > > > > > > > dou.wei1@zte.com.cn, Netconf , > > > > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn > > > > > > > > > > > > > > 主题 > > > > > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 5, 2014 at 11:18 PM, > wrote: > > > > > > > andy, > > > > > > > Thanks a lot. > > > > > > > Can you answer the first question? 'replace' can be used > > > as'remove'? > > > > > > > > > > > > > > Read RFC 6241, sec. 7.2 Attributes section. > > > > > > > It explains the difference between the NETCONF > > > > operations. > > > > > > > > > > > > > > > > > > > > > /frank > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > Andy Bierman 写于 2014-06-05 23:46:53: > > > > > > > > > > > > > > > Andy Bierman > > > > > > > > 2014-06-05 23:46 > > > > > > > > > > > > > > > > 收件人 > > > > > > > > > > > > > > > > feng.chong33@zte.com.cn, > > > > > > > > > > > > > > > > 抄送 > > > > > > > > > > > > > > > > Netconf , ye.xu1@zte.com.cn, > dou.wei1@zte.com.cn > > , > > > > > > > > xiao.yuqing@zte.com.cn > > > > > > > > > > > > > > > > 主题 > > > > > > > > > > > > > > > > Re: [Netconf] Some questions about the usage of 'operation' > > > > > > > > attribute in edit-config > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 4, 2014 at 6:35 PM, > wrote: > > > > > > > > Hi all, > > > > > > > > I have some questions about the usage of > 'operation'attribute > > > > > > > > in edit-config. > > > > > > > > 1. 'replace' attribute can only be used to remove > > configuration? > > > > > > > > For example, the rpc request listed below is valid? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.How to process nested operation attribute? > > > > > > > > For example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eth0/0/0 > > > > > > > > > > > > > > > > true > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The sequence of process is merge interface name > > 'eth0/0/0' and > > > > > > > > remove mtu and merge enabled to 'true' > > > > > > > > or merge interface name > > 'eth0/0/0' and > > > > > > > > merge enabled to 'true' and remove mtu? > > > > > > > > In other words, NETCONF will process outer layer > operation > > > > > > > > firstly and process inner layer operation later, or process > > > > > > > > operations in accordance with XML tree traversal order? > > > > > > > > > > > > > > > > > > > > > > > > There is no required processing order. > > > > > > > > It is an implementation detail. > > > > > > > > Some things to consider: > > > > > > > > 1) all operations are against the target datastore at > > the start of > > > > > > > > the operation > > > > > > > > 2) the operations are all-or-none, not incremental > > > > > > > > 2a) this implies that create within delete, or delete > within > > > > > > > > create, is always an error > > > > > > > > because 'data-exists' or 'data-missing' must be true > > > > > > > > > > > > > > > > In your example there is no problem because 'remove' > > works even if > > > > > > > > the data is missing. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3. If other operation attribute nested in operation > attribute > > > > > > > > 'remove',what should NETCONF server do? Only process remove > > > > operation? > > > > > > > > > > > > > > > > 4. Can NETCONF support the nested operation attribute > equals to > > > > > > > > parent operation attribute? > > > > > > > > > > > > > > > > /frank > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > > > > ZTE Information Security Notice: The information > > contained in this > > > > > > > > mail (and any attachment transmitted herewith) is > privileged and > > > > > > > > confidential and is intended for the exclusive use of > > the addressee > > > > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > > > > reproduction, distribution or other dissemination or use > of the > > > > > > > > information contained is strictly prohibited. If you > > havereceived > > > > > > > > this mail in error, please delete it and notify us > immediately. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Netconf mailing list > > > > > > > > Netconf@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > > > ZTE Information Security Notice: The information contained > in this > > > > > > > mail (and any attachment transmitted herewith) is > privileged and > > > > > > > confidential and is intended for the exclusive use of the > addressee > > > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > > > reproduction, distribution or other dissemination or use > of the > > > > > > > information contained is strictly prohibited. If you > havereceived > > > > > > > this mail in error, please delete it and notify us > immediately. > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > > ZTE Information Security Notice: The information contained > in this > > > > > > mail (and any attachment transmitted herewith) is privileged > and > > > > > > confidential and is intended for the exclusive use of the > addressee > > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > > reproduction, distribution or other dissemination or use of the > > > > > > information contained is strictly prohibited. If you have > received > > > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > ZTE Information Security Notice: The information contained in > this > > > > > mail (and any attachment transmitted herewith) is privileged and > > > > > confidential and is intended for the exclusive use of the > addressee > > > > > (s). If you are not an intended recipient, any disclosure, > > > > > reproduction, distribution or other dissemination or use of the > > > > > information contained is strictly prohibited. If you have > received > > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > ZTE Information Security Notice: The information contained in this > > > > mail (and any attachment transmitted herewith) is privileged and > > > > confidential and is intended for the exclusive use of the addressee > > > > (s). If you are not an intended recipient, any disclosure, > > > > reproduction, distribution or other dissemination or use of the > > > > information contained is strictly prohibited. If you have received > > > > this mail in error, please delete it and notify us immediately. > > > > > > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail (and any attachment transmitted herewith) is privileged and > > > confidential and is intended for the exclusive use of the addressee > > > (s). If you are not an intended recipient, any disclosure, > > > reproduction, distribution or other dissemination or use of the > > > information contained is strictly prohibited. If you have received > > > this mail in error, please delete it and notify us immediately. > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail (and any attachment transmitted herewith) is privileged and > > confidential and is intended for the exclusive use of the addressee > > (s). If you are not an intended recipient, any disclosure, > > reproduction, distribution or other dissemination or use of the > > information contained is strictly prohibited. If you have received > > this mail in error, please delete it and notify us immediately. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Radek Krejci mobile : +420 732 212 714 office : +420 234 680 256 e-mail : rkrejci@cesnet.cz LinkedIn: http://www.linkedin.com/in/radekkrejci CESNET Association of Legal Entities 160 00 Praha 6, Zikova 4 Czech Republic --------------040906010709070102040702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,

Dne 10.6.2014 08:15, feng.chong33@zte.com.cn napsal(a):
/frank

Andy Bierman <andy@yumaworks.com> 写于 2014-06-10 11:12:04:

> Andy Bierman <andy@yumaworks.com>
> 2014-06-10 11:12
>
> 收件人
>
> feng.chong33@zte.com.cn,
>
> 抄送
>
> dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
>
> 主题
>
> Re: [Netconf] Some questions about the usage of 'operation'
> attribute in edit-config
>
>

> On Mon, Jun 9, 2014 at 7:20 PM, <feng.chong33@zte.com.cn> wrote:
> /frank
>
> Andy Bierman <andy@yumaworks.com> 写于 2014-06-10 09:01:16:
>
> > Andy Bierman <andy@yumaworks.com>
> > 2014-06-10 09:01
> >
> > 收件人
> >
> > feng.chong33@zte.com.cn,
> >
> > 抄送
> >
> > dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> >
> > 主题
> >
> > Re: [Netconf] Some questions about the usage of 'operation'
> > attribute in edit-config
> >
> >
>
> > On Mon, Jun 9, 2014 at 5:46 PM, <feng.chong33@zte.com.cn> wrote:
> > /frank
> >
> > Andy Bierman <andy@yumaworks.com> 写于 2014-06-09 22:19:25:
> >
> > > Andy Bierman <andy@yumaworks.com>
> > > 2014-06-09 22:19
> > >
> > > 收件人
> > >
> > > feng.chong33@zte.com.cn,
> > >
> > > 抄送
> > >
> > > dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > >
> > > 主题
> > >
> > > Re: [Netconf] Some questions about the usage of 'operation'
> > > attribute in edit-config
> > >
> > >
> >
> > > On Sun, Jun 8, 2014 at 10:40 PM, <feng.chong33@zte.com.cn> wrote:
> > > /frank
> > >
> > > Andy Bierman <andy@yumaworks.com> 写于 2014-06-09 11:44:58:
> > >
> > > > Andy Bierman <andy@yumaworks.com>
> > > > 2014-06-09 11:44
> > > >
> > > > 收件人
> > > >
> > > > feng.chong33@zte.com.cn,
> > > >
> > > > 抄送
> > > >
> > > > dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > > >
> > > > 主题
> > > >
> > > > Re: [Netconf] Some questions about the usage of 'operation'
> > > > attribute in edit-config
> > > >
> > > >
> > >
> > > > On Sun, Jun 8, 2014 at 8:18 PM, <feng.chong33@zte.com.cn> wrote:
> > > > Andy,
> > > >    thanks,:)
> > > >    I understand only presence container or leaf node with empty type
> > > > can be placed 'replace' attribute
> > > > and have a empty node subtree. Is it right?
> > > >  
> > > >
> > > > no. any container. anyxml. empty leaf. zero-length string leaf.
> > > >
> > > Really? a NP container can be a valid configuration itself?
> >
> > >
> > > Yes -- there is some confusion because it is widely believed that
> > NPcontainers
> > > have no semantics -- but this is false.  They are collections.  
> > > must-stmt validation
> > > that fails on an NP-container will cause the edit/commit to fail
> > > just like any other node.
> > >
> >
> > I don't agree. I think NP-container MUST not be a valid
> > configuration if it has no children,
> > even if NP-container has some semantics, in that case, NP-container
> > just act as a unit can be
> > evaluated or validated.
> >
> > If a NP-container can be a valid configuration itself, what's the
> > difference between NP-container and presence container?
>
> >
> > A presence container's existence has some data model semantics described in
> > the text value for that statement.  A non-presence container is a
> > collection without
> > additional semantics for the existence of an empty container.
> >
> > There is no text that supports your claim.
> >
> > Note this text in sec. 7.5.8:
> >
> >
> >   If a container does not have a "presence" statement and the last
> >   child node is deleted, the NETCONF server MAY delete the container.
> > Note MAY instead of SHOULD or MUST.
> > You can treat an empty replace operation as a delete of an NP container
> > in your implementation.  Other servers can keep them in the data model.
> >
>
> In section 7.5.1:
> "In the first style, the container has no meaning of its own, existing
>    only to contain child nodes.  This is the default style."
>
> If a NP container exists only to contain child nodes, why itself can
> be accepted
> as a valid configuration?

>
> I can't find any text in any RFC that says to reject an empty NP
> container as invalid config.
> I can find text that says you MAY delete them. So do what you want in
> your implementation.
>

No, if a NP container itself can be accepted as valid configuration, and
sever delete it, client can use 'replace' as remove, 'merge' as remove.

If sever can decide whether support it. what client can do? If client send
a request to replace a NP container with a element contains empty node, the
response is uncertain.


but the empty NP container has no information value. It doesn't matter if the server deletes it or not. If you want to be sure, that the container will be removed, use 'remove' operation.

I think it's so bad for interoperability. I suggest NETCONF/NETMOD WGs reject
the NP container itself as invalid configuration. It's no any value and would
cause confusion.


I don't think this is an issue.

Radek


> Andy
>  
>
> >  
> > > They are not as standard as other YANG data nodes because a
> serverMAY choose
> > > to delete these nodes. Some server implementations even create them,
> > > although the
> > > spec is silent on this point.
> > >
> > > As Lada pointed out, the server flexibility for NP-containers is
> > > more of a bug than a feature.
> > >
> > > BTW, empty bits is another empty node that is legal (for replace
> operation).
> > > You can replace a leaf-list with itself (the instance containing the
> > > empty node, if any).
> >
> > If leaf-list can be replace with itself, then the list can be
> > replace with itself also.
> > Then all nodes container empty node should be considered to be a
> > valid configuration?
>
> >
> > But then you would be providing list keys, and the container would
> > not be empty.
> > Replacing a list entry with just the keys is the same as deleting
> > all the non-key child nodes.
> >
> >  
> > I think WG should give a more clear clarification.
> >
> > Sec. 7.5.8 could be clearer because it implies that this behavior
> > only applies to the "delete" operation.  It should be explicit that
> > "remove" and "replace"
> > can also cause the last child in an NP container to be deleted.
> >
> >
> >
> > IMO I think only NP-container,empty leaf, anyxml, zero-length string
> > or binary, bits can be a valid configuration itself.
> > >  
> > > > /frank
> > >
> > > Andy
> >
> > Andy
> >  
> > >  
> > > >
> > > > Andy Bierman <andy@yumaworks.com> 写于 2014-06-09 10:36:16:
> > > >
> > > > > Andy Bierman <andy@yumaworks.com>
> > > > > 2014-06-09 10:36
> > > > >
> > > > > 收件人
> > > > >
> > > > > feng.chong33@zte.com.cn,
> > > > >
> > > > > 抄送
> > > > >
> > > > > dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > > > >
> > > > > 主题
> > > > >
> > > > > Re: [Netconf] Some questions about the usage of 'operation'
> > > > > attribute in edit-config
> > > > >
> > > > >
> > > >
> > > > > On Sun, Jun 8, 2014 at 6:18 PM, <feng.chong33@zte.com.cn> wrote:
> > > > > Andy，
> > > > >     I have looked through this section for many times. In my
> > > > opinion, I think
> > > > > the element contains attribute 'replace' must have subtree, and
> > > > this subtree
> > > > > should be a valid configuration. But my colleagues don't think so,
> > > > > they argued
> > > > > that the empty configuration is also configuration, they want to
> > > > use'replace'
> > > > > as 'remove', I can't persuade them, :)
> > > > >     So,I want to get a clarification, thanks.
> > > > >
> > > > > you are both right ;-)
> > > > >
> > > > > the replace attribute does have to appear in a subtree, but a
> > > subtree may be
> > > > > an empty node (if it is schema valid).
> > > > >
> > > > > start:
> > > > >
> > > > >   <config>
> > > > >      <foo>
> > > > >         <a>42</a>
> > > > >      </foo>
> > > > >   </config>
> > > > >
> > > > > replace foo:
> > > > >
> > > > >  <config>
> > > > >      <foo operation="replace" />
> > > > >   </config>
> > > > >
> > > > > result:
> > > > >
> > > > >   <config>
> > > > >      <foo />
> > > > >   </config>
> > > > >
> > > > > The text seems very clear to me.
> > > > >
> > > > > /frank
> > > > >
> > > > > Andy
> > > > >
> > > >
> > > > In your example, the 'foo' MUST be a presence container?
> > > >  
> > > > >
> > > > > Andy Bierman <andy@yumaworks.com> 写于 2014-06-07 02:43:28:
> > > > >
> > > > > > Andy Bierman <andy@yumaworks.com>
> > > > > > 2014-06-07 02:43
> > > > > >
> > > > > > 收件人
> > > > > >
> > > > > > feng.chong33@zte.com.cn,
> > > > > >
> > > > > > 抄送
> > > > > >
> > > > > > dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>,
> > > > > > xiao.yuqing@zte.com.cn, ye.xu1@zte.com.cn
> > > > > >
> > > > > > 主题
> > > > > >
> > > > > > Re: [Netconf] Some questions about the usage of 'operation'
> > > > > > attribute in edit-config
> > > > > >
> > > > > >
> > > > >
> > > > > > On Thu, Jun 5, 2014 at 11:18 PM, <feng.chong33@zte.com.cn> wrote:
> > > > > > andy,
> > > > > >    Thanks a lot.
> > > > > >    Can you answer the first question? 'replace' can be used
> > as'remove'?
> > > > > >
> > > > > > Read RFC 6241, sec. 7.2 Attributes section.
> > > > > > It explains the difference between the NETCONF <edit-config>
> > > operations.
> > > > > >
> > > > > >  
> > > > > > /frank
> > > > > >
> > > > > > Andy
> > > > > >  
> > > > > >
> > > > > > Andy Bierman <andy@yumaworks.com> 写于 2014-06-05 23:46:53:
> > > > > >
> > > > > > > Andy Bierman <andy@yumaworks.com>
> > > > > > > 2014-06-05 23:46
> > > > > > >
> > > > > > > 收件人
> > > > > > >
> > > > > > > feng.chong33@zte.com.cn,
> > > > > > >
> > > > > > > 抄送
> > > > > > >
> > > > > > > Netconf <netconf@ietf.org>, ye.xu1@zte.com.cn, dou.wei1@zte.com.cn
> ,
> > > > > > > xiao.yuqing@zte.com.cn
> > > > > > >
> > > > > > > 主题
> > > > > > >
> > > > > > > Re: [Netconf] Some questions about the usage of 'operation'
> > > > > > > attribute in edit-config
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > > On Wed, Jun 4, 2014 at 6:35 PM, <feng.chong33@zte.com.cn> wrote:
> > > > > > > Hi all,
> > > > > > >    I have some questions about the usage of  'operation'attribute
> > > > > > > in edit-config.
> > > > > > >    1. 'replace' attribute can only be used to remove
> configuration?
> > > > > > >       For example, the rpc request listed below is valid?
> > > > > > >       <rpc message-id = "101">
> > > > > > >            <edit-config>
> > > > > > >                <target>
> > > > > > >                   <running/>
> > > > > > >                </target>
> > > > > > >                <config>
> > > > > > >                   <interfaces operation= "replace"/>
> > > > > > >                </config>
> > > > > > >            </edit-config>
> > > > > > >       </rpc>
> > > > > > >
> > > > > > >
> > > > > > >    2.How to process nested operation attribute?
> > > > > > >      For example:
> > > > > > >            <rpc message-id = "101">
> > > > > > >            <edit-config>
> > > > > > >                <target>
> > > > > > >                   <running/>
> > > > > > >                </target>
> > > > > > >                <config>
> > > > > > >                   <interfaces>
> > > > > > >                       <interface operation= "merge">
> > > > > > >                            <name>eth0/0/0</name>
> > > > > > >                            <mtu operation= "remove">
> > > > > > >                            <enabled>true</enalbled>
> > > > > > >                       </interface>
> > > > > > >                   </interfaces>
> > > > > > >                </config>
> > > > > > >            </edit-config>
> > > > > > >       </rpc>
> > > > > > >
> > > > > > >      The sequence of process is merge interface name
> 'eth0/0/0' and
> > > > > > > remove mtu and merge enabled to 'true'
> > > > > > >                              or merge interface name
> 'eth0/0/0' and
> > > > > > > merge enabled to 'true' and remove mtu?
> > > > > > >      In other words, NETCONF will process outer layer operation
> > > > > > > firstly and process inner layer operation later, or process
> > > > > > > operations in accordance with XML tree traversal order?
> > > > > > >  
> > > > > > >
> > > > > > > There is no required processing order.
> > > > > > > It is an implementation detail.
> > > > > > > Some things to consider:
> > > > > > >   1) all operations are against the target datastore at
> the start of
> > > > > > > the operation
> > > > > > >   2) the operations are all-or-none, not incremental
> > > > > > >   2a) this implies that create within delete, or delete within
> > > > > > > create, is always an error
> > > > > > >        because 'data-exists' or 'data-missing' must be true
> > > > > > >
> > > > > > > In your example there is no problem because 'remove'
> works even if
> > > > > > > the data is missing.
> > > > > > >
> > > > > > >          
> > > > > > >
> > > > > > > 3. If other operation attribute nested in operation attribute
> > > > > > > 'remove',what should NETCONF server do? Only process remove
> > > operation?
> > > > > > >
> > > > > > >   4. Can NETCONF support the nested operation attribute equals to
> > > > > > > parent operation attribute?
> > > > > > >      
> > > > > > > /frank
> > > > > > >
> > > > > > > Andy
> > > > > > >  
> > > > > > >
> > > > > > > --------------------------------------------------------
> > > > > > > ZTE Information Security Notice: The information
> contained in this
> > > > > > > mail (and any attachment transmitted herewith) is privileged and
> > > > > > > confidential and is intended for the exclusive use of
> the addressee
> > > > > > > (s).  If you are not an intended recipient, any disclosure,
> > > > > > > reproduction, distribution or other dissemination or use of the
> > > > > > > information contained is strictly prohibited.  If you
> havereceived
> > > > > > > this mail in error, please delete it and notify us immediately.
> > > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Netconf mailing list
> > > > > > > Netconf@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/netconf
> > > > >
> > > > > >
> > > > > > --------------------------------------------------------
> > > > > > ZTE Information Security Notice: The information contained in this
> > > > > > mail (and any attachment transmitted herewith) is privileged and
> > > > > > confidential and is intended for the exclusive use of the addressee
> > > > > > (s).  If you are not an intended recipient, any disclosure,
> > > > > > reproduction, distribution or other dissemination or use of the
> > > > > > information contained is strictly prohibited.  If you havereceived
> > > > > > this mail in error, please delete it and notify us immediately.
> > > > > >
> > > >
> > > > >
> > > > > --------------------------------------------------------
> > > > > ZTE Information Security Notice: The information contained in this
> > > > > mail (and any attachment transmitted herewith) is privileged and
> > > > > confidential and is intended for the exclusive use of the addressee
> > > > > (s).  If you are not an intended recipient, any disclosure,
> > > > > reproduction, distribution or other dissemination or use of the
> > > > > information contained is strictly prohibited.  If you have received
> > > > > this mail in error, please delete it and notify us immediately.
> > > > >
> > >
> > > >
> > > > --------------------------------------------------------
> > > > ZTE Information Security Notice: The information contained in this
> > > > mail (and any attachment transmitted herewith) is privileged and
> > > > confidential and is intended for the exclusive use of the addressee
> > > > (s).  If you are not an intended recipient, any disclosure,
> > > > reproduction, distribution or other dissemination or use of the
> > > > information contained is strictly prohibited.  If you have received
> > > > this mail in error, please delete it and notify us immediately.
> > > >
> >
> > >
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > > mail (and any attachment transmitted herewith) is privileged and
> > > confidential and is intended for the exclusive use of the addressee
> > > (s).  If you are not an intended recipient, any disclosure,
> > > reproduction, distribution or other dissemination or use of the
> > > information contained is strictly prohibited.  If you have received
> > > this mail in error, please delete it and notify us immediately.
> > >
>
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the addressee
> > (s).  If you are not an intended recipient, any disclosure,
> > reproduction, distribution or other dissemination or use of the
> > information contained is strictly prohibited.  If you have received
> > this mail in error, please delete it and notify us immediately.
> >

>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail (and any attachment transmitted herewith) is privileged and
> confidential and is intended for the exclusive use of the addressee
> (s).  If you are not an intended recipient, any disclosure,
> reproduction, distribution or other dissemination or use of the
> information contained is strictly prohibited.  If you have received
> this mail in error, please delete it and notify us immediately.
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.





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


-- 
Radek Krejci
mobile  : +420 732 212 714
office  : +420 234 680 256
e-mail  : rkrejci@cesnet.cz
LinkedIn: http://www.linkedin.com/in/radekkrejci

CESNET
Association of Legal Entities
160 00 Praha 6, Zikova 4
Czech Republic
--------------040906010709070102040702-- From nobody Fri Jun 13 09:49:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E091B27DF for ; Fri, 13 Jun 2014 09:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzpo2s9mhjpK for ; Fri, 13 Jun 2014 09:49:17 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 06CA81B29A1 for ; Fri, 13 Jun 2014 09:49:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oEW9avikDJykfVwP+F676zWwufTWskeNRGERX+r9VHNuoPkmdqVQhbXA0hAPzijA; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WvUey-0005VY-Vc for netconf@ietf.org; Fri, 13 Jun 2014 12:49:00 -0400 Received: from 99.187.238.242 by webmail.earthlink.net with HTTP; Fri, 13 Jun 2014 12:49:00 -0400 Message-ID: <14198987.1402678140890.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Fri, 13 Jun 2014 09:49:00 -0700 (GMT-07:00) From: Randy Presuhn To: Netconf Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd81fc7b511afdc14b87a6c1b28886a754ea350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7yL8pCpEu5WcE1uPo4ft93XuRFs Subject: Re: [Netconf] =?utf-8?b?562U5aSNOiBSZTogIFNvbWUgcXVlc3Rpb25zIGFib3V0?= =?utf-8?q?_the_usage_of_=27operation=27_attribute_in_edit-config?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:49:18 -0000 Hi - >From: Radek Krej=C4=8D=C3=AD >Sent: Jun 13, 2014 2:31 AM >To: feng.chong33@zte.com.cn, Andy Bierman >Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , xi= ao.yuqing@zte.com.cn >Subject: Re: [Netconf] =E7=AD=94=E5=A4=8D: Re: Some questions about the u= sage of 'operation' attribute in edit-config ... >Dne 10.6.2014 08:15, feng.chong33@zte.com.cn napsal(a): ... >> No, if a NP container itself can be accepted as valid configuration, and >> sever delete it, client can use 'replace' as remove, 'merge' as remove. >> >> If sever can decide whether support it. what client can do? If client >> send >> a request to replace a NP container with a element contains empty >> node, the >> response is uncertain. >> > >but the empty NP container has no information value. It doesn't matter >if the server deletes it or not. If you want to be sure, that the >container will be removed, use 'remove' operation. > >> I think it's so bad for interoperability. I suggest NETCONF/NETMOD WGs >> reject >> the NP container itself as invalid configuration. It's no any value >> and would >> cause confusion. >> > >I don't think this is an issue. One of the basic tasks in configuration management is to compare two configurations to determine whether they differ. This behaviour complicates something that should be trivial. Randy From nobody Fri Jun 13 10:00:56 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481981B27AE for ; Fri, 13 Jun 2014 10:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1UjHMXpj_Ej for ; Fri, 13 Jun 2014 10:00:50 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881921B2957 for ; Fri, 13 Jun 2014 10:00:47 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id m20so4297908qcx.41 for ; Fri, 13 Jun 2014 10:00:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oQ5rz8cNdc4iEj19NhWzmn6iKILElcV6VFYQ9xoOlcg=; b=fP3NCwQI7h0S8mHG+iTDQtuS5UQbBA5z/9W+pjh/WUWbUCqy/3sPKczHT024JdZZaj NstKTSCgi6nHs5kg7obaFKVxTzxiQfsBGegZhOqcYn7fiZgylS70TqeiztwuZpGVI3Dw A2IZg2CNx0HAcOI7vCQPcXAigK6JJRX+ZMPaLSOxp8VP9k662eCgEvpd51PYyiASKavc aoN0zOYAHxnm0tsFDk/milIieCovS6pQsAJZQ9ns7fxKe8T5nsGzBJeiyasN8Aitt3XT e7OVgMaE4NF7jRW334oiuZqziH3ZexLI21v/LZFvwCI7QPTXrR3qsAy6vyBIsVxhcTeU bvaQ== X-Gm-Message-State: ALoCoQn/p3mAH9YGfJFQZ9B1Jsv291vmPkinLe0Ni6JMiH1ry2LE0H2RpvsQ5/O+APck6B+S+GSn MIME-Version: 1.0 X-Received: by 10.224.20.10 with SMTP id d10mr5591946qab.16.1402678846702; Fri, 13 Jun 2014 10:00:46 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Fri, 13 Jun 2014 10:00:46 -0700 (PDT) In-Reply-To: <14198987.1402678140890.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> References: <14198987.1402678140890.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Fri, 13 Jun 2014 10:00:46 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=001a11c1c2ae649e7f04fbba9e19 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xubib2K2HSFzoomAaS0SAmFGsus Cc: Netconf Subject: Re: [Netconf] =?utf-8?b?562U5aSNOiBSZTogU29tZSBxdWVzdGlvbnMgYWJvdXQg?= =?utf-8?q?the_usage_of_=27operation=27_attribute_in_edit-config?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:00:54 -0000 --001a11c1c2ae649e7f04fbba9e19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 13, 2014 at 9:49 AM, Randy Presuhn wrote: > Hi - > > >From: Radek Krej=C4=8D=C3=AD > >Sent: Jun 13, 2014 2:31 AM > >To: feng.chong33@zte.com.cn, Andy Bierman > >Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , > xiao.yuqing@zte.com.cn > >Subject: Re: [Netconf] =E7=AD=94=E5=A4=8D: Re: Some questions about the= usage of > 'operation' attribute in edit-config > ... > >Dne 10.6.2014 08:15, feng.chong33@zte.com.cn napsal(a): > ... > >> No, if a NP container itself can be accepted as valid configuration, a= nd > >> sever delete it, client can use 'replace' as remove, 'merge' as remove= . > >> > >> If sever can decide whether support it. what client can do? If client > >> send > >> a request to replace a NP container with a element contains empty > >> node, the > >> response is uncertain. > >> > > > >but the empty NP container has no information value. It doesn't matter > >if the server deletes it or not. If you want to be sure, that the > >container will be removed, use 'remove' operation. > > > >> I think it's so bad for interoperability. I suggest NETCONF/NETMOD WGs > >> reject > >> the NP container itself as invalid configuration. It's no any value > >> and would > >> cause confusion. > >> > > > >I don't think this is an issue. > > One of the basic tasks in configuration management is to > compare two configurations to determine whether they differ. > This behaviour complicates something that should be trivial. > > It isn't trivial for many reasons. NP-containers are just 1 of them. Default leafs and system ordered lists (which are not ordered at all) also make trivial XML tree comparison unreliable. There are many aspects of server variability where a client developer would be wise to pay attention to the server minimum requirements and desig= n code accordingly. (e.g., why would you write code that depended on an empty NP container being present, knowing that servers are allowed to delete them?) Randy > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c1c2ae649e7f04fbba9e19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 9:49 AM, Randy Presuhn &l= t;randy_p= resuhn@mindspring.com> wrote:
Hi -

>From: Radek Krej=C4=8D=C3=AD <r= krejci@cesnet.cz>
>Sent: Jun 13, 2014 2:31 AM
>To: feng.chong33@zte.com.cn<= /a>, Andy Bierman <andy@yumaworks.= com>
>Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>, xiao.yuqing@zte.com.cn
>Subject: Re: [Netconf] =E7=AD=94=E5=A4=8D: Re: =C2=A0Some questions abo= ut the usage of 'operation' attribute in edit-config
...
>Dne 10.6.2014 08:15, feng.ch= ong33@zte.com.cn napsal(a):
...
>> No, if a NP container itself can be accepted as valid configuratio= n, and
>> sever delete it, client can use 'replace' as remove, '= merge' as remove.
>>
>> If sever can decide whether support it. what client can do? If cli= ent
>> send
>> a request to replace a NP container with a element contains empty<= br> >> node, the
>> response is uncertain.
>>
>
>but the empty NP container has no information value. It doesn't mat= ter
>if the server deletes it or not. If you want to be sure, that the
>container will be removed, use 'remove' operation.
>
>> I think it's so bad for interoperability. I suggest NETCONF/NE= TMOD WGs
>> reject
>> the NP container itself as invalid configuration. It's no any = value
>> and would
>> cause confusion.
>>
>
>I don't think this is an issue.

One of the basic tasks in configuration management is to
compare two configurations to determine whether they differ.
This behaviour complicates something that should be trivial.


It isn't trivial for many reasons.= NP-containers are just 1 of them.
Default leafs and system order= ed lists (which are not ordered at all)
also make trivial XML tre= e comparison unreliable.

There are many aspects of server variability where a cl= ient developer
would be wise to pay attention to the server minim= um requirements and design
code accordingly. (e.g., why would you= write code that depended on an
empty NP container being present, knowing that servers are allowed to<= /div>
delete them?)


Randy

Andy
=C2=A0

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

--001a11c1c2ae649e7f04fbba9e19-- From nobody Fri Jun 13 10:20:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391D81A0538 for ; Fri, 13 Jun 2014 10:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxXdM6QH8fDe for ; Fri, 13 Jun 2014 10:20:42 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2EC1A0190 for ; Fri, 13 Jun 2014 10:20:42 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id r5so828198qcx.22 for ; Fri, 13 Jun 2014 10:20:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rgaIxQ4EVkZV8la2lc+Y/Tl5bpsXy5SleEhSqBkAr9I=; b=mneLiVyTGa7a+PzkVN/ym2GkXoiQQUZHSMGhzKCgW2uPxh+DGcWT/Icrw47efrEzln CVc2O/SJE9CDZ2BRIhowMdpMR/svCGPajHNu8nbc+eIxMQDM6n7sHuPQpeOx/EQdCf+l 5yDFjIiE2A/3ZT9ZU0+QU2rW6AzJG2ywKQU6iAUmB+Dm4uoXBcPzlCvfYaWaCgzwwiB6 ndwYm9Aqc3VdLyXhQwpg78+WjgrnlogwTF+ZWqaVAobbxlPfIJ7V6/CWMzpbNN/fKA7Z qTth3ULcdTCRRtcXQz7z+x4feClmDePzfit7mtCfjpxCxLj8xyEwKEuNLCw8Nk5/MOYB LhdQ== X-Gm-Message-State: ALoCoQnuhqCpUFqnZqbywJax9lbOlGwIW62gpVtHR+wpTBt/IXzl7I1HdPj5FU5WViMoDzj81OmS MIME-Version: 1.0 X-Received: by 10.224.24.134 with SMTP id v6mr5855508qab.88.1402680041804; Fri, 13 Jun 2014 10:20:41 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Fri, 13 Jun 2014 10:20:41 -0700 (PDT) In-Reply-To: <14198987.1402678140890.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> References: <14198987.1402678140890.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Fri, 13 Jun 2014 10:20:41 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=001a11c252c6a0611704fbbae547 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yzgBmefGaw1Yyye3G4qVQ9ImIf4 Cc: Netconf Subject: Re: [Netconf] =?utf-8?b?562U5aSNOiBSZTogU29tZSBxdWVzdGlvbnMgYWJvdXQg?= =?utf-8?q?the_usage_of_=27operation=27_attribute_in_edit-config?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:20:44 -0000 --001a11c252c6a0611704fbbae547 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 13, 2014 at 9:49 AM, Randy Presuhn wrote: > Hi - > > >From: Radek Krej=C4=8D=C3=AD > >Sent: Jun 13, 2014 2:31 AM > >To: feng.chong33@zte.com.cn, Andy Bierman > >Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf , > xiao.yuqing@zte.com.cn > >Subject: Re: [Netconf] =E7=AD=94=E5=A4=8D: Re: Some questions about the= usage of > 'operation' attribute in edit-config > ... > >Dne 10.6.2014 08:15, feng.chong33@zte.com.cn napsal(a): > ... > >> No, if a NP container itself can be accepted as valid configuration, a= nd > >> sever delete it, client can use 'replace' as remove, 'merge' as remove= . > >> > >> If sever can decide whether support it. what client can do? If client > >> send > >> a request to replace a NP container with a element contains empty > >> node, the > >> response is uncertain. > >> > > > >but the empty NP container has no information value. It doesn't matter > >if the server deletes it or not. If you want to be sure, that the > >container will be removed, use 'remove' operation. > > > >> I think it's so bad for interoperability. I suggest NETCONF/NETMOD WGs > >> reject > >> the NP container itself as invalid configuration. It's no any value > >> and would > >> cause confusion. > >> > > > >I don't think this is an issue. > > One of the basic tasks in configuration management is to > compare two configurations to determine whether they differ. > This behaviour complicates something that should be trivial. > > To be clear -- I am in favor of changing the rules completely in YANG 1.1 so that empty NP containers MUST (conceptually) always be part of the config. XPath evaluation is currently implementation-dependent, which is much more than an inconvenience to YANG designers. Randy > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c252c6a0611704fbbae547 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 9:49 AM, Randy Presuhn &l= t;randy_p= resuhn@mindspring.com> wrote:
Hi -

>From: Radek Krej=C4=8D=C3=AD <r= krejci@cesnet.cz>
>Sent: Jun 13, 2014 2:31 AM
>To: feng.chong33@zte.com.cn<= /a>, Andy Bierman <andy@yumaworks.= com>
>Cc: ye.xu1@zte.com.cn, dou.wei1@zte.com.cn, Netconf <netconf@ietf.org>, xiao.yuqing@zte.com.cn
>Subject: Re: [Netconf] =E7=AD=94=E5=A4=8D: Re: =C2=A0Some questions abo= ut the usage of 'operation' attribute in edit-config
...
>Dne 10.6.2014 08:15, feng.ch= ong33@zte.com.cn napsal(a):
...
>> No, if a NP container itself can be accepted as valid configuratio= n, and
>> sever delete it, client can use 'replace' as remove, '= merge' as remove.
>>
>> If sever can decide whether support it. what client can do? If cli= ent
>> send
>> a request to replace a NP container with a element contains empty<= br> >> node, the
>> response is uncertain.
>>
>
>but the empty NP container has no information value. It doesn't mat= ter
>if the server deletes it or not. If you want to be sure, that the
>container will be removed, use 'remove' operation.
>
>> I think it's so bad for interoperability. I suggest NETCONF/NE= TMOD WGs
>> reject
>> the NP container itself as invalid configuration. It's no any = value
>> and would
>> cause confusion.
>>
>
>I don't think this is an issue.

One of the basic tasks in configuration management is to
compare two configurations to determine whether they differ.
This behaviour complicates something that should be trivial.


To be clear -- I am in favor of changi= ng the rules completely in YANG 1.1 so that empty
NP containers M= UST (conceptually) always be part of the config.
XPath evaluation= is currently implementation-dependent, which is much more than an
inconvenience to YANG designers.


Randy

Andy
=C2=A0

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

--001a11c252c6a0611704fbbae547-- From nobody Mon Jun 16 01:58:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C331B27EE for ; Mon, 16 Jun 2014 01:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3Q4ZFPXqUEz for ; Mon, 16 Jun 2014 01:58:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DF91A0225 for ; Mon, 16 Jun 2014 01:58:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A59CA707; Mon, 16 Jun 2014 10:57:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RZp4bL0BLbBY; Mon, 16 Jun 2014 10:57:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 16 Jun 2014 10:57:58 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15DBF20017; Mon, 16 Jun 2014 10:57:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hTMgjyWDTbQ0; Mon, 16 Jun 2014 10:57:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A0C420013; Mon, 16 Jun 2014 10:57:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8E6D32D7CEBA; Mon, 16 Jun 2014 10:57:56 +0200 (CEST) Date: Mon, 16 Jun 2014 10:57:56 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140616085756.GA73682@elstar.local> Mail-Followup-To: Andy Bierman , Giles Heron , Zhengguangying , Netconf , Yangshouchuan , Yangang References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> <20140611125025.GA33218@elstar.local> <20140611134539.GA33346@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/H3KbHO4uLwt3QKn4FeFTU1o6lZk Cc: Zhengguangying , Yangang , Netconf , Yangshouchuan Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 08:58:03 -0000 On Wed, Jun 11, 2014 at 06:53:51AM -0700, Andy Bierman wrote: > OK - If the client and server both advertised the capability (ala base:1.1) > then a new capability could work. The client is going to send > message-id=103 so > if the server sends a reply out of order, your solution will break. > It would work better if the original message-id was retained and just the > link-id > kept changing. Not sure why a next-link-id is needed. Increment a uint32. > > { message-id, link-id } forms a set of unique tuples fo a given linked > reply. Sure, the details can be worked out. The message-ids are pretty opaque in NETCONF and I just picked simple numbers and you are right that they might clash. My point was more that having a more powerful rpc layer would solve some problems in a much nicer way. In hindsight, if we would have had such a linked reply mechanism in the RPC layer, we likely would not have needed the special purpose message in RFC 5277. /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 Jun 16 03:54:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2E1B2BA3 for ; Mon, 16 Jun 2014 03:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMwtb6LEncHx for ; Mon, 16 Jun 2014 03:54:38 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B371E1B2BA7 for ; Mon, 16 Jun 2014 03:54:38 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so7552661qcz.28 for ; Mon, 16 Jun 2014 03:54:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=n8BdOoys00mvCXPYWDIZLsjnXpMSHE5/eSMoEwAcCQw=; b=VxpfaYtoPfTtlPyscYdWFTf9yiLiof/OLi+cuPZNEAqF87dY4NmzUB4Kdm4SEW6egr eimXJp32F43UEZvLMmlOhHZwDOnpdrWxsJrf7NNA5Pgp6HhzEnXHBQL3/uRFypW27xMZ wau4aL9P1zhjaV94qnKCKFWcjz4gShm070Fi7EBRcwCsXyU0RIpnphl13cS8bqSwuTck YArYis9lc+57iqOUtDRswhXKy79Fyi/Lf6Ei/ztMEYp4QJ9IyfV4AD10tNsRX5apM2KJ WN0bFcEhCo9ZwKLTuANBjbSR2dIBJ/Sk93LLH7vSiMXEJZvxD+asaogSSz+lCGY3VHXX Ol7g== X-Gm-Message-State: ALoCoQnzx6jfA8g7Z2L1cInig7isPcyx3to0Nx2MW7jsTXF/x+l89vcIML1LT3tkk5a8dXN+KAuI MIME-Version: 1.0 X-Received: by 10.224.24.134 with SMTP id v6mr9169902qab.88.1402916077664; Mon, 16 Jun 2014 03:54:37 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 16 Jun 2014 03:54:37 -0700 (PDT) In-Reply-To: <20140616085756.GA73682@elstar.local> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BB25F@nkgeml506-mbx.china.huawei.com> <20140611063312.GC32389@elstar.local> <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> <20140611125025.GA33218@elstar.local> <20140611134539.GA33346@elstar.local> <20140616085756.GA73682@elstar.local> Date: Mon, 16 Jun 2014 03:54:37 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Giles Heron , Zhengguangying , Netconf , Yangshouchuan , Yangang Content-Type: multipart/alternative; boundary=001a11c252c6758e9804fbf1da9c Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yDGj1P4OCRovz0tYpGdHBDtnxLo Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 10:54:41 -0000 --001a11c252c6758e9804fbf1da9c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 16, 2014 at 1:57 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 11, 2014 at 06:53:51AM -0700, Andy Bierman wrote: > > > OK - If the client and server both advertised the capability (ala > base:1.1) > > then a new capability could work. The client is going to send > > message-id=103 so > > if the server sends a reply out of order, your solution will break. > > It would work better if the original message-id was retained and just the > > link-id > > kept changing. Not sure why a next-link-id is needed. Increment a > uint32. > > > > { message-id, link-id } forms a set of unique tuples fo a given linked > > reply. > > Sure, the details can be worked out. The message-ids are pretty opaque > in NETCONF and I just picked simple numbers and you are right that > they might clash. > > not the point. They are client-selected strings. The only way the server can be 100% sure never to collide -- the server can never pick a message-id. (This field does not exist in a notification.) > My point was more that having a more powerful rpc layer would solve > some problems in a much nicer way. In hindsight, if we would have had > such a linked reply mechanism in the RPC layer, we likely would not > have needed the special purpose message in RFC 5277. > The notification message is needed because event notifications are not linked replies. Multiple replies per RPC request has some special purpose uses. > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c252c6758e9804fbf1da9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 16, 2014 at 1:57 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 11, 2014 at 06:53:51AM -0700, An= dy Bierman wrote:

> OK - If the client and server both advertised the capability (ala base= :1.1)
> then a new capability could work. =A0The client is going to send
> message-id=3D103 so
> if the server sends a reply out of order, your solution will break. > It would work better if the original message-id was retained and just = the
> link-id
> kept changing. Not sure why a next-link-id is needed. =A0Increment a u= int32.
>
> =A0 { message-id, link-id } forms a set of unique tuples fo a given li= nked
> reply.

Sure, the details can be worked out. The message-ids are pretty opaque
in NETCONF and I just picked simple numbers and you are right that
they might clash.


not the point. =A0They are client-sele= cted strings. =A0The only way the server can
be 100% sure never t= o collide -- =A0the server can never pick a message-id.
(This fie= ld does not exist in a notification.)

=A0
My point was more that having a more powerful rpc layer would solve
some problems in a much nicer way. In hindsight, if we would have had
such a linked reply mechanism in the RPC layer, we likely would not
have needed the special purpose <notification> message in RFC 5277.

The notification message is needed becau= se event notifications are not linked
replies. =A0Multiple replie= s per RPC request has some special purpose uses.

=A0

/js


Andy
=A0
=
--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--001a11c252c6758e9804fbf1da9c-- From nobody Mon Jun 16 04:01:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED8E1B2BB2 for ; Mon, 16 Jun 2014 04:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIRbNKokFgcm for ; Mon, 16 Jun 2014 04:01:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B491B2BAE for ; Mon, 16 Jun 2014 04:01:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CA9D6726; Mon, 16 Jun 2014 13:01:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1pczYUDFTkZz; Mon, 16 Jun 2014 13:01:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 16 Jun 2014 13:01:16 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A3B920013; Mon, 16 Jun 2014 13:01:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fclJvK7IC1ju; Mon, 16 Jun 2014 13:01:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F175320017; Mon, 16 Jun 2014 13:01:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D6B422D8DD46; Mon, 16 Jun 2014 13:01:13 +0200 (CEST) Date: Mon, 16 Jun 2014 13:01:13 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140616110113.GA187@elstar.local> Mail-Followup-To: Andy Bierman , Giles Heron , Zhengguangying , Netconf , Yangshouchuan , Yangang References: <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> <20140611125025.GA33218@elstar.local> <20140611134539.GA33346@elstar.local> <20140616085756.GA73682@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qlDUdDv_hTWSlAYpuRA799XF2Fo Cc: Zhengguangying , Yangang , Netconf , Yangshouchuan Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 11:01:23 -0000 On Mon, Jun 16, 2014 at 03:54:37AM -0700, Andy Bierman wrote: > On Mon, Jun 16, 2014 at 1:57 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Wed, Jun 11, 2014 at 06:53:51AM -0700, Andy Bierman wrote: > > > > > OK - If the client and server both advertised the capability (ala > > base:1.1) > > > then a new capability could work. The client is going to send > > > message-id=103 so > > > if the server sends a reply out of order, your solution will break. > > > It would work better if the original message-id was retained and just the > > > link-id > > > kept changing. Not sure why a next-link-id is needed. Increment a > > uint32. > > > > > > { message-id, link-id } forms a set of unique tuples fo a given linked > > > reply. > > > > Sure, the details can be worked out. The message-ids are pretty opaque > > in NETCONF and I just picked simple numbers and you are right that > > they might clash. > > > > > not the point. They are client-selected strings. The only way the > server can be 100% sure never to collide -- the server can never > pick a message-id. (This field does not exist in a notification.) OK. Pick some other field. > > My point was more that having a more powerful rpc layer would solve > > some problems in a much nicer way. In hindsight, if we would have had > > such a linked reply mechanism in the RPC layer, we likely would not > > have needed the special purpose message in RFC 5277. > > > > The notification message is needed because event notifications are > not linked replies. Multiple replies per RPC request has some > special purpose uses. Notification messages are not linked replies since linked replies did not exist. What I am saying is that at the end of the day, once could have modeled a 'create-subscription' rpc as a long lasting rpc, much like a 'ping' that runs indefinitely or a 'tail -f' that runs indefinitely. I think we created a special purpose solution for notifications but in hindsight it could have been equally possible to build a more general purpose mechanism. /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 Jun 16 07:25:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB681A0058 for ; Mon, 16 Jun 2014 07:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tad3YeTMlFe for ; Mon, 16 Jun 2014 07:25:07 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF271A0032 for ; Mon, 16 Jun 2014 07:25:07 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so6796827qcv.10 for ; Mon, 16 Jun 2014 07:25:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=A8dGfwXgCGTbeDpeu9Glih8+mU0iX2e2R4LshS4X8r8=; b=M+dv4Sll1O3S7dIzbFkHeiBLpSKjgorLRerRvh/ew8I2NAtwB3GxdF6Y2kiiMBs1IV fLW4dZb9vw+lU9pnexJ4jYtmuQOZMazlAKUO9zMCcuRMLAqAoIO/QWJznBv12fudiV2c VrjBYFc9UD8Y9O8pnSuCyyG08A73rOYx9d/Pj4YVRIQGVrn3wL+okvb7y1tUmYPS7dQw GuASLUAALsBfLy4U3vKpdkCCzcxOyR4ModfGAIAFS+kulddsH5ZeFSF0RXjnumKVYIlF r4SneddXRRTZTS5mKpeGD32WhmXKEmy/dXdMbIFBY6OXTs1UMJsHKJG0t8QSEjYPwcl3 r/BA== X-Gm-Message-State: ALoCoQka+IbK2I0aIZPb/zKjgLVGQ04u2VKlTorwhB+ud4XeHkCX6dSFniAWs0cWGujrehfttBow MIME-Version: 1.0 X-Received: by 10.140.36.17 with SMTP id o17mr25442737qgo.25.1402928706550; Mon, 16 Jun 2014 07:25:06 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 16 Jun 2014 07:25:06 -0700 (PDT) In-Reply-To: <20140616110113.GA187@elstar.local> References: <0E3CF594-AD96-42FA-B2FA-75491819C51C@gmail.com> <20140611101157.GA32889@elstar.local> <8323C2AD-65C8-493E-9C0E-5DF868A8B99B@gmail.com> <20140611125025.GA33218@elstar.local> <20140611134539.GA33346@elstar.local> <20140616085756.GA73682@elstar.local> <20140616110113.GA187@elstar.local> Date: Mon, 16 Jun 2014 07:25:06 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Giles Heron , Zhengguangying , Netconf , Yangshouchuan , Yangang Content-Type: multipart/alternative; boundary=001a11c174883313c004fbf4cbf9 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WhDslrsFpxtY9e9UvCX5P_3yXV4 Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:25:11 -0000 --001a11c174883313c004fbf4cbf9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 16, 2014 at 4:01 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jun 16, 2014 at 03:54:37AM -0700, Andy Bierman wrote: > > On Mon, Jun 16, 2014 at 1:57 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Wed, Jun 11, 2014 at 06:53:51AM -0700, Andy Bierman wrote: > > > > > > > OK - If the client and server both advertised the capability (ala > > > base:1.1) > > > > then a new capability could work. The client is going to send > > > > message-id=103 so > > > > if the server sends a reply out of order, your solution will break. > > > > It would work better if the original message-id was retained and > just the > > > > link-id > > > > kept changing. Not sure why a next-link-id is needed. Increment a > > > uint32. > > > > > > > > { message-id, link-id } forms a set of unique tuples fo a given > linked > > > > reply. > > > > > > Sure, the details can be worked out. The message-ids are pretty opaque > > > in NETCONF and I just picked simple numbers and you are right that > > > they might clash. > > > > > > > > not the point. They are client-selected strings. The only way the > > server can be 100% sure never to collide -- the server can never > > pick a message-id. (This field does not exist in a notification.) > > OK. Pick some other field. > You did -- the server always send the message-id the client first picked, and just increments the link-id { 101, 1 }, { 101, 2 }, { 101, 3 }, etc. > > > My point was more that having a more powerful rpc layer would solve > > > some problems in a much nicer way. In hindsight, if we would have had > > > such a linked reply mechanism in the RPC layer, we likely would not > > > have needed the special purpose message in RFC 5277. > > > > > > > The notification message is needed because event notifications are > > not linked replies. Multiple replies per RPC request has some > > special purpose uses. > > Notification messages are not linked replies since linked replies did > not exist. > > What I am saying is that at the end of the day, once could have > modeled a 'create-subscription' rpc as a long lasting rpc, much like a > 'ping' that runs indefinitely or a 'tail -f' that runs indefinitely. I > think we created a special purpose solution for notifications but in > hindsight it could have been equally possible to build a more general > purpose mechanism. > > OK - maybe we would have also decoupled the replay buffer features if we did it that way. In hindsight, we know that the XSD needs to be replaced by a YANG module, but we decided that was not worth doing. We implement source filtering in our server, since the standard filtering works on the output of the replay buffer. The WG might have thought more about how some event notifications can overwrite higher priority events in the ring buffer. IMO the lack of standardized fields such as 'severity' is a problem. A giant firehose stream called "NETCONF" is not that useful. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c174883313c004fbf4cbf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 16, 2014 at 4:01 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jun 16, 2014 at 03:54:37AM -0700, An= dy Bierman wrote:
> On Mon, Jun 16, 2014 at 1:57 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Wed, Jun 11, 2014 at 06:53:51AM -0700, Andy Bierman wrote:
> >
> > > OK - If the client and server both advertised the capability= (ala
> > base:1.1)
> > > then a new capability could work. =A0The client is going to = send
> > > message-id=3D103 so
> > > if the server sends a reply out of order, your solution will= break.
> > > It would work better if the original message-id was retained= and just the
> > > link-id
> > > kept changing. Not sure why a next-link-id is needed. =A0Inc= rement a
> > uint32.
> > >
> > > =A0 { message-id, link-id } forms a set of unique tuples fo = a given linked
> > > reply.
> >
> > Sure, the details can be worked out. The message-ids are pretty o= paque
> > in NETCONF and I just picked simple numbers and you are right tha= t
> > they might clash.
> >
> >
> not the point. =A0They are client-selected strings. =A0The only way th= e
> server can be 100% sure never to collide -- the server can never
> pick a message-id. =A0(This field does not exist in a notification.)
OK. Pick some other field.


You did -- the server always send the message-id the client first picked= ,
and just increments the link-id =A0{ 101, 1 }, { 101, 2 }, { 10= 1, 3 }, etc.



> > My point was more that having a more powerful rpc layer would sol= ve
> > some problems in a much nicer way. In hindsight, if we would have= had
> > such a linked reply mechanism in the RPC layer, we likely would n= ot
> > have needed the special purpose <notification> message in R= FC 5277.
> >
>
> The notification message is needed because event notifications are
> not linked replies. =A0Multiple replies per RPC request has some
> special purpose uses.

Notification messages are not linked replies since linked replies did
not exist.

What I am saying is that at the end of the day, once could have
modeled a 'create-subscription' rpc as a long lasting rpc, much lik= e a
'ping' that runs indefinitely or a 'tail -f' that runs inde= finitely. I
think we created a special purpose solution for notifications but in
hindsight it could have been equally possible to build a more general
purpose mechanism.



OK - maybe we would have also decoupl= ed the replay buffer features if
we did it that way. =A0In hindsi= ght, we know that the XSD needs to be
replaced by a YANG module, but we decided that was not worth doing.

We implement source filtering in our server, since t= he standard filtering works on the
output of the replay buffer. T= he WG might have thought more about how
some event notifications can overwrite higher priority events in the r= ing buffer.
IMO the lack of standardized fields such as 'seve= rity' is a problem.
A giant firehose stream called "NETC= ONF" is not that useful.


/js

Andy
=A0

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--001a11c174883313c004fbf4cbf9-- From nobody Mon Jun 16 09:23:10 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C31A00D7 for ; Mon, 16 Jun 2014 09:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNCJ9fwM117E for ; Mon, 16 Jun 2014 09:23:02 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7558B1A0107 for ; Mon, 16 Jun 2014 09:23:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ioSdtggheZpF9PqGjNhJusEUpLzlIfH3j9HCe8VALjobswJIs1QiPqQBOCMgPdZ/; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WwZgT-00067m-3x for netconf@ietf.org; Mon, 16 Jun 2014 12:23:01 -0400 Received: from 76.254.50.101 by webmail.earthlink.net with HTTP; Mon, 16 Jun 2014 12:23:01 -0400 Message-ID: <12406684.1402935781100.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Mon, 16 Jun 2014 09:23:01 -0700 (GMT-07:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd812974e536002416f667d134531831c39d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1QWATsgP8yXxRU98mfm486BJQ48 Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:23:08 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Jun 16, 2014 4:01 AM >To: Andy Bierman >Cc: Zhengguangying , Yangang , Netconf , Yangshouchuan >Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt ... >What I am saying is that at the end of the day, once could have >modeled a 'create-subscription' rpc as a long lasting rpc, much like a >'ping' that runs indefinitely or a 'tail -f' that runs indefinitely. I >think we created a special purpose solution for notifications but in >hindsight it could have been equally possible to build a more general >purpose mechanism. Yes, but such an approach to notifications has a few drawbacks, mostly tied to the limitation that it can realistically only be expected to work for the lifetime of the connection on which it was initiated, and clearly not in "call home if you catch fire" situations. Randy From nobody Mon Jun 16 09:33:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4F01A00FA for ; Mon, 16 Jun 2014 09:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLCokuT6aple for ; Mon, 16 Jun 2014 09:33:33 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DDF1A00C9 for ; Mon, 16 Jun 2014 09:33:33 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so8292154qcy.15 for ; Mon, 16 Jun 2014 09:33:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Se3/k86E9sSDYER2jAHx0oe1/BV2SomcMZC7mw9yS5s=; b=abI35HAZ7egf3oJ8xU+YhOIcu6wyhDNeBE9L9ExmAWcbQVEmmy3kMSTWTT4dJ3lKtN 9SvdpahNZ6WNQEyhQTCPYiLnpnl8o57Hv4Y3MoPFHTZ3AThqAa2qDdI2+JRfMDDjHLjd iUwPjDtLZZZb5tWqXIxkxVQeRg6ZbB51CjDxdWH+GubzO5gRcmgU5uuOWg6y2nu3m9KH mmdcDwksZSf1Y/acNxu10J6tFNWnxydqfMielIzuTIvCilr3OKQfyQGelSCXZp02yCST zM/CUGNW6edyUUqgw/Xlz+zHuF85OWrcSruEN24Nh0R/mb9JCytZxRQXcbMxsFmExk9/ tlew== X-Gm-Message-State: ALoCoQmzGOsypcp4lXuyRoOJl6Q2hYOgvkv4tGzTB94lvwDNFlgsubBwnrw+CFVOE/t6HC8jIz7Z MIME-Version: 1.0 X-Received: by 10.224.55.6 with SMTP id s6mr27806612qag.7.1402936412699; Mon, 16 Jun 2014 09:33:32 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 16 Jun 2014 09:33:32 -0700 (PDT) In-Reply-To: <12406684.1402935781100.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> References: <12406684.1402935781100.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Mon, 16 Jun 2014 09:33:32 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=089e0153705e8593b604fbf696bb Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/rQQ5iOdydkLMg0UG2ocUeFk0IGk Cc: Netconf Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:33:35 -0000 --089e0153705e8593b604fbf696bb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 16, 2014 at 9:23 AM, Randy Presuhn wrote: > Hi - > > >From: Juergen Schoenwaelder > >Sent: Jun 16, 2014 4:01 AM > >To: Andy Bierman > >Cc: Zhengguangying , Yangang < > yangang@huawei.com>, Netconf , Yangshouchuan < > yangshouchuan@huawei.com> > >Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version > Notification for draft-liu-netconf-fragmentation-00.txt > ... > >What I am saying is that at the end of the day, once could have > >modeled a 'create-subscription' rpc as a long lasting rpc, much like a > >'ping' that runs indefinitely or a 'tail -f' that runs indefinitely. I > >think we created a special purpose solution for notifications but in > >hindsight it could have been equally possible to build a more general > >purpose mechanism. > > Yes, but such an approach to notifications has a few drawbacks, > mostly tied to the limitation that it can realistically only > be expected to work for the lifetime of the connection on which > it was initiated, and clearly not in "call home if you catch fire" > situations. > > This is the major complaint I hear wrt/ NETCONF notifications -- that a session has to be initiated and maintained by the client in order to hear notifications from a server. IMO, call-home may help, but the cost of NETCONF session startup is so high, a notification session will still be maintained by the client for every server. Randy > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --089e0153705e8593b604fbf696bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 16, 2014 at 9:23 AM, Randy Presuhn &l= t;randy_p= resuhn@mindspring.com> wrote:
Hi -

>From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
>Sent: Jun 16, 2014 4:01 AM
>To: Andy Bierman <andy@yumawor= ks.com>
>Cc: Zhengguangying <zhe= ngguangying@huawei.com>, Yangang <yangang@huawei.com>, Netconf <netconf@ietf.org>, Yangshouchuan <yangshouchuan@huawei.com>
>Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notifica= tion for draft-liu-netconf-fragmentation-00.txt
...
>What I am saying is that at the end of the day, once could have
>modeled a 'create-subscription' rpc as a long lasting rpc, much= like a
>'ping' that runs indefinitely or a 'tail -f' that runs = indefinitely. I
>think we created a special purpose solution for notifications but in >hindsight it could have been equally possible to build a more general >purpose mechanism.

Yes, but such an approach to notifications has a few drawbacks,
mostly tied to the limitation that it can realistically only
be expected to work for the lifetime of the connection on which
it was initiated, and clearly not in "call home if you catch fire"= ;
situations.



This is the major compl= aint I hear wrt/ NETCONF notifications -- that a session
has to b= e initiated and maintained by the client in order to hear notifications
from a server.

IMO, call-home may help, but t= he cost of NETCONF session startup is so high,
a notification ses= sion will still be maintained by the client for every server.

Randy

Andy
=A0

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

--089e0153705e8593b604fbf696bb-- From nobody Mon Jun 16 09:53:54 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7DC1A00B5 for ; Mon, 16 Jun 2014 09:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RU_bCJcUf0n for ; Mon, 16 Jun 2014 09:53:51 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994821A011E for ; Mon, 16 Jun 2014 09:53:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E7817707; Mon, 16 Jun 2014 18:53:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GnqsYHtxo7MX; Mon, 16 Jun 2014 18:53:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 16 Jun 2014 18:53:42 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BAC520017; Mon, 16 Jun 2014 18:53:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 17fJitB4Gz1X; Mon, 16 Jun 2014 18:53:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56A8120013; Mon, 16 Jun 2014 18:53:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9CD552D8E525; Mon, 16 Jun 2014 18:53:40 +0200 (CEST) Date: Mon, 16 Jun 2014 18:53:40 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20140616165340.GA1328@elstar.local> Mail-Followup-To: Randy Presuhn , netconf@ietf.org References: <12406684.1402935781100.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12406684.1402935781100.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/h-YU4R77pzzgPBHVC1p1JrSR7vU Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:53:53 -0000 On Mon, Jun 16, 2014 at 09:23:01AM -0700, Randy Presuhn wrote: > Hi - > > >From: Juergen Schoenwaelder > >Sent: Jun 16, 2014 4:01 AM > >To: Andy Bierman > >Cc: Zhengguangying , Yangang , Netconf , Yangshouchuan > >Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt > ... > >What I am saying is that at the end of the day, once could have > >modeled a 'create-subscription' rpc as a long lasting rpc, much like a > >'ping' that runs indefinitely or a 'tail -f' that runs indefinitely. I > >think we created a special purpose solution for notifications but in > >hindsight it could have been equally possible to build a more general > >purpose mechanism. > > Yes, but such an approach to notifications has a few drawbacks, > mostly tied to the limitation that it can realistically only > be expected to work for the lifetime of the connection on which > it was initiated, and clearly not in "call home if you catch fire" > situations. > Yes, but RFC 5277 does exactly that - it ties notifications subscription to the underlying session. If you catch fire, you need to use something else to call for help. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jun 19 02:59:15 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725D71A00D4 for ; Thu, 19 Jun 2014 02:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhDCKiROFYT6 for ; Thu, 19 Jun 2014 02:59:11 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F531A008C for ; Thu, 19 Jun 2014 02:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2886; q=dns/txt; s=iport; t=1403171951; x=1404381551; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=2DLkyP4HQeqfN2dOHNLpQkQgcTpuH9mVBmo6aGTvsp0=; b=TR/tFbN2aBCzuS6EzcI/LRctYyX15rH3Ymor0nKxo4RV1FhuPx+vR2dm rcGYBh3u6w4JupCsXD0QgjPQZQYK1WfrctTScr8z6wCGBkAflMaoZmy+Z ZmzOXx+g4zGEVIs6GCeZI0j2CNd5cgChFdzoPR3GBTk6dx59hVjWg+4A4 Q=; X-IronPort-AV: E=Sophos;i="5.01,506,1400025600"; d="scan'208";a="86532439" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 19 Jun 2014 09:59:09 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5J9x9Hg017652; Thu, 19 Jun 2014 09:59:09 GMT Message-ID: <53A2B46D.5090608@cisco.com> Date: Thu, 19 Jun 2014 11:59:09 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Bjorklund , rob.enns@gmail.com, andy@yumaworks.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com, ksekera@cisco.com, netconf@ietf.org References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> <20140604121154.GA8481@elstar.local> In-Reply-To: <20140604121154.GA8481@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/X0aiC-yRqH3ST8jm5KuxEy0XOBE Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 09:59:13 -0000 Klement, Are you fine with this resolution below. If yes, please update the errata. If you don't have the right to do, I can do. In this case, provide OLD/NEW text. Regards, Benoit > On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote: >>>> Juergen Schoenwaelder wrote: >>>>> I am not sure since in the new text 'node' is rather unspecified. For >>>>> me, it would help to have a example demonstrating what is broken >>>> Assume this model: >>>> >>>> container servers { >>>> list server { >>>> key name; >>>> leaf name { ... } >>>> leaf ip { ... } >>>> leaf port { ... } >>>> } >>>> } >>>> >>>> and this data on the server: >>>> >>>> >>>> >>>> foo >>>> 10.0.0.1 >>>> 80 >>>> >>>> >>>> bar >>>> 10.0.0.1 >>>> 25 >>>> >>>> >>>> >>>> Now, with this filter: >>>> >>>> >>>> >>>> 80 >>>> >>>> >>>> >>>> >>>> It is, according to 6241, ok to return: >>>> >>>> >>>> >>>> foo >>>> 10.0.0.1 >>>> 80 >>>> >>>> >>>> >>>> (because 'name' is a sibling to the selection node 'ip') >>>> >>>> >>>> However, with this filter: >>>> >>>> >>>> >>>> 80 >>>> >>>> >>>> >>>> a strict interpretation of 6241 seems to suggest that this is illegal >>>> to return: >>>> >>>> >>>> >>>> foo >>>> 80 >>>> >>>> >>>> >>>> ... but that doesn't make much sense. >>>> >>>> The intention of the text was to allow keys to be inserted everywhere >>>> in the returned subtrees. >>>> >>>> >>>> This said, I am not convinced the proposed change fixes this. The >>>> subtree filter specification text is pretty difficult to interpret... >>>> >>> So any key leafs that are child nodes of any Containment Nodes of >>> the Subtree Filter can be added? Would that be more accurate? >> I think so, but the current text is in section 6.2.5 which talks about >> content match nodes. This is a bit confusing - what happens if you >> don't have any content match nodes? >> >> Your sentence belongs to text that discuss subtree filter in general, >> maybe somewhere in section 6.3. >> > Yes, that makes sense to me. > > /js > From ksekera@cisco.com Thu Jun 19 05:39:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF81A0194 for ; Thu, 19 Jun 2014 05:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P35P36KsUyO4 for ; Thu, 19 Jun 2014 05:39:27 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D25D1A018D for ; Thu, 19 Jun 2014 05:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6442; q=dns/txt; s=iport; t=1403181567; x=1404391167; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=B8GfwWH1+nzGcMU1BiVJ27eSknSEnDocXPsUHsE/wYE=; b=dYRbG3Ds1eJ57iTsoz0o3vkg+7LUALlUTTrNky9YAGwutMTWre6dRtBb jZAZMurB/qGy2FpwFYFKdMseKblEgwEM/I3LK3IIEZ0qrBB1o3ol1xtsM TWVq23Jh2aweDUfBhYX76qxQOlY30zQC1mU9CGVlssq1umekEy5wzxNkG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFALLZolOtJV2Y/2dsb2JhbABagw2BHw2CbcBZARluFnWEAwEBAQQjEUUQAgEIEAgCAiYCAgIwFRACBA4FiEKvb54wF4EqiiyCbTMHgneBTASuG4NCgjA X-IronPort-AV: E=Sophos;i="5.01,507,1400025600"; d="scan'208";a="54369847" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 19 Jun 2014 12:39:19 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5JCdJKu015384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 12:39:19 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 07:39:18 -0500 From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" To: "Benoit Claise (bclaise)" Thread-Topic: [Technical Errata Reported] RFC6241 (3980) Thread-Index: AQHPaHW7PCmq8r636UaAx9kYl7rT1JthH62AgAAZNwCAAAhQgIAAAeSAgAACLICAABn6AIAXbeKAgAAsWgA= Date: Thu, 19 Jun 2014 12:39:18 +0000 Message-ID: <1403181474.24901.6.camel@ksekera-fedora> References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> <20140604121154.GA8481@elstar.local> <53A2B46D.5090608@cisco.com> In-Reply-To: <53A2B46D.5090608@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.173.219] Content-Type: text/plain; charset="utf-8" Content-ID: <740F8A84D7B434498050730146F62C70@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nLAd3FzQUi0DvT4xNemBqrqC0YY X-Mailman-Approved-At: Thu, 19 Jun 2014 05:59:54 -0700 Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 12:44:10 -0000 SGkgQmVub2l0LA0KDQpJIGRvbid0IHRoaW5rIEkgY2FuLg0KDQpJZiB0aGlzIHNob3VsZCBiZSBw dXQgaW50byBzZWN0aW9uIDYuMywgdGhlbiBJJ2QgYWRkIHRvIHRoaXMgYmxvY2sgb2YNCnRleHQ6 DQoNCk9MRDoNCiAgIEZvciBlYWNoIHNpYmxpbmcgc2V0LCB0aGUgc2VydmVyIGRldGVybWluZXMg d2hpY2ggbm9kZXMgYXJlIGluY2x1ZGVkDQogICAob3IgcG90ZW50aWFsbHkgaW5jbHVkZWQpIGlu IHRoZSBmaWx0ZXIgb3V0cHV0LCBhbmQgd2hpY2ggc2libGluZw0KICAgc3VidHJlZXMgYXJlIGV4 Y2x1ZGVkIChwcnVuZWQpIGZyb20gdGhlIGZpbHRlciBvdXRwdXQuICBUaGUgc2VydmVyDQogICBm aXJzdCBkZXRlcm1pbmVzIHdoaWNoIHR5cGVzIG9mIG5vZGVzIGFyZSBwcmVzZW50IGluIHRoZSBz aWJsaW5nIHNldA0KICAgYW5kIHByb2Nlc3NlcyB0aGUgbm9kZXMgYWNjb3JkaW5nIHRvIHRoZSBy dWxlcyBmb3IgdGhlaXIgdHlwZS4gIElmDQogICBhbnkgbm9kZXMgaW4gdGhlIHNpYmxpbmcgc2V0 IGFyZSBzZWxlY3RlZCwgdGhlbiB0aGUgcHJvY2VzcyBpcw0KICAgcmVjdXJzaXZlbHkgYXBwbGll ZCB0byB0aGUgc2libGluZyBzZXRzIG9mIGVhY2ggc2VsZWN0ZWQgbm9kZS4gIFRoZQ0KICAgYWxn b3JpdGhtIGNvbnRpbnVlcyB1bnRpbCBhbGwgc2libGluZyBzZXRzIGluIGFsbCBzdWJ0cmVlcyBz cGVjaWZpZWQNCiAgIGluIHRoZSBmaWx0ZXIgaGF2ZSBiZWVuIHByb2Nlc3NlZC4NCg0KTkVXOg0K ICAgRm9yIGVhY2ggc2libGluZyBzZXQsIHRoZSBzZXJ2ZXIgZGV0ZXJtaW5lcyB3aGljaCBub2Rl cyBhcmUgaW5jbHVkZWQNCiAgIChvciBwb3RlbnRpYWxseSBpbmNsdWRlZCkgaW4gdGhlIGZpbHRl ciBvdXRwdXQsIGFuZCB3aGljaCBzaWJsaW5nDQogICBzdWJ0cmVlcyBhcmUgZXhjbHVkZWQgKHBy dW5lZCkgZnJvbSB0aGUgZmlsdGVyIG91dHB1dC4gIFRoZSBzZXJ2ZXINCiAgIGZpcnN0IGRldGVy bWluZXMgd2hpY2ggdHlwZXMgb2Ygbm9kZXMgYXJlIHByZXNlbnQgaW4gdGhlIHNpYmxpbmcgc2V0 DQogICBhbmQgcHJvY2Vzc2VzIHRoZSBub2RlcyBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGZvciB0 aGVpciB0eXBlLiAgSWYNCiAgIGFueSBub2RlcyBpbiB0aGUgc2libGluZyBzZXQgYXJlIHNlbGVj dGVkLCB0aGVuIHRoZSBwcm9jZXNzIGlzDQogICByZWN1cnNpdmVseSBhcHBsaWVkIHRvIHRoZSBz aWJsaW5nIHNldHMgb2YgZWFjaCBzZWxlY3RlZCBub2RlLiAgVGhlDQogICBhbGdvcml0aG0gY29u dGludWVzIHVudGlsIGFsbCBzaWJsaW5nIHNldHMgaW4gYWxsIHN1YnRyZWVzIHNwZWNpZmllZA0K ICAgaW4gdGhlIGZpbHRlciBoYXZlIGJlZW4gcHJvY2Vzc2VkLiBJZiBhbnkgc2libGluZyBub2Rl cyBvZiBhIG5vZGUgDQogICBhcmUgaW5zdGFuY2UgaWRlbnRpZmllciBjb21wb25lbnRzIGZvciBh IGNvbmNlcHR1YWwgZGF0YSBzdHJ1Y3R1cmUgDQogICAoZS5nLiwgbGlzdCBrZXkgbGVhZiksIHRo ZW4gdGhleSBNQVkgYmUgaW5jbHVkZWQgaW4gdGhlIGZpbHRlciBvdXRwdXQuDQoNClJhZ2FyZHMs DQpLbGVtZW50DQoNCk9uIFRodSwgMjAxNC0wNi0xOSBhdCAxMTo1OSArMDIwMCwgQmVub2l0IENs YWlzZSB3cm90ZToNCj4gS2xlbWVudCwNCj4gDQo+IEFyZSB5b3UgZmluZSB3aXRoIHRoaXMgcmVz b2x1dGlvbiBiZWxvdy4NCj4gSWYgeWVzLCBwbGVhc2UgdXBkYXRlIHRoZSBlcnJhdGEuDQo+IElm IHlvdSBkb24ndCBoYXZlIHRoZSByaWdodCB0byBkbywgSSBjYW4gZG8uIEluIHRoaXMgY2FzZSwg cHJvdmlkZSANCj4gT0xEL05FVyB0ZXh0Lg0KPiANCj4gUmVnYXJkcywgQmVub2l0DQo+ID4gT24g V2VkLCBKdW4gMDQsIDIwMTQgYXQgMTI6Mzg6NTVQTSArMDIwMCwgTWFydGluIEJqb3JrbHVuZCB3 cm90ZToNCj4gPj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+Pj4gT24gV2VkLCBKdW4gMDQsIDIwMTQgYXQgMTI6 MjQ6MjNQTSArMDIwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPj4+PiBKdWVyZ2VuIFNj aG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6 DQo+ID4+Pj4+IEkgYW0gbm90IHN1cmUgc2luY2UgaW4gdGhlIG5ldyB0ZXh0ICdub2RlJyBpcyBy YXRoZXIgdW5zcGVjaWZpZWQuICBGb3INCj4gPj4+Pj4gbWUsIGl0IHdvdWxkIGhlbHAgdG8gaGF2 ZSBhIGV4YW1wbGUgZGVtb25zdHJhdGluZyB3aGF0IGlzIGJyb2tlbg0KPiA+Pj4+IEFzc3VtZSB0 aGlzIG1vZGVsOg0KPiA+Pj4+DQo+ID4+Pj4gICAgY29udGFpbmVyIHNlcnZlcnMgew0KPiA+Pj4+ ICAgICAgbGlzdCBzZXJ2ZXIgew0KPiA+Pj4+ICAgICAgICBrZXkgbmFtZTsNCj4gPj4+PiAgICAg ICAgbGVhZiBuYW1lIHsgLi4uIH0NCj4gPj4+PiAgICAgICAgbGVhZiBpcCB7IC4uLiB9DQo+ID4+ Pj4gICAgICAgIGxlYWYgcG9ydCB7IC4uLiB9DQo+ID4+Pj4gICAgICB9DQo+ID4+Pj4gICAgfQ0K PiA+Pj4+DQo+ID4+Pj4gYW5kIHRoaXMgZGF0YSBvbiB0aGUgc2VydmVyOg0KPiA+Pj4+DQo+ID4+ Pj4gICAgPHNlcnZlcnM+DQo+ID4+Pj4gICAgICA8c2VydmVyPg0KPiA+Pj4+ICAgICAgICA8bmFt ZT5mb288L25hbWU+DQo+ID4+Pj4gICAgICAgIDxpcD4xMC4wLjAuMTwvaXA+DQo+ID4+Pj4gICAg ICAgIDxwb3J0PjgwPC9wb3J0Pg0KPiA+Pj4+ICAgICAgPC9zZXJ2ZXI+DQo+ID4+Pj4gICAgICA8 c2VydmVyPg0KPiA+Pj4+ICAgICAgICA8bmFtZT5iYXI8L25hbWU+DQo+ID4+Pj4gICAgICAgIDxp cD4xMC4wLjAuMTwvaXA+DQo+ID4+Pj4gICAgICAgIDxwb3J0PjI1PC9wb3J0Pg0KPiA+Pj4+ICAg ICAgPC9zZXJ2ZXI+DQo+ID4+Pj4gICAgPC9zZXJ2ZXJzPg0KPiA+Pj4+DQo+ID4+Pj4gTm93LCB3 aXRoIHRoaXMgZmlsdGVyOg0KPiA+Pj4+DQo+ID4+Pj4gICAgPHNlcnZlcnM+DQo+ID4+Pj4gICAg ICA8c2VydmVyPg0KPiA+Pj4+ICAgICAgICA8cG9ydD44MDwvcG9ydD4NCj4gPj4+PiAgICAgICAg PGlwLz4NCj4gPj4+PiAgICAgIDwvc2VydmVyPg0KPiA+Pj4+ICAgIDwvc2VydmVyPg0KPiA+Pj4+ DQo+ID4+Pj4gSXQgaXMsIGFjY29yZGluZyB0byA2MjQxLCBvayB0byByZXR1cm46DQo+ID4+Pj4N Cj4gPj4+PiAgICA8c2VydmVycz4NCj4gPj4+PiAgICAgIDxzZXJ2ZXI+DQo+ID4+Pj4gICAgICAg IDxuYW1lPmZvbzwvbmFtZT4NCj4gPj4+PiAgICAgICAgPGlwPjEwLjAuMC4xPC9pcD4NCj4gPj4+ PiAgICAgICAgPHBvcnQ+ODA8L3BvcnQ+DQo+ID4+Pj4gICAgICA8L3NlcnZlcj4NCj4gPj4+PiAg ICA8L3NlcnZlcnM+DQo+ID4+Pj4NCj4gPj4+PiAoYmVjYXVzZSAnbmFtZScgaXMgYSBzaWJsaW5n IHRvIHRoZSBzZWxlY3Rpb24gbm9kZSAnaXAnKQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBIb3dl dmVyLCB3aXRoIHRoaXMgZmlsdGVyOg0KPiA+Pj4+DQo+ID4+Pj4gICAgPHNlcnZlcnM+DQo+ID4+ Pj4gICAgICA8c2VydmVyPg0KPiA+Pj4+ICAgICAgICA8cG9ydD44MDwvcG9ydD4NCj4gPj4+PiAg ICAgIDwvc2VydmVyPg0KPiA+Pj4+ICAgIDwvc2VydmVyPg0KPiA+Pj4+DQo+ID4+Pj4gYSBzdHJp Y3QgaW50ZXJwcmV0YXRpb24gb2YgNjI0MSBzZWVtcyB0byBzdWdnZXN0IHRoYXQgdGhpcyBpcyBp bGxlZ2FsDQo+ID4+Pj4gdG8gcmV0dXJuOg0KPiA+Pj4+DQo+ID4+Pj4gICAgPHNlcnZlcnM+DQo+ ID4+Pj4gICAgICA8c2VydmVyPg0KPiA+Pj4+ICAgICAgICA8bmFtZT5mb288L25hbWU+DQo+ID4+ Pj4gICAgICAgIDxwb3J0PjgwPC9wb3J0Pg0KPiA+Pj4+ICAgICAgPC9zZXJ2ZXI+DQo+ID4+Pj4g ICAgPC9zZXJ2ZXJzPg0KPiA+Pj4+DQo+ID4+Pj4gLi4uIGJ1dCB0aGF0IGRvZXNuJ3QgbWFrZSBt dWNoIHNlbnNlLg0KPiA+Pj4+DQo+ID4+Pj4gVGhlIGludGVudGlvbiBvZiB0aGUgdGV4dCB3YXMg dG8gYWxsb3cga2V5cyB0byBiZSBpbnNlcnRlZCBldmVyeXdoZXJlDQo+ID4+Pj4gaW4gdGhlIHJl dHVybmVkIHN1YnRyZWVzLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBUaGlzIHNhaWQsIEkgYW0g bm90IGNvbnZpbmNlZCB0aGUgcHJvcG9zZWQgY2hhbmdlIGZpeGVzIHRoaXMuICBUaGUNCj4gPj4+ PiBzdWJ0cmVlIGZpbHRlciBzcGVjaWZpY2F0aW9uIHRleHQgaXMgcHJldHR5IGRpZmZpY3VsdCB0 byBpbnRlcnByZXQuLi4NCj4gPj4+Pg0KPiA+Pj4gU28gYW55IGtleSBsZWFmcyB0aGF0IGFyZSBj aGlsZCBub2RlcyBvZiBhbnkgQ29udGFpbm1lbnQgTm9kZXMgb2YNCj4gPj4+IHRoZSBTdWJ0cmVl IEZpbHRlciBjYW4gYmUgYWRkZWQ/IFdvdWxkIHRoYXQgYmUgbW9yZSBhY2N1cmF0ZT8NCj4gPj4g SSB0aGluayBzbywgYnV0IHRoZSBjdXJyZW50IHRleHQgaXMgaW4gc2VjdGlvbiA2LjIuNSB3aGlj aCB0YWxrcyBhYm91dA0KPiA+PiBjb250ZW50IG1hdGNoIG5vZGVzLiAgVGhpcyBpcyBhIGJpdCBj b25mdXNpbmcgLSB3aGF0IGhhcHBlbnMgaWYgeW91DQo+ID4+IGRvbid0IGhhdmUgYW55IGNvbnRl bnQgbWF0Y2ggbm9kZXM/DQo+ID4+DQo+ID4+IFlvdXIgc2VudGVuY2UgYmVsb25ncyB0byB0ZXh0 IHRoYXQgZGlzY3VzcyBzdWJ0cmVlIGZpbHRlciBpbiBnZW5lcmFsLA0KPiA+PiBtYXliZSBzb21l d2hlcmUgaW4gc2VjdGlvbiA2LjMuDQo+ID4+DQo+ID4gWWVzLCB0aGF0IG1ha2VzIHNlbnNlIHRv IG1lLg0KPiA+DQo+ID4gL2pzDQo+ID4NCj4gDQoNCg== From nobody Thu Jun 19 06:06:49 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A961A03BD for ; Thu, 19 Jun 2014 06:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrybbxcCT7B4 for ; Thu, 19 Jun 2014 06:06:45 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1164C1A03A3 for ; Thu, 19 Jun 2014 06:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4886; q=dns/txt; s=iport; t=1403183202; x=1404392802; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=W+srlEpNllkQsXhEY2hlS2ZJxYFVuZipnN8RVXRI/mM=; b=Ctyux7tJOW0v/jb7z0crtDdSSVU7oudGPvWIXKpaqHnSLQT9u0LdszZ1 p2G4QN6su1wJ98ZZCeDvnu8LxKpKR1E6iA9rWPBwFhssftpnHh6pOl+re k7/tEMMrUCdfXkzG2TMjEVbigAIC3VBW65CxmS2OG9MbujRd1mD/oYmII Y=; X-IronPort-AV: E=Sophos;i="5.01,507,1400025600"; d="scan'208";a="41960217" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 19 Jun 2014 13:06:39 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5JD6ZOG004480; Thu, 19 Jun 2014 13:06:36 GMT Message-ID: <53A2E05B.9070001@cisco.com> Date: Thu, 19 Jun 2014 15:06:35 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> <20140604121154.GA8481@elstar.local> <53A2B46D.5090608@cisco.com> <1403181474.24901.6.camel@ksekera-fedora> In-Reply-To: <1403181474.24901.6.camel@ksekera-fedora> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/n0Enrxub7HN9PVYiR9gQVhe6bdc Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 13:06:47 -0000 Martin, Jürgen, WG, Fine with this? Regards, B. > Hi Benoit, > > I don't think I can. > > If this should be put into section 6.3, then I'd add to this block of > text: > > OLD: > For each sibling set, the server determines which nodes are included > (or potentially included) in the filter output, and which sibling > subtrees are excluded (pruned) from the filter output. The server > first determines which types of nodes are present in the sibling set > and processes the nodes according to the rules for their type. If > any nodes in the sibling set are selected, then the process is > recursively applied to the sibling sets of each selected node. The > algorithm continues until all sibling sets in all subtrees specified > in the filter have been processed. > > NEW: > For each sibling set, the server determines which nodes are included > (or potentially included) in the filter output, and which sibling > subtrees are excluded (pruned) from the filter output. The server > first determines which types of nodes are present in the sibling set > and processes the nodes according to the rules for their type. If > any nodes in the sibling set are selected, then the process is > recursively applied to the sibling sets of each selected node. The > algorithm continues until all sibling sets in all subtrees specified > in the filter have been processed. If any sibling nodes of a node > are instance identifier components for a conceptual data structure > (e.g., list key leaf), then they MAY be included in the filter output. > > Ragards, > Klement > > On Thu, 2014-06-19 at 11:59 +0200, Benoit Claise wrote: >> Klement, >> >> Are you fine with this resolution below. >> If yes, please update the errata. >> If you don't have the right to do, I can do. In this case, provide >> OLD/NEW text. >> >> Regards, Benoit >>> On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund wrote: >>>> Juergen Schoenwaelder wrote: >>>>> On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote: >>>>>> Juergen Schoenwaelder wrote: >>>>>>> I am not sure since in the new text 'node' is rather unspecified. For >>>>>>> me, it would help to have a example demonstrating what is broken >>>>>> Assume this model: >>>>>> >>>>>> container servers { >>>>>> list server { >>>>>> key name; >>>>>> leaf name { ... } >>>>>> leaf ip { ... } >>>>>> leaf port { ... } >>>>>> } >>>>>> } >>>>>> >>>>>> and this data on the server: >>>>>> >>>>>> >>>>>> >>>>>> foo >>>>>> 10.0.0.1 >>>>>> 80 >>>>>> >>>>>> >>>>>> bar >>>>>> 10.0.0.1 >>>>>> 25 >>>>>> >>>>>> >>>>>> >>>>>> Now, with this filter: >>>>>> >>>>>> >>>>>> >>>>>> 80 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It is, according to 6241, ok to return: >>>>>> >>>>>> >>>>>> >>>>>> foo >>>>>> 10.0.0.1 >>>>>> 80 >>>>>> >>>>>> >>>>>> >>>>>> (because 'name' is a sibling to the selection node 'ip') >>>>>> >>>>>> >>>>>> However, with this filter: >>>>>> >>>>>> >>>>>> >>>>>> 80 >>>>>> >>>>>> >>>>>> >>>>>> a strict interpretation of 6241 seems to suggest that this is illegal >>>>>> to return: >>>>>> >>>>>> >>>>>> >>>>>> foo >>>>>> 80 >>>>>> >>>>>> >>>>>> >>>>>> ... but that doesn't make much sense. >>>>>> >>>>>> The intention of the text was to allow keys to be inserted everywhere >>>>>> in the returned subtrees. >>>>>> >>>>>> >>>>>> This said, I am not convinced the proposed change fixes this. The >>>>>> subtree filter specification text is pretty difficult to interpret... >>>>>> >>>>> So any key leafs that are child nodes of any Containment Nodes of >>>>> the Subtree Filter can be added? Would that be more accurate? >>>> I think so, but the current text is in section 6.2.5 which talks about >>>> content match nodes. This is a bit confusing - what happens if you >>>> don't have any content match nodes? >>>> >>>> Your sentence belongs to text that discuss subtree filter in general, >>>> maybe somewhere in section 6.3. >>>> >>> Yes, that makes sense to me. >>> >>> /js >>> From nobody Thu Jun 19 06:53:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFEE1A01EE for ; Thu, 19 Jun 2014 06:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCtGhikcIOuM for ; Thu, 19 Jun 2014 06:53:31 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id C5A731A0369 for ; Thu, 19 Jun 2014 06:53:30 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id DCD881FF52; Thu, 19 Jun 2014 15:53:29 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 908731FF46 for ; Thu, 19 Jun 2014 15:53:29 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 4171E37825A for ; Thu, 19 Jun 2014 15:53:29 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 19 Jun 2014 15:53:29 +0200 From: Adel Zaalouk To: "netconf@ietf.org" Date: Thu, 19 Jun 2014 15:53:28 +0200 Thread-Topic: Implementing a NETCONF Client Thread-Index: Ac+Lxdjh9o61LXBTT56CklQDBgBpbA== Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C5B276A@SBS2008.eict.local> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_0C7EDCF89AB9E2478B5D010026CFF4AEA10C5B276ASBS2008eictlo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/S-MK4Ds4R1fVJ2PsBM09TcbNjLM Subject: [Netconf] Implementing a NETCONF Client X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 13:53:33 -0000 --_000_0C7EDCF89AB9E2478B5D010026CFF4AEA10C5B276ASBS2008eictlo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am planning on implementing a NETCONF client from scratch. However, I am = relatively new to this business. Therefore, I would really appreciate it if= someone can give me some pointers on how to bootstrap my implementation, I= am not after a fancy client or anything, I just need to implement the basi= c functionalities assuming that I know the YANG model of the underlying dev= ice. Best regards, Adel. --_000_0C7EDCF89AB9E2478B5D010026CFF4AEA10C5B276ASBS2008eictlo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am planning on implementing a NETCONF client from scratch. Howev= er, I am relatively new to this business. Therefore, I would really appreci= ate it if someone can give me some pointers on how to bootstrap my implemen= tation, I am not after a fancy client or anything, I just need to implement= the basic functionalities assuming that I know the YANG model of the under= lying device.

 

&= nbsp;

Best regards,=

Adel. <= /o:p>

 

= --_000_0C7EDCF89AB9E2478B5D010026CFF4AEA10C5B276ASBS2008eictlo_-- From nobody Thu Jun 19 07:55:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8F1A03C6 for ; Thu, 19 Jun 2014 07:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12uPX365shye for ; Thu, 19 Jun 2014 07:55:06 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F2C1A027E for ; Thu, 19 Jun 2014 07:55:05 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so2008291qae.19 for ; Thu, 19 Jun 2014 07:55:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8LdJHV8LRsfXT8KTz22m+t/9I5pGfBLPaAkY549V0tw=; b=BPAIGN4wtm2CS7J2z0P3jdPij82Th6U31kSwViXzZh4gsant2iun80BSTo3/mbwbKv jIRDumGi4ywBgv7VtxdXWkr+jR6Qx6j7WElC3usm0CjZCIx8r4eUbFBlpD7ZuzZCJdBO 47ECVISRFYlAihFlbs8VM5Lr7E7PtWQXiuDqlMSIyWt/D6aYk6gPE7TwkF8shTHn7UXP OWJpdZdSjg/8BGnSTzGewiQ9R4I70hwhhVuV1x3XubHcDpHNpCXBrJ5bS0TOFCXaqYkA bOGhSh9KJqO/kVxoPiRh+guPkweqzAmQBF5A3uTcgd/38YJSTvzHgBW+QdjOgXD17jT8 c56Q== X-Gm-Message-State: ALoCoQmz0z/CCfEmmI4IAVQTls8SdRLDc0zBv69zilN3DLtxaAes8Gu1Oa6LCO1kREeXolBrOfQZ MIME-Version: 1.0 X-Received: by 10.140.41.113 with SMTP id y104mr7540909qgy.34.1403189705048; Thu, 19 Jun 2014 07:55:05 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Thu, 19 Jun 2014 07:55:04 -0700 (PDT) In-Reply-To: <53A2E05B.9070001@cisco.com> References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> <20140604121154.GA8481@elstar.local> <53A2B46D.5090608@cisco.com> <1403181474.24901.6.camel@ksekera-fedora> <53A2E05B.9070001@cisco.com> Date: Thu, 19 Jun 2014 07:55:04 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c121b0ec1f1a04fc318f1d Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/DcX5w1MneFrBbj0BcRaBhMc6m0A Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "Klement Sekera -X \(ksekera - Pantheon Technologies SRO at Cisco\)" , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 14:55:08 -0000 --001a11c121b0ec1f1a04fc318f1d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 19, 2014 at 6:06 AM, Benoit Claise wrote: > Martin, J=FCrgen, WG, > > Fine with this? > Not really. Why is the requirement to add key leafs a MAY instead of a MUST or SHOULD? It seems like subtree filters need to be implemented in a consistent manner to make them really useful. Andy > > Regards, B. > >> Hi Benoit, >> >> I don't think I can. >> >> If this should be put into section 6.3, then I'd add to this block of >> text: >> >> OLD: >> For each sibling set, the server determines which nodes are included >> (or potentially included) in the filter output, and which sibling >> subtrees are excluded (pruned) from the filter output. The server >> first determines which types of nodes are present in the sibling set >> and processes the nodes according to the rules for their type. If >> any nodes in the sibling set are selected, then the process is >> recursively applied to the sibling sets of each selected node. The >> algorithm continues until all sibling sets in all subtrees specified >> in the filter have been processed. >> >> NEW: >> For each sibling set, the server determines which nodes are included >> (or potentially included) in the filter output, and which sibling >> subtrees are excluded (pruned) from the filter output. The server >> first determines which types of nodes are present in the sibling set >> and processes the nodes according to the rules for their type. If >> any nodes in the sibling set are selected, then the process is >> recursively applied to the sibling sets of each selected node. The >> algorithm continues until all sibling sets in all subtrees specified >> in the filter have been processed. If any sibling nodes of a node >> are instance identifier components for a conceptual data structure >> (e.g., list key leaf), then they MAY be included in the filter outpu= t. >> >> Ragards, >> Klement >> >> On Thu, 2014-06-19 at 11:59 +0200, Benoit Claise wrote: >> >>> Klement, >>> >>> Are you fine with this resolution below. >>> If yes, please update the errata. >>> If you don't have the right to do, I can do. In this case, provide >>> OLD/NEW text. >>> >>> Regards, Benoit >>> >>>> On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund wrote: >>>> >>>>> Juergen Schoenwaelder wrote: >>>>> >>>>>> On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote: >>>>>> >>>>>>> Juergen Schoenwaelder wrote: >>>>>>> >>>>>>>> I am not sure since in the new text 'node' is rather unspecified. >>>>>>>> For >>>>>>>> me, it would help to have a example demonstrating what is broken >>>>>>>> >>>>>>> Assume this model: >>>>>>> >>>>>>> container servers { >>>>>>> list server { >>>>>>> key name; >>>>>>> leaf name { ... } >>>>>>> leaf ip { ... } >>>>>>> leaf port { ... } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> and this data on the server: >>>>>>> >>>>>>> >>>>>>> >>>>>>> foo >>>>>>> 10.0.0.1 >>>>>>> 80 >>>>>>> >>>>>>> >>>>>>> bar >>>>>>> 10.0.0.1 >>>>>>> 25 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Now, with this filter: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 80 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It is, according to 6241, ok to return: >>>>>>> >>>>>>> >>>>>>> >>>>>>> foo >>>>>>> 10.0.0.1 >>>>>>> 80 >>>>>>> >>>>>>> >>>>>>> >>>>>>> (because 'name' is a sibling to the selection node 'ip') >>>>>>> >>>>>>> >>>>>>> However, with this filter: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 80 >>>>>>> >>>>>>> >>>>>>> >>>>>>> a strict interpretation of 6241 seems to suggest that this is illeg= al >>>>>>> to return: >>>>>>> >>>>>>> >>>>>>> >>>>>>> foo >>>>>>> 80 >>>>>>> >>>>>>> >>>>>>> >>>>>>> ... but that doesn't make much sense. >>>>>>> >>>>>>> The intention of the text was to allow keys to be inserted everywhe= re >>>>>>> in the returned subtrees. >>>>>>> >>>>>>> >>>>>>> This said, I am not convinced the proposed change fixes this. The >>>>>>> subtree filter specification text is pretty difficult to interpret.= .. >>>>>>> >>>>>>> So any key leafs that are child nodes of any Containment Nodes of >>>>>> the Subtree Filter can be added? Would that be more accurate? >>>>>> >>>>> I think so, but the current text is in section 6.2.5 which talks abou= t >>>>> content match nodes. This is a bit confusing - what happens if you >>>>> don't have any content match nodes? >>>>> >>>>> Your sentence belongs to text that discuss subtree filter in general, >>>>> maybe somewhere in section 6.3. >>>>> >>>>> Yes, that makes sense to me. >>>> >>>> /js >>>> >>>> > --001a11c121b0ec1f1a04fc318f1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 19, 2014 at 6:06 AM, Benoit Claise &l= t;bclaise@cisco.com<= /a>> wrote:
Martin, J=FCrgen, WG,

Fine with this?

Not really.
W= hy is the requirement to add key leafs a MAY instead of a MUST or SHOULD?
It seems like subtree filters need to be implemented in a consiste= nt manner
to make them really useful.


An= dy
=A0

Regards, B.
Hi Benoit,

I don't think I can.

If this should be put into section 6.3, then I'd add to this block of text:

OLD:
=A0 =A0 For each sibling set, the server determines which nodes are include= d
=A0 =A0 (or potentially included) in the filter output, and which sibling =A0 =A0 subtrees are excluded (pruned) from the filter output. =A0The serve= r
=A0 =A0 first determines which types of nodes are present in the sibling se= t
=A0 =A0 and processes the nodes according to the rules for their type. =A0I= f
=A0 =A0 any nodes in the sibling set are selected, then the process is
=A0 =A0 recursively applied to the sibling sets of each selected node. =A0T= he
=A0 =A0 algorithm continues until all sibling sets in all subtrees specifie= d
=A0 =A0 in the filter have been processed.

NEW:
=A0 =A0 For each sibling set, the server determines which nodes are include= d
=A0 =A0 (or potentially included) in the filter output, and which sibling =A0 =A0 subtrees are excluded (pruned) from the filter output. =A0The serve= r
=A0 =A0 first determines which types of nodes are present in the sibling se= t
=A0 =A0 and processes the nodes according to the rules for their type. =A0I= f
=A0 =A0 any nodes in the sibling set are selected, then the process is
=A0 =A0 recursively applied to the sibling sets of each selected node. =A0T= he
=A0 =A0 algorithm continues until all sibling sets in all subtrees specifie= d
=A0 =A0 in the filter have been processed. If any sibling nodes of a node =A0 =A0 are instance identifier components for a conceptual data structure<= br> =A0 =A0 (e.g., list key leaf), then they MAY be included in the filter outp= ut.

Ragards,
Klement

On Thu, 2014-06-19 at 11:59 +0200, Benoit Claise wrote:
Klement,

Are you fine with this resolution below.
If yes, please update the errata.
If you don't have the right to do, I can do. In this case, provide
OLD/NEW text.

Regards, Benoit
On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>= ; wrote:
On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>= ; wrote:
I am not sure since in the new text 'node' is rather unspecified. = =A0For
me, it would help to have a example demonstrating what is broken
Assume this model:

=A0 =A0 container servers {
=A0 =A0 =A0 list server {
=A0 =A0 =A0 =A0 key name;
=A0 =A0 =A0 =A0 leaf name { ... }
=A0 =A0 =A0 =A0 leaf ip { ... }
=A0 =A0 =A0 =A0 leaf port { ... }
=A0 =A0 =A0 }
=A0 =A0 }

and this data on the server:

=A0 =A0 <servers>
=A0 =A0 =A0 <server>
=A0 =A0 =A0 =A0 <name>foo</name>
=A0 =A0 =A0 =A0 <ip>10.0.0.1</ip>
=A0 =A0 =A0 =A0 <port>80</port>
=A0 =A0 =A0 </server>
=A0 =A0 =A0 <server>
=A0 =A0 =A0 =A0 <name>bar</name>
=A0 =A0 =A0 =A0 <ip>10.0.0.1</ip>
=A0 =A0 =A0 =A0 <port>25</port>
=A0 =A0 =A0 </server>
=A0 =A0 </servers>

Now, with this filter:

=A0 =A0 <servers>
=A0 =A0 =A0 <server>
=A0 =A0 =A0 =A0 <port>80</port>
=A0 =A0 =A0 =A0 <ip/>
=A0 =A0 =A0 </server>
=A0 =A0 </server>

It is, according to 6241, ok to return:

=A0 =A0 <servers>
=A0 =A0 =A0 <server>
=A0 =A0 =A0 =A0 <name>foo</name>
=A0 =A0 =A0 =A0 <ip>10.0.0.1</ip>
=A0 =A0 =A0 =A0 <port>80</port>
=A0 =A0 =A0 </server>
=A0 =A0 </servers>

(because 'name' is a sibling to the selection node 'ip')

However, with this filter:

=A0 =A0 <servers>
=A0 =A0 =A0 <server>
=A0 =A0 =A0 =A0 <port>80</port>
=A0 =A0 =A0 </server>
=A0 =A0 </server>

a strict interpretation of 6241 seems to suggest that this is illegal
to return:

=A0 =A0 <servers>
=A0 =A0 =A0 <server>
=A0 =A0 =A0 =A0 <name>foo</name>
=A0 =A0 =A0 =A0 <port>80</port>
=A0 =A0 =A0 </server>
=A0 =A0 </servers>

... but that doesn't make much sense.

The intention of the text was to allow keys to be inserted everywhere
in the returned subtrees.


This said, I am not convinced the proposed change fixes this. =A0The
subtree filter specification text is pretty difficult to interpret...

So any key leafs that are child nodes of any Containment Nodes of
the Subtree Filter can be added? Would that be more accurate?
I think so, but the current text is in section 6.2.5 which talks about
content match nodes. =A0This is a bit confusing - what happens if you
don't have any content match nodes?

Your sentence belongs to text that discuss subtree filter in general,
maybe somewhere in section 6.3.

Yes, that makes sense to me.

/js



--001a11c121b0ec1f1a04fc318f1d-- From nobody Thu Jun 19 11:11:46 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8301A00CD for ; Thu, 19 Jun 2014 11:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Red523vUCF4k for ; Thu, 19 Jun 2014 11:11:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4911A026A for ; Thu, 19 Jun 2014 11:11:38 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 19 Jun 2014 18:11:36 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.23]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.23]) with mapi id 15.00.0969.007; Thu, 19 Jun 2014 18:11:36 +0000 From: Kent Watsen To: Adel Zaalouk , "netconf@ietf.org" Thread-Topic: [Netconf] Implementing a NETCONF Client Thread-Index: Ac+Lxdjh9o61LXBTT56CklQDBgBpbAAAoauA Date: Thu, 19 Jun 2014 18:11:35 +0000 Message-ID: References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C5B276A@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C5B276A@SBS2008.eict.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(377454003)(189002)(199002)(16236675004)(31966008)(85306003)(15202345003)(77096002)(95666004)(99286002)(74502001)(74662001)(18717965001)(36756003)(99396002)(79102001)(21056001)(64706001)(20776003)(76482001)(77982001)(46102001)(80022001)(66066001)(50986999)(76176999)(85852003)(83072002)(19580395003)(54356999)(83322001)(19300405004)(15975445006)(92726001)(19580405001)(86362001)(92566001)(87936001)(101416001)(19625215002)(2656002)(105586002)(4396001)(81342001)(81542001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: multipart/alternative; boundary="_000_CFC89F3977D4Dkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/G4eNeWxZXuBeuU8JTDSwbv8OIGM Subject: Re: [Netconf] Implementing a NETCONF Client X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 18:11:44 -0000 --_000_CFC89F3977D4Dkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are a number of open source NETCONF libraries to handle protocol basi= cs, but "assuming that I know the YANG model of the underlying device" intr= oduces the need for schema-aware logic, for instance, to drive a user-inter= face. Can you say more about the kind of client you are trying to write? Kent From: Adel Zaalouk > Date: Thursday, June 19, 2014 at 9:53 AM To: NetConf > Subject: [Netconf] Implementing a NETCONF Client Hi, I am planning on implementing a NETCONF client from scratch. However, I am = relatively new to this business. Therefore, I would really appreciate it if= someone can give me some pointers on how to bootstrap my implementation, I= am not after a fancy client or anything, I just need to implement the basi= c functionalities assuming that I know the YANG model of the underlying dev= ice. Best regards, Adel. --_000_CFC89F3977D4Dkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <11A32D85330C6A4C9B82983A20318344@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

There are a number of open source NETCONF libraries to handle protocol= basics, but "assuming that I know the YANG model of the underlying de= vice" introduces the need for schema-aware logic, for instance, to dri= ve a user-interface.   Can you say more about the kind of client you are trying to write?

Kent

From: Adel Zaalouk <Adel.Zaalouk@eict.de>
Date: Thursday, June 19, 2014 at 9:= 53 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf] Implementing a N= ETCONF Client

Hi,

 

I am planning on implementing a= NETCONF client from scratch. However, I am relatively new to this business= . Therefore, I would really appreciate it if someone can give me some point= ers on how to bootstrap my implementation, I am not after a fancy client or anything, I just need to implement the ba= sic functionalities assuming that I know the YANG model of the underlying d= evice.

 

 

Best regards,

Adel.

 

 --_000_CFC89F3977D4Dkwatsenjunipernet_-- From nobody Thu Jun 19 12:03:01 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAA71A02FB for ; Thu, 19 Jun 2014 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkN8XvQ6--_E for ; Thu, 19 Jun 2014 12:02:57 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7451A0301 for ; Thu, 19 Jun 2014 12:02:45 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id 2CA0A1FF4B; Thu, 19 Jun 2014 21:02:43 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id A8E801FF46; Thu, 19 Jun 2014 21:02:42 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 53661378235; Thu, 19 Jun 2014 21:02:42 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 19 Jun 2014 21:02:42 +0200 From: Adel Zaalouk To: Kent Watsen , "netconf@ietf.org" Date: Thu, 19 Jun 2014 20:58:18 +0200 Thread-Topic: [Netconf] Implementing a NETCONF Client Thread-Index: Ac+Lxdjh9o61LXBTT56CklQDBgBpbAAAoauAAAoDzG0= Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C39CEB7@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C5B276A@SBS2008.eict.local>, In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eWYZ_wDeg5SGszxeyYtHcJIUfIw Subject: Re: [Netconf] Implementing a NETCONF Client X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 19:02:59 -0000 Hi Kent,=20 Thank you for your reply.=20 For example, if I have the following yang sub-tree=20 +--rw resources | +--rw port* [resource-id] | | +--rw resource-id inet:uri | | +--ro number? uint64 | | +--ro name? string | | +--ro current-rate? uint32 | | +--ro max-rate? uint32 | | +--rw configuration I would like to be able to use the client to list ports, or to modify the p= ort configuration for instance. I.e., I am given the YANG model, and I woul= d like to translate this to configurable NETCONF parameters.=20 Thank you.=20 Best regards,=20 Adel.=20 ________________________________________ From: Kent Watsen [kwatsen@juniper.net] Sent: Thursday, 19 June 2014 8:11 PM To: Adel Zaalouk; netconf@ietf.org Subject: Re: [Netconf] Implementing a NETCONF Client There are a number of open source NETCONF libraries to handle protocol basi= cs, but "assuming that I know the YANG model of the underlying device" intr= oduces the need for schema-aware logic, for instance, to drive a user-inter= face. Can you say more about the kind of client you are trying to write? Kent From: Adel Zaalouk > Date: Thursday, June 19, 2014 at 9:53 AM To: NetConf > Subject: [Netconf] Implementing a NETCONF Client Hi, I am planning on implementing a NETCONF client from scratch. However, I am = relatively new to this business. Therefore, I would really appreciate it if= someone can give me some pointers on how to bootstrap my implementation, I= am not after a fancy client or anything, I just need to implement the basi= c functionalities assuming that I know the YANG model of the underlying dev= ice. Best regards, Adel. From nobody Thu Jun 19 19:43:01 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286DA1A0527; Thu, 19 Jun 2014 19:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.6 X-Spam-Level: X-Spam-Status: No, score=-96.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QEWRVlpFVxM; Thu, 19 Jun 2014 19:42:55 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC121A02C6; Thu, 19 Jun 2014 19:42:55 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 9A878193B420; Fri, 20 Jun 2014 10:42:44 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 2E6434B0383; Fri, 20 Jun 2014 10:42:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s5K2gb6G098150; Fri, 20 Jun 2014 10:42:37 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C39CEB7@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C5B276A@SBS2008.eict.local>, <0C7EDCF89AB9E2478B5D010026CFF4AEA10C39CEB7@SBS2008.eict.local> To: Adel Zaalouk MIME-Version: 1.0 X-KeepSent: 044ABA35:3D1AF0EF-48257CFD:000E8C27; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Fri, 20 Jun 2014 10:42:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-20 10:42:30, Serialize complete at 2014-06-20 10:42:30 Content-Type: multipart/alternative; boundary="=_alternative 000EE38B48257CFD_=" X-MAIL: mse02.zte.com.cn s5K2gb6G098150 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2dpM7yQ3VEV5DZcfTIpzwgC0m-s Cc: Netconf , "netconf@ietf.org" Subject: [Netconf] =?gb2312?b?tPC4tDogUmU6ICBJbXBsZW1lbnRpbmcgYSBORVRDT05G?= =?gb2312?b?IENsaWVudA==?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 02:42:59 -0000 This is a multipart message in MIME format. --=_alternative 000EE38B48257CFD_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSB0aGluayB5b3Ugc2hvdWxkIHdyaXRlIGEgWUFORyBwYXJzZXIgb3IgZ2V0IGEgb3BlbiBzb3Vy Y2UgWUFORyBwYXJzZXIoIA0KZS5nIHB5YW5nKHB5dGhvbiksIHlhbmdkdW1wKEMpLCBvcGVuZGF5 bGlnaHQgeWFuZ3Rvb2xzKGphdmEpKS4NCg0KDQovZnJhbmsNCg0KIk5ldGNvbmYiIDxuZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmc+INC009ogMjAxNC0wNi0yMCAwMjo1ODoxODoNCg0KPiBBZGVsIFph YWxvdWsgPEFkZWwuWmFhbG91a0BlaWN0LmRlPiANCj4gt6K8/sjLOiAgIk5ldGNvbmYiIDxuZXRj b25mLWJvdW5jZXNAaWV0Zi5vcmc+DQo+IA0KPiAyMDE0LTA2LTIwIDAyOjU4DQo+IA0KPiDK1bz+ yMsNCj4gDQo+IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiwgIm5ldGNvbmZAaWV0 Zi5vcmciIA0KPG5ldGNvbmZAaWV0Zi5vcmc+LCANCj4gDQo+ILOty80NCj4gDQo+INb3zOINCj4g DQo+IFJlOiBbTmV0Y29uZl0gSW1wbGVtZW50aW5nIGEgTkVUQ09ORiBDbGllbnQNCj4gDQo+IEhp IEtlbnQsIA0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5LiANCj4gDQo+IEZvciBleGFt cGxlLCBpZiBJIGhhdmUgdGhlIGZvbGxvd2luZyB5YW5nIHN1Yi10cmVlIA0KPiANCj4gICAgICAg Ky0tcncgcmVzb3VyY2VzDQo+ICAgICAgIHwgICstLXJ3IHBvcnQqIFtyZXNvdXJjZS1pZF0NCj4g ICAgICAgfCAgfCAgKy0tcncgcmVzb3VyY2UtaWQgICAgICBpbmV0OnVyaQ0KPiAgICAgICB8ICB8 ICArLS1ybyBudW1iZXI/ICAgICAgICAgIHVpbnQ2NA0KPiAgICAgICB8ICB8ICArLS1ybyBuYW1l PyAgICAgICAgICAgIHN0cmluZw0KPiAgICAgICB8ICB8ICArLS1ybyBjdXJyZW50LXJhdGU/ICAg IHVpbnQzMg0KPiAgICAgICB8ICB8ICArLS1ybyBtYXgtcmF0ZT8gICAgICAgIHVpbnQzMg0KPiAg ICAgICB8ICB8ICArLS1ydyBjb25maWd1cmF0aW9uDQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8gYmUg YWJsZSB0byB1c2UgdGhlIGNsaWVudCB0byBsaXN0IHBvcnRzLCBvciB0byANCj4gbW9kaWZ5IHRo ZSBwb3J0IGNvbmZpZ3VyYXRpb24gZm9yIGluc3RhbmNlLiBJLmUuLCBJIGFtIGdpdmVuIHRoZSAN Cj4gWUFORyBtb2RlbCwgYW5kIEkgd291bGQgbGlrZSB0byB0cmFuc2xhdGUgdGhpcyB0byBjb25m aWd1cmFibGUgDQo+IE5FVENPTkYgcGFyYW1ldGVycy4gDQo+IA0KPiBUaGFuayB5b3UuIA0KPiBC ZXN0IHJlZ2FyZHMsIA0KPiBBZGVsLiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBGcm9tOiBLZW50IFdhdHNlbiBba3dhdHNlbkBqdW5pcGVyLm5ldF0NCj4g U2VudDogVGh1cnNkYXksIDE5IEp1bmUgMjAxNCA4OjExIFBNDQo+IFRvOiBBZGVsIFphYWxvdWs7 IG5ldGNvbmZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBJbXBsZW1lbnRpbmcg YSBORVRDT05GIENsaWVudA0KPiANCj4gVGhlcmUgYXJlIGEgbnVtYmVyIG9mIG9wZW4gc291cmNl IE5FVENPTkYgbGlicmFyaWVzIHRvIGhhbmRsZSANCj4gcHJvdG9jb2wgYmFzaWNzLCBidXQgImFz c3VtaW5nIHRoYXQgSSBrbm93IHRoZSBZQU5HIG1vZGVsIG9mIHRoZSANCj4gdW5kZXJseWluZyBk ZXZpY2UiIGludHJvZHVjZXMgdGhlIG5lZWQgZm9yIHNjaGVtYS1hd2FyZSBsb2dpYywgZm9yIA0K PiBpbnN0YW5jZSwgdG8gZHJpdmUgYSB1c2VyLWludGVyZmFjZS4gICBDYW4geW91IHNheSBtb3Jl IGFib3V0IHRoZSANCj4ga2luZCBvZiBjbGllbnQgeW91IGFyZSB0cnlpbmcgdG8gd3JpdGU/DQo+ IA0KPiBLZW50DQo+IA0KPiBGcm9tOiBBZGVsIFphYWxvdWsgPEFkZWwuWmFhbG91a0BlaWN0LmRl PG1haWx0bzpBZGVsLlphYWxvdWtAZWljdC5kZT4+DQo+IERhdGU6IFRodXJzZGF5LCBKdW5lIDE5 LCAyMDE0IGF0IDk6NTMgQU0NCj4gVG86IE5ldENvbmYgPG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRv Om5ldGNvbmZAaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBbTmV0Y29uZl0gSW1wbGVtZW50aW5nIGEg TkVUQ09ORiBDbGllbnQNCj4gDQo+IEhpLA0KPiANCj4gSSBhbSBwbGFubmluZyBvbiBpbXBsZW1l bnRpbmcgYSBORVRDT05GIGNsaWVudCBmcm9tIHNjcmF0Y2guIA0KPiBIb3dldmVyLCBJIGFtIHJl bGF0aXZlbHkgbmV3IHRvIHRoaXMgYnVzaW5lc3MuIFRoZXJlZm9yZSwgSSB3b3VsZCANCj4gcmVh bGx5IGFwcHJlY2lhdGUgaXQgaWYgc29tZW9uZSBjYW4gZ2l2ZSBtZSBzb21lIHBvaW50ZXJzIG9u IGhvdyB0byANCj4gYm9vdHN0cmFwIG15IGltcGxlbWVudGF0aW9uLCBJIGFtIG5vdCBhZnRlciBh IGZhbmN5IGNsaWVudCBvciANCj4gYW55dGhpbmcsIEkganVzdCBuZWVkIHRvIGltcGxlbWVudCB0 aGUgYmFzaWMgZnVuY3Rpb25hbGl0aWVzIA0KPiBhc3N1bWluZyB0aGF0IEkga25vdyB0aGUgWUFO RyBtb2RlbCBvZiB0aGUgdW5kZXJseWluZyBkZXZpY2UuDQo+IA0KPiANCj4gQmVzdCByZWdhcmRz LA0KPiBBZGVsLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp bGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUg dXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNp cGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhl ciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJy b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2 aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZl IHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVj aXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3Ro ZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVy cm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo= --=_alternative 000EE38B48257CFD_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgeW91IHNob3VsZCB3cml0ZSBh IFlBTkcgcGFyc2VyDQpvciBnZXQgYSBvcGVuIHNvdXJjZSBZQU5HIHBhcnNlciggZS5nIHB5YW5n KHB5dGhvbiksIHlhbmdkdW1wKEMpLCBvcGVuZGF5bGlnaHQNCnlhbmd0b29scyhqYXZhKSkuPC9m b250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4vZnJh bms8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtOZXRjb25mJnF1b3Q7 ICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQrQtNPaIDIwMTQtMDYtMjAgMDI6NTg6 MTg6PGJyPg0KPGJyPg0KJmd0OyBBZGVsIFphYWxvdWsgJmx0O0FkZWwuWmFhbG91a0BlaWN0LmRl Jmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgt6K8/sjLOiAmbmJz cDsmcXVvdDtOZXRjb25mJnF1b3Q7ICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJy Pg0KJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMjAxNC0wNi0y MCAwMjo1ODwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7 IMrVvP7IyzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7 IEtlbnQgV2F0c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0OywgJnF1b3Q7bmV0Y29uZkBp ZXRmLm9yZyZxdW90Ow0KJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCA8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJlOiBbTmV0Y29uZl0gSW1wbGVtZW50aW5n IGEgTkVUQ09ORiBDbGllbnQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyBIaSBLZW50LCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmsgeW91IGZvciB5 b3VyIHJlcGx5LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgRm9yIGV4YW1wbGUsIGlmIEkgaGF2ZSB0 aGUgZm9sbG93aW5nIHlhbmcgc3ViLXRyZWUgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICstLXJ3IHJlc291cmNlczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDsrLS1ydyBwb3J0KiBbcmVzb3VyY2UtaWRdPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7Ky0tcncgcmVzb3VyY2UtaWQgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7aW5ldDp1cmk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 fCAmbmJzcDsrLS1ybyBudW1iZXI/ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 dWludDY0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7Ky0t cm8gbmFtZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7c3RyaW5n PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7Ky0tcm8gY3Vy cmVudC1yYXRlPyAmbmJzcDsgJm5ic3A7dWludDMyPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB8ICZuYnNwO3wgJm5ic3A7Ky0tcm8gbWF4LXJhdGU/ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDt1aW50MzI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAm bmJzcDsrLS1ydyBjb25maWd1cmF0aW9uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgd291bGQgbGlr ZSB0byBiZSBhYmxlIHRvIHVzZSB0aGUgY2xpZW50IHRvIGxpc3QgcG9ydHMsIG9yIHRvIDxicj4N CiZndDsgbW9kaWZ5IHRoZSBwb3J0IGNvbmZpZ3VyYXRpb24gZm9yIGluc3RhbmNlLiBJLmUuLCBJ IGFtIGdpdmVuIHRoZSA8YnI+DQomZ3Q7IFlBTkcgbW9kZWwsIGFuZCBJIHdvdWxkIGxpa2UgdG8g dHJhbnNsYXRlIHRoaXMgdG8gY29uZmlndXJhYmxlIDxicj4NCiZndDsgTkVUQ09ORiBwYXJhbWV0 ZXJzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmsgeW91LiA8YnI+DQomZ3Q7IEJlc3QgcmVn YXJkcywgPGJyPg0KJmd0OyBBZGVsLiA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEZyb206IEtlbnQgV2F0c2VuIFtrd2F0c2VuQGp1 bmlwZXIubmV0XTxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIDE5IEp1bmUgMjAxNCA4OjExIFBN PGJyPg0KJmd0OyBUbzogQWRlbCBaYWFsb3VrOyBuZXRjb25mQGlldGYub3JnPGJyPg0KJmd0OyBT dWJqZWN0OiBSZTogW05ldGNvbmZdIEltcGxlbWVudGluZyBhIE5FVENPTkYgQ2xpZW50PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRoZXJlIGFyZSBhIG51bWJlciBvZiBvcGVuIHNvdXJjZSBORVRDT05G IGxpYnJhcmllcyB0byBoYW5kbGUgPGJyPg0KJmd0OyBwcm90b2NvbCBiYXNpY3MsIGJ1dCAmcXVv dDthc3N1bWluZyB0aGF0IEkga25vdyB0aGUgWUFORyBtb2RlbCBvZg0KdGhlIDxicj4NCiZndDsg dW5kZXJseWluZyBkZXZpY2UmcXVvdDsgaW50cm9kdWNlcyB0aGUgbmVlZCBmb3Igc2NoZW1hLWF3 YXJlIGxvZ2ljLA0KZm9yIDxicj4NCiZndDsgaW5zdGFuY2UsIHRvIGRyaXZlIGEgdXNlci1pbnRl cmZhY2UuICZuYnNwOyBDYW4geW91IHNheSBtb3JlIGFib3V0DQp0aGUgPGJyPg0KJmd0OyBraW5k IG9mIGNsaWVudCB5b3UgYXJlIHRyeWluZyB0byB3cml0ZT88YnI+DQomZ3Q7IDxicj4NCiZndDsg S2VudDxicj4NCiZndDsgPGJyPg0KJmd0OyBGcm9tOiBBZGVsIFphYWxvdWsgJmx0O0FkZWwuWmFh bG91a0BlaWN0LmRlJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOkFkZWwuWmFhbG91a0Bl aWN0LmRlPjx0dD48Zm9udCBzaXplPTI+bWFpbHRvOkFkZWwuWmFhbG91a0BlaWN0LmRlPC9mb250 PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Jmd0OyZndDs8YnI+DQomZ3Q7IERhdGU6IFRodXJz ZGF5LCBKdW5lIDE5LCAyMDE0IGF0IDk6NTMgQU08YnI+DQomZ3Q7IFRvOiBOZXRDb25mICZsdDtu ZXRjb25mQGlldGYub3JnJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOm5ldGNvbmZAaWV0 Zi5vcmc+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86bmV0Y29uZkBpZXRmLm9yZzwvZm9udD48L3R0 PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDsmZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBbTmV0Y29u Zl0gSW1wbGVtZW50aW5nIGEgTkVUQ09ORiBDbGllbnQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGks PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYW0gcGxhbm5pbmcgb24gaW1wbGVtZW50aW5nIGEgTkVU Q09ORiBjbGllbnQgZnJvbSBzY3JhdGNoLiA8YnI+DQomZ3Q7IEhvd2V2ZXIsIEkgYW0gcmVsYXRp dmVseSBuZXcgdG8gdGhpcyBidXNpbmVzcy4gVGhlcmVmb3JlLCBJIHdvdWxkDQo8YnI+DQomZ3Q7 IHJlYWxseSBhcHByZWNpYXRlIGl0IGlmIHNvbWVvbmUgY2FuIGdpdmUgbWUgc29tZSBwb2ludGVy cyBvbiBob3cgdG8NCjxicj4NCiZndDsgYm9vdHN0cmFwIG15IGltcGxlbWVudGF0aW9uLCBJIGFt IG5vdCBhZnRlciBhIGZhbmN5IGNsaWVudCBvciA8YnI+DQomZ3Q7IGFueXRoaW5nLCBJIGp1c3Qg bmVlZCB0byBpbXBsZW1lbnQgdGhlIGJhc2ljIGZ1bmN0aW9uYWxpdGllcyA8YnI+DQomZ3Q7IGFz c3VtaW5nIHRoYXQgSSBrbm93IHRoZSBZQU5HIG1vZGVsIG9mIHRoZSB1bmRlcmx5aW5nIGRldmlj ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0 OyBBZGVsLjxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7IE5ldGNvbmZAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPjx0dD48Zm9udCBzaXplPTI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9mb250PjwvdHQ+ PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQoNCjxicj48cHJlPjxmb250 IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5z bWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGlu dGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91 IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkg dXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQoNCjxicj48cHJlPjxmb250IGNv bG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0 dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVu ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9u LCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 000EE38B48257CFD_=-- From nobody Fri Jun 20 00:41:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2F81A04FA for ; Fri, 20 Jun 2014 00:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv1f5mWvu2mI for ; Fri, 20 Jun 2014 00:32:18 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620C41A04A3 for ; Fri, 20 Jun 2014 00:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8560; q=dns/txt; s=iport; t=1403249538; x=1404459138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XEsLJ7vxVle8w3dzAatXszyYH9BZy+e3kzSU3SyZKUQ=; b=mV1SyHDJecj8ZL85nEmKl4c/OLr5h4Km5FAAqZRO2NHnKH64fazfF3Mn rn5tnlLYuOSS1mIkfpxy2PRewPm2JO6Vdb9DC3+weyoUKfvQaIDcqJrQ+ qy2vOB0JR5tGcPUnG3xkHlT3x5lxsQ2JoUR+nLZdKl8Ne/RGaGGbY5/Id Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAAXjo1OtJA2K/2dsb2JhbABPCoMNgSyCbcBlARlrFnWEAwEBAQQjEUUQAgEIEAgCAiYCAgIwFRACBA4FiEKtDp49F4EqiiyCRAQlMweCd4FMBKYfh3+DQoFuQg X-IronPort-AV: E=Sophos;i="5.01,512,1400025600"; d="scan'208";a="54639082" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 20 Jun 2014 07:32:17 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5K7WHCW010708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 07:32:17 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 20 Jun 2014 02:32:17 -0500 From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" To: "andy@yumaworks.com" Thread-Topic: [Technical Errata Reported] RFC6241 (3980) Thread-Index: AQHPaHW7PCmq8r636UaAx9kYl7rT1JthH62AgAAZNwCAAAhQgIAAAeSAgAACLICAABn6AIAXbeKAgAAsWgCAAAgEgIAAHk8AgAEWmwA= Date: Fri, 20 Jun 2014 07:32:16 +0000 Message-ID: <1403249534.21565.5.camel@ksekera-fedora> References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> <20140604121154.GA8481@elstar.local> <53A2B46D.5090608@cisco.com> <1403181474.24901.6.camel@ksekera-fedora> <53A2E05B.9070001@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.161.72] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UC-D_04BRoPnHBU0KaIlErOkLpo X-Mailman-Approved-At: Fri, 20 Jun 2014 00:41:04 -0700 Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 07:32:21 -0000 QWRkaW5nIGtleXMgYWxsb3dzIHRoZSBjbGllbnQgdG8gaWRlbnRpZnkgc2VwYXJhdGUgbGlzdCBl bnRpdGllcy4gVGhlDQpjbGllbnQgc2hvdWxkIGJlIGJyaWdodCBlbm91Z2ggdG8gcmVxdWVzdCB0 aGUga2V5cywgYnV0IGlmIGhlIGRvZXMgbm90LA0KYSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gd2hp Y2ggaXMgc21hcnQgZW5vdWdoIGNvdWxkIHN1cHBseSB0aGVtDQphdXRvbWF0aWNhbGx5IC0gc2lu Y2Ugd2l0aG91dCB0aGVtLCBtb3N0IHJlcGx5cyB3b3VsZCBwcm9iYWJseSBiZQ0KdW51c2FibGUu IEJ1dCBJIGNhbiBpbWFnaW5lIGEgbGltaXRlZCBlbnZpcm9ubWVudCwgd2hlcmUgY3B1L21lbW9y eSBpcw0Kc2NhcmNlIGFuZCB0aGUgbmV0Y29uZiBzZXJ2ZXIgY291bGQgYmUgYXMgc2ltcGxlIGFz IHBvc3NpYmxlLiBUaGVyZWZvcmUsDQpJIHByb3Bvc2VkIE1BWSBpbnN0ZWFkIG9mIE1VU1QuDQoN Ck9uIFRodSwgMjAxNC0wNi0xOSBhdCAwNzo1NSAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3RlOg0K PiBPbiBUaHUsIEp1biAxOSwgMjAxNCBhdCA2OjA2IEFNLCBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNl QGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiA+IE1hcnRpbiwgSsO8cmdlbiwgV0csDQo+ID4NCj4g PiBGaW5lIHdpdGggdGhpcz8NCj4gPg0KPiANCj4gTm90IHJlYWxseS4NCj4gV2h5IGlzIHRoZSBy ZXF1aXJlbWVudCB0byBhZGQga2V5IGxlYWZzIGEgTUFZIGluc3RlYWQgb2YgYSBNVVNUIG9yIFNI T1VMRD8NCj4gSXQgc2VlbXMgbGlrZSBzdWJ0cmVlIGZpbHRlcnMgbmVlZCB0byBiZSBpbXBsZW1l bnRlZCBpbiBhIGNvbnNpc3RlbnQgbWFubmVyDQo+IHRvIG1ha2UgdGhlbSByZWFsbHkgdXNlZnVs Lg0KPiANCj4gDQo+IEFuZHkNCj4gDQo+IA0KPiA+DQo+ID4gUmVnYXJkcywgQi4NCj4gPg0KPiA+ PiBIaSBCZW5vaXQsDQo+ID4+DQo+ID4+IEkgZG9uJ3QgdGhpbmsgSSBjYW4uDQo+ID4+DQo+ID4+ IElmIHRoaXMgc2hvdWxkIGJlIHB1dCBpbnRvIHNlY3Rpb24gNi4zLCB0aGVuIEknZCBhZGQgdG8g dGhpcyBibG9jayBvZg0KPiA+PiB0ZXh0Og0KPiA+Pg0KPiA+PiBPTEQ6DQo+ID4+ICAgICBGb3Ig ZWFjaCBzaWJsaW5nIHNldCwgdGhlIHNlcnZlciBkZXRlcm1pbmVzIHdoaWNoIG5vZGVzIGFyZSBp bmNsdWRlZA0KPiA+PiAgICAgKG9yIHBvdGVudGlhbGx5IGluY2x1ZGVkKSBpbiB0aGUgZmlsdGVy IG91dHB1dCwgYW5kIHdoaWNoIHNpYmxpbmcNCj4gPj4gICAgIHN1YnRyZWVzIGFyZSBleGNsdWRl ZCAocHJ1bmVkKSBmcm9tIHRoZSBmaWx0ZXIgb3V0cHV0LiAgVGhlIHNlcnZlcg0KPiA+PiAgICAg Zmlyc3QgZGV0ZXJtaW5lcyB3aGljaCB0eXBlcyBvZiBub2RlcyBhcmUgcHJlc2VudCBpbiB0aGUg c2libGluZyBzZXQNCj4gPj4gICAgIGFuZCBwcm9jZXNzZXMgdGhlIG5vZGVzIGFjY29yZGluZyB0 byB0aGUgcnVsZXMgZm9yIHRoZWlyIHR5cGUuICBJZg0KPiA+PiAgICAgYW55IG5vZGVzIGluIHRo ZSBzaWJsaW5nIHNldCBhcmUgc2VsZWN0ZWQsIHRoZW4gdGhlIHByb2Nlc3MgaXMNCj4gPj4gICAg IHJlY3Vyc2l2ZWx5IGFwcGxpZWQgdG8gdGhlIHNpYmxpbmcgc2V0cyBvZiBlYWNoIHNlbGVjdGVk IG5vZGUuICBUaGUNCj4gPj4gICAgIGFsZ29yaXRobSBjb250aW51ZXMgdW50aWwgYWxsIHNpYmxp bmcgc2V0cyBpbiBhbGwgc3VidHJlZXMgc3BlY2lmaWVkDQo+ID4+ICAgICBpbiB0aGUgZmlsdGVy IGhhdmUgYmVlbiBwcm9jZXNzZWQuDQo+ID4+DQo+ID4+IE5FVzoNCj4gPj4gICAgIEZvciBlYWNo IHNpYmxpbmcgc2V0LCB0aGUgc2VydmVyIGRldGVybWluZXMgd2hpY2ggbm9kZXMgYXJlIGluY2x1 ZGVkDQo+ID4+ICAgICAob3IgcG90ZW50aWFsbHkgaW5jbHVkZWQpIGluIHRoZSBmaWx0ZXIgb3V0 cHV0LCBhbmQgd2hpY2ggc2libGluZw0KPiA+PiAgICAgc3VidHJlZXMgYXJlIGV4Y2x1ZGVkIChw cnVuZWQpIGZyb20gdGhlIGZpbHRlciBvdXRwdXQuICBUaGUgc2VydmVyDQo+ID4+ICAgICBmaXJz dCBkZXRlcm1pbmVzIHdoaWNoIHR5cGVzIG9mIG5vZGVzIGFyZSBwcmVzZW50IGluIHRoZSBzaWJs aW5nIHNldA0KPiA+PiAgICAgYW5kIHByb2Nlc3NlcyB0aGUgbm9kZXMgYWNjb3JkaW5nIHRvIHRo ZSBydWxlcyBmb3IgdGhlaXIgdHlwZS4gIElmDQo+ID4+ICAgICBhbnkgbm9kZXMgaW4gdGhlIHNp Ymxpbmcgc2V0IGFyZSBzZWxlY3RlZCwgdGhlbiB0aGUgcHJvY2VzcyBpcw0KPiA+PiAgICAgcmVj dXJzaXZlbHkgYXBwbGllZCB0byB0aGUgc2libGluZyBzZXRzIG9mIGVhY2ggc2VsZWN0ZWQgbm9k ZS4gIFRoZQ0KPiA+PiAgICAgYWxnb3JpdGhtIGNvbnRpbnVlcyB1bnRpbCBhbGwgc2libGluZyBz ZXRzIGluIGFsbCBzdWJ0cmVlcyBzcGVjaWZpZWQNCj4gPj4gICAgIGluIHRoZSBmaWx0ZXIgaGF2 ZSBiZWVuIHByb2Nlc3NlZC4gSWYgYW55IHNpYmxpbmcgbm9kZXMgb2YgYSBub2RlDQo+ID4+ICAg ICBhcmUgaW5zdGFuY2UgaWRlbnRpZmllciBjb21wb25lbnRzIGZvciBhIGNvbmNlcHR1YWwgZGF0 YSBzdHJ1Y3R1cmUNCj4gPj4gICAgIChlLmcuLCBsaXN0IGtleSBsZWFmKSwgdGhlbiB0aGV5IE1B WSBiZSBpbmNsdWRlZCBpbiB0aGUgZmlsdGVyIG91dHB1dC4NCj4gPj4NCj4gPj4gUmFnYXJkcywN Cj4gPj4gS2xlbWVudA0KPiA+Pg0KPiA+PiBPbiBUaHUsIDIwMTQtMDYtMTkgYXQgMTE6NTkgKzAy MDAsIEJlbm9pdCBDbGFpc2Ugd3JvdGU6DQo+ID4+DQo+ID4+PiBLbGVtZW50LA0KPiA+Pj4NCj4g Pj4+IEFyZSB5b3UgZmluZSB3aXRoIHRoaXMgcmVzb2x1dGlvbiBiZWxvdy4NCj4gPj4+IElmIHll cywgcGxlYXNlIHVwZGF0ZSB0aGUgZXJyYXRhLg0KPiA+Pj4gSWYgeW91IGRvbid0IGhhdmUgdGhl IHJpZ2h0IHRvIGRvLCBJIGNhbiBkby4gSW4gdGhpcyBjYXNlLCBwcm92aWRlDQo+ID4+PiBPTEQv TkVXIHRleHQuDQo+ID4+Pg0KPiA+Pj4gUmVnYXJkcywgQmVub2l0DQo+ID4+Pg0KPiA+Pj4+IE9u IFdlZCwgSnVuIDA0LCAyMDE0IGF0IDEyOjM4OjU1UE0gKzAyMDAsIE1hcnRpbiBCam9ya2x1bmQg d3JvdGU6DQo+ID4+Pj4NCj4gPj4+Pj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gT24g V2VkLCBKdW4gMDQsIDIwMTQgYXQgMTI6MjQ6MjNQTSArMDIwMCwgTWFydGluIEJqb3JrbHVuZCB3 cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+IEkgYW0gbm90IHN1cmUgc2luY2UgaW4gdGhlIG5ldyB0ZXh0ICdub2RlJyBpcyByYXRoZXIg dW5zcGVjaWZpZWQuDQo+ID4+Pj4+Pj4+ICBGb3INCj4gPj4+Pj4+Pj4gbWUsIGl0IHdvdWxkIGhl bHAgdG8gaGF2ZSBhIGV4YW1wbGUgZGVtb25zdHJhdGluZyB3aGF0IGlzIGJyb2tlbg0KPiA+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+IEFzc3VtZSB0aGlzIG1vZGVsOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g ICAgIGNvbnRhaW5lciBzZXJ2ZXJzIHsNCj4gPj4+Pj4+PiAgICAgICBsaXN0IHNlcnZlciB7DQo+ ID4+Pj4+Pj4gICAgICAgICBrZXkgbmFtZTsNCj4gPj4+Pj4+PiAgICAgICAgIGxlYWYgbmFtZSB7 IC4uLiB9DQo+ID4+Pj4+Pj4gICAgICAgICBsZWFmIGlwIHsgLi4uIH0NCj4gPj4+Pj4+PiAgICAg ICAgIGxlYWYgcG9ydCB7IC4uLiB9DQo+ID4+Pj4+Pj4gICAgICAgfQ0KPiA+Pj4+Pj4+ICAgICB9 DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBhbmQgdGhpcyBkYXRhIG9uIHRoZSBzZXJ2ZXI6DQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiAgICAgPHNlcnZlcnM+DQo+ID4+Pj4+Pj4gICAgICAgPHNlcnZlcj4N Cj4gPj4+Pj4+PiAgICAgICAgIDxuYW1lPmZvbzwvbmFtZT4NCj4gPj4+Pj4+PiAgICAgICAgIDxp cD4xMC4wLjAuMTwvaXA+DQo+ID4+Pj4+Pj4gICAgICAgICA8cG9ydD44MDwvcG9ydD4NCj4gPj4+ Pj4+PiAgICAgICA8L3NlcnZlcj4NCj4gPj4+Pj4+PiAgICAgICA8c2VydmVyPg0KPiA+Pj4+Pj4+ ICAgICAgICAgPG5hbWU+YmFyPC9uYW1lPg0KPiA+Pj4+Pj4+ICAgICAgICAgPGlwPjEwLjAuMC4x PC9pcD4NCj4gPj4+Pj4+PiAgICAgICAgIDxwb3J0PjI1PC9wb3J0Pg0KPiA+Pj4+Pj4+ICAgICAg IDwvc2VydmVyPg0KPiA+Pj4+Pj4+ICAgICA8L3NlcnZlcnM+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ PiBOb3csIHdpdGggdGhpcyBmaWx0ZXI6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAgICAgPHNlcnZl cnM+DQo+ID4+Pj4+Pj4gICAgICAgPHNlcnZlcj4NCj4gPj4+Pj4+PiAgICAgICAgIDxwb3J0Pjgw PC9wb3J0Pg0KPiA+Pj4+Pj4+ICAgICAgICAgPGlwLz4NCj4gPj4+Pj4+PiAgICAgICA8L3NlcnZl cj4NCj4gPj4+Pj4+PiAgICAgPC9zZXJ2ZXI+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJdCBpcywg YWNjb3JkaW5nIHRvIDYyNDEsIG9rIHRvIHJldHVybjoNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAg ICA8c2VydmVycz4NCj4gPj4+Pj4+PiAgICAgICA8c2VydmVyPg0KPiA+Pj4+Pj4+ICAgICAgICAg PG5hbWU+Zm9vPC9uYW1lPg0KPiA+Pj4+Pj4+ICAgICAgICAgPGlwPjEwLjAuMC4xPC9pcD4NCj4g Pj4+Pj4+PiAgICAgICAgIDxwb3J0PjgwPC9wb3J0Pg0KPiA+Pj4+Pj4+ICAgICAgIDwvc2VydmVy Pg0KPiA+Pj4+Pj4+ICAgICA8L3NlcnZlcnM+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAoYmVjYXVz ZSAnbmFtZScgaXMgYSBzaWJsaW5nIHRvIHRoZSBzZWxlY3Rpb24gbm9kZSAnaXAnKQ0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBIb3dldmVyLCB3aXRoIHRoaXMgZmlsdGVyOg0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgIDxzZXJ2ZXJzPg0KPiA+Pj4+Pj4+ICAgICAgIDxzZXJ2ZXI+ DQo+ID4+Pj4+Pj4gICAgICAgICA8cG9ydD44MDwvcG9ydD4NCj4gPj4+Pj4+PiAgICAgICA8L3Nl cnZlcj4NCj4gPj4+Pj4+PiAgICAgPC9zZXJ2ZXI+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBhIHN0 cmljdCBpbnRlcnByZXRhdGlvbiBvZiA2MjQxIHNlZW1zIHRvIHN1Z2dlc3QgdGhhdCB0aGlzIGlz IGlsbGVnYWwNCj4gPj4+Pj4+PiB0byByZXR1cm46DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAgICAg PHNlcnZlcnM+DQo+ID4+Pj4+Pj4gICAgICAgPHNlcnZlcj4NCj4gPj4+Pj4+PiAgICAgICAgIDxu YW1lPmZvbzwvbmFtZT4NCj4gPj4+Pj4+PiAgICAgICAgIDxwb3J0PjgwPC9wb3J0Pg0KPiA+Pj4+ Pj4+ICAgICAgIDwvc2VydmVyPg0KPiA+Pj4+Pj4+ICAgICA8L3NlcnZlcnM+DQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+PiAuLi4gYnV0IHRoYXQgZG9lc24ndCBtYWtlIG11Y2ggc2Vuc2UuDQo+ID4+Pj4+ Pj4NCj4gPj4+Pj4+PiBUaGUgaW50ZW50aW9uIG9mIHRoZSB0ZXh0IHdhcyB0byBhbGxvdyBrZXlz IHRvIGJlIGluc2VydGVkIGV2ZXJ5d2hlcmUNCj4gPj4+Pj4+PiBpbiB0aGUgcmV0dXJuZWQgc3Vi dHJlZXMuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoaXMgc2FpZCwgSSBhbSBu b3QgY29udmluY2VkIHRoZSBwcm9wb3NlZCBjaGFuZ2UgZml4ZXMgdGhpcy4gIFRoZQ0KPiA+Pj4+ Pj4+IHN1YnRyZWUgZmlsdGVyIHNwZWNpZmljYXRpb24gdGV4dCBpcyBwcmV0dHkgZGlmZmljdWx0 IHRvIGludGVycHJldC4uLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gIFNvIGFueSBrZXkgbGVhZnMg dGhhdCBhcmUgY2hpbGQgbm9kZXMgb2YgYW55IENvbnRhaW5tZW50IE5vZGVzIG9mDQo+ID4+Pj4+ PiB0aGUgU3VidHJlZSBGaWx0ZXIgY2FuIGJlIGFkZGVkPyBXb3VsZCB0aGF0IGJlIG1vcmUgYWNj dXJhdGU/DQo+ID4+Pj4+Pg0KPiA+Pj4+PiBJIHRoaW5rIHNvLCBidXQgdGhlIGN1cnJlbnQgdGV4 dCBpcyBpbiBzZWN0aW9uIDYuMi41IHdoaWNoIHRhbGtzIGFib3V0DQo+ID4+Pj4+IGNvbnRlbnQg bWF0Y2ggbm9kZXMuICBUaGlzIGlzIGEgYml0IGNvbmZ1c2luZyAtIHdoYXQgaGFwcGVucyBpZiB5 b3UNCj4gPj4+Pj4gZG9uJ3QgaGF2ZSBhbnkgY29udGVudCBtYXRjaCBub2Rlcz8NCj4gPj4+Pj4N Cj4gPj4+Pj4gWW91ciBzZW50ZW5jZSBiZWxvbmdzIHRvIHRleHQgdGhhdCBkaXNjdXNzIHN1YnRy ZWUgZmlsdGVyIGluIGdlbmVyYWwsDQo+ID4+Pj4+IG1heWJlIHNvbWV3aGVyZSBpbiBzZWN0aW9u IDYuMy4NCj4gPj4+Pj4NCj4gPj4+Pj4gIFllcywgdGhhdCBtYWtlcyBzZW5zZSB0byBtZS4NCj4g Pj4+Pg0KPiA+Pj4+IC9qcw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPg0KDQo= From nobody Fri Jun 20 01:06:46 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750A71B279A for ; Fri, 20 Jun 2014 01:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec5K81a_ZgiI for ; Fri, 20 Jun 2014 01:06:41 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF001AD6B1 for ; Fri, 20 Jun 2014 01:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14738; q=dns/txt; s=iport; t=1403251601; x=1404461201; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=k7AsL1N4F88KNurvJm2bJOsvtV33+umToDRzYtmSpLE=; b=C6/Riefk/DDUzfXm2Vb8C7EMM1xkwKd4fd1cceaVfA5wRxcc54MlLj3h INX4t6fJ12d4LtZRhvKn7fEctIk8QH1MISxIEDkxWEdrn6tjZ46FsZte3 XN5EdCT3XatHDTuKuWyISbBMrFNFpWroFW58t8ubQf9WHCG16Ktkrfx8n M=; X-IronPort-AV: E=Sophos; i="5.01,512,1400025600"; d="scan'208,217"; a="41980427" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 20 Jun 2014 08:06:38 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5K86YVO005002; Fri, 20 Jun 2014 08:06:35 GMT Message-ID: <53A3EB8A.3070101@cisco.com> Date: Fri, 20 Jun 2014 10:06:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" , "andy@yumaworks.com" References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> <20140604121154.GA8481@elstar.local> <53A2B46D.5090608@cisco.com> <1403181474.24901.6.camel@ksekera-fedora> <53A2E05B.9070001@cisco.com> <1403249534.21565.5.camel@ksekera-fedora> In-Reply-To: <1403249534.21565.5.camel@ksekera-fedora> Content-Type: multipart/alternative; boundary="------------020905010100090702010006" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2mXayPy5LMcLJP8DiniFabIPgL0 Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 08:06:44 -0000 This is a multi-part message in MIME format. --------------020905010100090702010006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Klement, Based on your reasoning, SHOULD is appropriate. From RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Regards, Benoit > Adding keys allows the client to identify separate list entities. The > client should be bright enough to request the keys, but if he does not, > a server implementation which is smart enough could supply them > automatically - since without them, most replys would probably be > unusable. But I can imagine a limited environment, where cpu/memory is > scarce and the netconf server could be as simple as possible. Therefore, > I proposed MAY instead of MUST. > > On Thu, 2014-06-19 at 07:55 -0700, Andy Bierman wrote: >> On Thu, Jun 19, 2014 at 6:06 AM, Benoit Claise wrote: >> >>> Martin, Jürgen, WG, >>> >>> Fine with this? >>> >> Not really. >> Why is the requirement to add key leafs a MAY instead of a MUST or SHOULD? >> It seems like subtree filters need to be implemented in a consistent manner >> to make them really useful. >> >> >> Andy >> >> >>> Regards, B. >>> >>>> Hi Benoit, >>>> >>>> I don't think I can. >>>> >>>> If this should be put into section 6.3, then I'd add to this block of >>>> text: >>>> >>>> OLD: >>>> For each sibling set, the server determines which nodes are included >>>> (or potentially included) in the filter output, and which sibling >>>> subtrees are excluded (pruned) from the filter output. The server >>>> first determines which types of nodes are present in the sibling set >>>> and processes the nodes according to the rules for their type. If >>>> any nodes in the sibling set are selected, then the process is >>>> recursively applied to the sibling sets of each selected node. The >>>> algorithm continues until all sibling sets in all subtrees specified >>>> in the filter have been processed. >>>> >>>> NEW: >>>> For each sibling set, the server determines which nodes are included >>>> (or potentially included) in the filter output, and which sibling >>>> subtrees are excluded (pruned) from the filter output. The server >>>> first determines which types of nodes are present in the sibling set >>>> and processes the nodes according to the rules for their type. If >>>> any nodes in the sibling set are selected, then the process is >>>> recursively applied to the sibling sets of each selected node. The >>>> algorithm continues until all sibling sets in all subtrees specified >>>> in the filter have been processed. If any sibling nodes of a node >>>> are instance identifier components for a conceptual data structure >>>> (e.g., list key leaf), then they MAY be included in the filter output. >>>> >>>> Ragards, >>>> Klement >>>> >>>> On Thu, 2014-06-19 at 11:59 +0200, Benoit Claise wrote: >>>> >>>>> Klement, >>>>> >>>>> Are you fine with this resolution below. >>>>> If yes, please update the errata. >>>>> If you don't have the right to do, I can do. In this case, provide >>>>> OLD/NEW text. >>>>> >>>>> Regards, Benoit >>>>> >>>>>> On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund wrote: >>>>>> >>>>>>> Juergen Schoenwaelder wrote: >>>>>>> >>>>>>>> On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote: >>>>>>>> >>>>>>>>> Juergen Schoenwaelder wrote: >>>>>>>>> >>>>>>>>>> I am not sure since in the new text 'node' is rather unspecified. >>>>>>>>>> For >>>>>>>>>> me, it would help to have a example demonstrating what is broken >>>>>>>>>> >>>>>>>>> Assume this model: >>>>>>>>> >>>>>>>>> container servers { >>>>>>>>> list server { >>>>>>>>> key name; >>>>>>>>> leaf name { ... } >>>>>>>>> leaf ip { ... } >>>>>>>>> leaf port { ... } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> and this data on the server: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> foo >>>>>>>>> 10.0.0.1 >>>>>>>>> 80 >>>>>>>>> >>>>>>>>> >>>>>>>>> bar >>>>>>>>> 10.0.0.1 >>>>>>>>> 25 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Now, with this filter: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 80 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> It is, according to 6241, ok to return: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> foo >>>>>>>>> 10.0.0.1 >>>>>>>>> 80 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (because 'name' is a sibling to the selection node 'ip') >>>>>>>>> >>>>>>>>> >>>>>>>>> However, with this filter: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 80 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> a strict interpretation of 6241 seems to suggest that this is illegal >>>>>>>>> to return: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> foo >>>>>>>>> 80 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ... but that doesn't make much sense. >>>>>>>>> >>>>>>>>> The intention of the text was to allow keys to be inserted everywhere >>>>>>>>> in the returned subtrees. >>>>>>>>> >>>>>>>>> >>>>>>>>> This said, I am not convinced the proposed change fixes this. The >>>>>>>>> subtree filter specification text is pretty difficult to interpret... >>>>>>>>> >>>>>>>>> So any key leafs that are child nodes of any Containment Nodes of >>>>>>>> the Subtree Filter can be added? Would that be more accurate? >>>>>>>> >>>>>>> I think so, but the current text is in section 6.2.5 which talks about >>>>>>> content match nodes. This is a bit confusing - what happens if you >>>>>>> don't have any content match nodes? >>>>>>> >>>>>>> Your sentence belongs to text that discuss subtree filter in general, >>>>>>> maybe somewhere in section 6.3. >>>>>>> >>>>>>> Yes, that makes sense to me. >>>>>> /js >>>>>> >>>>>> --------------020905010100090702010006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Klement,

Based on your reasoning, SHOULD is appropriate.
From RFC 2119:
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.
Regards, Benoit
Adding keys allows the client to identify separate list entities. The
client should be bright enough to request the keys, but if he does not,
a server implementation which is smart enough could supply them
automatically - since without them, most replys would probably be
unusable. But I can imagine a limited environment, where cpu/memory is
scarce and the netconf server could be as simple as possible. Therefore,
I proposed MAY instead of MUST.

On Thu, 2014-06-19 at 07:55 -0700, Andy Bierman wrote:

On Thu, Jun 19, 2014 at 6:06 AM, Benoit Claise <bclaise@cisco.com> wrote:


Martin, Jürgen, WG,

Fine with this?


Not really.
Why is the requirement to add key leafs a MAY instead of a MUST or SHOULD?
It seems like subtree filters need to be implemented in a consistent manner
to make them really useful.


Andy



Regards, B.


Hi Benoit,

I don't think I can.

If this should be put into section 6.3, then I'd add to this block of
text:

OLD:
    For each sibling set, the server determines which nodes are included
    (or potentially included) in the filter output, and which sibling
    subtrees are excluded (pruned) from the filter output.  The server
    first determines which types of nodes are present in the sibling set
    and processes the nodes according to the rules for their type.  If
    any nodes in the sibling set are selected, then the process is
    recursively applied to the sibling sets of each selected node.  The
    algorithm continues until all sibling sets in all subtrees specified
    in the filter have been processed.

NEW:
    For each sibling set, the server determines which nodes are included
    (or potentially included) in the filter output, and which sibling
    subtrees are excluded (pruned) from the filter output.  The server
    first determines which types of nodes are present in the sibling set
    and processes the nodes according to the rules for their type.  If
    any nodes in the sibling set are selected, then the process is
    recursively applied to the sibling sets of each selected node.  The
    algorithm continues until all sibling sets in all subtrees specified
    in the filter have been processed. If any sibling nodes of a node
    are instance identifier components for a conceptual data structure
    (e.g., list key leaf), then they MAY be included in the filter output.

Ragards,
Klement

On Thu, 2014-06-19 at 11:59 +0200, Benoit Claise wrote:


Klement,

Are you fine with this resolution below.
If yes, please update the errata.
If you don't have the right to do, I can do. In this case, provide
OLD/NEW text.

Regards, Benoit


On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund wrote:


Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote:


Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


I am not sure since in the new text 'node' is rather unspecified.
 For
me, it would help to have a example demonstrating what is broken


Assume this model:

    container servers {
      list server {
        key name;
        leaf name { ... }
        leaf ip { ... }
        leaf port { ... }
      }
    }

and this data on the server:

    <servers>
      <server>
        <name>foo</name>
        <ip>10.0.0.1</ip>
        <port>80</port>
      </server>
      <server>
        <name>bar</name>
        <ip>10.0.0.1</ip>
        <port>25</port>
      </server>
    </servers>

Now, with this filter:

    <servers>
      <server>
        <port>80</port>
        <ip/>
      </server>
    </server>

It is, according to 6241, ok to return:

    <servers>
      <server>
        <name>foo</name>
        <ip>10.0.0.1</ip>
        <port>80</port>
      </server>
    </servers>

(because 'name' is a sibling to the selection node 'ip')


However, with this filter:

    <servers>
      <server>
        <port>80</port>
      </server>
    </server>

a strict interpretation of 6241 seems to suggest that this is illegal
to return:

    <servers>
      <server>
        <name>foo</name>
        <port>80</port>
      </server>
    </servers>

... but that doesn't make much sense.

The intention of the text was to allow keys to be inserted everywhere
in the returned subtrees.


This said, I am not convinced the proposed change fixes this.  The
subtree filter specification text is pretty difficult to interpret...

 So any key leafs that are child nodes of any Containment Nodes of

the Subtree Filter can be added? Would that be more accurate?


I think so, but the current text is in section 6.2.5 which talks about
content match nodes.  This is a bit confusing - what happens if you
don't have any content match nodes?

Your sentence belongs to text that discuss subtree filter in general,
maybe somewhere in section 6.3.

 Yes, that makes sense to me.

/js




        

      

      

    

    

  


--------------020905010100090702010006--


From nobody Fri Jun 20 01:54:50 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFA51A040E for ; Fri, 20 Jun 2014 01:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 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=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkmbkQlhXznC for ; Fri, 20 Jun 2014 01:54:42 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9951A0351 for ; Fri, 20 Jun 2014 01:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9812; q=dns/txt; s=iport; t=1403254483; x=1404464083; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mm+XNuN8EX9mhy/oM9SpPrCHgwllfXh+Jo2eRsZLto8=; b=i1NUkNORvp4Mq1q8R0n/wb66lWk9QGqdHrbQffPkPWhFXBdD7c/vfiYh DwSYh6c7Qku44fa+v4xsyV0tnA7pjrPYYPc9jBq1SxqzUwD/rkkbDe7pz xbGGqxhcpFQKnPzNYoekEduWTxsV6oi7wzHGgF9OqyYuarQ/PMbI8gXjp M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFAMr1o1OtJV2Y/2dsb2JhbABPCoMNgR8Ngm3AZwEZaxZ1hAMBAQEEIxFFEAIBCBAIAgImAgICMBUQAgQOBYhCrRWeQxeBKoosgkQEJTMHgneBTASmH4d/g0KBbkI
X-IronPort-AV: E=Sophos;i="5.01,512,1400025600"; d="scan'208";a="334580489"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jun 2014 08:54:40 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5K8sc2L001193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 08:54:38 GMT
Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 20 Jun 2014 03:54:38 -0500
From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
To: "Benoit Claise (bclaise)" 
Thread-Topic: [Technical Errata Reported] RFC6241 (3980)
Thread-Index: AQHPaHW7PCmq8r636UaAx9kYl7rT1JthH62AgAAZNwCAAAhQgIAAAeSAgAACLICAABn6AIAXbeKAgAAsWgCAAAgEgIAAHk8AgAEWmwCAAAmYAIAADW2A
Date: Fri, 20 Jun 2014 08:54:38 +0000
Message-ID: <1403254477.11410.1.camel@ksekera-fedora>
References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> <20140604121154.GA8481@elstar.local> <53A2B46D.5090608@cisco.com> <1403181474.24901.6.camel@ksekera-fedora> <53A2E05B.9070001@cisco.com>  <1403249534.21565.5.camel@ksekera-fedora> <53A3EB8A.3070101@cisco.com>
In-Reply-To: <53A3EB8A.3070101@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.161.72]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9DBFC0C466AF9A4EB192EE94F5C4D146@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/DrV1FGozKPnW3nVad2w2hbjzC-U
Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" 
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 08:54:45 -0000

U0hPVUxEIGluc3RlYWQgb2YgTUFZIGlzIGZpbmUuDQoNCk9uIEZyaSwgMjAxNC0wNi0yMCBhdCAx
MDowNiArMDIwMCwgQmVub2l0IENsYWlzZSB3cm90ZToNCj4gS2xlbWVudCwNCj4gDQo+IEJhc2Vk
IG9uIHlvdXIgcmVhc29uaW5nLCBTSE9VTEQgaXMgYXBwcm9wcmlhdGUuDQo+ICBGcm9tIFJGQyAy
MTE5Og0KPiANCj4gICAgIDMuIFNIT1VMRCAgIFRoaXMgd29yZCwgb3IgdGhlIGFkamVjdGl2ZSAi
UkVDT01NRU5ERUQiLCBtZWFuIHRoYXQgdGhlcmUNCj4gICAgICAgICBtYXkgZXhpc3QgdmFsaWQg
cmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgdG8gaWdub3JlIGENCj4gICAgICAg
ICBwYXJ0aWN1bGFyIGl0ZW0sIGJ1dCB0aGUgZnVsbCBpbXBsaWNhdGlvbnMgbXVzdCBiZSB1bmRl
cnN0b29kIGFuZA0KPiAgICAgICAgIGNhcmVmdWxseSB3ZWlnaGVkIGJlZm9yZSBjaG9vc2luZyBh
IGRpZmZlcmVudCBjb3Vyc2UuDQo+IA0KPiBSZWdhcmRzLCBCZW5vaXQNCj4gPiBBZGRpbmcga2V5
cyBhbGxvd3MgdGhlIGNsaWVudCB0byBpZGVudGlmeSBzZXBhcmF0ZSBsaXN0IGVudGl0aWVzLiBU
aGUNCj4gPiBjbGllbnQgc2hvdWxkIGJlIGJyaWdodCBlbm91Z2ggdG8gcmVxdWVzdCB0aGUga2V5
cywgYnV0IGlmIGhlIGRvZXMgbm90LA0KPiA+IGEgc2VydmVyIGltcGxlbWVudGF0aW9uIHdoaWNo
IGlzIHNtYXJ0IGVub3VnaCBjb3VsZCBzdXBwbHkgdGhlbQ0KPiA+IGF1dG9tYXRpY2FsbHkgLSBz
aW5jZSB3aXRob3V0IHRoZW0sIG1vc3QgcmVwbHlzIHdvdWxkIHByb2JhYmx5IGJlDQo+ID4gdW51
c2FibGUuIEJ1dCBJIGNhbiBpbWFnaW5lIGEgbGltaXRlZCBlbnZpcm9ubWVudCwgd2hlcmUgY3B1
L21lbW9yeSBpcw0KPiA+IHNjYXJjZSBhbmQgdGhlIG5ldGNvbmYgc2VydmVyIGNvdWxkIGJlIGFz
IHNpbXBsZSBhcyBwb3NzaWJsZS4gVGhlcmVmb3JlLA0KPiA+IEkgcHJvcG9zZWQgTUFZIGluc3Rl
YWQgb2YgTVVTVC4NCj4gPg0KPiA+IE9uIFRodSwgMjAxNC0wNi0xOSBhdCAwNzo1NSAtMDcwMCwg
QW5keSBCaWVybWFuIHdyb3RlOg0KPiA+PiBPbiBUaHUsIEp1biAxOSwgMjAxNCBhdCA2OjA2IEFN
LCBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+DQo+ID4+PiBN
YXJ0aW4sIErDvHJnZW4sIFdHLA0KPiA+Pj4NCj4gPj4+IEZpbmUgd2l0aCB0aGlzPw0KPiA+Pj4N
Cj4gPj4gTm90IHJlYWxseS4NCj4gPj4gV2h5IGlzIHRoZSByZXF1aXJlbWVudCB0byBhZGQga2V5
IGxlYWZzIGEgTUFZIGluc3RlYWQgb2YgYSBNVVNUIG9yIFNIT1VMRD8NCj4gPj4gSXQgc2VlbXMg
bGlrZSBzdWJ0cmVlIGZpbHRlcnMgbmVlZCB0byBiZSBpbXBsZW1lbnRlZCBpbiBhIGNvbnNpc3Rl
bnQgbWFubmVyDQo+ID4+IHRvIG1ha2UgdGhlbSByZWFsbHkgdXNlZnVsLg0KPiA+Pg0KPiA+Pg0K
PiA+PiBBbmR5DQo+ID4+DQo+ID4+DQo+ID4+PiBSZWdhcmRzLCBCLg0KPiA+Pj4NCj4gPj4+PiBI
aSBCZW5vaXQsDQo+ID4+Pj4NCj4gPj4+PiBJIGRvbid0IHRoaW5rIEkgY2FuLg0KPiA+Pj4+DQo+
ID4+Pj4gSWYgdGhpcyBzaG91bGQgYmUgcHV0IGludG8gc2VjdGlvbiA2LjMsIHRoZW4gSSdkIGFk
ZCB0byB0aGlzIGJsb2NrIG9mDQo+ID4+Pj4gdGV4dDoNCj4gPj4+Pg0KPiA+Pj4+IE9MRDoNCj4g
Pj4+PiAgICAgIEZvciBlYWNoIHNpYmxpbmcgc2V0LCB0aGUgc2VydmVyIGRldGVybWluZXMgd2hp
Y2ggbm9kZXMgYXJlIGluY2x1ZGVkDQo+ID4+Pj4gICAgICAob3IgcG90ZW50aWFsbHkgaW5jbHVk
ZWQpIGluIHRoZSBmaWx0ZXIgb3V0cHV0LCBhbmQgd2hpY2ggc2libGluZw0KPiA+Pj4+ICAgICAg
c3VidHJlZXMgYXJlIGV4Y2x1ZGVkIChwcnVuZWQpIGZyb20gdGhlIGZpbHRlciBvdXRwdXQuICBU
aGUgc2VydmVyDQo+ID4+Pj4gICAgICBmaXJzdCBkZXRlcm1pbmVzIHdoaWNoIHR5cGVzIG9mIG5v
ZGVzIGFyZSBwcmVzZW50IGluIHRoZSBzaWJsaW5nIHNldA0KPiA+Pj4+ICAgICAgYW5kIHByb2Nl
c3NlcyB0aGUgbm9kZXMgYWNjb3JkaW5nIHRvIHRoZSBydWxlcyBmb3IgdGhlaXIgdHlwZS4gIElm
DQo+ID4+Pj4gICAgICBhbnkgbm9kZXMgaW4gdGhlIHNpYmxpbmcgc2V0IGFyZSBzZWxlY3RlZCwg
dGhlbiB0aGUgcHJvY2VzcyBpcw0KPiA+Pj4+ICAgICAgcmVjdXJzaXZlbHkgYXBwbGllZCB0byB0
aGUgc2libGluZyBzZXRzIG9mIGVhY2ggc2VsZWN0ZWQgbm9kZS4gIFRoZQ0KPiA+Pj4+ICAgICAg
YWxnb3JpdGhtIGNvbnRpbnVlcyB1bnRpbCBhbGwgc2libGluZyBzZXRzIGluIGFsbCBzdWJ0cmVl
cyBzcGVjaWZpZWQNCj4gPj4+PiAgICAgIGluIHRoZSBmaWx0ZXIgaGF2ZSBiZWVuIHByb2Nlc3Nl
ZC4NCj4gPj4+Pg0KPiA+Pj4+IE5FVzoNCj4gPj4+PiAgICAgIEZvciBlYWNoIHNpYmxpbmcgc2V0
LCB0aGUgc2VydmVyIGRldGVybWluZXMgd2hpY2ggbm9kZXMgYXJlIGluY2x1ZGVkDQo+ID4+Pj4g
ICAgICAob3IgcG90ZW50aWFsbHkgaW5jbHVkZWQpIGluIHRoZSBmaWx0ZXIgb3V0cHV0LCBhbmQg
d2hpY2ggc2libGluZw0KPiA+Pj4+ICAgICAgc3VidHJlZXMgYXJlIGV4Y2x1ZGVkIChwcnVuZWQp
IGZyb20gdGhlIGZpbHRlciBvdXRwdXQuICBUaGUgc2VydmVyDQo+ID4+Pj4gICAgICBmaXJzdCBk
ZXRlcm1pbmVzIHdoaWNoIHR5cGVzIG9mIG5vZGVzIGFyZSBwcmVzZW50IGluIHRoZSBzaWJsaW5n
IHNldA0KPiA+Pj4+ICAgICAgYW5kIHByb2Nlc3NlcyB0aGUgbm9kZXMgYWNjb3JkaW5nIHRvIHRo
ZSBydWxlcyBmb3IgdGhlaXIgdHlwZS4gIElmDQo+ID4+Pj4gICAgICBhbnkgbm9kZXMgaW4gdGhl
IHNpYmxpbmcgc2V0IGFyZSBzZWxlY3RlZCwgdGhlbiB0aGUgcHJvY2VzcyBpcw0KPiA+Pj4+ICAg
ICAgcmVjdXJzaXZlbHkgYXBwbGllZCB0byB0aGUgc2libGluZyBzZXRzIG9mIGVhY2ggc2VsZWN0
ZWQgbm9kZS4gIFRoZQ0KPiA+Pj4+ICAgICAgYWxnb3JpdGhtIGNvbnRpbnVlcyB1bnRpbCBhbGwg
c2libGluZyBzZXRzIGluIGFsbCBzdWJ0cmVlcyBzcGVjaWZpZWQNCj4gPj4+PiAgICAgIGluIHRo
ZSBmaWx0ZXIgaGF2ZSBiZWVuIHByb2Nlc3NlZC4gSWYgYW55IHNpYmxpbmcgbm9kZXMgb2YgYSBu
b2RlDQo+ID4+Pj4gICAgICBhcmUgaW5zdGFuY2UgaWRlbnRpZmllciBjb21wb25lbnRzIGZvciBh
IGNvbmNlcHR1YWwgZGF0YSBzdHJ1Y3R1cmUNCj4gPj4+PiAgICAgIChlLmcuLCBsaXN0IGtleSBs
ZWFmKSwgdGhlbiB0aGV5IE1BWSBiZSBpbmNsdWRlZCBpbiB0aGUgZmlsdGVyIG91dHB1dC4NCj4g
Pj4+Pg0KPiA+Pj4+IFJhZ2FyZHMsDQo+ID4+Pj4gS2xlbWVudA0KPiA+Pj4+DQo+ID4+Pj4gT24g
VGh1LCAyMDE0LTA2LTE5IGF0IDExOjU5ICswMjAwLCBCZW5vaXQgQ2xhaXNlIHdyb3RlOg0KPiA+
Pj4+DQo+ID4+Pj4+IEtsZW1lbnQsDQo+ID4+Pj4+DQo+ID4+Pj4+IEFyZSB5b3UgZmluZSB3aXRo
IHRoaXMgcmVzb2x1dGlvbiBiZWxvdy4NCj4gPj4+Pj4gSWYgeWVzLCBwbGVhc2UgdXBkYXRlIHRo
ZSBlcnJhdGEuDQo+ID4+Pj4+IElmIHlvdSBkb24ndCBoYXZlIHRoZSByaWdodCB0byBkbywgSSBj
YW4gZG8uIEluIHRoaXMgY2FzZSwgcHJvdmlkZQ0KPiA+Pj4+PiBPTEQvTkVXIHRleHQuDQo+ID4+
Pj4+DQo+ID4+Pj4+IFJlZ2FyZHMsIEJlbm9pdA0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gT24gV2VkLCBK
dW4gMDQsIDIwMTQgYXQgMTI6Mzg6NTVQTSArMDIwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToN
Cj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxk
ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IE9u
IFdlZCwgSnVuIDA0LCAyMDE0IGF0IDEyOjI0OjIzUE0gKzAyMDAsIE1hcnRpbiBCam9ya2x1bmQg
d3JvdGU6DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGou
c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pg0K
PiA+Pj4+Pj4+Pj4+IEkgYW0gbm90IHN1cmUgc2luY2UgaW4gdGhlIG5ldyB0ZXh0ICdub2RlJyBp
cyByYXRoZXIgdW5zcGVjaWZpZWQuDQo+ID4+Pj4+Pj4+Pj4gICBGb3INCj4gPj4+Pj4+Pj4+PiBt
ZSwgaXQgd291bGQgaGVscCB0byBoYXZlIGEgZXhhbXBsZSBkZW1vbnN0cmF0aW5nIHdoYXQgaXMg
YnJva2VuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEFzc3VtZSB0aGlzIG1vZGVsOg0KPiA+
Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ICAgICAgY29udGFpbmVyIHNlcnZlcnMgew0KPiA+Pj4+Pj4+
Pj4gICAgICAgIGxpc3Qgc2VydmVyIHsNCj4gPj4+Pj4+Pj4+ICAgICAgICAgIGtleSBuYW1lOw0K
PiA+Pj4+Pj4+Pj4gICAgICAgICAgbGVhZiBuYW1lIHsgLi4uIH0NCj4gPj4+Pj4+Pj4+ICAgICAg
ICAgIGxlYWYgaXAgeyAuLi4gfQ0KPiA+Pj4+Pj4+Pj4gICAgICAgICAgbGVhZiBwb3J0IHsgLi4u
IH0NCj4gPj4+Pj4+Pj4+ICAgICAgICB9DQo+ID4+Pj4+Pj4+PiAgICAgIH0NCj4gPj4+Pj4+Pj4+
DQo+ID4+Pj4+Pj4+PiBhbmQgdGhpcyBkYXRhIG9uIHRoZSBzZXJ2ZXI6DQo+ID4+Pj4+Pj4+Pg0K
PiA+Pj4+Pj4+Pj4gICAgICA8c2VydmVycz4NCj4gPj4+Pj4+Pj4+ICAgICAgICA8c2VydmVyPg0K
PiA+Pj4+Pj4+Pj4gICAgICAgICAgPG5hbWU+Zm9vPC9uYW1lPg0KPiA+Pj4+Pj4+Pj4gICAgICAg
ICAgPGlwPjEwLjAuMC4xPC9pcD4NCj4gPj4+Pj4+Pj4+ICAgICAgICAgIDxwb3J0PjgwPC9wb3J0
Pg0KPiA+Pj4+Pj4+Pj4gICAgICAgIDwvc2VydmVyPg0KPiA+Pj4+Pj4+Pj4gICAgICAgIDxzZXJ2
ZXI+DQo+ID4+Pj4+Pj4+PiAgICAgICAgICA8bmFtZT5iYXI8L25hbWU+DQo+ID4+Pj4+Pj4+PiAg
ICAgICAgICA8aXA+MTAuMC4wLjE8L2lwPg0KPiA+Pj4+Pj4+Pj4gICAgICAgICAgPHBvcnQ+MjU8
L3BvcnQ+DQo+ID4+Pj4+Pj4+PiAgICAgICAgPC9zZXJ2ZXI+DQo+ID4+Pj4+Pj4+PiAgICAgIDwv
c2VydmVycz4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBOb3csIHdpdGggdGhpcyBmaWx0ZXI6
DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gICAgICA8c2VydmVycz4NCj4gPj4+Pj4+Pj4+ICAg
ICAgICA8c2VydmVyPg0KPiA+Pj4+Pj4+Pj4gICAgICAgICAgPHBvcnQ+ODA8L3BvcnQ+DQo+ID4+
Pj4+Pj4+PiAgICAgICAgICA8aXAvPg0KPiA+Pj4+Pj4+Pj4gICAgICAgIDwvc2VydmVyPg0KPiA+
Pj4+Pj4+Pj4gICAgICA8L3NlcnZlcj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBJdCBpcywg
YWNjb3JkaW5nIHRvIDYyNDEsIG9rIHRvIHJldHVybjoNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+
PiAgICAgIDxzZXJ2ZXJzPg0KPiA+Pj4+Pj4+Pj4gICAgICAgIDxzZXJ2ZXI+DQo+ID4+Pj4+Pj4+
PiAgICAgICAgICA8bmFtZT5mb288L25hbWU+DQo+ID4+Pj4+Pj4+PiAgICAgICAgICA8aXA+MTAu
MC4wLjE8L2lwPg0KPiA+Pj4+Pj4+Pj4gICAgICAgICAgPHBvcnQ+ODA8L3BvcnQ+DQo+ID4+Pj4+
Pj4+PiAgICAgICAgPC9zZXJ2ZXI+DQo+ID4+Pj4+Pj4+PiAgICAgIDwvc2VydmVycz4NCj4gPj4+
Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiAoYmVjYXVzZSAnbmFtZScgaXMgYSBzaWJsaW5nIHRvIHRoZSBz
ZWxlY3Rpb24gbm9kZSAnaXAnKQ0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+
PiBIb3dldmVyLCB3aXRoIHRoaXMgZmlsdGVyOg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ICAg
ICAgPHNlcnZlcnM+DQo+ID4+Pj4+Pj4+PiAgICAgICAgPHNlcnZlcj4NCj4gPj4+Pj4+Pj4+ICAg
ICAgICAgIDxwb3J0PjgwPC9wb3J0Pg0KPiA+Pj4+Pj4+Pj4gICAgICAgIDwvc2VydmVyPg0KPiA+
Pj4+Pj4+Pj4gICAgICA8L3NlcnZlcj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBhIHN0cmlj
dCBpbnRlcnByZXRhdGlvbiBvZiA2MjQxIHNlZW1zIHRvIHN1Z2dlc3QgdGhhdCB0aGlzIGlzIGls
bGVnYWwNCj4gPj4+Pj4+Pj4+IHRvIHJldHVybjoNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiAg
ICAgIDxzZXJ2ZXJzPg0KPiA+Pj4+Pj4+Pj4gICAgICAgIDxzZXJ2ZXI+DQo+ID4+Pj4+Pj4+PiAg
ICAgICAgICA8bmFtZT5mb288L25hbWU+DQo+ID4+Pj4+Pj4+PiAgICAgICAgICA8cG9ydD44MDwv
cG9ydD4NCj4gPj4+Pj4+Pj4+ICAgICAgICA8L3NlcnZlcj4NCj4gPj4+Pj4+Pj4+ICAgICAgPC9z
ZXJ2ZXJzPg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IC4uLiBidXQgdGhhdCBkb2Vzbid0IG1h
a2UgbXVjaCBzZW5zZS4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBUaGUgaW50ZW50aW9uIG9m
IHRoZSB0ZXh0IHdhcyB0byBhbGxvdyBrZXlzIHRvIGJlIGluc2VydGVkIGV2ZXJ5d2hlcmUNCj4g
Pj4+Pj4+Pj4+IGluIHRoZSByZXR1cm5lZCBzdWJ0cmVlcy4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+
Pj4+Pg0KPiA+Pj4+Pj4+Pj4gVGhpcyBzYWlkLCBJIGFtIG5vdCBjb252aW5jZWQgdGhlIHByb3Bv
c2VkIGNoYW5nZSBmaXhlcyB0aGlzLiAgVGhlDQo+ID4+Pj4+Pj4+PiBzdWJ0cmVlIGZpbHRlciBz
cGVjaWZpY2F0aW9uIHRleHQgaXMgcHJldHR5IGRpZmZpY3VsdCB0byBpbnRlcnByZXQuLi4NCj4g
Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiAgIFNvIGFueSBrZXkgbGVhZnMgdGhhdCBhcmUgY2hpbGQg
bm9kZXMgb2YgYW55IENvbnRhaW5tZW50IE5vZGVzIG9mDQo+ID4+Pj4+Pj4+IHRoZSBTdWJ0cmVl
IEZpbHRlciBjYW4gYmUgYWRkZWQ/IFdvdWxkIHRoYXQgYmUgbW9yZSBhY2N1cmF0ZT8NCj4gPj4+
Pj4+Pj4NCj4gPj4+Pj4+PiBJIHRoaW5rIHNvLCBidXQgdGhlIGN1cnJlbnQgdGV4dCBpcyBpbiBz
ZWN0aW9uIDYuMi41IHdoaWNoIHRhbGtzIGFib3V0DQo+ID4+Pj4+Pj4gY29udGVudCBtYXRjaCBu
b2Rlcy4gIFRoaXMgaXMgYSBiaXQgY29uZnVzaW5nIC0gd2hhdCBoYXBwZW5zIGlmIHlvdQ0KPiA+
Pj4+Pj4+IGRvbid0IGhhdmUgYW55IGNvbnRlbnQgbWF0Y2ggbm9kZXM/DQo+ID4+Pj4+Pj4NCj4g
Pj4+Pj4+PiBZb3VyIHNlbnRlbmNlIGJlbG9uZ3MgdG8gdGV4dCB0aGF0IGRpc2N1c3Mgc3VidHJl
ZSBmaWx0ZXIgaW4gZ2VuZXJhbCwNCj4gPj4+Pj4+PiBtYXliZSBzb21ld2hlcmUgaW4gc2VjdGlv
biA2LjMuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAgIFllcywgdGhhdCBtYWtlcyBzZW5zZSB0byBt
ZS4NCj4gPj4+Pj4+IC9qcw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+IA0KDQo=


From nobody Fri Jun 20 02:01:18 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9371A0351 for ; Fri, 20 Jun 2014 02:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 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=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlYGupHTP1ve for ; Fri, 20 Jun 2014 02:01:12 -0700 (PDT)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E0E1A035E for ; Fri, 20 Jun 2014 02:01:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7395; q=dns/txt; s=iport; t=1403254871; x=1404464471; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IXGsvUG71rTEZbm/0fcO6pnYcdFuvkSwIJaCz4wqXpY=; b=jQdylZvSwvzx4DCjGjR3ARZ7mlzv8hpuR8NpnFBUr8+NKhgcgQFIkP9l hCrCLAs/6/s2ez8TlRpIQezQTktLzBBDrKDunsmEcsiGO4pQG9iDkujNy 9/8FndYbxnXbr/0Q0MGjmx3Q+U45B/CoInJzgmNCUsm+KygAjVPeV6E9H A=;
X-IronPort-AV: E=Sophos;i="5.01,512,1400025600"; d="scan'208";a="41981573"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 20 Jun 2014 09:01:09 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5K916aX009472; Fri, 20 Jun 2014 09:01:06 GMT
Message-ID: <53A3F851.3090208@cisco.com>
Date: Fri, 20 Jun 2014 11:01:05 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
References: <20140604095438.GB7993@elstar.local>		 <20140604.122423.1320188282940387836.mbj@tail-f.com>		 <20140604103109.GA8220@elstar.local>		 <20140604.123855.1971075702450619730.mbj@tail-f.com>		 <20140604121154.GA8481@elstar.local> <53A2B46D.5090608@cisco.com>		 <1403181474.24901.6.camel@ksekera-fedora> <53A2E05B.9070001@cisco.com>		 	 <1403249534.21565.5.camel@ksekera-fedora> <53A3EB8A.3070101@cisco.com> <1403254477.11410.1.camel@ksekera-fedora>
In-Reply-To: <1403254477.11410.1.camel@ksekera-fedora>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4BdfEyqzHGeQUc3x6KltlDL_DLI
Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" 
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 09:01:16 -0000

One last check (till mid next week) for everybody in the WG before I 
apply this change below to the errata, and accept it.

Regards, Benoit

> SHOULD instead of MAY is fine.
>
> On Fri, 2014-06-20 at 10:06 +0200, Benoit Claise wrote:
>> Klement,
>>
>> Based on your reasoning, SHOULD is appropriate.
>>   From RFC 2119:
>>
>>      3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>>          may exist valid reasons in particular circumstances to ignore a
>>          particular item, but the full implications must be understood and
>>          carefully weighed before choosing a different course.
>>
>> Regards, Benoit
>>> Adding keys allows the client to identify separate list entities. The
>>> client should be bright enough to request the keys, but if he does not,
>>> a server implementation which is smart enough could supply them
>>> automatically - since without them, most replys would probably be
>>> unusable. But I can imagine a limited environment, where cpu/memory is
>>> scarce and the netconf server could be as simple as possible. Therefore,
>>> I proposed MAY instead of MUST.
>>>
>>> On Thu, 2014-06-19 at 07:55 -0700, Andy Bierman wrote:
>>>> On Thu, Jun 19, 2014 at 6:06 AM, Benoit Claise  wrote:
>>>>
>>>>> Martin, Jürgen, WG,
>>>>>
>>>>> Fine with this?
>>>>>
>>>> Not really.
>>>> Why is the requirement to add key leafs a MAY instead of a MUST or SHOULD?
>>>> It seems like subtree filters need to be implemented in a consistent manner
>>>> to make them really useful.
>>>>
>>>>
>>>> Andy
>>>>
>>>>
>>>>> Regards, B.
>>>>>
>>>>>> Hi Benoit,
>>>>>>
>>>>>> I don't think I can.
>>>>>>
>>>>>> If this should be put into section 6.3, then I'd add to this block of
>>>>>> text:
>>>>>>
>>>>>> OLD:
>>>>>>       For each sibling set, the server determines which nodes are included
>>>>>>       (or potentially included) in the filter output, and which sibling
>>>>>>       subtrees are excluded (pruned) from the filter output.  The server
>>>>>>       first determines which types of nodes are present in the sibling set
>>>>>>       and processes the nodes according to the rules for their type.  If
>>>>>>       any nodes in the sibling set are selected, then the process is
>>>>>>       recursively applied to the sibling sets of each selected node.  The
>>>>>>       algorithm continues until all sibling sets in all subtrees specified
>>>>>>       in the filter have been processed.
>>>>>>
>>>>>> NEW:
>>>>>>       For each sibling set, the server determines which nodes are included
>>>>>>       (or potentially included) in the filter output, and which sibling
>>>>>>       subtrees are excluded (pruned) from the filter output.  The server
>>>>>>       first determines which types of nodes are present in the sibling set
>>>>>>       and processes the nodes according to the rules for their type.  If
>>>>>>       any nodes in the sibling set are selected, then the process is
>>>>>>       recursively applied to the sibling sets of each selected node.  The
>>>>>>       algorithm continues until all sibling sets in all subtrees specified
>>>>>>       in the filter have been processed. If any sibling nodes of a node
>>>>>>       are instance identifier components for a conceptual data structure
>>>>>>       (e.g., list key leaf), then they MAY be included in the filter output.
>>>>>>
>>>>>> Ragards,
>>>>>> Klement
>>>>>>
>>>>>> On Thu, 2014-06-19 at 11:59 +0200, Benoit Claise wrote:
>>>>>>
>>>>>>> Klement,
>>>>>>>
>>>>>>> Are you fine with this resolution below.
>>>>>>> If yes, please update the errata.
>>>>>>> If you don't have the right to do, I can do. In this case, provide
>>>>>>> OLD/NEW text.
>>>>>>>
>>>>>>> Regards, Benoit
>>>>>>>
>>>>>>>> On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund wrote:
>>>>>>>>
>>>>>>>>> Juergen Schoenwaelder  wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund wrote:
>>>>>>>>>>
>>>>>>>>>>> Juergen Schoenwaelder  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I am not sure since in the new text 'node' is rather unspecified.
>>>>>>>>>>>>    For
>>>>>>>>>>>> me, it would help to have a example demonstrating what is broken
>>>>>>>>>>>>
>>>>>>>>>>> Assume this model:
>>>>>>>>>>>
>>>>>>>>>>>       container servers {
>>>>>>>>>>>         list server {
>>>>>>>>>>>           key name;
>>>>>>>>>>>           leaf name { ... }
>>>>>>>>>>>           leaf ip { ... }
>>>>>>>>>>>           leaf port { ... }
>>>>>>>>>>>         }
>>>>>>>>>>>       }
>>>>>>>>>>>
>>>>>>>>>>> and this data on the server:
>>>>>>>>>>>
>>>>>>>>>>>       
>>>>>>>>>>>         
>>>>>>>>>>>           foo
>>>>>>>>>>>           10.0.0.1
>>>>>>>>>>>           80
>>>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>           bar
>>>>>>>>>>>           10.0.0.1
>>>>>>>>>>>           25
>>>>>>>>>>>         
>>>>>>>>>>>       
>>>>>>>>>>>
>>>>>>>>>>> Now, with this filter:
>>>>>>>>>>>
>>>>>>>>>>>       
>>>>>>>>>>>         
>>>>>>>>>>>           80
>>>>>>>>>>>           
>>>>>>>>>>>         
>>>>>>>>>>>       
>>>>>>>>>>>
>>>>>>>>>>> It is, according to 6241, ok to return:
>>>>>>>>>>>
>>>>>>>>>>>       
>>>>>>>>>>>         
>>>>>>>>>>>           foo
>>>>>>>>>>>           10.0.0.1
>>>>>>>>>>>           80
>>>>>>>>>>>         
>>>>>>>>>>>       
>>>>>>>>>>>
>>>>>>>>>>> (because 'name' is a sibling to the selection node 'ip')
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> However, with this filter:
>>>>>>>>>>>
>>>>>>>>>>>       
>>>>>>>>>>>         
>>>>>>>>>>>           80
>>>>>>>>>>>         
>>>>>>>>>>>       
>>>>>>>>>>>
>>>>>>>>>>> a strict interpretation of 6241 seems to suggest that this is illegal
>>>>>>>>>>> to return:
>>>>>>>>>>>
>>>>>>>>>>>       
>>>>>>>>>>>         
>>>>>>>>>>>           foo
>>>>>>>>>>>           80
>>>>>>>>>>>         
>>>>>>>>>>>       
>>>>>>>>>>>
>>>>>>>>>>> ... but that doesn't make much sense.
>>>>>>>>>>>
>>>>>>>>>>> The intention of the text was to allow keys to be inserted everywhere
>>>>>>>>>>> in the returned subtrees.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This said, I am not convinced the proposed change fixes this.  The
>>>>>>>>>>> subtree filter specification text is pretty difficult to interpret...
>>>>>>>>>>>
>>>>>>>>>>>    So any key leafs that are child nodes of any Containment Nodes of
>>>>>>>>>> the Subtree Filter can be added? Would that be more accurate?
>>>>>>>>>>
>>>>>>>>> I think so, but the current text is in section 6.2.5 which talks about
>>>>>>>>> content match nodes.  This is a bit confusing - what happens if you
>>>>>>>>> don't have any content match nodes?
>>>>>>>>>
>>>>>>>>> Your sentence belongs to text that discuss subtree filter in general,
>>>>>>>>> maybe somewhere in section 6.3.
>>>>>>>>>
>>>>>>>>>    Yes, that makes sense to me.
>>>>>>>> /js
>>>>>>>>
>>>>>>>>


From nobody Fri Jun 20 07:09:24 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F911B27D5 for ; Fri, 20 Jun 2014 07:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.252
X-Spam-Level: 
X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz5M4MaQpMkt for ; Fri, 20 Jun 2014 07:09:18 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 877831B27E0 for ; Fri, 20 Jun 2014 07:09:17 -0700 (PDT)
Received: from [192.168.1.110] (unknown [63.142.209.177]) by mail.tail-f.com (Postfix) with ESMTPSA id E105312808F4; Fri, 20 Jun 2014 16:07:03 +0200 (CEST)
User-Agent: K-9 Mail for Android
In-Reply-To: <53A3F851.3090208@cisco.com>
References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> <20140604121154.GA8481@elstar.local> <53A2B46D.5090608@cisco.com> <1403181474.24901.6.camel@ksekera-fedora> <53A2E05B.9070001@cisco.com>  <1403249534.21565.5.camel@ksekera-fedora> <53A3EB8A.3070101@cisco.com> <1403254477.11410.1.camel@ksekera-fedora> <53A3F851.3090208@cisco.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: =?ISO-8859-1?Q?Martin_Bj=F6rklund?= 
Date: Fri, 20 Jun 2014 07:09:03 -0700
To: Benoit Claise , "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
Message-ID: <9c1a4cd6-5f96-495e-a332-badfa2406461@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qURUKIqteceHT5x6tT68xx1RPqs
Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" 
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 14:09:21 -0000

I don't think SHOULD is appropriate. The existing text uses MAY, and the errata is supposed to clarify in which situations the server is allowed to add keys. The errata is not about changing a MAY to SHOULD. 

On 20 juni 2014 02:01:05 PDT, Benoit Claise  wrote:
>One last check (till mid next week) for everybody in the WG before I 
>apply this change below to the errata, and accept it.
>
>Regards, Benoit
>
>> SHOULD instead of MAY is fine.
>>
>> On Fri, 2014-06-20 at 10:06 +0200, Benoit Claise wrote:
>>> Klement,
>>>
>>> Based on your reasoning, SHOULD is appropriate.
>>>   From RFC 2119:
>>>
>>>      3. SHOULD   This word, or the adjective "RECOMMENDED", mean
>that there
>>>          may exist valid reasons in particular circumstances to
>ignore a
>>>          particular item, but the full implications must be
>understood and
>>>          carefully weighed before choosing a different course.
>>>
>>> Regards, Benoit
>>>> Adding keys allows the client to identify separate list entities.
>The
>>>> client should be bright enough to request the keys, but if he does
>not,
>>>> a server implementation which is smart enough could supply them
>>>> automatically - since without them, most replys would probably be
>>>> unusable. But I can imagine a limited environment, where cpu/memory
>is
>>>> scarce and the netconf server could be as simple as possible.
>Therefore,
>>>> I proposed MAY instead of MUST.
>>>>
>>>> On Thu, 2014-06-19 at 07:55 -0700, Andy Bierman wrote:
>>>>> On Thu, Jun 19, 2014 at 6:06 AM, Benoit Claise 
>wrote:
>>>>>
>>>>>> Martin, Jürgen, WG,
>>>>>>
>>>>>> Fine with this?
>>>>>>
>>>>> Not really.
>>>>> Why is the requirement to add key leafs a MAY instead of a MUST or
>SHOULD?
>>>>> It seems like subtree filters need to be implemented in a
>consistent manner
>>>>> to make them really useful.
>>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>> Regards, B.
>>>>>>
>>>>>>> Hi Benoit,
>>>>>>>
>>>>>>> I don't think I can.
>>>>>>>
>>>>>>> If this should be put into section 6.3, then I'd add to this
>block of
>>>>>>> text:
>>>>>>>
>>>>>>> OLD:
>>>>>>>       For each sibling set, the server determines which nodes
>are included
>>>>>>>       (or potentially included) in the filter output, and which
>sibling
>>>>>>>       subtrees are excluded (pruned) from the filter output. 
>The server
>>>>>>>       first determines which types of nodes are present in the
>sibling set
>>>>>>>       and processes the nodes according to the rules for their
>type.  If
>>>>>>>       any nodes in the sibling set are selected, then the
>process is
>>>>>>>       recursively applied to the sibling sets of each selected
>node.  The
>>>>>>>       algorithm continues until all sibling sets in all subtrees
>specified
>>>>>>>       in the filter have been processed.
>>>>>>>
>>>>>>> NEW:
>>>>>>>       For each sibling set, the server determines which nodes
>are included
>>>>>>>       (or potentially included) in the filter output, and which
>sibling
>>>>>>>       subtrees are excluded (pruned) from the filter output. 
>The server
>>>>>>>       first determines which types of nodes are present in the
>sibling set
>>>>>>>       and processes the nodes according to the rules for their
>type.  If
>>>>>>>       any nodes in the sibling set are selected, then the
>process is
>>>>>>>       recursively applied to the sibling sets of each selected
>node.  The
>>>>>>>       algorithm continues until all sibling sets in all subtrees
>specified
>>>>>>>       in the filter have been processed. If any sibling nodes of
>a node
>>>>>>>       are instance identifier components for a conceptual data
>structure
>>>>>>>       (e.g., list key leaf), then they MAY be included in the
>filter output.
>>>>>>>
>>>>>>> Ragards,
>>>>>>> Klement
>>>>>>>
>>>>>>> On Thu, 2014-06-19 at 11:59 +0200, Benoit Claise wrote:
>>>>>>>
>>>>>>>> Klement,
>>>>>>>>
>>>>>>>> Are you fine with this resolution below.
>>>>>>>> If yes, please update the errata.
>>>>>>>> If you don't have the right to do, I can do. In this case,
>provide
>>>>>>>> OLD/NEW text.
>>>>>>>>
>>>>>>>> Regards, Benoit
>>>>>>>>
>>>>>>>>> On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund
>wrote:
>>>>>>>>>
>>>>>>>>>> Juergen Schoenwaelder 
>wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund
>wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Juergen Schoenwaelder
> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I am not sure since in the new text 'node' is rather
>unspecified.
>>>>>>>>>>>>>    For
>>>>>>>>>>>>> me, it would help to have a example demonstrating what is
>broken
>>>>>>>>>>>>>
>>>>>>>>>>>> Assume this model:
>>>>>>>>>>>>
>>>>>>>>>>>>       container servers {
>>>>>>>>>>>>         list server {
>>>>>>>>>>>>           key name;
>>>>>>>>>>>>           leaf name { ... }
>>>>>>>>>>>>           leaf ip { ... }
>>>>>>>>>>>>           leaf port { ... }
>>>>>>>>>>>>         }
>>>>>>>>>>>>       }
>>>>>>>>>>>>
>>>>>>>>>>>> and this data on the server:
>>>>>>>>>>>>
>>>>>>>>>>>>       
>>>>>>>>>>>>         
>>>>>>>>>>>>           foo
>>>>>>>>>>>>           10.0.0.1
>>>>>>>>>>>>           80
>>>>>>>>>>>>         
>>>>>>>>>>>>         
>>>>>>>>>>>>           bar
>>>>>>>>>>>>           10.0.0.1
>>>>>>>>>>>>           25
>>>>>>>>>>>>         
>>>>>>>>>>>>       
>>>>>>>>>>>>
>>>>>>>>>>>> Now, with this filter:
>>>>>>>>>>>>
>>>>>>>>>>>>       
>>>>>>>>>>>>         
>>>>>>>>>>>>           80
>>>>>>>>>>>>           
>>>>>>>>>>>>         
>>>>>>>>>>>>       
>>>>>>>>>>>>
>>>>>>>>>>>> It is, according to 6241, ok to return:
>>>>>>>>>>>>
>>>>>>>>>>>>       
>>>>>>>>>>>>         
>>>>>>>>>>>>           foo
>>>>>>>>>>>>           10.0.0.1
>>>>>>>>>>>>           80
>>>>>>>>>>>>         
>>>>>>>>>>>>       
>>>>>>>>>>>>
>>>>>>>>>>>> (because 'name' is a sibling to the selection node 'ip')
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> However, with this filter:
>>>>>>>>>>>>
>>>>>>>>>>>>       
>>>>>>>>>>>>         
>>>>>>>>>>>>           80
>>>>>>>>>>>>         
>>>>>>>>>>>>       
>>>>>>>>>>>>
>>>>>>>>>>>> a strict interpretation of 6241 seems to suggest that this
>is illegal
>>>>>>>>>>>> to return:
>>>>>>>>>>>>
>>>>>>>>>>>>       
>>>>>>>>>>>>         
>>>>>>>>>>>>           foo
>>>>>>>>>>>>           80
>>>>>>>>>>>>         
>>>>>>>>>>>>       
>>>>>>>>>>>>
>>>>>>>>>>>> ... but that doesn't make much sense.
>>>>>>>>>>>>
>>>>>>>>>>>> The intention of the text was to allow keys to be inserted
>everywhere
>>>>>>>>>>>> in the returned subtrees.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This said, I am not convinced the proposed change fixes
>this.  The
>>>>>>>>>>>> subtree filter specification text is pretty difficult to
>interpret...
>>>>>>>>>>>>
>>>>>>>>>>>>    So any key leafs that are child nodes of any Containment
>Nodes of
>>>>>>>>>>> the Subtree Filter can be added? Would that be more
>accurate?
>>>>>>>>>>>
>>>>>>>>>> I think so, but the current text is in section 6.2.5 which
>talks about
>>>>>>>>>> content match nodes.  This is a bit confusing - what happens
>if you
>>>>>>>>>> don't have any content match nodes?
>>>>>>>>>>
>>>>>>>>>> Your sentence belongs to text that discuss subtree filter in
>general,
>>>>>>>>>> maybe somewhere in section 6.3.
>>>>>>>>>>
>>>>>>>>>>    Yes, that makes sense to me.
>>>>>>>>> /js
>>>>>>>>>
>>>>>>>>>


/martin


From nobody Fri Jun 20 07:58:42 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F64B1B2819 for ; Fri, 20 Jun 2014 07:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.852
X-Spam-Level: 
X-Spam-Status: No, score=-9.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRzN0aWR7rBR for ; Fri, 20 Jun 2014 07:58:39 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9CD1B2802 for ; Fri, 20 Jun 2014 07:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8276; q=dns/txt; s=iport; t=1403276320; x=1404485920; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pxWHEgcBERjITqOzLcRL4lnDiohEoPqwfZSL1f0fgHQ=; b=ZQlGYctztmMtpUkMu87csIG7WH3uPmNz8KDkezcmZvVqHDTPVjWtWfUn X5TpfvcSBW6WFZsB2XhWHjB2wl0f7VlHYtCvje+b91lUBavPI0zXiTyXo y2FEpp8YFmppHx5WRlG0xIW0oRm1pxtPIwb1+3pGDlVRlAQA0hxJ69iox c=;
X-IronPort-AV: E=Sophos;i="5.01,514,1400025600"; d="scan'208";a="92044825"
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; 20 Jun 2014 14:58:38 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5KEwbh4023589; Fri, 20 Jun 2014 14:58:37 GMT
Message-ID: <53A44C1D.6040902@cisco.com>
Date: Fri, 20 Jun 2014 16:58:37 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= , "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
References: <20140604095438.GB7993@elstar.local> <20140604.122423.1320188282940387836.mbj@tail-f.com> <20140604103109.GA8220@elstar.local> <20140604.123855.1971075702450619730.mbj@tail-f.com> <20140604121154.GA8481@elstar.local> <53A2B46D.5090608@cisco.com> <1403181474.24901.6.camel@ksekera-fedora> <53A2E05B.9070001@cisco.com>  <1403249534.21565.5.camel@ksekera-fedora> <53A3EB8A.3070101@cisco.com> <1403254477.11410.1.camel@ksekera-fedora> <53A3F851.3090208@cisco.com> <9c1a4cd6-5f96-495e-a332-badfa2406461@email.android.com>
In-Reply-To: <9c1a4cd6-5f96-495e-a332-badfa2406461@email.android.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yqTraPSljI54LgvioxE9zazVtNM
Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" 
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 14:58:41 -0000

Can you please provide some text.

Regards, B.
> I don't think SHOULD is appropriate. The existing text uses MAY, and the errata is supposed to clarify in which situations the server is allowed to add keys. The errata is not about changing a MAY to SHOULD.
>
> On 20 juni 2014 02:01:05 PDT, Benoit Claise  wrote:
>> One last check (till mid next week) for everybody in the WG before I
>> apply this change below to the errata, and accept it.
>>
>> Regards, Benoit
>>
>>> SHOULD instead of MAY is fine.
>>>
>>> On Fri, 2014-06-20 at 10:06 +0200, Benoit Claise wrote:
>>>> Klement,
>>>>
>>>> Based on your reasoning, SHOULD is appropriate.
>>>>    From RFC 2119:
>>>>
>>>>       3. SHOULD   This word, or the adjective "RECOMMENDED", mean
>> that there
>>>>           may exist valid reasons in particular circumstances to
>> ignore a
>>>>           particular item, but the full implications must be
>> understood and
>>>>           carefully weighed before choosing a different course.
>>>>
>>>> Regards, Benoit
>>>>> Adding keys allows the client to identify separate list entities.
>> The
>>>>> client should be bright enough to request the keys, but if he does
>> not,
>>>>> a server implementation which is smart enough could supply them
>>>>> automatically - since without them, most replys would probably be
>>>>> unusable. But I can imagine a limited environment, where cpu/memory
>> is
>>>>> scarce and the netconf server could be as simple as possible.
>> Therefore,
>>>>> I proposed MAY instead of MUST.
>>>>>
>>>>> On Thu, 2014-06-19 at 07:55 -0700, Andy Bierman wrote:
>>>>>> On Thu, Jun 19, 2014 at 6:06 AM, Benoit Claise 
>> wrote:
>>>>>>> Martin, Jürgen, WG,
>>>>>>>
>>>>>>> Fine with this?
>>>>>>>
>>>>>> Not really.
>>>>>> Why is the requirement to add key leafs a MAY instead of a MUST or
>> SHOULD?
>>>>>> It seems like subtree filters need to be implemented in a
>> consistent manner
>>>>>> to make them really useful.
>>>>>>
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>> Regards, B.
>>>>>>>
>>>>>>>> Hi Benoit,
>>>>>>>>
>>>>>>>> I don't think I can.
>>>>>>>>
>>>>>>>> If this should be put into section 6.3, then I'd add to this
>> block of
>>>>>>>> text:
>>>>>>>>
>>>>>>>> OLD:
>>>>>>>>        For each sibling set, the server determines which nodes
>> are included
>>>>>>>>        (or potentially included) in the filter output, and which
>> sibling
>>>>>>>>        subtrees are excluded (pruned) from the filter output.
>> The server
>>>>>>>>        first determines which types of nodes are present in the
>> sibling set
>>>>>>>>        and processes the nodes according to the rules for their
>> type.  If
>>>>>>>>        any nodes in the sibling set are selected, then the
>> process is
>>>>>>>>        recursively applied to the sibling sets of each selected
>> node.  The
>>>>>>>>        algorithm continues until all sibling sets in all subtrees
>> specified
>>>>>>>>        in the filter have been processed.
>>>>>>>>
>>>>>>>> NEW:
>>>>>>>>        For each sibling set, the server determines which nodes
>> are included
>>>>>>>>        (or potentially included) in the filter output, and which
>> sibling
>>>>>>>>        subtrees are excluded (pruned) from the filter output.
>> The server
>>>>>>>>        first determines which types of nodes are present in the
>> sibling set
>>>>>>>>        and processes the nodes according to the rules for their
>> type.  If
>>>>>>>>        any nodes in the sibling set are selected, then the
>> process is
>>>>>>>>        recursively applied to the sibling sets of each selected
>> node.  The
>>>>>>>>        algorithm continues until all sibling sets in all subtrees
>> specified
>>>>>>>>        in the filter have been processed. If any sibling nodes of
>> a node
>>>>>>>>        are instance identifier components for a conceptual data
>> structure
>>>>>>>>        (e.g., list key leaf), then they MAY be included in the
>> filter output.
>>>>>>>> Ragards,
>>>>>>>> Klement
>>>>>>>>
>>>>>>>> On Thu, 2014-06-19 at 11:59 +0200, Benoit Claise wrote:
>>>>>>>>
>>>>>>>>> Klement,
>>>>>>>>>
>>>>>>>>> Are you fine with this resolution below.
>>>>>>>>> If yes, please update the errata.
>>>>>>>>> If you don't have the right to do, I can do. In this case,
>> provide
>>>>>>>>> OLD/NEW text.
>>>>>>>>>
>>>>>>>>> Regards, Benoit
>>>>>>>>>
>>>>>>>>>> On Wed, Jun 04, 2014 at 12:38:55PM +0200, Martin Bjorklund
>> wrote:
>>>>>>>>>>> Juergen Schoenwaelder 
>> wrote:
>>>>>>>>>>>> On Wed, Jun 04, 2014 at 12:24:23PM +0200, Martin Bjorklund
>> wrote:
>>>>>>>>>>>>> Juergen Schoenwaelder
>>  wrote:
>>>>>>>>>>>>>> I am not sure since in the new text 'node' is rather
>> unspecified.
>>>>>>>>>>>>>>     For
>>>>>>>>>>>>>> me, it would help to have a example demonstrating what is
>> broken
>>>>>>>>>>>>> Assume this model:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        container servers {
>>>>>>>>>>>>>          list server {
>>>>>>>>>>>>>            key name;
>>>>>>>>>>>>>            leaf name { ... }
>>>>>>>>>>>>>            leaf ip { ... }
>>>>>>>>>>>>>            leaf port { ... }
>>>>>>>>>>>>>          }
>>>>>>>>>>>>>        }
>>>>>>>>>>>>>
>>>>>>>>>>>>> and this data on the server:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        
>>>>>>>>>>>>>          
>>>>>>>>>>>>>            foo
>>>>>>>>>>>>>            10.0.0.1
>>>>>>>>>>>>>            80
>>>>>>>>>>>>>          
>>>>>>>>>>>>>          
>>>>>>>>>>>>>            bar
>>>>>>>>>>>>>            10.0.0.1
>>>>>>>>>>>>>            25
>>>>>>>>>>>>>          
>>>>>>>>>>>>>        
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now, with this filter:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        
>>>>>>>>>>>>>          
>>>>>>>>>>>>>            80
>>>>>>>>>>>>>            
>>>>>>>>>>>>>          
>>>>>>>>>>>>>        
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is, according to 6241, ok to return:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        
>>>>>>>>>>>>>          
>>>>>>>>>>>>>            foo
>>>>>>>>>>>>>            10.0.0.1
>>>>>>>>>>>>>            80
>>>>>>>>>>>>>          
>>>>>>>>>>>>>        
>>>>>>>>>>>>>
>>>>>>>>>>>>> (because 'name' is a sibling to the selection node 'ip')
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, with this filter:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        
>>>>>>>>>>>>>          
>>>>>>>>>>>>>            80
>>>>>>>>>>>>>          
>>>>>>>>>>>>>        
>>>>>>>>>>>>>
>>>>>>>>>>>>> a strict interpretation of 6241 seems to suggest that this
>> is illegal
>>>>>>>>>>>>> to return:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        
>>>>>>>>>>>>>          
>>>>>>>>>>>>>            foo
>>>>>>>>>>>>>            80
>>>>>>>>>>>>>          
>>>>>>>>>>>>>        
>>>>>>>>>>>>>
>>>>>>>>>>>>> ... but that doesn't make much sense.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The intention of the text was to allow keys to be inserted
>> everywhere
>>>>>>>>>>>>> in the returned subtrees.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This said, I am not convinced the proposed change fixes
>> this.  The
>>>>>>>>>>>>> subtree filter specification text is pretty difficult to
>> interpret...
>>>>>>>>>>>>>     So any key leafs that are child nodes of any Containment
>> Nodes of
>>>>>>>>>>>> the Subtree Filter can be added? Would that be more
>> accurate?
>>>>>>>>>>> I think so, but the current text is in section 6.2.5 which
>> talks about
>>>>>>>>>>> content match nodes.  This is a bit confusing - what happens
>> if you
>>>>>>>>>>> don't have any content match nodes?
>>>>>>>>>>>
>>>>>>>>>>> Your sentence belongs to text that discuss subtree filter in
>> general,
>>>>>>>>>>> maybe somewhere in section 6.3.
>>>>>>>>>>>
>>>>>>>>>>>     Yes, that makes sense to me.
>>>>>>>>>> /js
>>>>>>>>>>
>>>>>>>>>>
>
> /martin
> .
>


From nobody Fri Jun 20 13:57:41 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F711B28ED for ; Fri, 20 Jun 2014 13:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMcj0ZX_df7S for ; Fri, 20 Jun 2014 13:57:37 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 813F31B28E8 for ; Fri, 20 Jun 2014 13:57:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hfQ+6qWHIjrO7I/xDDnliC69+ALHH/wjevecR2DFHc+Tiow8M6LV4racO72wE2by; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Wy5sD-0003J7-2I; Fri, 20 Jun 2014 16:57:25 -0400
Received: from 99.101.140.47 by webmail.earthlink.net with HTTP; Fri, 20 Jun 2014 16:57:24 -0400
Message-ID: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
Date: Fri, 20 Jun 2014 13:57:24 -0700 (GMT-07:00)
From: Randy Presuhn 
To: Benoit Claise ,  "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd817729ab6d7b2326d22650b40a727d483e350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.27
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6vUZ2qvcFe4zYNV6CIa6SP7GBuA
Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" 
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 20:57:39 -0000

Hi -

>From: Benoit Claise 
>Sent: Jun 20, 2014 2:01 AM
...
>Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
>
>One last check (till mid next week) for everybody in the WG before I 
>apply this change below to the errata, and accept it.

"SHOULD" is no better than "MAY" or "OPTIONAL" from an
interoperability perspective.  "MUST" would be much simpler
for all concerned.

Randy


From nobody Fri Jun 20 18:40:31 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD0F1A02A9 for ; Fri, 20 Jun 2014 18:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.252
X-Spam-Level: 
X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca3Zg9pbK2IJ for ; Fri, 20 Jun 2014 18:40:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 72B821A02F4 for ; Fri, 20 Jun 2014 18:40:28 -0700 (PDT)
Received: from [172.22.3.41] (unknown [12.216.224.110]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C1C51280D36; Sat, 21 Jun 2014 03:38:09 +0200 (CEST)
User-Agent: K-9 Mail for Android
In-Reply-To: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: =?ISO-8859-1?Q?Martin_Bj=F6rklund?= 
Date: Fri, 20 Jun 2014 18:38:42 -0700
To: Randy Presuhn , Randy Presuhn , Benoit Claise , "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
Message-ID: 
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/AEsShuxOpETHPMeni00KI22ZplQ
Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" 
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jun 2014 01:40:30 -0000

I agree that MUST would be better. But I don't think we can/should do thar change in an errata. 

On 20 juni 2014 13:57:24 PDT, Randy Presuhn  wrote:
>Hi -
>
>>From: Benoit Claise 
>>Sent: Jun 20, 2014 2:01 AM
>...
>>Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
>>
>>One last check (till mid next week) for everybody in the WG before I 
>>apply this change below to the errata, and accept it.
>
>"SHOULD" is no better than "MAY" or "OPTIONAL" from an
>interoperability perspective.  "MUST" would be much simpler
>for all concerned.
>
>Randy
>
>_______________________________________________
>Netconf mailing list
>Netconf@ietf.org
>https://www.ietf.org/mailman/listinfo/netconf


/martin


From nobody Tue Jun 24 13:24:20 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555E51B282C for ; Tue, 24 Jun 2014 13:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XColYL0cR2F8 for ; Tue, 24 Jun 2014 13:24:09 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2AE1B2803 for ; Tue, 24 Jun 2014 13:24:04 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s5OKO2ZF020297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Jun 2014 20:24:02 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s5OKO22G009278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Jun 2014 22:24:02 +0200
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 24 Jun 2014 22:24:01 +0200
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.136]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0181.006; Tue, 24 Jun 2014 22:24:02 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" 
To: netconf 
Thread-Topic: netconf - Requested session has been scheduled for IETF 90
Thread-Index: AQHPjxFdu03ROAn7GEOVzOH9Ij3toJuAtj9g
Date: Tue, 24 Jun 2014 20:24:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.110]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1972
X-purgate-ID: 151667::1403641442-00007A71-C6CD9875/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/shAjge0GxxWHJLxbwU5IO7CwyeY
Subject: [Netconf] FW: netconf - Requested session has been scheduled for IETF 90
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 20:24:16 -0000

RllJDQoNCk1laG1ldCANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogIklF
VEYgU2VjcmV0YXJpYXQiIFttYWlsdG86YWdlbmRhQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwg
SnVuZSAyMywgMjAxNCA4OjMxIFBNDQpUbzogRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNo
KQ0KQ2M6IG5ldGNvbmYtYWRzQHRvb2xzLmlldGYub3JnOyBiZXJ0aWV0ZkBid2lqbmVuLm5ldDsg
RXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KU3ViamVjdDogbmV0Y29uZiAtIFJlcXVl
c3RlZCBzZXNzaW9uIGhhcyBiZWVuIHNjaGVkdWxlZCBmb3IgSUVURiA5MA0KDQpEZWFyIE1laG1l
dCBFcnN1ZSwNCg0KVGhlIHNlc3Npb24ocykgdGhhdCB5b3UgaGF2ZSByZXF1ZXN0ZWQgaGF2ZSBi
ZWVuIHNjaGVkdWxlZC4NCkJlbG93IGlzIHRoZSBzY2hlZHVsZWQgc2Vzc2lvbiBpbmZvcm1hdGlv
biBmb2xsb3dlZCBieQ0KdGhlIG9yaWdpbmFsIHJlcXVlc3QuIA0KDQpuZXRjb25mIFNlc3Npb24g
MSAoMjowMDowMCkNCiAgICBUdWVzZGF5LCBBZnRlcm5vb24gU2Vzc2lvbiBJSUkgMTY0MC0xODQw
DQogICAgUm9vbSBOYW1lOiBTYWxvbiBCIHNpemU6IDEyMA0KICAgIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KDQoNClJlcXVlc3QgSW5mb3JtYXRp
b246DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQpXb3JraW5nIEdyb3VwIE5hbWU6IE5ldHdvcmsgQ29uZmlndXJhdGlvbg0KQXJl
YSBOYW1lOiBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWENClNlc3Npb24gUmVxdWVzdGVy
OiBNZWhtZXQgRXJzdWUNCg0KTnVtYmVyIG9mIFNlc3Npb25zOiAxDQpMZW5ndGggb2YgU2Vzc2lv
bihzKTogIDIgSG91cnMNCk51bWJlciBvZiBBdHRlbmRlZXM6IDUwDQpDb25mbGljdHMgdG8gQXZv
aWQ6IA0KIEZpcnN0IFByaW9yaXR5OiBuZXRtb2Qgb3BzYXJlYSBvcHNhd2cNCiBTZWNvbmQgUHJp
b3JpdHk6IGRpbWUgcmFkZXh0IGlwZml4IGVtYW4gbG1hcCBubXJnIGkycnMgc2ZjDQogVGhpcmQg
UHJpb3JpdHk6IHY2b3BzIGludGFyZWEgdHN2YXJlYSBhcHBhcmVhIGNvcmUgbHdpZyBzZG5yZyBz
YWNtIHZuZnBvb2wNCg0KDQpTcGVjaWFsIFJlcXVlc3RzOg0KICBJZiBwb3NzaWJsZSBwbGVhc2Ug
c2NoZWR1bGUgTkVUQ09ORiBzZXNzaW9uIG9uIE1vbmRheSAob3IgVHVlc2RheSkuIA0KSXQgd291
bGQgYmUgdXNlZnVsIHRvIGhhdmUgTmV0Y29uZiBhbmQgTmV0bW9kIHNlc3Npb25zIG9uIGZvbGxv
d2luZyBkYXlzLg0KRnJpZGF5IGlzIE5PVCBwb3NzaWJsZSBmb3IgTmV0Y29uZiEgDQpUaGFuayB5
b3UuIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KDQo=


From nobody Wed Jun 25 22:52:44 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9C21B2AC1 for ; Wed, 25 Jun 2014 22:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.551
X-Spam-Level: 
X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2y64d8B-lXQ for ; Wed, 25 Jun 2014 22:52:40 -0700 (PDT)
Received: from mailgw12.technion.ac.il (mailgw12.technion.ac.il [132.68.225.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3255C1B2AB9 for ; Wed, 25 Jun 2014 22:52:39 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjUDANq0q1OERAEifGdsb2JhbABZDoNRWoJupzMBAQEGBYNhji6HRYEKFg8BAQsWBT6ELRVBNQImAi4yiFQNpUSXXoYQgSuEOYkcgn6BTAWKQJAXgUeQUIRZRYFrBA
X-IPAS-Result: AjUDANq0q1OERAEifGdsb2JhbABZDoNRWoJupzMBAQEGBYNhji6HRYEKFg8BAQsWBT6ELRVBNQImAi4yiFQNpUSXXoYQgSuEOYkcgn6BTAWKQJAXgUeQUIRZRYFrBA
X-IronPort-AV: E=Sophos;i="5.01,548,1400014800"; d="scan'208";a="113208982"
Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw12.technion.ac.il with ESMTP; 26 Jun 2014 08:52:20 +0300
Received: by webmail.technion.ac.il (Postfix, from userid 48) id 7EABA1000FF; Thu, 26 Jun 2014 08:52:21 +0300 (IDT)
Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Thu, 26 Jun 2014 08:52:21 +0300
Date: Thu, 26 Jun 2014 08:52:21 +0300
Message-ID: <20140626085221.Horde.gldxHIFgJCZsYtIR3JuSHg9@webmail.technion.ac.il>
From: Tal Mizrahi 
To: netconf@ietf.org, Ersue@tx.technion.ac.il, mehmet.ersue@nsn.com, bertietf@bwijnen.net
User-Agent: Internet Messaging Program (IMP) H5 (6.1.3)
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1MgmsRkzypIuxl-nNK_M4L9ZnvA
Cc: moses@ee.technion.ac.il
Subject: [Netconf] Updated draft-mm-netconf-time-capability-02
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 05:52:43 -0000

Hi,

We have posted an updated draft.
http://tools.ietf.org/html/draft-mm-netconf-time-capability-02

Summary of the changes compared to the previous draft:
-	We have added a YANG module that defines the time capability.
-	Following the feedback we received, two significant features were  
added: notifications and cancellation messages.
-	Added a detailed discussion about near future scheduling vs. far  
future scheduling.
-	The current draft also includes a description of how the client can  
check whether the server has a synchronized clock or not.
-	Several typo fixes and phrasing improvements.

Many thanks to those who reviewed and helped us improve the draft. We  
believe this draft has significantly matured, and that it is ready for  
WG adoption.

Comments will be welcome.
Thanks,
Tal and Yoram.