éThis document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o draft-ietf-netconf-restconf o draft-ietf-netconf-server-modelé

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

Sent:

Tue, 22 Sep 2015 21:03:08 +0200

Subject:

Re: [Netconf] restconf and namespac= es and unique module names.

:

=0ABecause peo= ple often do not read specifications and if tools do not
=0Acomplai= n they assume everything is fine. The YANG spec has clear
=0Awords,= there is text in the guidelines. We can write more text and it
=0A= will likely not help. Perhaps tutorials need to stress these points.
:

=0A/js

=0A--
=0AJuergen Schoenwae= lder Jacobs University Bremen gGmbH
=0APhone: +49 421 200= 3587 Campus Ring 1 | 28759 Bremen | Germany
=0AFax: +49= 421 200 3103 <http://www.jacobs-university.de/>
=0A_______________________________________________
=0ANetconf ma= iling list
=0ANetconf@ietf.org
=0Ahttps://www.ietf.org/mailman= /listinfo/netconf
--=_020c7c42790233a47670c2d2c8051264-- From nobody Wed Sep 23 02:15:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E844D1AC3C2 for ; Wed, 23 Sep 2015 02:15: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 JUO3fFaeZH4u for ; Wed, 23 Sep 2015 02:15:43 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 432BF1AC3C1 for ; Wed, 23 Sep 2015 02:15:43 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id A06C61CC0116; Wed, 23 Sep 2015 11:15:50 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn , "netconf\@ietf.org" In-Reply-To: <12411173.1442943289384.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <12411173.1442943289384.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 23 Sep 2015 11:15:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Netconf] restconf and namespaces and unique module names. 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, 23 Sep 2015 09:15:46 -0000 Randy Presuhn writes: > Hi - > >>From: Juergen Schoenwaelder >>Sent: Sep 22, 2015 7:26 AM >>To: Kent Watsen >>Cc: "netconf@ietf.org" >>Subject: Re: [Netconf] restconf and namespaces and unique module names. >> >>On Tue, Sep 22, 2015 at 01:41:39PM +0000, Kent Watsen wrote: >>> >>> My issue is with RESTCONF, but the concern extends to YANG and JSON >>> encoding as well. >>> >>> YANG's namespace statement is intended to make module names unique. >>> While IETF-defined modules tend to have a unique namespace per module (why >>> is that?), this is not required and I wonder if it will interfere with our >>> module-structure aspirations. >>> >>> But back to my concern, RESTCONF's URL-encoding uses module names (not >>> namespace) as a prefix to uniquely identify the module and yet there is no >>> guarantee that the module names are unique. For instance: >>> >>> module system { >>> namespace "http://vendor-foo.com"; >>> leaf hostname { >>> type string; >>> } >>> } >>> >>> >>> module system { >>> namespace "http://openconfig.net"; <--- using OC just to make a point >>> leaf hostname { >>> type string; >>> } >>> } >>> >>> >>> >>> And then we have the RESTCONF call: >>> >>> GET https:///data/system:hostname HTTP/1.1 >>> >>> >>> So which module is used? Is this an error condition? - do we need a >>> statement that no two modules can have the same name? Should we use YANG >>> library to provide an alternate module-name (e.g., system-1) for when >>> collisions occur? >>> >> >>RFC 6020: >> >> The names of all standard modules and submodules MUST be unique. >> Developers of enterprise modules are RECOMMENDED to choose names for >> their modules that will have a low probability of colliding with >> standard or other enterprise modules, e.g., by using the enterprise >> or organization name as a prefix for the module name. >> >>Apparently, both module names in the example violate this. Note that >>module names are used to resolve imports and hence they better are >>unique. For the IETF, we can manage that via the IANA registry. For >>the other modules, there is a clear recommendation. > > A couple of questions on the RFC 6020 text cited... > > (1) is "standard modules" intended to include those from *all* SDOs? > > (2) "MUST" is normally used in situations where "if you don't > do this this way, this protocol/process won't work correctly." This is not the case unless different modules of the same name are used by the same server. BTW, there are also no hard guarantees that all URIs are unique. Lada > If that is indeed so for standard modules, why is it not > also true for enterprise modules? That is, what is different > about enterprise modules that allows them to operate correctly > without the "MUST"? > > I suspect this language may have been (subconsciously) borrowed from > the conventions for SMI module names which, unlike Yang module names, > don't show up in the corresponding protocols. > > Randy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 23 02:22:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6E1AC3DB for ; Wed, 23 Sep 2015 02:22:07 -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 uT8oeDAQ5Ja0 for ; Wed, 23 Sep 2015 02:22:05 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5EB1AC3D7 for ; Wed, 23 Sep 2015 02:22:05 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0EFB01CC0116; Wed, 23 Sep 2015 11:22:13 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Randy Presuhn In-Reply-To: <20150922185838.GA99737@elstar.local> References: <12411173.1442943289384.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <20150922185838.GA99737@elstar.local> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 23 Sep 2015 11:22:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] restconf and namespaces and unique module names. 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, 23 Sep 2015 09:22:07 -0000 Juergen Schoenwaelder writes: > On Tue, Sep 22, 2015 at 10:34:48AM -0700, Randy Presuhn wrote: >> Hi - >> >> >From: Juergen Schoenwaelder >> >Sent: Sep 22, 2015 7:26 AM >> >To: Kent Watsen >> >Cc: "netconf@ietf.org" >> >Subject: Re: [Netconf] restconf and namespaces and unique module names. >> > >> >On Tue, Sep 22, 2015 at 01:41:39PM +0000, Kent Watsen wrote: >> >> >> >> My issue is with RESTCONF, but the concern extends to YANG and JSON >> >> encoding as well. >> >> >> >> YANG's namespace statement is intended to make module names unique. >> >> While IETF-defined modules tend to have a unique namespace per module (why >> >> is that?), this is not required and I wonder if it will interfere with our >> >> module-structure aspirations. >> >> >> >> But back to my concern, RESTCONF's URL-encoding uses module names (not >> >> namespace) as a prefix to uniquely identify the module and yet there is no >> >> guarantee that the module names are unique. For instance: >> >> >> >> module system { >> >> namespace "http://vendor-foo.com"; >> >> leaf hostname { >> >> type string; >> >> } >> >> } >> >> >> >> >> >> module system { >> >> namespace "http://openconfig.net"; <--- using OC just to make a point >> >> leaf hostname { >> >> type string; >> >> } >> >> } >> >> >> >> >> >> >> >> And then we have the RESTCONF call: >> >> >> >> GET https:///data/system:hostname HTTP/1.1 >> >> >> >> >> >> So which module is used? Is this an error condition? - do we need a >> >> statement that no two modules can have the same name? Should we use YANG >> >> library to provide an alternate module-name (e.g., system-1) for when >> >> collisions occur? >> >> >> > >> >RFC 6020: >> > >> > The names of all standard modules and submodules MUST be unique. >> > Developers of enterprise modules are RECOMMENDED to choose names for >> > their modules that will have a low probability of colliding with >> > standard or other enterprise modules, e.g., by using the enterprise >> > or organization name as a prefix for the module name. >> > >> >Apparently, both module names in the example violate this. Note that >> >module names are used to resolve imports and hence they better are >> >unique. For the IETF, we can manage that via the IANA registry. For >> >the other modules, there is a clear recommendation. >> >> A couple of questions on the RFC 6020 text cited... >> >> (1) is "standard modules" intended to include those from *all* SDOs? >> >> (2) "MUST" is normally used in situations where "if you don't >> do this this way, this protocol/process won't work correctly." >> If that is indeed so for standard modules, why is it not >> also true for enterprise modules? That is, what is different >> about enterprise modules that allows them to operate correctly >> without the "MUST"? >> >> I suspect this language may have been (subconsciously) borrowed from >> the conventions for SMI module names which, unlike Yang module names, >> don't show up in the corresponding protocols. >> > > You may propose alternative wording. Yes, the wording has been > borrowed from SMI specifications and for resolving imports SMI module > names better are unique as well. Also note that YANG module names only > show up in the JSON encoding on the wire, not im XML. But they are Not true, they also show up in Request-URI. Lada > also used to annouce capabilities - so they better be unique, as the > text says. > > /js > > -- > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 23 06:44:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531681B30CD; Wed, 23 Sep 2015 06:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1HHgwUI7nFqO; Wed, 23 Sep 2015 06:44:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9D21A854D; Wed, 23 Sep 2015 06:44:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150923134435.5589.2325.idtracker@ietfa.amsl.com> Date: Wed, 23 Sep 2015 06:44:35 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] Last Call: (NETCONF Call Home and RESTCONF Call Home) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 13:44:36 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'NETCONF Call Home and RESTCONF Call Home' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-10-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2170/ https://datatracker.ietf.org/ipr/2445/ From nobody Wed Sep 23 08:11:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03161A6FA8 for ; Wed, 23 Sep 2015 08:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl0W2qJ-Io2G for ; Wed, 23 Sep 2015 08:11:36 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 42FA01A6F9A for ; Wed, 23 Sep 2015 08:11:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DEF5W8PRhSket6oaR7G1TWPuBd2K+MaPSN7csSHANr3RpHfV7VHmpUoNCjpX0Fal; 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.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Zelhi-00047f-Kx for netconf@ietf.org; Wed, 23 Sep 2015 11:11:30 -0400 Received: from 76.254.54.248 by webmail.earthlink.net with HTTP; Wed, 23 Sep 2015 11:11:30 -0400 Message-ID: <7047634.1443021090650.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Wed, 23 Sep 2015 08:11:30 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3eda1c983dc9d85fff0657b9dd707f154fd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Archived-At: Subject: Re: [Netconf] restconf and namespaces and unique module names. 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: Wed, 23 Sep 2015 15:11:37 -0000 Hi - >From: Ladislav Lhotka >Sent: Sep 23, 2015 2:15 AM >To: Randy Presuhn , "netconf@ietf.org" >Subject: Re: [Netconf] restconf and namespaces and unique module names. ... >>>RFC 6020: >>> >>> The names of all standard modules and submodules MUST be unique. >>> Developers of enterprise modules are RECOMMENDED to choose names for >>> their modules that will have a low probability of colliding with >>> standard or other enterprise modules, e.g., by using the enterprise >>> or organization name as a prefix for the module name. >>> >>>Apparently, both module names in the example violate this. Note that >>>module names are used to resolve imports and hence they better are >>>unique. For the IETF, we can manage that via the IANA registry. For >>>the other modules, there is a clear recommendation. >> >> A couple of questions on the RFC 6020 text cited... >> >> (1) is "standard modules" intended to include those from *all* SDOs? >> >> (2) "MUST" is normally used in situations where "if you don't >> do this this way, this protocol/process won't work correctly." > >This is not the case unless different modules of the same name are used >by the same server. (1) My question remains: why a "MUST" for "standard" modules but not enterprise ones? It sounds like you're arguing that a "SHOULD" or "RECOMMENDED" would suffice in both cases. (2) A question of curiousity: what does a client do when it encounters different servers using different modules of the same name, and how does it know they are indeed different, using only mandatory features of the protocol and mandatory-to-implement models? Randy From nobody Wed Sep 23 08:56:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CC11A8716 for ; Wed, 23 Sep 2015 08:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7Xk5WG_pshb for ; Wed, 23 Sep 2015 08:56:51 -0700 (PDT) Received: from ni.com (skprod3.natinst.com [130.164.80.24]) (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 0A8561A8712 for ; Wed, 23 Sep 2015 08:56:50 -0700 (PDT) Received: from US-AUS-MAIL4.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod3.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id t8NFuoRm019846; Wed, 23 Sep 2015 10:56:50 -0500 In-Reply-To: References: To: "Ersue, Mehmet (Nokia - DE/Munich)" MIME-Version: 1.0 X-KeepSent: BEABE647:23C67498-86257EC9:0057168A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP6 November 22, 2013 From: Rodney Cummings Message-ID: Date: Wed, 23 Sep 2015 10:56:49 -0500 X-MIMETrack: Serialize by Router on US-AUS-MAIL4/AUS/M/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 09/23/2015 10:56:49 AM, Serialize complete at 09/23/2015 10:56:49 AM Content-Type: multipart/alternative; boundary="=_alternative 0057996986257EC9_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-23_06:, , signatures=0 Archived-At: Cc: Netconf Subject: Re: [Netconf] Draft charter update for review 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, 23 Sep 2015 15:56:54 -0000 This is a multipart message in MIME format. --=_alternative 0057996986257EC9_= Content-Type: text/plain; charset="US-ASCII" Hello, I apologize for commenting a bit late on the proposed charter, but I have a concern. The proposal states: > RESTCONF should not deviate from the NETCONF capabilities unless proper justification > is provided and documented. RESTCONF is currently being explored for use in many applications due to the fact that it is a subset of NETCONF capabilities, with a simpler implementation in servers. This is described in section 1.1 of the current draft (i.e. "Simple Subset of NETCONF Functionality"). In my opinion this is a benefit of RESTCONF that cannot be lost. If anything, the opposite strategy should be taken, in that NETCONF capabilities should only be added to RESTCONF with a strong justification. Rodney From: "Ersue, Mehmet (Nokia - DE/Munich)" To: Netconf , Date: 09/17/2015 05:25 PM Subject: [Netconf] Draft charter update for review Sent by: "Netconf" Dear NETCONF WG, please find below the draft charter update which we provided to our AD for review. Comments are welcome. Mehmet & Mahesh ------------------ Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Mahesh Jethanandani Mehmet Ersue Operations and Management Area Directors: Benoit Claise Joel Jaeggli Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: https://mailarchive.ietf.org/arch/browse/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interconnected networks. Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF protocol (RFC 6241) provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF is based on the secure transport (SSH is mandatory to implement while TLS is an optional transport) and uses an XML-based data representation. The NETCONF protocol is data modeling language independent, but YANG (RFC 6020) is the recommended NETCONF modeling language, which introduces advanced language features for configuration management. Recently NETCONF WG define the Call Home mechanism for NETCONF and RESTCONF protocols as well as updated RFC5539 by adding the new message framing used by NETCONF 1.1. Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for RFC6241 and RFC6242 and addressing any reported errata. In the current phase of NETCONF's incremental development the workgroup will focus on following items: 1. Combine the server configuration data models from the Call Home and RFC5539bis drafts in a separate Server Configuration YANG module by addressing the need for NETCONF as well as RESTCONF. 2. Develop RESTCONF, a protocol based on NETCONF in terms of capabilities, but over HTTP and with some REST characteristics, for accessing YANG data in NETCONF datastores. An "ordered edit list" approach is needed (the YANG patch) to provide client developers with a simpler edit request format that can be more efficient and also allow more precise client control of the transaction procedure than existing mechanisms. The YANG patch operation, based on the HTTP PATCH method, will be prepared in a separate draft. In addition develop a YANG library, which identifies the information about all YANG modules used by a server. Furthermore develop a collection resource for the RESTCONF protocol to provide enhanced filtering features for the retrieval of data nodes with the GET method. RESTCONF should not deviate from the NETCONF capabilities unless proper justification is provided and documented. The RESTCONF work will consider requirements suggested by the other working groups (for example I2RS). 3. Develop a zero touch configuration document (a technique to establish a secure network management relationship between a newly delivered network device configured with just its factory default settings, and the Network Management System), specific to the NETCONF use case. 4. Develop a subscription and push mechanism that allows client applications to request notifications for changes in the datastore. These updates will be pushed by the server to the client based on a subscription policy. 5. Update RFC 6536 (NETCONF Access Control Model) to introduce access control rights associated with actions. 6.Enhance RFC 5277 with the ability to delete subscriptions without closing the client session, to modify existing subscriptions, and to have multiple subscriptions on a established client session. These changes should not affect older clients that do not support these particular subscription requirements. The RPCs and the data models in RFC 5277 should be converted to YANG. Goals and Milestones: Done - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard Done - Submit NETCONF call home mechanism to AD/IESG for consideration as Proposed Standard Oct 2015 - WGLC for RESTCONF, YANG patch operation and YANG Library drafts Nov 2015 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard Jan 2016 - WGLC for RFC5277bis draft Jan 2016 - Submit RFC5277bis to AD/IESG for consideration as Proposed Standard Jan 2016 - WGLC for YANG datastore push update draft Feb 2016 - Submit YANG datastore push update to AD/IESG for consideration as Proposed Standard Feb 2016 - WGLC for RFC6536bis draft Feb 2016 - Submit RFC6536bis to AD/IESG for consideration as Proposed Standard Feb 2016 - WGLC for zero touch configuration Feb 2016 - WGLC for RESTCONF Collection Resource draft Mar 2016 - Submit zero touch configuration to AD/IESG for consideration as Proposed Standard Mar 2016 - Submit RESTCONF Collection to AD/IESG for consideration as Proposed Standard Mar 2016 - WGLC for NETCONF server configuration data model Apr 2016 - Submit server configuration data model to AD/IESG for consideration as _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --=_alternative 0057996986257EC9_= Content-Type: text/html; charset="US-ASCII" Hello,

I apologize for commenting a bit late on the proposed charter, but I have a concern.

The proposal states:
> RESTCONF should not deviate from the NETCONF capabilities unless proper justification
> is provided and documented.

RESTCONF is currently being explored for use in many applications due to the fact that it is a subset of NETCONF capabilities, with a simpler implementation in servers. This is described in section 1.1 of the current draft (i.e. "Simple Subset of NETCONF Functionality").

In my opinion this is a benefit of RESTCONF that cannot be lost. If anything, the opposite strategy should be taken, in that NETCONF capabilities should only be added to RESTCONF with a strong justification.

Rodney

From: "Ersue, Mehmet (Nokia - DE/Munich)" <mehmet.ersue@nokia.com>
To: Netconf <netconf@ietf.org>,
Date: 09/17/2015 05:25 PM
Subject: [Netconf] Draft charter update for review
Sent by: "Netconf" <netconf-bounces@ietf.org>

Dear NETCONF WG,

please find below the draft charter update which we provided to our AD for review.

Comments are welcome.

Mehmet & Mahesh

------------------

Network Configuration (netconf)

-------------------------------

Charter

Current Status: Active

Chairs:

Mahesh Jethanandani <mjethanandani@gmail.com>

Mehmet Ersue <mehmet.ersue@nokia.com>

Operations and Management Area Directors:

Benoit Claise <bclaise@cisco.com>

Joel Jaeggli <joelja@bogus.com>

Operations and Management Area Advisor:

Benoit Claise <bclaise@cisco.com>

Mailing Lists:

General Discussion: netconf@ietf.org

To Subscribe: https://www.ietf.org/mailman/listinfo/netconf

Archive: https://mailarchive.ietf.org/arch/browse/netconf/

Description of Working Group:

Configuration of networks of devices has become a critical requirement

for operators in today's highly interconnected networks. Large and small

operators alike have developed their own mechanisms or have used vendor

specific mechanisms to transfer configuration data to and from a device

and to examine device state information which may impact the

configuration. Each of these mechanisms may be different in various

aspects, such as session establishment, user authentication,

configuration data exchange, and error responses.

The NETCONF protocol (RFC 6241) provides mechanisms to install, manipulate,

and delete the configuration of network devices. NETCONF is based on the

secure transport (SSH is mandatory to implement while TLS is an optional

transport) and uses an XML-based data representation. The NETCONF protocol

is data modeling language independent, but YANG (RFC 6020) is the recommended

NETCONF modeling language, which introduces advanced

language features for configuration management.

Recently NETCONF WG define the Call Home mechanism for NETCONF and RESTCONF protocols

as well as updated RFC5539 by adding the new message framing used by NETCONF 1.1.

Based on the implementation, deployment experience and interoperability

testing, the WG aims to produce a NETCONF status report in a later stage.

The result may be clarifications for RFC6241 and RFC6242 and addressing

any reported errata.

In the current phase of NETCONF's incremental development the workgroup

will focus on following items:

1. Combine the server configuration data models from the Call Home and RFC5539bis drafts in a separate Server Configuration YANG module by addressing the need for NETCONF as well as RESTCONF.

2. Develop RESTCONF, a protocol based on NETCONF in terms of capabilities, but over HTTP and with some REST characteristics, for accessing YANG data in NETCONF datastores. An "ordered edit list" approach is needed (the YANG patch) to provide client developers with a simpler edit request format that can be more efficient and also allow more precise client control of the transaction procedure than existing mechanisms. The YANG patch operation, based on the HTTP PATCH method, will be prepared in a separate draft.

In addition develop a YANG library, which identifies the information about all YANG modules used by a server. Furthermore develop a collection resource for the RESTCONF protocol to provide enhanced filtering features for the retrieval of data nodes with the GET method.

RESTCONF should not deviate from the NETCONF capabilities unless proper justification is provided and documented. The RESTCONF work will consider requirements suggested by the other working groups (for example I2RS).

3. Develop a zero touch configuration document (a technique to establish a secure network management relationship between a newly delivered network device configured with just its factory default settings, and the Network Management System), specific to the NETCONF use case.

4. Develop a subscription and push mechanism that allows client applications to request notifications for changes in the datastore. These updates will be pushed by the server to the client based on a subscription policy.

5. Update RFC 6536 (NETCONF Access Control Model) to introduce access control rights associated with actions.

6.Enhance RFC 5277 with the ability to delete subscriptions without closing the client session, to modify existing subscriptions, and to have multiple subscriptions on a established client session. These changes should not affect older clients that do not support these particular subscription requirements. The RPCs and the data models in RFC 5277 should be converted to YANG.

Goals and Milestones:

Done - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard

Done - Submit NETCONF call home mechanism to AD/IESG for consideration as Proposed Standard

Oct 2015 - WGLC for RESTCONF, YANG patch operation and YANG Library drafts

Nov 2015 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard

Jan 2016 - WGLC for RFC5277bis draft

Jan 2016 - Submit RFC5277bis to AD/IESG for consideration as Proposed Standard

Jan 2016 - WGLC for YANG datastore push update draft

Feb 2016 - Submit YANG datastore push update to AD/IESG for consideration as Proposed Standard

Feb 2016 - WGLC for RFC6536bis draft

Feb 2016 - Submit RFC6536bis to AD/IESG for consideration as Proposed Standard

Feb 2016 - WGLC for zero touch configuration

Feb 2016 - WGLC for RESTCONF Collection Resource draft

Mar 2016 - Submit zero touch configuration to AD/IESG for consideration as Proposed Standard

Mar 2016 - Submit RESTCONF Collection to AD/IESG for consideration as Proposed Standard

Mar 2016 - WGLC for NETCONF server configuration data model

Apr 2016 - Submit server configuration data model to AD/IESG for consideration as

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

--=_alternative 0057996986257EC9_=-- From nobody Wed Sep 23 09:08:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDBF1A87AD for ; Wed, 23 Sep 2015 09:08:27 -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, 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 bhw2ILMB7lrd for ; Wed, 23 Sep 2015 09:08:26 -0700 (PDT) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830201A874E for ; Wed, 23 Sep 2015 09:08:25 -0700 (PDT) Received: from [192.168.10.101] ([73.211.21.12]) by p3plsmtpa09-06.prod.phx3.secureserver.net with id Lg8P1r00L0FehNH01g8QbJ; Wed, 23 Sep 2015 09:08:24 -0700 To: netconf@ietf.org References: <20150922142615.GC99134@elstar.local> <20150922190308.GB99737@elstar.local> From: Xiang Li Message-ID: <5602CE77.8040208@seguesoft.com> Date: Wed, 23 Sep 2015 11:08:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150922190308.GB99737@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] restconf and namespaces and unique module names. 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, 23 Sep 2015 16:08:28 -0000 Hi On 9/22/2015 2:03 PM, Juergen Schoenwaelder wrote: > On Tue, Sep 22, 2015 at 05:25:04PM +0000, Kent Watsen wrote: >>> RFC 6020: >>> >>> The names of all standard modules and submodules MUST be unique. >>> Developers of enterprise modules are RECOMMENDED to choose names for >>> their modules that will have a low probability of colliding with >>> standard or other enterprise modules, e.g., by using the enterprise >>> or organization name as a prefix for the module name. >>> >>> Apparently, both module names in the example violate this. Note that >>> module names are used to resolve imports and hence they better are >>> unique. For the IETF, we can manage that via the IANA registry. For >>> the other modules, there is a clear recommendation. >> >> OK, that's fair, but it doesn't seem to be a followed often outside of the >> IETF. >> >> For instance, >> >> - ETSI NFV-MANO has module names like "nsd", "vnfd" and "vld" >> - Open Config has module names beginning with "bgp-" and "mpls-" >> - IEEE has module names like "ethernet" >> - ODL has some module names like "config" and "flow-errors" > Because people often do not read specifications and if tools do not > complain they assume everything is fine. The YANG spec has clear > words, there is text in the guidelines. We can write more text and it > will likely not help. Perhaps tutorials need to stress these points. I agree for standard modules it "MUST" have unique names since it is enforceable. To ensure maximum interoperability, a private module designer better follow the recommendation and carefully choose a name that is unlikely conflicting with others. We see many private MIBs use a name with company name prefixed, and for some MIB designers, I believe that is a learned lesson. --Xiang Li From nobody Thu Sep 24 02:21:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E881A8986 for ; Thu, 24 Sep 2015 02:21:07 -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 0w_29-efMQi8 for ; Thu, 24 Sep 2015 02:21:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A3A1A8974 for ; Thu, 24 Sep 2015 02:21:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id t8O9L1Xm007464 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Sep 2015 09:21:01 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t8O9L0MH004415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Sep 2015 11:21:01 +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.248.2; Thu, 24 Sep 2015 11:21:00 +0200 Received: from DEMUMBX006.nsn-intra.net ([169.254.6.213]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0248.002; Thu, 24 Sep 2015 11:21:00 +0200 From: "Uveges, Balint (Nokia - HU/Budapest)" To: "netconf@ietf.org" Thread-Topic: Long-lasting RESTCONF operations Thread-Index: AdD2qlN3N/lWCzBIQVO6Z0AWvW6WZA== Date: Thu, 24 Sep 2015 09:21:00 +0000 Message-ID: <28B876C36C5AA84CBAB912BA734FAC35016469DA@DEMUMBX006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 1991 X-purgate-ID: 151667::1443086462-0000538C-60F505ED/0/0 Archived-At: Subject: [Netconf] Long-lasting RESTCONF operations 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, 24 Sep 2015 09:21:07 -0000 Hi All, I would like to clarify an issue regarding the following RESTCONF scenario. Let's assume that certain RESTCONF operations take quite some time on the server side, for example the evaluation of a received POST method (in Create Resource Mode), due to internal validations or due to the processing of large amount of received data. According to the RESTCONF draft (section 4.4.1): "If the POST method succeeds, a "201 Created" status-line is returned and there is no response message-body." If I interpret this right, a RESTCONF client has to wait for 201 Created (or for 4xx/5xx if something goes wrong) no matter how long it takes for the server to process and answer the POST method. This behavior has no significance if a RESTCONF client manages only a few RESTCONF server, but could lead easily to a bottleneck in the client in case of large amount of RESTCONF servers, when the client manages them in parallel. RESTCONF is an HTTP-based protocol and RFC 7231 defines the status code 202 Accepted (section 6.3.3) as: "The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. . . .=20 The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled." With 202 Accepted it would be possible not just to inform the RESTCONF client, that the method is accepted and is waiting to be processed but also the HTTP connection could be terminated (if needed). Moreover it would provide means for the client to poll the status of the request at the URI provided in the Location header of 202 Accepted. Side note: The RESTCONF draft lists the HTTP method 202 Accepted as well in chapter 7, but it does not define any semantics. Thank you in advance for your comments. Best regards, -Balint From nobody Thu Sep 24 09:36:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68361A802E for ; Thu, 24 Sep 2015 09:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq1ERwDprX1X for ; Thu, 24 Sep 2015 09:36:54 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA201A6F45 for ; Thu, 24 Sep 2015 09:36:53 -0700 (PDT) Received: by lacdq2 with SMTP id dq2so14919728lac.1 for ; Thu, 24 Sep 2015 09:36: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=iimy1z6leJChxtFUU2/BiNv5e7Pbk5c2oCYegS/VN88=; b=SXmEBNkibfmxaEJ10yeqm+Efo2dYA7wqpVn1nAvB39sYX2i+BeEY+T2qlaxaRL/FNS GfSeHS0EHfo2RoSXI2ZPzH7I0VoJxPtILA3bseGhakUHbPKSirTp8WXDKKXAbJEkrplU yReQ+6uOEl3zCvGfT3ymUZVrJjCtFcXfv/jnLsTpe/Z1pdnq8cYcldkvu4jUGciM0XGJ bolOAKYCjhxYGZg2KN1sIpikWo86K98YRxBieu3gVwAWwwLOUgEEkyeE4fa6v6xUB79W gZaBJ9HsMShlUU37wiTGAsLFRqU4vZyGr6ZHpjGumOABBbrCAeg/aj4KbAZkDR6wiYPy 7JdQ== X-Gm-Message-State: ALoCoQllCixkmoQJWazA9ufO0e+Ty600mVxIDk0IMJ+4wyUG1D9b5Phz10f9CqSwhos31Lv4CEWT MIME-Version: 1.0 X-Received: by 10.112.200.229 with SMTP id jv5mr170694lbc.123.1443112611246; Thu, 24 Sep 2015 09:36:51 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 24 Sep 2015 09:36:51 -0700 (PDT) In-Reply-To: <28B876C36C5AA84CBAB912BA734FAC35016469DA@DEMUMBX006.nsn-intra.net> References: <28B876C36C5AA84CBAB912BA734FAC35016469DA@DEMUMBX006.nsn-intra.net> Date: Thu, 24 Sep 2015 09:36:51 -0700 Message-ID: From: Andy Bierman To: "Uveges, Balint (Nokia - HU/Budapest)" Content-Type: multipart/alternative; boundary=001a11c26650908ee2052080d69a Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Long-lasting RESTCONF operations 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, 24 Sep 2015 16:36:56 -0000 --001a11c26650908ee2052080d69a Content-Type: text/plain; charset=UTF-8 On Thu, Sep 24, 2015 at 2:21 AM, Uveges, Balint (Nokia - HU/Budapest) < balint.uveges@nokia.com> wrote: > Hi All, > > I would like to clarify an issue regarding the following RESTCONF scenario. > > Let's assume that certain RESTCONF operations take quite some time on > the server side, for example the evaluation of a received POST method > (in Create Resource Mode), due to internal validations or due to the > processing of large amount of received data. According to the RESTCONF > draft (section 4.4.1): > > "If the POST method succeeds, a "201 Created" status-line is returned > and there is no response message-body." > > If I interpret this right, a RESTCONF client has to wait for 201 Created > (or for 4xx/5xx if something goes wrong) no matter how long it takes for > the server to process and answer the POST method. This behavior has no > significance if a RESTCONF client manages only a few RESTCONF server, > but could lead easily to a bottleneck in the client in case of large > amount of RESTCONF servers, when the client manages them in parallel. > > RESTCONF is an HTTP-based protocol and RFC 7231 defines the status code > 202 Accepted (section 6.3.3) as: > > "The 202 (Accepted) status code indicates that the request has been > accepted for processing, but the processing has not been completed. > . . . > The representation sent with this > response ought to describe the request's current status and point to > (or embed) a status monitor that can provide the user with an > estimate of when the request will be fulfilled." > > With 202 Accepted it would be possible not just to inform the RESTCONF > client, that the method is accepted and is waiting to be processed but > also the HTTP connection could be terminated (if needed). Moreover it > would provide means for the client to poll the status of the request at > the URI provided in the Location header of 202 Accepted. > > Side note: The RESTCONF draft lists the HTTP method 202 Accepted as well > in chapter 7, but it does not define any semantics. > > Thank you in advance for your comments. > > So you are suggesting that a server can optionally support 202 Accepted, which means of course it is mandatory to support for the client. There seems to be some interest in the IETF right now wrt/ clarifying what it means when the server returns to an edit request. If it means "your edit is part of the intended configuration" then 202 Accepted is not really needed as any decent server can do this without delay. If it means "your edit is now reflected in actual network behavior" then perhaps it will be useful. > Best regards, > -Balint > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c26650908ee2052080d69a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 24, 2015 at 2:21 AM, Uveges, Balint (Nokia - HU/Budapest) <= span dir=3D"ltr"><balint.uveges@nokia.com> wrote:

Hi All,

I would like to clarify an issue regarding the following RESTCONF scenario.=

Let's assume that certain RESTCONF operations take quite some time on the server side, for example the evaluation of a received POST method
(in Create Resource Mode), due to internal validations or due to the
processing of large amount of received data. According to the RESTCONF
draft (section 4.4.1):

=C2=A0 "If the POST method succeeds, a "201 Created" status-= line is returned
=C2=A0 =C2=A0and there is no response message-body."

If I interpret this right, a RESTCONF client has to wait for 201 Created (or for 4xx/5xx if something goes wrong) no matter how long it takes for the server to process and answer the POST method. This behavior has no
significance if a RESTCONF client manages only a few RESTCONF server,
but could lead easily to a bottleneck in the client in case of large
amount of RESTCONF servers, when the client manages them in parallel.

RESTCONF is an HTTP-based protocol and RFC 7231 defines the status code
202 Accepted (section 6.3.3) as:

=C2=A0 "The 202 (Accepted) status code indicates that the request has = been
=C2=A0 =C2=A0accepted for processing, but the processing has not been compl= eted.
. . .
=C2=A0 =C2=A0The representation sent with this
=C2=A0 =C2=A0response ought to describe the request's current status an= d point to
=C2=A0 =C2=A0(or embed) a status monitor that can provide the user with an<= br> =C2=A0 =C2=A0estimate of when the request will be fulfilled."

With 202 Accepted it would be possible not just to inform the RESTCONF
client, that the method is accepted and is waiting to be processed but
also the HTTP connection could be terminated (if needed). Moreover it
would provide means for the client to poll the status of the request at
the URI provided in the Location header of 202 Accepted.

Side note: The RESTCONF draft lists the HTTP method 202 Accepted as well in chapter 7, but it does not define any semantics.

Thank you in advance for your comments.

So you are suggesting t= hat a server can optionally support 202 Accepted,

which means of = course it is mandatory to support for the client.

= There seems to be some interest in the IETF right now wrt/ clarifying what = it

means when the server returns <ok/> to an edit request.= =C2=A0 If it means "your edit

is part of the intended config= uration" then 202 Accepted is not really needed as

any decen= t server can do this without delay.=C2=A0 If it means "your edit is no= w

reflected in actual network behavior" then perhaps it will= be useful.

=C2=A0

Best regards,
-Balint

Andy

=C2=A0

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

--001a11c26650908ee2052080d69a-- From nobody Fri Sep 25 20:25:14 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAF21AD06C for ; Fri, 25 Sep 2015 20:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w32JLE9QIDzy for ; Fri, 25 Sep 2015 20:25:11 -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 D81D51AD06B for ; Fri, 25 Sep 2015 20:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11267; q=dns/txt; s=iport; t=1443237910; x=1444447510; h=from:to:cc:subject:date:message-id:mime-version; bh=f0kg7J08pf4KAnlcpsPHVYXeR9CdBbu9ijRgrli2uD4=; b=fzcqxXCUzrJBAV/bF3r/pn31qBsp0eK6GuYOFduizcWwNo7pcg8WKuql l+oGkwRleabt6vc+ad1J7KBKdpFJLH/EopC/nbWh+r8IfnZLjkBUwxStP ZyHAVDqKgFida9A00KghEAtUs5NzNjoWn0IZQsO1LoGDHZG89XlUJp4nL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABAgDvDgZW/4ENJK1dgldNVG+9MgENgXeFfQKBJjgUAQEBAQEBAYEKhCYBBC1MEgEqViYBBAENDYgmDcwYAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BMMYMfgRQFjH+IbQGFE4oOmR4fAQFChAGJDYEFAQEB X-IronPort-AV: E=Sophos; i="5.17,590,1437436800"; d="scan'208,217"; a="30328002" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2015 03:25:09 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8Q3P9h9026770 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 26 Sep 2015 03:25:09 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Sep 2015 22:25:09 -0500 Received: from xhc-rcd-x15.cisco.com (173.37.183.89) by xch-rcd-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 25 Sep 2015 22:25:09 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.194]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 22:25:08 -0500 From: "Alexander Clemm (alex)" To: "Andy Bierman (andy@yumaworks.com)" , "Martin Bjorklund (mbjorklu)" , Kent Watsen Thread-Topic: YANG patch with XML and Netconf edit-config Thread-Index: AdD4CCuxvjUk1rC+SvOyPcAnIocwzA== Date: Sat, 26 Sep 2015 03:25:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.48.185] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571DCCD960xmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: [Netconf] YANG patch with XML and Netconf 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: Sat, 26 Sep 2015 03:25:13 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571DCCD960xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Helo Andy, Martin, Kent, looking at draft-ietf-netconf-yang-patch-05, I am wondering if you have exa= mples for YANG-patch with XML encoding. The examples in section D are all = JSON-encoded. I am wondering specifically about how the XML encoding in YANG-patch relate= s to the Netconf encoding of edit-config. I was hoping the two would be al= igned or even the same, but is this the case? It seems that the yang-patch= way of doing things will require a different encoding of the payload, mean= ing you cannot simply take the same "edit snippet" and use it both for Netc= onf and Restconf, instead the content/encoding will depend on the underlyin= g transport, not be agnostic to it. Is this understanding correct? What i= s the intention? Do we have some examples? For example, if we have (per the example in RFC 6241) the following edit-co= nfig snippet:

none

Ethernet0/0 what does the corresponding YANG-patch look like - something like this: (e= dit-config style) Accept: application/yang.patch-status+xml Content-Type: application/yang.patch+xml

my-patch

Ethernet0/0 or is it something like this: Accept: application/yang.patch-status+xml Content-Type: application/yang.patch+xml

my-patch

edit1

delete Ethernet0/0 Thanks --- Alex --_000_DBC595ED2346914F9F81D17DD5C32B571DCCD960xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Helo Andy, Martin, Kent,

looking at draft-ietf-netconf-yang-patch-05, I am wo= ndering if you have examples for YANG-patch with XML encoding. The ex= amples in section D are all JSON-encoded.

I am wondering specifically about how the XML encodi= ng in YANG-patch relates to the Netconf encoding of edit-config. I wa= s hoping the two would be aligned or even the same, but is this the case?&n= bsp; It seems that the yang-patch way of doing things will require a different encoding of the payload, meaning you canno= t simply take the same “edit snippet” and use it both for Netco= nf and Restconf, instead the content/encoding will depend on the underlying= transport, not be agnostic to it. Is this understanding correct? What is the intention? Do we have some = examples?

For example, if we have (per the example in RFC 6241= ) the following edit-config snippet:

       <edit-config>

         <target>

           <runni=
ng/>

         </target><=
/o:p>

         <default-operation=
>none</default-operation>

         <config xmlns:xc=
=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

           <top x=
mlns=3D"http://example.com/schema/1.2/config">
           &nbs=
p; <interface xc:operation=3D"delete">
           &nbs=
p;   <name>Ethernet0/0</name>
            &nb=
sp;</interface>
           </top&=
gt;
         </config><=
/o:p>
       </edit-config>
 
what does the corresponding YANG-patch look like =
211; something like this:  (edit-config style)
 
      Accept: application/yang.patch-status&#=
43;xml
      Content-Type: application/yang.patch=
3;xml
 
      <yang-patch>
        <patch-id>my-patch<=
;/patch-id> 
        <edit> 
         <config xmlns=
:xc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
           <top x=
mlns=3D"http://example.com/schema/1.2/config">
           &nbs=
p; <interface xc:operation=3D"delete">
           &nbs=
p;   <name>Ethernet0/0</name>
            &nb=
sp;</interface>
           </top&=
gt;
         </config><=
/o:p>
        </edit>
       </yang-patch>
 
or is it something like this:
      Accept: application/yang.patch-status&#=
43;xml
      Content-Type: application/yang.patch=
3;xml
 
      <yang-patch>
        <patch-id>my-patch<=
;/patch-id> 
        <edit> 
          <edit-i=
d>edit1</edit-id>
          <operation&g=
t;delete</operation>
          <target><=
o:p>
           &nbs=
p; <interface>
           &nbs=
p;   <name>Ethernet0/0</name>
            &nb=
sp;</interface>
          </target>=

         </edit>
       </yang-patch>
 
Thanks
--- Alex

--_000_DBC595ED2346914F9F81D17DD5C32B571DCCD960xmbrcdx05ciscoc_-- From nobody Fri Sep 25 21:34:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030881AD366 for ; Fri, 25 Sep 2015 21:34:04 -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 8_gN7kh9xOmN for ; Fri, 25 Sep 2015 21:34:01 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B761AD365 for ; Fri, 25 Sep 2015 21:34:01 -0700 (PDT) Received: by lahh2 with SMTP id h2so115427161lah.0 for ; Fri, 25 Sep 2015 21:33:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WHPOC1dS7LYprPwDY9q8EyOE/Rb4eAxjxj/J1vWuYlQ=; b=jti4A5G6Sf3jWRVA8qoH1DWNLhjrYD6wwi+HP6hM8yRZ8G+/726j7un+ebDC2JhIwT YbKNxqF72vEfWg8hu0zLd73YF0gw5dWqdBbbCV1w9PTMWLaJhHhnAphH05C5Q4hImYhl cKX735RwO9MBOLdXLjOig0tBB2eqVH3ScpJTb50yfu7uPWgB45wMuu8ABvwje9XH0aoE uV7VnS6ozDkR1uSf15d3UjgNmzaWId7UDCenPjrZhuLn1FnZfNnZnnQcOKaDesYhBYhE Vu7ea9+Y0GP3Ve/30Nw6FojtdPjsk92E/s/5FZATxql9a3KejXanU0/mpcbmW6/n2TL2 JxCg== X-Gm-Message-State: ALoCoQlDhOforV1Muqe/6NuN/XcTlh99zbnjbwVEM2CyseCr582Km6MAi1xatY4RwO9oz9AQUOSz MIME-Version: 1.0 X-Received: by 10.25.150.83 with SMTP id y80mr1677145lfd.119.1443242039048; Fri, 25 Sep 2015 21:33:59 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Fri, 25 Sep 2015 21:33:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Sep 2015 21:33:58 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: multipart/alternative; boundary=001a11401a2410124805209ef931 Archived-At: Cc: "Martin Bjorklund $mbjorklu$" , Netconf Subject: Re: [Netconf] YANG patch with XML and Netconf 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: Sat, 26 Sep 2015 04:34:04 -0000 --001a11401a2410124805209ef931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 25, 2015 at 8:25 PM, Alexander Clemm (alex) wrote: > Helo Andy, Martin, Kent, > > > > looking at draft-ietf-netconf-yang-patch-05, I am wondering if you have > examples for YANG-patch with XML encoding. The examples in section D are > all JSON-encoded. > > > > I am wondering specifically about how the XML encoding in YANG-patch > relates to the Netconf encoding of edit-config. I was hoping the two wou= ld > be aligned or even the same, but is this the case? It seems that the > yang-patch way of doing things will require a different encoding of the > payload, meaning you cannot simply take the same =E2=80=9Cedit snippet=E2= =80=9D and use it > both for Netconf and Restconf, instead the content/encoding will depend o= n > the underlying transport, not be agnostic to it. Is this understanding > correct? What is the intention? Do we have some examples? > > > Why would it be the same as just because it is encoded in XML= ? Why would the data model change because it was XML vs. JSON? If you want to use edit-config and the server supports it through RESTCONF: POST /restconf/operations/edit-config ... ... Otherwise just use NETCONF if you want to use Andy > For example, if we have (per the example in RFC 6241) the following > edit-config snippet: > > > > > > > > > > none > > > > > > > > Ethernet0/0 > > > > > > > > > > > > what does the corresponding YANG-patch look like =E2=80=93 something like= this: > (edit-config style) > > > > Accept: application/yang.patch-status+xml > > Content-Type: application/yang.patch+xml > > > > > > my-patch > > > > > > > > > > Ethernet0/0 > > > > > > > > > > > > > > or is it something like this: > > Accept: application/yang.patch-status+xml > > Content-Type: application/yang.patch+xml > > > > > > my-patch > > > > edit1 > > delete > > > > > > Ethernet0/0 > > > > > > > > > > > > Thanks > > --- Alex > --001a11401a2410124805209ef931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 25, 2015 at 8:25 PM, Alexander Clemm (alex) <alex@cisco.com> wrote:

Helo Andy, Martin, Kent,

=C2=A0

looking at draft-ietf-netconf-yang-patch-05, I am wo= ndering if you have examples for YANG-patch with XML encoding.=C2=A0 The ex= amples in section D are all JSON-encoded.=C2=A0

=C2=A0

I am wondering specifically about how the XML encodi= ng in YANG-patch relates to the Netconf encoding of edit-config.=C2=A0 I wa= s hoping the two would be aligned or even the same, but is this the case?= =C2=A0 It seems that the yang-patch way of doing things will require a different encoding of the payload, meaning you canno= t simply take the same =E2=80=9Cedit snippet=E2=80=9D and use it both for N= etconf and Restconf, instead the content/encoding will depend on the underl= ying transport, not be agnostic to it.=C2=A0 Is this understanding correct?=C2=A0 What is the intention?=C2=A0 Do we have some = examples?

=C2=A0

<= /div>

Why would it be the same as <edit-config> ju= st because it is encoded in XML?

Why would the data model change = because it was XML vs. JSON?

If you want to use ed= it-config and the server supports it through RESTCONF:

=C2=A0 =C2=A0POST /restconf/operations/edit-config

=C2=A0 <input>

=C2=A0 =C2=A0 =C2=A0<target> ...= </target>

=C2=A0 =C2=A0 =C2=A0<config>

=C2= =A0 =C2=A0 =C2=A0 =C2=A0...

=C2=A0 =C2=A0 =C2=A0</config>

=C2=A0 </input>

Othe= rwise just use NETCONF if you want to use <edit-config>

Andy

=C2= =A0

For example, if we have (per the example in RFC 6241= ) the following edit-config snippet:=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit-config>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <target>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <runni=
ng/>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </target>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <default-operation=
>none</default-operation>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <config xmlns:xc=
=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <top x=
mlns=3D"http://example.com/schema/1.2/config">

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 <interface xc:operation=3D"delete">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 <name>Ethernet0/0</name>
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0</interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </top&=
gt;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </config>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </edit-config>

=C2=A0
what does the corresponding YANG-patch look like =E2=
=80=93 something like this:=C2=A0 (edit-config style)
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Accept: application/yang.patch-status+x=
ml
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Type: application/yang.patch+xm=
l
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <yang-patch>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <patch-id>my-patch<=
;/patch-id> 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit> 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<config xmlns=
:xc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <top x=
mlns=3D"http://example.com/schema/1.2/config">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 <interface xc:operation=3D"delete">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 <name>Ethernet0/0</name>
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0</interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </top&=
gt;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </config>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </edit>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </yang-patch>=

=C2=A0
or is it something like this:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Accept: application/yang.patch-status+x=
ml
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Type: application/yang.patch+xm=
l
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <yang-patch>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <patch-id>my-patch<=
;/patch-id> 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit> 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit-i=
d>edit1</edit-id>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <operation&g=
t;delete</operation>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <target><=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 <interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 <name>Ethernet0/0</name>
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0</interface>
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</target>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </edit><=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </yang-patch>=

=C2=A0
Thanks

--- Alex

--001a11401a2410124805209ef931-- From nobody Mon Sep 28 02:21:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1121B32B8 for ; Mon, 28 Sep 2015 02:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQbyBSl5VIxv for ; Mon, 28 Sep 2015 02:21: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 EFC781B32B7 for ; Mon, 28 Sep 2015 02:21:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BCB30FD3; Mon, 28 Sep 2015 11:21:49 +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 rPYhJRPaE1SF; Mon, 28 Sep 2015 11:21:48 +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, 28 Sep 2015 11:21:48 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E95920054; Mon, 28 Sep 2015 11:21:48 +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 Dndiwgiv0Iga; Mon, 28 Sep 2015 11:21:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 053932004E; Mon, 28 Sep 2015 11:21:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A1B213768B08; Mon, 28 Sep 2015 11:21:44 +0200 (CEST) Date: Mon, 28 Sep 2015 11:21:43 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20150928092143.GA95769@elstar.local> Mail-Followup-To: Randy Presuhn , "netconf@ietf.org" References: <8271248.1442957431544.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8271248.1442957431544.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] restconf and namespaces and unique module names. 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, 28 Sep 2015 09:21:52 -0000 On Tue, Sep 22, 2015 at 02:30:31PM -0700, Randy Presuhn wrote: > Hi - > > >From: Juergen Schoenwaelder > >Sent: Sep 22, 2015 11:58 AM > >To: Randy Presuhn > >Cc: "netconf@ietf.org" > >Subject: Re: [Netconf] restconf and namespaces and unique module names. > ... > >> >RFC 6020: > >> > > >> > The names of all standard modules and submodules MUST be unique. > >> > Developers of enterprise modules are RECOMMENDED to choose names for > >> > their modules that will have a low probability of colliding with > >> > standard or other enterprise modules, e.g., by using the enterprise > >> > or organization name as a prefix for the module name. > >> > > >> >Apparently, both module names in the example violate this. Note that > >> >module names are used to resolve imports and hence they better are > >> >unique. For the IETF, we can manage that via the IANA registry. For > >> >the other modules, there is a clear recommendation. > >> > >> A couple of questions on the RFC 6020 text cited... > >> > >> (1) is "standard modules" intended to include those from *all* SDOs? > >> > >> (2) "MUST" is normally used in situations where "if you don't > >> do this this way, this protocol/process won't work correctly." > >> If that is indeed so for standard modules, why is it not > >> also true for enterprise modules? That is, what is different > >> about enterprise modules that allows them to operate correctly > >> without the "MUST"? > >> > >> I suspect this language may have been (subconsciously) borrowed from > >> the conventions for SMI module names which, unlike Yang module names, > >> don't show up in the corresponding protocols. > >> > > > >You may propose alternative wording. Yes, the wording has been > >borrowed from SMI specifications and for resolving imports SMI module > >names better are unique as well. Also note that YANG module names only > >show up in the JSON encoding on the wire, not im XML. But they are > >also used to annouce capabilities - so they better be unique, as the > >text says. > > If the JSON encoding will be around for a while, then I'd suggest > the following revision: > > OLD: > The names of all standard modules and submodules MUST be unique. > Developers of enterprise modules are RECOMMENDED to choose names for > their modules that will have a low probability of colliding with > standard or other enterprise modules, e.g., by using the enterprise > or organization name as a prefix for the module name. > > NEW: > The names of all modules and submodules MUST be unique. > Randy, since this proposal affects YANG itself, it would be nice if you can make this suggestion on the NETMOD mailing list so we have the discussion recorded in the right email archive. /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 Sep 28 02:41:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672EB1B32CE for ; Mon, 28 Sep 2015 02:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJvh4zosQBHe for ; Mon, 28 Sep 2015 02:41: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 E65AB1B3209 for ; Mon, 28 Sep 2015 02:40:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B2DD78DC; Mon, 28 Sep 2015 11:40: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 GJdO7xx3JfRa; Mon, 28 Sep 2015 11:40:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Sep 2015 11:40:57 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CB6820053; Mon, 28 Sep 2015 11:40: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 6T21aAcFso0p; Mon, 28 Sep 2015 11:40: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 049522004E; Mon, 28 Sep 2015 11:40:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0EF113768B93; Mon, 28 Sep 2015 11:40:54 +0200 (CEST) Date: Mon, 28 Sep 2015 11:40:54 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20150928094054.GB95769@elstar.local> Mail-Followup-To: Randy Presuhn , netconf@ietf.org References: <7047634.1443021090650.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7047634.1443021090650.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] restconf and namespaces and unique module names. 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, 28 Sep 2015 09:41:01 -0000 On Wed, Sep 23, 2015 at 08:11:30AM -0700, Randy Presuhn wrote: > Hi - > > (1) My question remains: why a "MUST" for "standard" modules but > not enterprise ones? It sounds like you're arguing that a > "SHOULD" or "RECOMMENDED" would suffice in both cases. In a perfect world, module names would be globally unique. This is, however, difficult to guarantee in practice unless we force all modules to be registered with IANA (and even then some people will simply not follow the rules and not register). Within an SDO, it can be possible to guarantee that all module names released by that SDO are unique. > (2) A question of curiousity: what does a client do when it encounters > different servers using different modules of the same name, and > how does it know they are indeed different, using only mandatory > features of the protocol and mandatory-to-implement models? It depends. A smart client can fetch the module information from the server and adapt to what the server implements and if two servers implement 'foo' such a smart client would be able to figure out 'foo' may mean different things. There will, however, be clients that simply assume module 'foo' means module 'foo' everywhere or that resolve imports of 'foo' against a local module library without carefully checking with the server and in this case client and server likely run into failing RPCs since the data models do not match. /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 Sep 28 10:00:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C311ACE6E for ; Mon, 28 Sep 2015 10:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx_1co3qmQ4E for ; Mon, 28 Sep 2015 10:00:21 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 956941ACE7E for ; Mon, 28 Sep 2015 10:00:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mHq95aMVpIOVEnyTU2Sw2Ur2oU2PsXvpsKqMKflkbYWkqwv6vzuBr97olrki3U2s; 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.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZgbmY-0007uh-6A; Mon, 28 Sep 2015 13:00:06 -0400 Received: from 76.254.51.191 by webmail.earthlink.net with HTTP; Mon, 28 Sep 2015 13:00:05 -0400 Message-ID: <14682904.1443459606176.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> Date: Mon, 28 Sep 2015 10:00:05 -0700 (GMT-07:00) From: Randy Presuhn To: Juergen Schoenwaelder 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3edb38f2093d668d3e0989095176e036bb2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.40 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] restconf and namespaces and unique module names. 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, 28 Sep 2015 17:00:23 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Sep 28, 2015 2:40 AM >To: Randy Presuhn >Cc: netconf@ietf.org >Subject: Re: [Netconf] restconf and namespaces and unique module names. > >On Wed, Sep 23, 2015 at 08:11:30AM -0700, Randy Presuhn wrote: >> Hi - >> >> (1) My question remains: why a "MUST" for "standard" modules but >> not enterprise ones? It sounds like you're arguing that a >> "SHOULD" or "RECOMMENDED" would suffice in both cases. > >In a perfect world, module names would be globally unique. This is, >however, difficult to guarantee in practice unless we force all >modules to be registered with IANA (and even then some people will >simply not follow the rules and not register). Within an SDO, it can >be possible to guarantee that all module names released by that SDO >are unique. It's more than a little ironic that there'd be such a basic configuration management problem here, particularly when a well-understood distributed solution has been around for at least thirty years. :-( >> (2) A question of curiousity: what does a client do when it encounters >> different servers using different modules of the same name, and >> how does it know they are indeed different, using only mandatory >> features of the protocol and mandatory-to-implement models? > >It depends. A smart client can fetch the module information from the >server I didn't realize server support for this was mandatory to implement. >and adapt to what the server implements and if two servers >implement 'foo' such a smart client would be able to figure out 'foo' >may mean different things. There will, however, be clients that simply >assume module 'foo' means module 'foo' everywhere or that resolve >imports of 'foo' against a local module library without carefully >checking with the server and in this case client and server likely run >into failing RPCs since the data models do not match. These are the things that worry me. Randy From nobody Mon Sep 28 10:13:05 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442451ACF17 for ; Mon, 28 Sep 2015 10:13:04 -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 aBz_KaECYR1A for ; Mon, 28 Sep 2015 10:13:02 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD2B1ACF1D for ; Mon, 28 Sep 2015 10:13:01 -0700 (PDT) Received: by laclj5 with SMTP id lj5so74085364lac.3 for ; Mon, 28 Sep 2015 10:12:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gsm4eZg4/ZlBjHSl/KX5EwDOUKRdOb4bXbCQlSyhViI=; b=Qdz6PGPg3rfXcYPPcxQFTVMtPXwIB/lnPULbwfu10c5575yvdj54g0lU1vrpHp9o1/ 3QO+V9miUATFN9bXo+XzcQQQV9wVsTYy1CMuU00MNdoRxP/IMds9ji3XO+g30dFHfQzL R1pOEclRYX442dNqH5LnStq19tPqxhsmr3Dr8/REEKPap4BGTKN0/lp/aiol+wIHTflX Pb6T+zdScYepZUx8G7JMZCyA7wBaB3/RuieJwU3F5mZupiGE4xg59UR+JBO/8Rp13sgj QYN3ZbmSMpcf3n92kSK4omLvU+ReQNsD4/9k4ju3onEyGp48LP0PrgpmzBTEvpXxvFZZ Tjrg== X-Gm-Message-State: ALoCoQkafCiluTu05ia2xe//T0KeNb2T377TiKYDuyoR8igiUgAHrf5JsiNeoMMMU2l5m0vPW4KV MIME-Version: 1.0 X-Received: by 10.152.179.40 with SMTP id dd8mr5730859lac.119.1443460379511; Mon, 28 Sep 2015 10:12:59 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Mon, 28 Sep 2015 10:12:59 -0700 (PDT) In-Reply-To: <14682904.1443459606176.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> References: <14682904.1443459606176.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> Date: Mon, 28 Sep 2015 10:12:59 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=001a113433ee2b319b0520d1cf39 Archived-At: Cc: Netconf Subject: Re: [Netconf] restconf and namespaces and unique module names. 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, 28 Sep 2015 17:13:04 -0000 --001a113433ee2b319b0520d1cf39 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 28, 2015 at 10:00 AM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > Hi - > > >From: Juergen Schoenwaelder > >Sent: Sep 28, 2015 2:40 AM > >To: Randy Presuhn > >Cc: netconf@ietf.org > >Subject: Re: [Netconf] restconf and namespaces and unique module names. > > > >On Wed, Sep 23, 2015 at 08:11:30AM -0700, Randy Presuhn wrote: > >> Hi - > >> > >> (1) My question remains: why a "MUST" for "standard" modules but > >> not enterprise ones? It sounds like you're arguing that a > >> "SHOULD" or "RECOMMENDED" would suffice in both cases. > > > >In a perfect world, module names would be globally unique. This is, > >however, difficult to guarantee in practice unless we force all > >modules to be registered with IANA (and even then some people will > >simply not follow the rules and not register). Within an SDO, it can > >be possible to guarantee that all module names released by that SDO > >are unique. > > It's more than a little ironic that there'd be such a basic > configuration management problem here, particularly when > a well-understood distributed solution has been around for > at least thirty years. :-( > > >> (2) A question of curiousity: what does a client do when it encounters > >> different servers using different modules of the same name, and > >> how does it know they are indeed different, using only mandatory > >> features of the protocol and mandatory-to-implement models? > > > >It depends. A smart client can fetch the module information from the > >server > > I didn't realize server support for this was mandatory to implement. > > >and adapt to what the server implements and if two servers > >implement 'foo' such a smart client would be able to figure out 'foo' > >may mean different things. There will, however, be clients that simply > >assume module 'foo' means module 'foo' everywhere or that resolve > >imports of 'foo' against a local module library without carefully > >checking with the server and in this case client and server likely run > >into failing RPCs since the data models do not match. > > These are the things that worry me. > > Doesn't the same situation exist in SNMP-land? The SMIv2 module uses import-by-name, not raw OIDs. XML is more robust than JSON (is so many ways, but here wrt/ namespace). The client or server will only get the namespace in an XML message and then needs to map that namespace to a module name. This will certainly fail (if the wrong 'foo' is used) since the namespace URIs should be different. With JSON, each peer will just think the other is sending invalid data. I agree that this is a serious weakness. We rely on conventions where MUST is more appropriate. But in real operations, the module names need to be unique. If not, it will be reported as a bug to the vendor who created the duplicate module name. > Randy > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a113433ee2b319b0520d1cf39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 28, 2015 at 10:00 AM, Randy Presuhn <<= a href=3D"mailto:randy_presuhn@mindspring.com" target=3D"_blank">randy_pres= uhn@mindspring.com> wrote:

= Hi -

>From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
>Sent: Sep 28, 2015 2:40 AM
>To: Randy Presuhn <r= andy_presuhn@mindspring.com>
>Cc: netconf@ietf.org
>Subject: Re: [Netconf] restconf and namespaces and unique module names.=
>
>On Wed, Sep 23, 2015 at 08:11:30AM -0700, Randy Presuhn wrote:
>> Hi -
>>
>> (1) My question remains: why a "MUST" for "standard= " modules but
>>=C2=A0 =C2=A0 =C2=A0not enterprise ones?=C2=A0 It sounds like you&#= 39;re arguing that a
>>=C2=A0 =C2=A0 =C2=A0"SHOULD" or "RECOMMENDED" w= ould suffice in both cases.
>
>In a perfect world, module names would be globally unique. This is,
>however, difficult to guarantee in practice unless we force all
>modules to be registered with IANA (and even then some people will
>simply not follow the rules and not register). Within an SDO, it can >be possible to guarantee that all module names released by that SDO
>are unique.

It's more than a little ironic that there'd be such a basic
configuration management problem here, particularly when
a well-understood distributed solution has been around for
at least thirty years.=C2=A0 :-(

>> (2) A question of curiousity: what does a client do when it encoun= ters
>>=C2=A0 =C2=A0 =C2=A0different servers using different modules of th= e same name, and
>>=C2=A0 =C2=A0 =C2=A0how does it know they are indeed different, usi= ng only mandatory
>>=C2=A0 =C2=A0 =C2=A0features of the protocol and mandatory-to-imple= ment models?
>
>It depends. A smart client can fetch the module information from the >server

I didn't realize server support for this was mandatory to implement.
>and adapt to what the server implements and if two servers
>implement 'foo' such a smart client would be able to figure out= 'foo'
>may mean different things. There will, however, be clients that simply<= br> >assume module 'foo' means module 'foo' everywhere or th= at resolve
>imports of 'foo' against a local module library without careful= ly
>checking with the server and in this case client and server likely run<= br> >into failing RPCs since the data models do not match.

These are the things that worry me.

Doesn't the same situation exist i= n SNMP-land?

The SMIv2 module uses import-by-name, not raw OIDs.<= /div>

XML is more robust than JSON (is so many ways, but= here wrt/ namespace).

The client or server will only get the nam= espace in an XML message and

then needs to map that namespace to = a module name.=C2=A0 This will certainly

fail (if the wrong '= foo' is used) since the namespace URIs should be different.

<= br>

With JSON, each peer will just think the other is sending inv= alid data.

I agree that this is a serious weakness= .

We rely on conventions where MUST is more appropriate.

But in real operations, the module names need to be unique.

If = not, it will be reported as a bug to the vendor who created

the d= uplicate module name.

=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Randy

Andy

=C2=A0

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

--001a113433ee2b319b0520d1cf39-- From nobody Mon Sep 28 11:17:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAA31B2A80 for ; Mon, 28 Sep 2015 11:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I41EYLJoPSOj for ; Mon, 28 Sep 2015 11:17:10 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2C91B2A7E for ; Mon, 28 Sep 2015 11:17:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iI1H2p+psdejZzSVHqDkOUBAWpmRzT1JO+V/zvUoid1OlV78Zj4NYOEj7rvtAvKo; 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.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Zgcz2-0001Nl-8g for netconf@ietf.org; Mon, 28 Sep 2015 14:17:04 -0400 Received: from 76.254.51.191 by webmail.earthlink.net with HTTP; Mon, 28 Sep 2015 14:17:03 -0400 Message-ID: <10624205.1443464224199.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> Date: Mon, 28 Sep 2015 11:17:03 -0700 (GMT-07:00) From: Randy Presuhn To: Netconf 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed5a92eed3dd10b0397bd0c1be309abfae350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.40 Archived-At: Subject: Re: [Netconf] restconf and namespaces and unique module names. 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, 28 Sep 2015 18:17:12 -0000 Hi - > From: Andy Bierman > Sent: Sep 28, 2015 10:12 AM > To: Randy Presuhn > Cc: Netconf > Subject: Re: [Netconf] restconf and namespaces and unique module names. ... > Doesn't the same situation exist in SNMP-land?The SMIv2 module uses > import-by-name, not raw OIDs. Yes. It's a perfectly avoidable problem that Yang inherited from SMI. The bug was introduced when SMI "subsetted" ASN.1 and failed to preserve the option of referencing modules by OID. However, the problem is much less severe in SNMP-land, since module names don't appear on the wire. In the very few cases where one might be tempted to do such a thing, the module OID is used. It *is* a problem for IMPORTS, but that's only a minor tractable headache, since an outside-the-scope-of-standardization mapping from module names to file names is needed anyway. > XML is more robust than JSON (is so many ways, but here wrt/ > namespace).The client or server will only get the namespace > in an XML message andthen needs to map that namespace to a > module name. This will certainlyfail (if the wrong 'foo' is > used) since the namespace URIs should be different. > > With JSON, each peer will just think the other is sending > invalid data. This is in the *best* case. In the worst case, there might be sufficient syntactic similarity between when the models permit to allow an operation to succeed, even though the intent/semantics understood by the endpoints could be radically different. > I agree that this is a serious weakness.We rely on conventions > where MUST is more appropriate.But in real operations, the module > names need to be unique.If not, it will be reported as a bug to > the vendor who createdthe duplicate module name. Agreed, this is essentially the case for "MUST" for uniqueness of both enterprise and standard modules. When a "MUST" puts vendors or operators in an untenable situation, it's time to revisit the design assumptions of the specification. However, I'm not fully convinced that things are so bad as to require replacement of the naming mechanism, although that would be required to completely eliminate all collisions. I'm more concerned about honesty in specification. Embracing JSON, as you've detailed, brings more serious consequences for collisions. The softest language I could support for module name collisions would be something like "Use of enterprise modules with non-unique names is NOT RECOMMENDED." But I'd still prefer a blanket "MUST be unique", since that's the truth if things are to work correctly. Randy From nobody Mon Sep 28 11:28:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD4D1B2AE6 for ; Mon, 28 Sep 2015 11:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5RmKHtbNrKe for ; Mon, 28 Sep 2015 11:28:47 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514151B2AE5 for ; Mon, 28 Sep 2015 11:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28320; q=dns/txt; s=iport; t=1443464927; x=1444674527; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qkuT0jTnH6Hn1Ffr8J5VyiOYlrw9XSKK9KW8raJH97o=; b=FP6EOqpV124MqEYYppukNlG7S1hlkxkx3F+GpQ/ci14PqRJQ9CpJ3dES b3hIqfJXFa+XfIzkof1J7MCDvDbVacn4lQ7EOxFzhgTuJOmBZIf2E2JLQ 03pdaNBjeBfeCNUr3+dn5QkGZVlM2qTNHNp0kW957e5Qb7b75vkPgS/tO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwAQDUhQlW/4UNJK1egldNVGkGvTkBDYF3hX0CHIEvOBQBAQEBAQEBgQqEJAEBAQQjCkwQAgEIEQQBAQsWBwMCAgIwFAkIAQEEDgUIiCYNtnKUUQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLcIRCGjEGAYJpL4EUBYx/hUODLgGFFIlJRpU9g20RDgEBQoQBcYgcgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,604,1437436800"; d="scan'208,217";a="192537993" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Sep 2015 18:28:45 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t8SISjNu021529 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2015 18:28:45 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 13:28:44 -0500 Received: from xhc-rcd-x07.cisco.com (173.37.183.81) by xch-aln-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 28 Sep 2015 13:28:44 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.194]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0248.002; Mon, 28 Sep 2015 13:28:44 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman Thread-Topic: YANG patch with XML and Netconf edit-config Thread-Index: AdD4CCuxvjUk1rC+SvOyPcAnIocwzAANkxgAAHalviA= Date: Mon, 28 Sep 2015 18:28:44 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.101.220.149] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571DCCF917xmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "Martin Bjorklund $mbjorklu$" , Netconf Subject: Re: [Netconf] YANG patch with XML and Netconf 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, 28 Sep 2015 18:28:50 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571DCCF917xmbrcdx05ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KdGhhbmsgeW91IGZvciB5b3VyIHJlc3BvbnNlLg0KDQoNClNvLCB0aGUgZW5j b2RpbmcgaXMgbGlrZSBpbiB0aGUgc2Vjb25kIGFsdGVybmF0aXZlIOKAkyBlLmcuIHNvbWV0aGlu ZyBsaWtlDQoNCiAgICAgIDx5YW5nLXBhdGNoPg0KDQogICAgICAgIDxwYXRjaC1pZD5teS1wYXRj aDwvcGF0Y2gtaWQ+DQoNCiAgICAgICAgPGVkaXQ+DQoNCiAgICAgICAgICA8ZWRpdC1pZD5lZGl0 MTwvZWRpdC1pZD4NCg0KICAgICAgICAgIDxvcGVyYXRpb24+ZGVsZXRlPC9vcGVyYXRpb24+DQoN CiAgICAgICAgICA8dGFyZ2V0Pg0KDQogICAgICAgICAgICAgPGludGVyZmFjZT4NCg0KICAgICAg ICAgICAgICAgPG5hbWU+RXRoZXJuZXQwLzA8L25hbWU+DQoNCiAgICAgICAgICAgICA8L2ludGVy ZmFjZT4NCg0KICAgICAgICAgIDwvdGFyZ2V0Pg0KDQogICAgICAgICA8L2VkaXQ+DQoNCiAgICAg ICA8L3lhbmctcGF0Y2g+DQoNCihJdCB3b3VsZCBzdGlsbCBiZSBnb29kIHRvIGFkZCBhbiBleGFt cGxlIHRvIHRoZSBhcHBlbmRpeCBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuKSAg U28sIGNsZWFybHkgZGlmZmVyZW50IGZyb20gd2hhdCB5b3UgaGF2ZSBpbiBhbiBlZGl0LWNvbmZp Zy4NCg0KTXkgcmVhc29uIGZvciBhc2tpbmcgd2FzIHRoYXQgaXQgc2VlbXMgeW91IGNvdWxkIGFj Y29tcGxpc2ggZXNzZW50aWFsbHkgdGhlIHNhbWUgdGhyb3VnaCBlaXRoZXIgYSB5YW5nLXBhdGNo LCBvciB0aHJvdWdoIGFuIGVkaXQtY29uZmlnLiAgSWYgdGhhdOKAmXMgdGhlIGNhc2UsIEkgd2Fz IHdvbmRlcmluZyBpZiB0aGUgd2F5IHRob3NlIG9wZXJhdGlvbnMgYXJlIGVuY29kZWQgaW4gWE1M IGJlIGFsaWduZWQ/ICAgIChDbGVhcmx5LCB0aGUgZGF0YSBtb2RlbCBpcyB0aGUgc2FtZS4pDQoN ClRoYW5rcw0KLS0tIEFsZXgNCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1h d29ya3MuY29tXQ0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTUgOTozNCBQTQ0KVG86 IEFsZXhhbmRlciBDbGVtbSAoYWxleCkgPGFsZXhAY2lzY28uY29tPg0KQ2M6IE1hcnRpbiBCam9y a2x1bmQgKG1iam9ya2x1KSA8bWJqb3JrbHVAY2lzY28uY29tPjsgS2VudCBXYXRzZW4gPGt3YXRz ZW5AanVuaXBlci5uZXQ+OyBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFlBTkcgcGF0Y2ggd2l0aCBYTUwgYW5kIE5ldGNvbmYgZWRpdC1jb25maWcNCg0KDQoNCk9uIEZy aSwgU2VwIDI1LCAyMDE1IGF0IDg6MjUgUE0sIEFsZXhhbmRlciBDbGVtbSAoYWxleCkgPGFsZXhA Y2lzY28uY29tPG1haWx0bzphbGV4QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGVsbyBBbmR5LCBNYXJ0 aW4sIEtlbnQsDQoNCmxvb2tpbmcgYXQgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcGF0Y2gtMDUs IEkgYW0gd29uZGVyaW5nIGlmIHlvdSBoYXZlIGV4YW1wbGVzIGZvciBZQU5HLXBhdGNoIHdpdGgg WE1MIGVuY29kaW5nLiAgVGhlIGV4YW1wbGVzIGluIHNlY3Rpb24gRCBhcmUgYWxsIEpTT04tZW5j b2RlZC4NCg0KSSBhbSB3b25kZXJpbmcgc3BlY2lmaWNhbGx5IGFib3V0IGhvdyB0aGUgWE1MIGVu Y29kaW5nIGluIFlBTkctcGF0Y2ggcmVsYXRlcyB0byB0aGUgTmV0Y29uZiBlbmNvZGluZyBvZiBl ZGl0LWNvbmZpZy4gIEkgd2FzIGhvcGluZyB0aGUgdHdvIHdvdWxkIGJlIGFsaWduZWQgb3IgZXZl biB0aGUgc2FtZSwgYnV0IGlzIHRoaXMgdGhlIGNhc2U/ICBJdCBzZWVtcyB0aGF0IHRoZSB5YW5n LXBhdGNoIHdheSBvZiBkb2luZyB0aGluZ3Mgd2lsbCByZXF1aXJlIGEgZGlmZmVyZW50IGVuY29k aW5nIG9mIHRoZSBwYXlsb2FkLCBtZWFuaW5nIHlvdSBjYW5ub3Qgc2ltcGx5IHRha2UgdGhlIHNh bWUg4oCcZWRpdCBzbmlwcGV04oCdIGFuZCB1c2UgaXQgYm90aCBmb3IgTmV0Y29uZiBhbmQgUmVz dGNvbmYsIGluc3RlYWQgdGhlIGNvbnRlbnQvZW5jb2Rpbmcgd2lsbCBkZXBlbmQgb24gdGhlIHVu ZGVybHlpbmcgdHJhbnNwb3J0LCBub3QgYmUgYWdub3N0aWMgdG8gaXQuICBJcyB0aGlzIHVuZGVy c3RhbmRpbmcgY29ycmVjdD8gIFdoYXQgaXMgdGhlIGludGVudGlvbj8gIERvIHdlIGhhdmUgc29t ZSBleGFtcGxlcz8NCg0KDQoNCldoeSB3b3VsZCBpdCBiZSB0aGUgc2FtZSBhcyA8ZWRpdC1jb25m aWc+IGp1c3QgYmVjYXVzZSBpdCBpcyBlbmNvZGVkIGluIFhNTD8NCldoeSB3b3VsZCB0aGUgZGF0 YSBtb2RlbCBjaGFuZ2UgYmVjYXVzZSBpdCB3YXMgWE1MIHZzLiBKU09OPw0KDQpJZiB5b3Ugd2Fu dCB0byB1c2UgZWRpdC1jb25maWcgYW5kIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgaXQgdGhyb3VnaCBS RVNUQ09ORjoNCg0KICAgUE9TVCAvcmVzdGNvbmYvb3BlcmF0aW9ucy9lZGl0LWNvbmZpZw0KDQog IDxpbnB1dD4NCiAgICAgPHRhcmdldD4gLi4uIDwvdGFyZ2V0Pg0KICAgICA8Y29uZmlnPg0KICAg ICAgIC4uLg0KICAgICA8L2NvbmZpZz4NCiAgPC9pbnB1dD4NCg0KDQpPdGhlcndpc2UganVzdCB1 c2UgTkVUQ09ORiBpZiB5b3Ugd2FudCB0byB1c2UgPGVkaXQtY29uZmlnPg0KDQoNCkFuZHkNCg0K DQoNCkZvciBleGFtcGxlLCBpZiB3ZSBoYXZlIChwZXIgdGhlIGV4YW1wbGUgaW4gUkZDIDYyNDEp IHRoZSBmb2xsb3dpbmcgZWRpdC1jb25maWcgc25pcHBldDoNCg0KICAgICAgIDxlZGl0LWNvbmZp Zz4NCg0KICAgICAgICAgPHRhcmdldD4NCg0KICAgICAgICAgICA8cnVubmluZy8+DQoNCiAgICAg ICAgIDwvdGFyZ2V0Pg0KDQogICAgICAgICA8ZGVmYXVsdC1vcGVyYXRpb24+bm9uZTwvZGVmYXVs dC1vcGVyYXRpb24+DQoNCiAgICAgICAgIDxjb25maWcgeG1sbnM6eGM9InVybjppZXRmOnBhcmFt czp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQoNCiAgICAgICAgICAgPHRvcCB4bWxucz0iaHR0 cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4NCg0KICAgICAgICAgICAgIDxpbnRl cmZhY2UgeGM6b3BlcmF0aW9uPSJkZWxldGUiPg0KDQogICAgICAgICAgICAgICA8bmFtZT5FdGhl cm5ldDAvMDwvbmFtZT4NCg0KICAgICAgICAgICAgIDwvaW50ZXJmYWNlPg0KDQogICAgICAgICAg IDwvdG9wPg0KDQogICAgICAgICA8L2NvbmZpZz4NCg0KICAgICAgIDwvZWRpdC1jb25maWc+DQoN CndoYXQgZG9lcyB0aGUgY29ycmVzcG9uZGluZyBZQU5HLXBhdGNoIGxvb2sgbGlrZSDigJMgc29t ZXRoaW5nIGxpa2UgdGhpczogIChlZGl0LWNvbmZpZyBzdHlsZSkNCg0KDQogICAgICBBY2NlcHQ6 IGFwcGxpY2F0aW9uL3lhbmcucGF0Y2gtc3RhdHVzK3htbA0KDQogICAgICBDb250ZW50LVR5cGU6 IGFwcGxpY2F0aW9uL3lhbmcucGF0Y2greG1sDQoNCg0KDQogICAgICA8eWFuZy1wYXRjaD4NCg0K ICAgICAgICA8cGF0Y2gtaWQ+bXktcGF0Y2g8L3BhdGNoLWlkPg0KDQogICAgICAgIDxlZGl0Pg0K DQogICAgICAgICA8Y29uZmlnIHhtbG5zOnhjPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv bmY6YmFzZToxLjAiPg0KDQogICAgICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNv bS9zY2hlbWEvMS4yL2NvbmZpZyI+DQoNCiAgICAgICAgICAgICA8aW50ZXJmYWNlIHhjOm9wZXJh dGlvbj0iZGVsZXRlIj4NCg0KICAgICAgICAgICAgICAgPG5hbWU+RXRoZXJuZXQwLzA8L25hbWU+ DQoNCiAgICAgICAgICAgICA8L2ludGVyZmFjZT4NCg0KICAgICAgICAgICA8L3RvcD4NCg0KICAg ICAgICAgPC9jb25maWc+DQoNCiAgICAgICAgPC9lZGl0Pg0KDQogICAgICAgPC95YW5nLXBhdGNo Pg0KDQpvciBpcyBpdCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQogICAgICBBY2NlcHQ6IGFwcGxp Y2F0aW9uL3lhbmcucGF0Y2gtc3RhdHVzK3htbA0KDQogICAgICBDb250ZW50LVR5cGU6IGFwcGxp Y2F0aW9uL3lhbmcucGF0Y2greG1sDQoNCg0KDQogICAgICA8eWFuZy1wYXRjaD4NCg0KICAgICAg ICA8cGF0Y2gtaWQ+bXktcGF0Y2g8L3BhdGNoLWlkPg0KDQogICAgICAgIDxlZGl0Pg0KDQogICAg ICAgICAgPGVkaXQtaWQ+ZWRpdDE8L2VkaXQtaWQ+DQoNCiAgICAgICAgICA8b3BlcmF0aW9uPmRl bGV0ZTwvb3BlcmF0aW9uPg0KDQogICAgICAgICAgPHRhcmdldD4NCg0KICAgICAgICAgICAgIDxp bnRlcmZhY2U+DQoNCiAgICAgICAgICAgICAgIDxuYW1lPkV0aGVybmV0MC8wPC9uYW1lPg0KDQog ICAgICAgICAgICAgPC9pbnRlcmZhY2U+DQoNCiAgICAgICAgICA8L3RhcmdldD4NCg0KICAgICAg ICAgPC9lZGl0Pg0KDQogICAgICAgPC95YW5nLXBhdGNoPg0KDQpUaGFua3MNCi0tLSBBbGV4DQoN Cg== --_000_DBC595ED2346914F9F81D17DD5C32B571DCCF917xmbrcdx05ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PnRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25zZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5TbywgdGhlIGVuY29kaW5nIGlzIGxpa2UgaW4gdGhlIHNlY29uZCBhbHRlcm5hdGl2 ZSDigJMgZS5nLiBzb21ldGhpbmcgbGlrZTwvc3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jmx0O3lhbmctcGF0Y2gmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtwYXRjaC1pZCZndDtteS1w YXRjaCZsdDsvcGF0Y2gtaWQmZ3Q7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtlZGl0Jmd0OyA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7ZWRpdC1pZCZndDtlZGl0MSZsdDsvZWRpdC1pZCZndDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O29wZXJhdGlvbiZndDtkZWxldGUmbHQ7L29wZXJhdGlv biZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3RhcmdldCZndDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2ludGVyZmFjZSZndDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O25hbWUmZ3Q7RXRoZXJuZXQw LzAmbHQ7L25hbWUmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZs dDsvaW50ZXJmYWNlJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L3RhcmdldCZndDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0Oy9lZGl0Jmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L3lhbmctcGF0Y2gmZ3Q7PG86cD48L286 cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+KEl0IHdvdWxkIHN0aWxsIGJlIGdvb2QgdG8g YWRkIGFuIGV4YW1wbGUgdG8gdGhlIGFwcGVuZGl4IGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRo ZSBkcmFmdC4pJm5ic3A7IFNvLCBjbGVhcmx5IGRpZmZlcmVudCBmcm9tIHdoYXQgeW91IGhhdmUg aW4gYW4gZWRpdC1jb25maWcuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPk15IHJlYXNvbiBmb3IgYXNraW5nIHdhcyB0aGF0IGl0IHNlZW1zIHlvdSBj b3VsZCBhY2NvbXBsaXNoIGVzc2VudGlhbGx5IHRoZSBzYW1lIHRocm91Z2ggZWl0aGVyIGEgeWFu Zy1wYXRjaCwgb3IgdGhyb3VnaCBhbiBlZGl0LWNvbmZpZy4mbmJzcDsgSWYgdGhhdOKAmXMgdGhl IGNhc2UsDQogSSB3YXMgd29uZGVyaW5nIGlmIHRoZSB3YXkgdGhvc2Ugb3BlcmF0aW9ucyBhcmUg ZW5jb2RlZCBpbiBYTUwgYmUgYWxpZ25lZD8gJm5ic3A7Jm5ic3A7Jm5ic3A7KENsZWFybHksIHRo ZSBkYXRhIG1vZGVsIGlzIHRoZSBzYW1lLikmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tLSBBbGV4PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBGcmlkYXksIFNlcHRlbWJlciAyNSwgMjAxNSA5OjM0IFBNPGJyPg0KPGI+VG86 PC9iPiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpICZsdDthbGV4QGNpc2NvLmNvbSZndDs8YnI+DQo8 Yj5DYzo8L2I+IE1hcnRpbiBCam9ya2x1bmQgKG1iam9ya2x1KSAmbHQ7bWJqb3JrbHVAY2lzY28u Y29tJmd0OzsgS2VudCBXYXRzZW4gJmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7OyBOZXRjb25m ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogWUFORyBw YXRjaCB3aXRoIFhNTCBhbmQgTmV0Y29uZiBlZGl0LWNvbmZpZzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZyaSwgU2VwIDI1LCAyMDE1IGF0IDg6MjUgUE0sIEFsZXhhbmRlciBDbGVtbSAo YWxleCkgJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmFsZXhAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlbG8gQW5keSwgTWFydGlu LCBLZW50LA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5sb29raW5nIGF0IGRyYWZ0LWll dGYtbmV0Y29uZi15YW5nLXBhdGNoLTA1LCBJIGFtIHdvbmRlcmluZyBpZiB5b3UgaGF2ZSBleGFt cGxlcyBmb3IgWUFORy1wYXRjaCB3aXRoIFhNTCBlbmNvZGluZy4mbmJzcDsgVGhlIGV4YW1wbGVz IGluIHNlY3Rpb24gRCBhcmUgYWxsIEpTT04tZW5jb2RlZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBhbSB3b25kZXJpbmcgc3BlY2lmaWNhbGx5IGFib3V0IGhvdyB0aGUg WE1MIGVuY29kaW5nIGluIFlBTkctcGF0Y2ggcmVsYXRlcyB0byB0aGUgTmV0Y29uZiBlbmNvZGlu ZyBvZiBlZGl0LWNvbmZpZy4mbmJzcDsgSSB3YXMgaG9waW5nIHRoZSB0d28gd291bGQgYmUgYWxp Z25lZCBvciBldmVuIHRoZSBzYW1lLCBidXQNCiBpcyB0aGlzIHRoZSBjYXNlPyZuYnNwOyBJdCBz ZWVtcyB0aGF0IHRoZSB5YW5nLXBhdGNoIHdheSBvZiBkb2luZyB0aGluZ3Mgd2lsbCByZXF1aXJl IGEgZGlmZmVyZW50IGVuY29kaW5nIG9mIHRoZSBwYXlsb2FkLCBtZWFuaW5nIHlvdSBjYW5ub3Qg c2ltcGx5IHRha2UgdGhlIHNhbWUg4oCcZWRpdCBzbmlwcGV04oCdIGFuZCB1c2UgaXQgYm90aCBm b3IgTmV0Y29uZiBhbmQgUmVzdGNvbmYsIGluc3RlYWQgdGhlIGNvbnRlbnQvZW5jb2Rpbmcgd2ls bCBkZXBlbmQNCiBvbiB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQsIG5vdCBiZSBhZ25vc3RpYyB0 byBpdC4mbmJzcDsgSXMgdGhpcyB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/Jm5ic3A7IFdoYXQgaXMg dGhlIGludGVudGlvbj8mbmJzcDsgRG8gd2UgaGF2ZSBzb21lIGV4YW1wbGVzPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldoeSB3b3VsZCBpdCBiZSB0aGUgc2FtZSBhcyAmbHQ7ZWRpdC1jb25maWcmZ3Q7IGp1c3QgYmVj YXVzZSBpdCBpcyBlbmNvZGVkIGluIFhNTD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSB3b3VsZCB0aGUgZGF0YSBtb2RlbCBjaGFuZ2UgYmVj YXVzZSBpdCB3YXMgWE1MIHZzLiBKU09OPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3Ugd2FudCB0byB1c2UgZWRpdC1jb25maWcgYW5k IHRoZSBzZXJ2ZXIgc3VwcG9ydHMgaXQgdGhyb3VnaCBSRVNUQ09ORjo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1BPU1Qg L3Jlc3Rjb25mL29wZXJhdGlvbnMvZWRpdC1jb25maWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZsdDtpbnB1dCZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0O3RhcmdldCZndDsgLi4uICZsdDsvdGFyZ2V0Jmd0OzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7Y29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Li4uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyZsdDsvY29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZsdDsvaW5wdXQmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3RoZXJ3aXNlIGp1c3QgdXNlIE5FVENP TkYgaWYgeW91IHdhbnQgdG8gdXNlICZsdDtlZGl0LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Rm9yIGV4YW1wbGUsIGlmIHdlIGhhdmUgKHBlciB0aGUgZXhhbXBsZSBpbiBS RkMgNjI0MSkgdGhlIGZvbGxvd2luZyBlZGl0LWNvbmZpZyBzbmlwcGV0OiZuYnNwOw0KPG86cD48 L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZsdDtlZGl0LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3RhcmdldCZndDs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3J1bm5pbmcvJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7 L3RhcmdldCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2RlZmF1bHQtb3BlcmF0aW9uJmd0O25vbmUm bHQ7L2RlZmF1bHQtb3BlcmF0aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y29uZmlnIHhtbG5z OnhjPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyZn dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3RvcCB4bWxucz0mcXVvdDs8YSBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWc8L2E+JnF1b3Q7Jmd0OzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aW50ZXJmYWNlIHhjOm9wZXJhdGlv bj0mcXVvdDtkZWxldGUmcXVvdDsmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtuYW1lJmd0O0V0aGVybmV0MC8wJmx0Oy9uYW1lJmd0Ozxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L2ludGVyZmFjZSZndDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy90b3AmZ3Q7PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDsvY29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2VkaXQtY29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj53aGF0IGRvZXMgdGhlIGNvcnJlc3BvbmRpbmcgWUFORy1wYXRjaCBsb29rIGxp a2Ug4oCTIHNvbWV0aGluZyBsaWtlIHRoaXM6Jm5ic3A7IChlZGl0LWNvbmZpZyBzdHlsZSk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2NlcHQ6IGFwcGxpY2F0aW9u L3lhbmcucGF0Y2gtc3RhdHVzJiM0Mzt4bWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi95YW5nLnBh dGNoJiM0Mzt4bWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3lhbmctcGF0Y2gmZ3Q7 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDtwYXRjaC1pZCZndDtteS1wYXRjaCZsdDsvcGF0Y2gtaWQmZ3Q7IDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZsdDtlZGl0Jmd0OyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7Y29uZmlnIHht bG5zOnhjPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90 OyZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3RvcCB4bWxucz0mcXVvdDs8YSBo cmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWc8L2E+JnF1b3Q7Jmd0OzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aW50ZXJmYWNlIHhjOm9wZXJh dGlvbj0mcXVvdDtkZWxldGUmcXVvdDsmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtuYW1lJmd0O0V0aGVybmV0MC8wJmx0Oy9uYW1lJmd0 OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L2ludGVyZmFjZSZn dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy90b3AmZ3Q7PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDsvY29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2VkaXQmZ3Q7PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsveWFuZy1wYXRj aCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+b3IgaXMgaXQgc29tZXRoaW5nIGxp a2UgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEFjY2VwdDogYXBwbGljYXRpb24veWFuZy5wYXRjaC1zdGF0dXMmIzQzO3htbDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb250ZW50LVR5 cGU6IGFwcGxpY2F0aW9uL3lhbmcucGF0Y2gmIzQzO3htbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7eWFuZy1wYXRjaCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3BhdGNoLWlkJmd0O215LXBhdGNo Jmx0Oy9wYXRjaC1pZCZndDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2VkaXQmZ3Q7IDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZsdDtlZGl0LWlkJmd0O2VkaXQxJmx0Oy9lZGl0LWlkJmd0OzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7b3BlcmF0aW9uJmd0O2RlbGV0ZSZsdDsvb3BlcmF0aW9uJmd0 OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7dGFyZ2V0Jmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aW50ZXJmYWNlJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bmFtZSZndDtFdGhlcm5ldDAvMCZs dDsvbmFtZSZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy9p bnRlcmZhY2UmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvdGFyZ2V0Jmd0OzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbHQ7L2VkaXQmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsveWFuZy1wYXRjaCZndDs8bzpwPjwvbzpwPjwv cHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLS0gQWxleDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBC595ED2346914F9F81D17DD5C32B571DCCF917xmbrcdx05ciscoc_-- From nobody Mon Sep 28 11:46:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506E31B2B70 for ; Mon, 28 Sep 2015 11:46:46 -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 Axl2idCDvTVP for ; Mon, 28 Sep 2015 11:46:43 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A431B2B6E for ; Mon, 28 Sep 2015 11:46:43 -0700 (PDT) Received: by laclj5 with SMTP id lj5so76955460lac.3 for ; Mon, 28 Sep 2015 11:46: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=ORKYJjOpPTS+XNMHQgeL5oJbLtH60S9DlUeR95rJiY0=; b=f0721lXflUrcg+XFGQ8aecGKOVZIEdPPRd4Lnxb3VSFwqy6zUHkcbY07RaCK6xVfqk zdaxyEqG2i0AfQgsbFFR/NAoSQnuXRxpEkqFyR2fi0FpoV7Qa036Ej+ynH0X7oclpngd NKKfchOGIj+hh3U1AAmHylN0W40xwgo43RPlKdwhUu8OgmVB3QPEOxZypqDqVH5apv9L w9/wl90/DPHWlatxQWSd/kBJpmU2MLdNr7x6WYRPFmselsn4Z6CnjaEGamHtup24Qdi2 3bwgEYwoMMsaxnMz5m7eTtAnW3QD7m8qH9Bdv5wF4U0V7DNL6WpZo+qbJcAiqqf7JrHs v+FQ== X-Gm-Message-State: ALoCoQlXIwNcC4aF7jw/QgS0XUHFzwT+ZN+soFXE5vMf13Kd3vq/IcZa1AW4aRwklV5JQjzmQ5sG MIME-Version: 1.0 X-Received: by 10.25.155.75 with SMTP id d72mr3355975lfe.33.1443466001101; Mon, 28 Sep 2015 11:46:41 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Mon, 28 Sep 2015 11:46:41 -0700 (PDT) In-Reply-To: References:

Date: Mon, 28 Sep 2015 11:46:41 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: multipart/alternative; boundary=001a11401bd23dd4ae0520d31ee6 Archived-At: Cc: "Martin Bjorklund $mbjorklu$" , Netconf Subject: Re: [Netconf] YANG patch with XML and Netconf 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, 28 Sep 2015 18:46:46 -0000 --001a11401bd23dd4ae0520d31ee6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 28, 2015 at 11:28 AM, Alexander Clemm (alex) wrote: > Hi Andy, > > > > thank you for your response. > > > > So, the encoding is like in the second alternative =E2=80=93 e.g. somethi= ng like ' > > It follows the schema in ietf-yang-patch.yang > > > my-patch > > > > edit1 > > delete > > > > > > Ethernet0/0 > > > > > > > > > > > > (It would still be good to add an example to the appendix in the next > revision of the draft.) So, clearly different from what you have in an > edit-config. > > > > My reason for asking was that it seems you could accomplish essentially > the same through either a yang-patch, or through an edit-config. If that= =E2=80=99s > the case, I was wondering if the way those operations are encoded in XML = be > aligned? (Clearly, the data model is the same.) > > > There are examples in YANG Patch, appendix D. > Thanks > > --- Alex > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Friday, September 25, 2015 9:34 PM > *To:* Alexander Clemm (alex) > *Cc:* Martin Bjorklund (mbjorklu) ; Kent Watsen < > kwatsen@juniper.net>; Netconf > *Subject:* Re: YANG patch with XML and Netconf edit-config > > > > > > > > On Fri, Sep 25, 2015 at 8:25 PM, Alexander Clemm (alex) > wrote: > > Helo Andy, Martin, Kent, > > > > looking at draft-ietf-netconf-yang-patch-05, I am wondering if you have > examples for YANG-patch with XML encoding. The examples in section D are > all JSON-encoded. > > > > I am wondering specifically about how the XML encoding in YANG-patch > relates to the Netconf encoding of edit-config. I was hoping the two wou= ld > be aligned or even the same, but is this the case? It seems that the > yang-patch way of doing things will require a different encoding of the > payload, meaning you cannot simply take the same =E2=80=9Cedit snippet=E2= =80=9D and use it > both for Netconf and Restconf, instead the content/encoding will depend o= n > the underlying transport, not be agnostic to it. Is this understanding > correct? What is the intention? Do we have some examples? > > > > > > > > Why would it be the same as just because it is encoded in > XML? > > Why would the data model change because it was XML vs. JSON? > > > > If you want to use edit-config and the server supports it through RESTCON= F: > > > > POST /restconf/operations/edit-config > > > > > > ... > > > > ... > > > > > > > > > > Otherwise just use NETCONF if you want to use > > > > > > Andy > > > > > > > > For example, if we have (per the example in RFC 6241) the following > edit-config snippet: > > > > > > > > > > none > > > > > > > > Ethernet0/0 > > > > > > > > > > > > what does the corresponding YANG-patch look like =E2=80=93 something like= this: > (edit-config style) > > > > Accept: application/yang.patch-status+xml > > Content-Type: application/yang.patch+xml > > > > > > my-patch > > > > > > > > > > Ethernet0/0 > > > > > > > > > > > > > > or is it something like this: > > Accept: application/yang.patch-status+xml > > Content-Type: application/yang.patch+xml > > > > > > my-patch > > > > edit1 > > delete > > > > > > Ethernet0/0 > > > > > > > > > > > > Thanks > > --- Alex > > > --001a11401bd23dd4ae0520d31ee6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 28, 2015 at 11:28 AM, Alexander Clemm (alex) <alex@cisco.com<= /a>> wrote:

Hi Andy,

=C2=A0

thank you for your response.=C2=A0

=C2=A0
So, the encoding is like in the second alternative =E2=
=80=93 e.g. something like=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 '
=

It follows the = schema in ietf-yang-patch.yang

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<yang-patch>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <patch-id>my-patch<=
;/patch-id> 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit> 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit-i=
d>edit1</edit-id>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <operation&g=
t;delete</operation>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <target><=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 <interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 <name>Ethernet0/0</name>
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0</interface>
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</target>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </edit><=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </yang-patch>=

=C2=A0
(It would still be good to add an exa=
mple to the appendix in the next revision of the draft.)=C2=A0 So, clearly =
different from what you have in an edit-config.=C2=A0

=C2=A0
My reason for asking was that it seem=
s you could accomplish essentially the same through either a yang-patch, or=
 through an edit-config.=C2=A0 If that=E2=80=99s the case,
 I was wondering if the way those operations are encoded in XML be aligned?=
 =C2=A0=C2=A0=C2=A0(Clearly, the data model is the same.)=C2=A0

=C2=A0

<= /blockquote>

There are examples in YANG P= atch, appendix D.

=C2=A0

Thanks

--- Alex

Andy
=C2=A0

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, September 25, 2015 9:34 PM
To: Alexander Clemm (alex) <alex@cisco.com>
Cc: Martin Bjorklund (mbjorklu) <mbjorklu@cisco.com>; Kent Watsen <kwatsen@juniper.net&g= t;; Netconf <netco= nf@ietf.org>
Subject: Re: YANG patch with XML and Netconf edit-config

=C2=A0

=C2=A0

=C2=A0

On Fri, Sep 25, 2015 at 8:25 PM, Alexander Clemm (al= ex) <alex@cisco.com<= /a>> wrote:

Helo Andy, Martin, Kent,

=C2=A0

looking at draft-ietf-netconf-yang-patch-05, I am wo= ndering if you have examples for YANG-patch with XML encoding.=C2=A0 The ex= amples in section D are all JSON-encoded.=C2=A0

=C2=A0

I am wondering specifically about how the XML encodi= ng in YANG-patch relates to the Netconf encoding of edit-config.=C2=A0 I wa= s hoping the two would be aligned or even the same, but is this the case?=C2=A0 It seems that the yang-patch way of doing things w= ill require a different encoding of the payload, meaning you cannot simply = take the same =E2=80=9Cedit snippet=E2=80=9D and use it both for Netconf an= d Restconf, instead the content/encoding will depend on the underlying transport, not be agnostic to it.=C2=A0 Is this understa= nding correct?=C2=A0 What is the intention?=C2=A0 Do we have some examples?=

=C2=A0

=C2=A0

=C2=A0

Why would it be the same as <edit-config> just= because it is encoded in XML?

Why would the data model change because it was XML v= s. JSON?

=C2=A0

If you want to use edit-config and the server suppor= ts it through RESTCONF:

=C2=A0

=C2=A0 =C2=A0POST /restconf/operations/edit-config

=C2=A0

=C2=A0 <input>

=C2=A0 =C2=A0 =C2=A0<target> ... </target&g= t;

=C2=A0 =C2=A0 =C2=A0<config>

=C2=A0 =C2=A0 =C2=A0 =C2=A0...

=C2=A0 =C2=A0 =C2=A0</config>

=C2=A0 </input>

=C2=A0

=C2=A0

Otherwise just use NETCONF if you want to use <ed= it-config>

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

For example, if we have (per the example in RFC 6241= ) the following edit-config snippet:=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit-config>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <target>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <runni= ng/>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </target>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <default-operation= >none</default-operation>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <config xmlns:xc= =3D"urn:ietf:params:xml:ns:netconf:base:1.0">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <top x= mlns=3D"http://example.com/schema/1.2/config">

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <interface xc:operation=3D"delete">

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <name>Ethernet0/0</name>

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0</interface>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </top&= gt;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </config>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </edit-config>

=C2=A0

what does the corresponding YANG-patch look like =E2= =80=93 something like this:=C2=A0 (edit-config style)

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Accept: application/yang.patch-status+x= ml

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Type: application/yang.patch+xm= l

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <yang-patch>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <patch-id>my-patch<= ;/patch-id>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<config xmlns= :xc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <top x= mlns=3D"http://example.com/schema/1.2/config">

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <interface xc:operation=3D"delete">

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <name>Ethernet0/0</name>

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0</interface>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </top&= gt;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </config>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </edit>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </yang-patch>=

=C2=A0

or is it something like this:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Accept: application/yang.patch-status+x= ml

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Type: application/yang.patch+xm= l

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <yang-patch>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <patch-id>my-patch<= ;/patch-id>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<edit-i= d>edit1</edit-id>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <operation&g= t;delete</operation>

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <interface>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <name>Ethernet0/0</name>

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0</interface>

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</target>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </edit><= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </yang-patch>=

=C2=A0

Thanks

--- Alex=

=C2=A0

--001a11401bd23dd4ae0520d31ee6-- From nobody Mon Sep 28 11:46:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6DD1B2B54 for ; Mon, 28 Sep 2015 11:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1fJJlrS_gst for ; Mon, 28 Sep 2015 11:46:53 -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 DD50C1B2B76 for ; Mon, 28 Sep 2015 11:46:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7F17BE75; Mon, 28 Sep 2015 20:46:51 +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 xSZMJIGehtKO; Mon, 28 Sep 2015 20:46:50 +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, 28 Sep 2015 20:46:50 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAF3F20053; Mon, 28 Sep 2015 20:46:50 +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 IE1tU8T855us; Mon, 28 Sep 2015 20:46:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA52C2004E; Mon, 28 Sep 2015 20:46:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E00DF3768FF6; Mon, 28 Sep 2015 20:46:48 +0200 (CEST) Date: Mon, 28 Sep 2015 20:46:47 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20150928184647.GA97040@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , Andy Bierman , "Martin Bjorklund (mbjorklu)" , Netconf References:

Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Martin Bjorklund $mbjorklu$" , Netconf Subject: Re: [Netconf] YANG patch with XML and Netconf edit-config 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, 28 Sep 2015 18:46:57 -0000 On Mon, Sep 28, 2015 at 06:28:44PM +0000, Alexander Clemm (alex) wrote: > > My reason for asking was that it seems you could accomplish essentially the same through either a yang-patch, or through an edit-config. If that’s the case, I was wondering if the way those operations are encoded in XML be aligned? (Clearly, the data model is the same.) > While yang-patch and edit-config can functionally do the same, they have little in common how they work and this is by design and not by accident. I personally think that having yang-patch (not sure I like the name but I do not have a better proposal) defined so that it is works with both RESTCONF and NETCONF would be desirable. It is not clear to me how the configuration datastore, the so called target datastore, is selected. /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 Sep 28 12:03:44 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2831B2BBA for ; Mon, 28 Sep 2015 12:03:43 -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 0nDrrVeHdEi8 for ; Mon, 28 Sep 2015 12:03:41 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FA01B2B9F for ; Mon, 28 Sep 2015 12:03:41 -0700 (PDT) Received: by laclj5 with SMTP id lj5so77471738lac.3 for ; Mon, 28 Sep 2015 12:03:39 -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=56nPkWDVSZwKgpJq04iDTHB45DpaYkZAwXdtmRo08Yc=; b=f3iF8STM7/2pP7AffVVNUN4BdO+Z8WrGDjL1gsGl7xVYwq7cjtgpAnjJ1a+Jtuc4ky HHz6q6Bnd403sYGKI8W9zg/asdogf88cpMKjM00xQV3ZJsY3CXrXlC2OUXZyQ5YVfyVb TcBINcjouW/oH9Hs8EmoHfY+XGlKHTgx21okEOvUuk0Ev41Rlp3MCNICNfQ3sWnJw0F/ A/OJ9vjTW/h2F0vtIPvFevtrwyu/RocJ8bKjiDOGeS1Y8W/a7fFAaEElLKBgX0GU/Td3 9y00pIemZ3ANGq4sbQnWNuG6K5t6QZbKCOhb4sk7Vf7sY/ar3tmKsDpNQ4U1BqvEDe/9 gh3g== X-Gm-Message-State: ALoCoQmxayM2z+ujlKiO2f+l5v4OkI975u97aWI9fIkizhMzLZOXwOnepBynGK/Hmall6924AxU4 MIME-Version: 1.0 X-Received: by 10.112.12.165 with SMTP id z5mr6039847lbb.33.1443467019543; Mon, 28 Sep 2015 12:03:39 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Mon, 28 Sep 2015 12:03:39 -0700 (PDT) In-Reply-To: <20150928184647.GA97040@elstar.local> References:

<20150928184647.GA97040@elstar.local> Date: Mon, 28 Sep 2015 12:03:39 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Alexander Clemm (alex)" , Andy Bierman , "Martin Bjorklund (mbjorklu)" , Netconf Content-Type: multipart/alternative; boundary=001a11c3b830f200eb0520d35ad1 Archived-At: Subject: Re: [Netconf] YANG patch with XML and Netconf 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, 28 Sep 2015 19:03:43 -0000 --001a11c3b830f200eb0520d35ad1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 28, 2015 at 11:46 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Sep 28, 2015 at 06:28:44PM +0000, Alexander Clemm (alex) wrote: > > > > My reason for asking was that it seems you could accomplish essentially > the same through either a yang-patch, or through an edit-config. If that= =E2=80=99s > the case, I was wondering if the way those operations are encoded in XML = be > aligned? (Clearly, the data model is the same.) > > > > While yang-patch and edit-config can functionally do the same, they > have little in common how they work and this is by design and not by > accident. > > I personally think that having yang-patch (not sure I like the name > but I do not have a better proposal) defined so that it is works with > both RESTCONF and NETCONF would be desirable. It is not clear to me > how the configuration datastore, the so called target datastore, is > selected. > https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-02#= section-2.2 As you can see from the module structure: http://www.netconfcentral.org/modulereport/ietf-yang-patch YANG patch has an edit list. The 'target' within each edit is a path-expr relative to the target resource specified in the request URL. (In our implementation we have found it useful to set the target resource URI to the datastore root, and set the 'target' leaf to the full path. The missing target URI in the structure has been a problem because it is RESTCONF-specific.) YANG Patch is being used (already) in several ways. It also serves as a notification suitable for pub/sub synching. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11c3b830f200eb0520d35ad1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 28, 2015 at 11:46 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Sep 28, 2015 at 06:28:44PM +0000, Alexander Clemm (alex) = wrote:
>
> My reason for asking was that it seems you could accomplish essentiall= y the same through either a yang-patch, or through an edit-config.=C2=A0 If= that=E2=80=99s the case, I was wondering if the way those operations are e= ncoded in XML be aligned?=C2=A0 =C2=A0 (Clearly, the data model is the same= .)
>

While yang-patch and edit-config can functionally do the same, they
have little in common how they work and this is by design and not by
accident.

I personally think that having yang-patch (not sure I like the name
but I do not have a better proposal) defined so that it is works with
both RESTCONF and NETCONF would be desirable. It is not clear to me
how the configuration datastore, the so called target datastore, is
selected.

https= ://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-02#secti= on-2.2

As you can see from the module structur= e:

http://www.netconfcentral.org/modulereport/ietf-yang-patch

YANG patch has an edit list.=C2=A0 The 'target= 9; within each edit is a path-expr

relative to the target resourc= e specified in the request URL.

(In our implementa= tion we have found it useful to set the target resource URI to

th= e datastore root, and set the 'target' leaf to the full path. The m= issing target URI

in the structure has been a problem because it = is RESTCONF-specific.)

YANG Patch is being used (a= lready) in several ways.

It also serves as a notification suitabl= e for pub/sub synching.

/js

Andy

=C2=A0

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

--001a11c3b830f200eb0520d35ad1-- From nobody Mon Sep 28 12:05:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2571B2BD7 for ; Mon, 28 Sep 2015 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au0jhJzpGezg for ; Mon, 28 Sep 2015 12:05:25 -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 0A9F51B2BA7 for ; Mon, 28 Sep 2015 12:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39630; q=dns/txt; s=iport; t=1443467124; x=1444676724; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1ZG7wB2/0BdrvOueTsVIyNfiCtKV6IBtasIHjAgmjxQ=; b=B19xg9ka5b38jcDOfGrYsTm28RINYND+S+5nAkl9FF/jzPF+x2Ts78Fr Xg1z7MUDlvWtsXSfJE9n7etBoo3Bp1aB+2BKcqsSQ9Hanp7PACup7exIS Qxl0Vmy9I/RW4yVGI95TaD2Zh/l/F1AEEHIg8bCg289SyJ51SAFeJzPoZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwAQAtjglW/4gNJK1egldNVGkGvTkBDYF3hX0CHIEwOBQBAQEBAQEBgQqEJAEBAQQjCkwQAgEIEQQBAQsWAQYDAgICMBQJCAEBBA4FCIgmDbZ/lFQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi3CEQhoWGwYBgmkvgRQFjH+FQ4MuAYUUiUlGlT2DbREOAQFChAFxiByBBQEBAQ X-IronPort-AV: E=Sophos; i="5.17,604,1437436800"; d="scan'208,217"; a="30863354" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP; 28 Sep 2015 19:05:23 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t8SJ5NVY015050 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2015 19:05:23 GMT Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 14:05:23 -0500 Received: from xhc-aln-x02.cisco.com (173.36.12.76) by xch-aln-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 28 Sep 2015 14:05:23 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.194]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0248.002; Mon, 28 Sep 2015 14:05:23 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman Thread-Topic: YANG patch with XML and Netconf edit-config Thread-Index: AdD4CCuxvjUk1rC+SvOyPcAnIocwzAANkxgAAHalviAAC7dZgAAJ8kIg Date: Mon, 28 Sep 2015 19:05:22 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.101.220.154] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571DCCFA18xmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "Martin Bjorklund $mbjorklu$" , Netconf Subject: Re: [Netconf] YANG patch with XML and Netconf 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, 28 Sep 2015 19:05:28 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571DCCFA18xmbrcdx05ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KdGhhbmtzLg0KDQpUaGUgZXhhbXBsZXMgaW4gWUFORyBQYXRjaCBhcHBlbmRp eCBEIGFyZSBhbGwgSlNPTiwgbm90IFhNTC4gIEJ1dCB5b3UgYW5zd2VyZWQgbXkgcXVlc3Rpb24u DQoNCi0tLSBBbGV4DQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbV0NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI4LCAyMDE1IDExOjQ3IEFNDQpUbzogQWxl eGFuZGVyIENsZW1tIChhbGV4KSA8YWxleEBjaXNjby5jb20+DQpDYzogTWFydGluIEJqb3JrbHVu ZCAobWJqb3JrbHUpIDxtYmpvcmtsdUBjaXNjby5jb20+OyBLZW50IFdhdHNlbiA8a3dhdHNlbkBq dW5pcGVyLm5ldD47IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogWUFO RyBwYXRjaCB3aXRoIFhNTCBhbmQgTmV0Y29uZiBlZGl0LWNvbmZpZw0KDQoNCg0KT24gTW9uLCBT ZXAgMjgsIDIwMTUgYXQgMTE6MjggQU0sIEFsZXhhbmRlciBDbGVtbSAoYWxleCkgPGFsZXhAY2lz Y28uY29tPG1haWx0bzphbGV4QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgQW5keSwNCg0KdGhhbmsg eW91IGZvciB5b3VyIHJlc3BvbnNlLg0KDQoNClNvLCB0aGUgZW5jb2RpbmcgaXMgbGlrZSBpbiB0 aGUgc2Vjb25kIGFsdGVybmF0aXZlIOKAkyBlLmcuIHNvbWV0aGluZyBsaWtlICAgICAgJw0KDQoN Ckl0IGZvbGxvd3MgdGhlIHNjaGVtYSBpbiBpZXRmLXlhbmctcGF0Y2gueWFuZw0KDQoNCg0KICAg ICAgPHlhbmctcGF0Y2g+DQoNCiAgICAgICAgPHBhdGNoLWlkPm15LXBhdGNoPC9wYXRjaC1pZD4N Cg0KICAgICAgICA8ZWRpdD4NCg0KICAgICAgICAgIDxlZGl0LWlkPmVkaXQxPC9lZGl0LWlkPg0K DQogICAgICAgICAgPG9wZXJhdGlvbj5kZWxldGU8L29wZXJhdGlvbj4NCg0KICAgICAgICAgIDx0 YXJnZXQ+DQoNCiAgICAgICAgICAgICA8aW50ZXJmYWNlPg0KDQogICAgICAgICAgICAgICA8bmFt ZT5FdGhlcm5ldDAvMDwvbmFtZT4NCg0KICAgICAgICAgICAgIDwvaW50ZXJmYWNlPg0KDQogICAg ICAgICAgPC90YXJnZXQ+DQoNCiAgICAgICAgIDwvZWRpdD4NCg0KICAgICAgIDwveWFuZy1wYXRj aD4NCg0KKEl0IHdvdWxkIHN0aWxsIGJlIGdvb2QgdG8gYWRkIGFuIGV4YW1wbGUgdG8gdGhlIGFw cGVuZGl4IGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkcmFmdC4pICBTbywgY2xlYXJseSBk aWZmZXJlbnQgZnJvbSB3aGF0IHlvdSBoYXZlIGluIGFuIGVkaXQtY29uZmlnLg0KDQpNeSByZWFz b24gZm9yIGFza2luZyB3YXMgdGhhdCBpdCBzZWVtcyB5b3UgY291bGQgYWNjb21wbGlzaCBlc3Nl bnRpYWxseSB0aGUgc2FtZSB0aHJvdWdoIGVpdGhlciBhIHlhbmctcGF0Y2gsIG9yIHRocm91Z2gg YW4gZWRpdC1jb25maWcuICBJZiB0aGF04oCZcyB0aGUgY2FzZSwgSSB3YXMgd29uZGVyaW5nIGlm IHRoZSB3YXkgdGhvc2Ugb3BlcmF0aW9ucyBhcmUgZW5jb2RlZCBpbiBYTUwgYmUgYWxpZ25lZD8g ICAgKENsZWFybHksIHRoZSBkYXRhIG1vZGVsIGlzIHRoZSBzYW1lLikNCg0KDQoNClRoZXJlIGFy ZSBleGFtcGxlcyBpbiBZQU5HIFBhdGNoLCBhcHBlbmRpeCBELg0KDQoNClRoYW5rcw0KLS0tIEFs ZXgNCg0KDQpBbmR5DQoNCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29y a3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+XQ0KU2VudDogRnJpZGF5LCBTZXB0ZW1i ZXIgMjUsIDIwMTUgOTozNCBQTQ0KVG86IEFsZXhhbmRlciBDbGVtbSAoYWxleCkgPGFsZXhAY2lz Y28uY29tPG1haWx0bzphbGV4QGNpc2NvLmNvbT4+DQpDYzogTWFydGluIEJqb3JrbHVuZCAobWJq b3JrbHUpIDxtYmpvcmtsdUBjaXNjby5jb208bWFpbHRvOm1iam9ya2x1QGNpc2NvLmNvbT4+OyBL ZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5l dD4+OyBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBZQU5HIHBhdGNoIHdpdGggWE1MIGFuZCBOZXRjb25mIGVkaXQtY29uZmln DQoNCg0KDQpPbiBGcmksIFNlcCAyNSwgMjAxNSBhdCA4OjI1IFBNLCBBbGV4YW5kZXIgQ2xlbW0g KGFsZXgpIDxhbGV4QGNpc2NvLmNvbTxtYWlsdG86YWxleEBjaXNjby5jb20+PiB3cm90ZToNCkhl bG8gQW5keSwgTWFydGluLCBLZW50LA0KDQpsb29raW5nIGF0IGRyYWZ0LWlldGYtbmV0Y29uZi15 YW5nLXBhdGNoLTA1LCBJIGFtIHdvbmRlcmluZyBpZiB5b3UgaGF2ZSBleGFtcGxlcyBmb3IgWUFO Ry1wYXRjaCB3aXRoIFhNTCBlbmNvZGluZy4gIFRoZSBleGFtcGxlcyBpbiBzZWN0aW9uIEQgYXJl IGFsbCBKU09OLWVuY29kZWQuDQoNCkkgYW0gd29uZGVyaW5nIHNwZWNpZmljYWxseSBhYm91dCBo b3cgdGhlIFhNTCBlbmNvZGluZyBpbiBZQU5HLXBhdGNoIHJlbGF0ZXMgdG8gdGhlIE5ldGNvbmYg ZW5jb2Rpbmcgb2YgZWRpdC1jb25maWcuICBJIHdhcyBob3BpbmcgdGhlIHR3byB3b3VsZCBiZSBh bGlnbmVkIG9yIGV2ZW4gdGhlIHNhbWUsIGJ1dCBpcyB0aGlzIHRoZSBjYXNlPyAgSXQgc2VlbXMg dGhhdCB0aGUgeWFuZy1wYXRjaCB3YXkgb2YgZG9pbmcgdGhpbmdzIHdpbGwgcmVxdWlyZSBhIGRp ZmZlcmVudCBlbmNvZGluZyBvZiB0aGUgcGF5bG9hZCwgbWVhbmluZyB5b3UgY2Fubm90IHNpbXBs eSB0YWtlIHRoZSBzYW1lIOKAnGVkaXQgc25pcHBldOKAnSBhbmQgdXNlIGl0IGJvdGggZm9yIE5l dGNvbmYgYW5kIFJlc3Rjb25mLCBpbnN0ZWFkIHRoZSBjb250ZW50L2VuY29kaW5nIHdpbGwgZGVw ZW5kIG9uIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCwgbm90IGJlIGFnbm9zdGljIHRvIGl0LiAg SXMgdGhpcyB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/ICBXaGF0IGlzIHRoZSBpbnRlbnRpb24/ICBE byB3ZSBoYXZlIHNvbWUgZXhhbXBsZXM/DQoNCg0KDQpXaHkgd291bGQgaXQgYmUgdGhlIHNhbWUg YXMgPGVkaXQtY29uZmlnPiBqdXN0IGJlY2F1c2UgaXQgaXMgZW5jb2RlZCBpbiBYTUw/DQpXaHkg d291bGQgdGhlIGRhdGEgbW9kZWwgY2hhbmdlIGJlY2F1c2UgaXQgd2FzIFhNTCB2cy4gSlNPTj8N Cg0KSWYgeW91IHdhbnQgdG8gdXNlIGVkaXQtY29uZmlnIGFuZCB0aGUgc2VydmVyIHN1cHBvcnRz IGl0IHRocm91Z2ggUkVTVENPTkY6DQoNCiAgIFBPU1QgL3Jlc3Rjb25mL29wZXJhdGlvbnMvZWRp dC1jb25maWcNCg0KICA8aW5wdXQ+DQogICAgIDx0YXJnZXQ+IC4uLiA8L3RhcmdldD4NCiAgICAg PGNvbmZpZz4NCiAgICAgICAuLi4NCiAgICAgPC9jb25maWc+DQogIDwvaW5wdXQ+DQoNCg0KT3Ro ZXJ3aXNlIGp1c3QgdXNlIE5FVENPTkYgaWYgeW91IHdhbnQgdG8gdXNlIDxlZGl0LWNvbmZpZz4N Cg0KDQpBbmR5DQoNCg0KDQpGb3IgZXhhbXBsZSwgaWYgd2UgaGF2ZSAocGVyIHRoZSBleGFtcGxl IGluIFJGQyA2MjQxKSB0aGUgZm9sbG93aW5nIGVkaXQtY29uZmlnIHNuaXBwZXQ6DQoNCiAgICAg ICA8ZWRpdC1jb25maWc+DQoNCiAgICAgICAgIDx0YXJnZXQ+DQoNCiAgICAgICAgICAgPHJ1bm5p bmcvPg0KDQogICAgICAgICA8L3RhcmdldD4NCg0KICAgICAgICAgPGRlZmF1bHQtb3BlcmF0aW9u Pm5vbmU8L2RlZmF1bHQtb3BlcmF0aW9uPg0KDQogICAgICAgICA8Y29uZmlnIHhtbG5zOnhjPSJ1 cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KDQogICAgICAgICAgIDx0 b3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQoNCiAgICAg ICAgICAgICA8aW50ZXJmYWNlIHhjOm9wZXJhdGlvbj0iZGVsZXRlIj4NCg0KICAgICAgICAgICAg ICAgPG5hbWU+RXRoZXJuZXQwLzA8L25hbWU+DQoNCiAgICAgICAgICAgICA8L2ludGVyZmFjZT4N Cg0KICAgICAgICAgICA8L3RvcD4NCg0KICAgICAgICAgPC9jb25maWc+DQoNCiAgICAgICA8L2Vk aXQtY29uZmlnPg0KDQp3aGF0IGRvZXMgdGhlIGNvcnJlc3BvbmRpbmcgWUFORy1wYXRjaCBsb29r IGxpa2Ug4oCTIHNvbWV0aGluZyBsaWtlIHRoaXM6ICAoZWRpdC1jb25maWcgc3R5bGUpDQoNCg0K ICAgICAgQWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLnBhdGNoLXN0YXR1cyt4bWwNCg0KICAgICAg Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi95YW5nLnBhdGNoK3htbA0KDQoNCg0KICAgICAgPHlh bmctcGF0Y2g+DQoNCiAgICAgICAgPHBhdGNoLWlkPm15LXBhdGNoPC9wYXRjaC1pZD4NCg0KICAg ICAgICA8ZWRpdD4NCg0KICAgICAgICAgPGNvbmZpZyB4bWxuczp4Yz0idXJuOmlldGY6cGFyYW1z OnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCg0KICAgICAgICAgICA8dG9wIHhtbG5zPSJodHRw Oi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciPg0KDQogICAgICAgICAgICAgPGludGVy ZmFjZSB4YzpvcGVyYXRpb249ImRlbGV0ZSI+DQoNCiAgICAgICAgICAgICAgIDxuYW1lPkV0aGVy bmV0MC8wPC9uYW1lPg0KDQogICAgICAgICAgICAgPC9pbnRlcmZhY2U+DQoNCiAgICAgICAgICAg PC90b3A+DQoNCiAgICAgICAgIDwvY29uZmlnPg0KDQogICAgICAgIDwvZWRpdD4NCg0KICAgICAg IDwveWFuZy1wYXRjaD4NCg0Kb3IgaXMgaXQgc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KICAgICAg QWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLnBhdGNoLXN0YXR1cyt4bWwNCg0KICAgICAgQ29udGVu dC1UeXBlOiBhcHBsaWNhdGlvbi95YW5nLnBhdGNoK3htbA0KDQoNCg0KICAgICAgPHlhbmctcGF0 Y2g+DQoNCiAgICAgICAgPHBhdGNoLWlkPm15LXBhdGNoPC9wYXRjaC1pZD4NCg0KICAgICAgICA8 ZWRpdD4NCg0KICAgICAgICAgIDxlZGl0LWlkPmVkaXQxPC9lZGl0LWlkPg0KDQogICAgICAgICAg PG9wZXJhdGlvbj5kZWxldGU8L29wZXJhdGlvbj4NCg0KICAgICAgICAgIDx0YXJnZXQ+DQoNCiAg ICAgICAgICAgICA8aW50ZXJmYWNlPg0KDQogICAgICAgICAgICAgICA8bmFtZT5FdGhlcm5ldDAv MDwvbmFtZT4NCg0KICAgICAgICAgICAgIDwvaW50ZXJmYWNlPg0KDQogICAgICAgICAgPC90YXJn ZXQ+DQoNCiAgICAgICAgIDwvZWRpdD4NCg0KICAgICAgIDwveWFuZy1wYXRjaD4NCg0KVGhhbmtz DQotLS0gQWxleA0KDQoNCg== --_000_DBC595ED2346914F9F81D17DD5C32B571DCCFA18xmbrcdx05ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQW5k eSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoYW5rcy4mbmJz cDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGV4YW1w bGVzIGluIFlBTkcgUGF0Y2ggYXBwZW5kaXggRCBhcmUgYWxsIEpTT04sIG5vdCBYTUwuJm5ic3A7 IEJ1dCB5b3UgYW5zd2VyZWQgbXkgcXVlc3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzph bmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIg MjgsIDIwMTUgMTE6NDcgQU08YnI+DQo8Yj5Ubzo8L2I+IEFsZXhhbmRlciBDbGVtbSAoYWxleCkg Jmx0O2FsZXhAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGluIEJqb3JrbHVuZCAo bWJqb3JrbHUpICZsdDttYmpvcmtsdUBjaXNjby5jb20mZ3Q7OyBLZW50IFdhdHNlbiAmbHQ7a3dh dHNlbkBqdW5pcGVyLm5ldCZndDs7IE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBZQU5HIHBhdGNoIHdpdGggWE1MIGFuZCBOZXRjb25mIGVk aXQtY29uZmlnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBTZXAgMjgsIDIwMTUg YXQgMTE6MjggQU0sIEFsZXhhbmRlciBDbGVtbSAoYWxleCkgJmx0OzxhIGhyZWY9Im1haWx0bzph bGV4QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsZXhAY2lzY28uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQW5keSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2UuJm5ic3A7 DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbywgdGhlIGVuY29kaW5nIGlzIGxpa2Ug aW4gdGhlIHNlY29uZCBhbHRlcm5hdGl2ZSDigJMgZS5nLiBzb21ldGhpbmcgbGlrZTwvc3Bhbj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J dCBmb2xsb3dzIHRoZSBzY2hlbWEgaW4gaWV0Zi15YW5nLXBhdGNoLnlhbmc8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZsdDt5YW5nLXBhdGNoJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7cGF0Y2gtaWQmZ3Q7bXktcGF0 Y2gmbHQ7L3BhdGNoLWlkJmd0OyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7ZWRpdCZndDsgPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2VkaXQtaWQmZ3Q7ZWRpdDEmbHQ7L2VkaXQtaWQmZ3Q7PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtvcGVyYXRpb24mZ3Q7ZGVsZXRlJmx0Oy9vcGVyYXRpb24m Z3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt0YXJnZXQmZ3Q7PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtpbnRlcmZhY2UmZ3Q7PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtuYW1lJmd0O0V0aGVybmV0MC8w Jmx0Oy9uYW1lJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7 L2ludGVyZmFjZSZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy90YXJnZXQmZ3Q7PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDsvZWRpdCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy95YW5nLXBhdGNoJmd0OzxvOnA+PC9vOnA+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4oSXQgd291bGQgc3RpbGwgYmUgZ29vZCB0 byBhZGQgYW4gZXhhbXBsZSB0byB0aGUgYXBwZW5kaXggaW4gdGhlIG5leHQgcmV2aXNpb24gb2Yg dGhlIGRyYWZ0LikmbmJzcDsgU28sDQogY2xlYXJseSBkaWZmZXJlbnQgZnJvbSB3aGF0IHlvdSBo YXZlIGluIGFuIGVkaXQtY29uZmlnLiZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5NeSByZWFzb24gZm9yIGFza2luZyB3YXMgdGhhdCBpdCBzZWVt cyB5b3UgY291bGQgYWNjb21wbGlzaCBlc3NlbnRpYWxseSB0aGUgc2FtZSB0aHJvdWdoIGVpdGhl ciBhIHlhbmctcGF0Y2gsDQogb3IgdGhyb3VnaCBhbiBlZGl0LWNvbmZpZy4mbmJzcDsgSWYgdGhh dOKAmXMgdGhlIGNhc2UsIEkgd2FzIHdvbmRlcmluZyBpZiB0aGUgd2F5IHRob3NlIG9wZXJhdGlv bnMgYXJlIGVuY29kZWQgaW4gWE1MIGJlIGFsaWduZWQ/ICZuYnNwOyZuYnNwOyZuYnNwOyhDbGVh cmx5LCB0aGUgZGF0YSBtb2RlbCBpcyB0aGUgc2FtZS4pJm5ic3A7DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgZXhhbXBs ZXMgaW4gWUFORyBQYXRjaCwgYXBwZW5kaXggRC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGFua3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gW21h aWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YW5keUB5dW1hd29ya3MuY29tPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIFNlcHRlbWJlciAyNSwg MjAxNSA5OjM0IFBNPGJyPg0KPGI+VG86PC9iPiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFsZXhAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5hbGV4QGNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gQmpvcmtsdW5kIChtYmpvcmtsdSkgJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86bWJqb3JrbHVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5tYmpvcmtsdUBjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OzsNCiBLZW50IFdhdHNlbiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzprd2F0c2Vu QGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5rd2F0c2VuQGp1 bmlwZXIubmV0PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IE5ldGNvbmYgJmx0Ozwv c3Bhbj48YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+bmV0Y29uZkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBZQU5HIHBhdGNoIHdpdGggWE1MIGFuZCBO ZXRjb25mIGVkaXQtY29uZmlnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBG cmksIFNlcCAyNSwgMjAxNSBhdCA4OjI1IFBNLCBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpICZsdDs8 YSBocmVmPSJtYWlsdG86YWxleEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5hbGV4QGNpc2Nv LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SGVsbyBBbmR5LCBNYXJ0aW4sIEtlbnQsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPmxvb2tpbmcgYXQgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcGF0Y2gtMDUsIEkgYW0g d29uZGVyaW5nIGlmIHlvdSBoYXZlIGV4YW1wbGVzIGZvciBZQU5HLXBhdGNoIHdpdGggWE1MIGVu Y29kaW5nLiZuYnNwOyBUaGUgZXhhbXBsZXMgaW4gc2VjdGlvbiBEIGFyZSBhbGwgSlNPTi1lbmNv ZGVkLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIHdvbmRlcmluZyBz cGVjaWZpY2FsbHkgYWJvdXQgaG93IHRoZSBYTUwgZW5jb2RpbmcgaW4gWUFORy1wYXRjaCByZWxh dGVzIHRvIHRoZSBOZXRjb25mIGVuY29kaW5nIG9mIGVkaXQtY29uZmlnLiZuYnNwOyBJIHdhcyBo b3BpbmcgdGhlIHR3byB3b3VsZCBiZSBhbGlnbmVkIG9yIGV2ZW4gdGhlIHNhbWUsIGJ1dA0KIGlz IHRoaXMgdGhlIGNhc2U/Jm5ic3A7IEl0IHNlZW1zIHRoYXQgdGhlIHlhbmctcGF0Y2ggd2F5IG9m IGRvaW5nIHRoaW5ncyB3aWxsIHJlcXVpcmUgYSBkaWZmZXJlbnQgZW5jb2Rpbmcgb2YgdGhlIHBh eWxvYWQsIG1lYW5pbmcgeW91IGNhbm5vdCBzaW1wbHkgdGFrZSB0aGUgc2FtZSDigJxlZGl0IHNu aXBwZXTigJ0gYW5kIHVzZSBpdCBib3RoIGZvciBOZXRjb25mIGFuZCBSZXN0Y29uZiwgaW5zdGVh ZCB0aGUgY29udGVudC9lbmNvZGluZyB3aWxsIGRlcGVuZA0KIG9uIHRoZSB1bmRlcmx5aW5nIHRy YW5zcG9ydCwgbm90IGJlIGFnbm9zdGljIHRvIGl0LiZuYnNwOyBJcyB0aGlzIHVuZGVyc3RhbmRp bmcgY29ycmVjdD8mbmJzcDsgV2hhdCBpcyB0aGUgaW50ZW50aW9uPyZuYnNwOyBEbyB3ZSBoYXZl IHNvbWUgZXhhbXBsZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2h5IHdvdWxkIGl0IGJlIHRoZSBzYW1l IGFzICZsdDtlZGl0LWNvbmZpZyZndDsganVzdCBiZWNhdXNlIGl0IGlzIGVuY29kZWQgaW4gWE1M PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5X aHkgd291bGQgdGhlIGRhdGEgbW9kZWwgY2hhbmdlIGJlY2F1c2UgaXQgd2FzIFhNTCB2cy4gSlNP Tj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPklmIHlvdSB3YW50IHRvIHVzZSBlZGl0LWNvbmZpZyBhbmQgdGhlIHNlcnZlciBzdXBwb3J0 cyBpdCB0aHJvdWdoIFJFU1RDT05GOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO1BPU1QgL3Jlc3Rjb25mL29wZXJh dGlvbnMvZWRpdC1jb25maWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbHQ7aW5wdXQmZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O3RhcmdldCZndDsgLi4uICZsdDsvdGFyZ2V0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtj b25maWcmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZs dDsvY29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsgJmx0Oy9pbnB1dCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PdGhlcndpc2UganVzdCB1c2Ug TkVUQ09ORiBpZiB5b3Ugd2FudCB0byB1c2UgJmx0O2VkaXQtY29uZmlnJmd0OzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Rm9yIGV4YW1wbGUsIGlmIHdlIGhhdmUgKHBlciB0aGUgZXhhbXBsZSBpbiBSRkMg NjI0MSkgdGhlIGZvbGxvd2luZyBlZGl0LWNvbmZpZyBzbmlwcGV0OiZuYnNwOw0KPG86cD48L286 cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZs dDtlZGl0LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3RhcmdldCZndDs8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmx0O3J1bm5pbmcvJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L3Rh cmdldCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2RlZmF1bHQtb3BlcmF0aW9uJmd0O25vbmUmbHQ7 L2RlZmF1bHQtb3BlcmF0aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y29uZmlnIHhtbG5zOnhj PSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyZndDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3RvcCB4bWxucz0mcXVvdDs8YSBocmVmPSJo dHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWc8L2E+JnF1b3Q7Jmd0OzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aW50ZXJmYWNlIHhjOm9wZXJhdGlvbj0m cXVvdDtkZWxldGUmcXVvdDsmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZsdDtuYW1lJmd0O0V0aGVybmV0MC8wJmx0Oy9uYW1lJmd0OzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L2ludGVyZmFjZSZndDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy90b3AmZ3Q7PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsv Y29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7L2VkaXQtY29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj53aGF0IGRvZXMgdGhlIGNvcnJlc3BvbmRpbmcgWUFORy1wYXRjaCBsb29rIGxpa2Ug 4oCTIHNvbWV0aGluZyBsaWtlIHRoaXM6Jm5ic3A7IChlZGl0LWNvbmZpZyBzdHlsZSk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2NlcHQ6IGFwcGxpY2F0aW9uL3lh bmcucGF0Y2gtc3RhdHVzJiM0Mzt4bWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi95YW5nLnBhdGNo JiM0Mzt4bWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3lhbmctcGF0Y2gmZ3Q7PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDtwYXRjaC1pZCZndDtteS1wYXRjaCZsdDsvcGF0Y2gtaWQmZ3Q7IDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZsdDtlZGl0Jmd0OyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7Y29uZmlnIHhtbG5z OnhjPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyZn dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3RvcCB4bWxucz0mcXVvdDs8YSBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWc8L2E+JnF1b3Q7Jmd0OzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aW50ZXJmYWNlIHhjOm9wZXJhdGlv bj0mcXVvdDtkZWxldGUmcXVvdDsmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtuYW1lJmd0O0V0aGVybmV0MC8wJmx0Oy9uYW1lJmd0Ozxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L2ludGVyZmFjZSZndDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy90b3AmZ3Q7PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDsvY29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2VkaXQmZ3Q7PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsveWFuZy1wYXRjaCZn dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+b3IgaXMgaXQgc29tZXRoaW5nIGxpa2Ug dGhpczo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEFjY2VwdDogYXBwbGljYXRpb24veWFuZy5wYXRjaC1zdGF0dXMmIzQzO3htbDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb250ZW50LVR5cGU6 IGFwcGxpY2F0aW9uL3lhbmcucGF0Y2gmIzQzO3htbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7eWFuZy1wYXRjaCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3BhdGNoLWlkJmd0O215LXBhdGNoJmx0 Oy9wYXRjaC1pZCZndDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2VkaXQmZ3Q7IDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZsdDtlZGl0LWlkJmd0O2VkaXQxJmx0Oy9lZGl0LWlkJmd0OzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7b3BlcmF0aW9uJmd0O2RlbGV0ZSZsdDsvb3BlcmF0aW9uJmd0Ozxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7dGFyZ2V0Jmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7aW50ZXJmYWNlJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bmFtZSZndDtFdGhlcm5ldDAvMCZsdDsv bmFtZSZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy9pbnRl cmZhY2UmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvdGFyZ2V0Jmd0OzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7L2VkaXQmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsveWFuZy1wYXRjaCZndDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLS0gQWxleDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_DBC595ED2346914F9F81D17DD5C32B571DCCFA18xmbrcdx05ciscoc_-- From nobody Mon Sep 28 14:21:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9923A1B33D9; Mon, 28 Sep 2015 14:21:41 -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 uwdonuF2bH3K; Mon, 28 Sep 2015 14:21:39 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13EF1B33C9; Mon, 28 Sep 2015 14:21:39 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so188511802pac.2; Mon, 28 Sep 2015 14:21:39 -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=N3cDAGAP7uyrS+AMd/So+6AM2F0bvwtyTkvJxS03oPg=; b=fDZveFhWNAAk2VyD6gQeMmj/a202tyeqRLUfHSeD/UasWU40J4+RgcgqTGB0DacAec Ut04wiTRyjr8zYLkq2UyAifg+7Z07V42G9zmAem6UYHL161u4ZXyLwZcou9V20rbGgPR FzS2GaB262ojGqa6Rwy1CsyHNVn4RI3dCF4pwwbIEHjPllwIeWwDUpG+uIczpxnEZ0Fq Fg9Fwjpvr7oByZko6IzGH+kTpJzQkTl90t539cHQG4qRf/BRyjokIcB7wv2r8kgssQHv iKs+fU/sCGTKpkp2gWYnbFMt/Q1f5/nh1KgC4A4FUFKcYOgf+4WIHqcm2biBLYLf1bd3 8EdA== X-Received: by 10.66.241.40 with SMTP id wf8mr17035252pac.157.1443475299446; Mon, 28 Sep 2015 14:21:39 -0700 (PDT) Received: from ?IPv6:2001:420:302:1270:4d23:9d4f:ee7c:225f? ([2001:420:302:1270:4d23:9d4f:ee7c:225f]) by smtp.gmail.com with ESMTPSA id zc4sm21203467pbb.24.2015.09.28.14.21.38 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 14:21:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 $2098$) From: Mahesh Jethanandani In-Reply-To: <20150922190308.GB99737@elstar.local> Date: Mon, 28 Sep 2015 14:22:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2633B208-C180-4F96-9B50-C354BFAF3C5E@gmail.com> References: <20150922142615.GC99134@elstar.local> <20150922190308.GB99737@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "netconf@ietf.org" , NETMOD Working Group Subject: Re: [Netconf] restconf and namespaces and unique module names. 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, 28 Sep 2015 21:21:41 -0000 [Cross posting to netmod mailing list since this discussion affects = YANG] > On Sep 22, 2015, at 12:03 PM, Juergen Schoenwaelder = wrote: >=20 > On Tue, Sep 22, 2015 at 05:25:04PM +0000, Kent Watsen wrote: >>>=20 >>> RFC 6020: >>>=20 >>> The names of all standard modules and submodules MUST be unique. >>> Developers of enterprise modules are RECOMMENDED to choose names = for >>> their modules that will have a low probability of colliding with >>> standard or other enterprise modules, e.g., by using the enterprise >>> or organization name as a prefix for the module name. >>>=20 >>> Apparently, both module names in the example violate this. Note that >>> module names are used to resolve imports and hence they better are >>> unique. For the IETF, we can manage that via the IANA registry. For >>> the other modules, there is a clear recommendation. >>=20 >>=20 >> OK, that's fair, but it doesn't seem to be a followed often outside = of the >> IETF. >>=20 >> For instance, >>=20 >> - ETSI NFV-MANO has module names like "nsd", "vnfd" and "vld" >> - Open Config has module names beginning with "bgp-" and "mpls-" >> - IEEE has module names like =E2=80=9Cethernet" IEEE models did that because they did not have a namespace reserved. As = IEEE goes through the motions of registering for a URN namespace, all = IEEE standard models will be prefixed with ieee-. >> - ODL has some module names like "config" and "flow-errors" >=20 > Because people often do not read specifications and if tools do not > complain they assume everything is fine. The YANG spec has clear > words, there is text in the guidelines. We can write more text and it > will likely not help. Perhaps tutorials need to stress these points. >=20 >> BTW, this sentence in 6087bis may be overreaching "All published = module >> names MUST be unique." - as it is only enforceable within the scope = of a >> specific registrar like IANA. Perhaps replace MUST with SHOULD, or = limit >> the scope to IANA-published modules? >=20 > IANA does not publish modules. The IETF can enforce unique module > names. I would hope that once the IEEE _publishes_ YANG modules they > also find ways to enforce unique module names. Perhaps ODL, ETSI, OC > etc will eventually get this right as well. That is the plan for IEEE and MEF, where we are working on getting them = a URN namespace and have them manage uniqueness between the models they = produce. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Sep 29 00:23:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2951A1B96 for ; Tue, 29 Sep 2015 00:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFaj1kDK5tLE for

--001a11c27b261c602e0520e5329a-- From nobody Wed Sep 30 04:05:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A411B5D2C for ; Wed, 30 Sep 2015 04:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmP74XF83GVd for ; Wed, 30 Sep 2015 04:05:12 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395C91B5D2A for ; Wed, 30 Sep 2015 04:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30129; q=dns/txt; s=iport; t=1443611111; x=1444820711; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=7W7hYzigI0QodgsZQmYRgyBFPeaV2onJMQW7ALp2xb0=; b=JlXAcyZbZVHPQEotkhf1aXizK4ZIrwfBtOeyOz7Os2C525N6jKiRjCds YQ095ZG7XfBGoLpxHrm1bFNvZYZjxEykW28DO7CXFGMk28dmXvvN0kVJN Z6+LSviq8Xp4WVZj9pw5MvZiVHkNi9+096Orr+m3nKSunlJUxzj95gFIp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CjBAAOwQtW/xbLJq1eg3hptFaKfBoBCYUvSgKCAQEBAQEBAYELhCQBAQEEAQEBawQCBAEQCxEDAQIKAwESAQEGBwkDAgECAQ8GHwkIBgoDBgIBAQWIEAMSDcY5DYUOAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzhH2CQg6BUCI6EQcGhCYFhzaLEIMyhRaGDYFwgU9Gg3CDAIoGfYdIY4QEPDOHX4E/AQEB X-IronPort-AV: E=Sophos;i="5.17,611,1437436800"; d="scan'208,217";a="605451126" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2015 11:05:08 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8UB55gx012733; Wed, 30 Sep 2015 11:05:06 GMT To: Rodney Cummings , "Ersue, Mehmet (Nokia - DE/Munich)" References:

From: Benoit Claise Message-ID: <560BC1E0.6080601@cisco.com> Date: Wed, 30 Sep 2015 13:05:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040208020404070001060506" Archived-At: Cc: Netconf Subject: Re: [Netconf] Draft charter update for review 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, 30 Sep 2015 11:05:15 -0000 This is a multi-part message in MIME format. --------------040208020404070001060506 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Rodney, The sentence you mention tells: NETCONF and RESTCONF may differ but only for a good and documented reason. And I believe it does the job. Regards, Benoit > Hello, > > I apologize for commenting a bit late on the proposed charter, but I > have a concern. > > The proposal states: > > RESTCONF should not deviate from the NETCONF capabilities unless > proper justification > > is provided and documented. > > RESTCONF is currently being explored for use in many applications due > to the fact that it is a subset of NETCONF capabilities, with a > simpler implementation in servers. This is described in section 1.1 of > the current draft (i.e. "Simple Subset of NETCONF Functionality"). > > In my opinion this is a benefit of RESTCONF that cannot be lost. If > anything, the opposite strategy should be taken, in that NETCONF > capabilities should only be added to RESTCONF with a strong > justification. > > Rodney > > > > > > From: "Ersue, Mehmet (Nokia - DE/Munich)" > To: Netconf , > Date: 09/17/2015 05:25 PM > Subject: [Netconf] Draft charter update for review > Sent by: "Netconf" > > ------------------------------------------------------------------------ > > > > Dear NETCONF WG, > > please find below the draft charter update which we provided to our AD > for review. > > Comments are welcome. > > Mehmet & Mahesh > > ------------------ > > Network Configuration (netconf) > > ------------------------------- > > Charter > > Current Status: Active > > Chairs: > > Mahesh Jethanandani <_mjethanandani@gmail.com_ > > > > Mehmet Ersue <_mehmet.ersue@nokia.com_ > > > > Operations and Management Area Directors: > > Benoit Claise <_bclaise@cisco.com_ > > > Joel Jaeggli <_joelja@bogus.com_ > > > Operations and Management Area Advisor: > > Benoit Claise <_bclaise@cisco.com_ > > > Mailing Lists: > > General Discussion: _netconf@ietf.org_ > > To Subscribe: _https://www.ietf.org/mailman/listinfo/netconf_ > > Archive: _https://mailarchive.ietf.org/arch/browse/netconf/_ > > Description of Working Group: > > Configuration of networks of devices has become a critical requirement > > for operators in today's highly interconnected networks. Large and > small > > operators alike have developed their own mechanisms or have used vendor > > specific mechanisms to transfer configuration data to and from a device > > and to examine device state information which may impact the > > configuration. Each of these mechanisms may be different in various > > aspects, such as session establishment, user authentication, > > configuration data exchange, and error responses. > > The NETCONF protocol (RFC 6241) provides mechanisms to install, > manipulate, > > and delete the configuration of network devices. NETCONF is based on > the > > secure transport (SSH is mandatory to implement while TLS is an > optional > > transport) and uses an XML-based data representation. The NETCONF > protocol > > is data modeling language independent, but YANG (RFC 6020) is the > recommended > > NETCONF modeling language, which introduces advanced > > language features for configuration management. > > Recently NETCONF WG define the Call Home mechanism for NETCONF and > RESTCONF protocols > > as well as updated RFC5539 by adding the new message framing used by > NETCONF 1.1. > > Based on the implementation, deployment experience and interoperability > > testing, the WG aims to produce a NETCONF status report in a later > stage. > > The result may be clarifications for RFC6241 and RFC6242 and addressing > > any reported errata. > > In the current phase of NETCONF's incremental development the workgroup > > will focus on following items: > > 1. Combine the server configuration data models from the Call Home > and RFC5539bis drafts in a separate Server Configuration YANG module > by addressing the need for NETCONF as well as RESTCONF. > > 2. Develop RESTCONF, a protocol based on NETCONF in terms of > capabilities, but over HTTP and with some REST characteristics, for > accessing YANG data in NETCONF datastores. An "ordered edit list" > approach is needed (the YANG patch) to provide client developers with > a simpler edit request format that can be more efficient and also > allow more precise client control of the transaction procedure than > existing mechanisms. The YANG patch operation, based on the HTTP > PATCH method, will be prepared in a separate draft. > > In addition develop a YANG library, which identifies the information > about all YANG modules used by a server. Furthermore develop a > collection resource for the RESTCONF protocol to provide enhanced > filtering features for the retrieval of data nodes with the GET method. > > RESTCONF should not deviate from the NETCONF capabilities unless > proper justification is provided and documented. The RESTCONF work > will consider requirements suggested by the other working groups (for > example I2RS). > > 3. Develop a zero touch configuration document (a technique to > establish a secure network management relationship between a newly > delivered network device configured with just its factory default > settings, and the Network Management System), specific to the NETCONF > use case. > > 4. Develop a subscription and push mechanism that allows client > applications to request notifications for changes in the datastore. > These updates will be pushed by the server to the client based on a > subscription policy. > > 5. Update RFC 6536 (NETCONF Access Control Model) to introduce > access control rights associated with actions. > > 6.Enhance RFC 5277 with the ability to delete subscriptions > without closing the client session, to modify existing subscriptions, > and to have multiple subscriptions on a established client session. > These changes should not affect older clients that do not support > these particular subscription requirements. The RPCs and the data > models in RFC 5277 should be converted to YANG. > > Goals and Milestones: > > Done - Submit RFC5539bis to AD/IESG for consideration as Proposed > Standard > > Done - Submit NETCONF call home mechanism to AD/IESG for > consideration as Proposed Standard > > Oct 2015 - WGLC for RESTCONF, YANG patch operation and YANG Library > drafts > > Nov 2015 - Submit RESTCONF to AD/IESG for consideration as Proposed > Standard > > Jan 2016 - WGLC for RFC5277bis draft > > Jan 2016 - Submit RFC5277bis to AD/IESG for consideration as > Proposed Standard > > Jan 2016 - WGLC for YANG datastore push update draft > > Feb 2016 - Submit YANG datastore push update to AD/IESG for > consideration as Proposed Standard > > Feb 2016 - WGLC for RFC6536bis draft > > Feb 2016 - Submit RFC6536bis to AD/IESG for consideration as > Proposed Standard > > Feb 2016 - WGLC for zero touch configuration > > Feb 2016 - WGLC for RESTCONF Collection Resource draft > > Mar 2016 - Submit zero touch configuration to AD/IESG for > consideration as Proposed Standard > > Mar 2016 - Submit RESTCONF Collection to AD/IESG for consideration > as Proposed Standard > > Mar 2016 - WGLC for NETCONF server configuration data model > > Apr 2016 - Submit server configuration data model to AD/IESG for > consideration as > > _______________________________________________ > 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 --------------040208020404070001060506 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Rodney,

The sentence you mention tells: NETCONF and RESTCONF may differ but only for a good and documented reason.
And I believe it does the job.

Regards, Benoit

Hello,

I apologize for commenting a bit late on the proposed charter, but I have a concern.

The proposal states:
> RESTCONF should not deviate from the NETCONF capabilities unless proper justification
> is provided and documented.

RESTCONF is currently being explored for use in many applications due to the fact that it is a subset of NETCONF capabilities, with a simpler implementation in servers. This is described in section 1.1 of the current draft (i.e. "Simple Subset of NETCONF Functionality").

In my opinion this is a benefit of RESTCONF that cannot be lost. If anything, the opposite strategy should be taken, in that NETCONF capabilities should only be added to RESTCONF with a strong justification.

Rodney

From: � � � �"Ersue, Mehmet (Nokia - DE/Munich)" <mehmet.ersue@nokia.com>
To: � � � �Netconf <netconf@ietf.org>,
Date: � � � �09/17/2015 05:25 PM
Subject: � � � �[Netconf] Draft charter update for review
Sent by: � � � �"Netconf" <netconf-bounces@ietf.org>

Dear NETCONF WG,
�

please find below the draft charter update which we provided to our AD for review.

Comments are welcome.

�

Mehmet & Mahesh

�

------------------ �

�

Network Configuration (netconf)

-------------------------------

�

Charter

�

Current Status: Active

�

Chairs:

� � Mahesh Jethanandani <mjethanandani@gmail.com>

� � Mehmet Ersue <mehmet.ersue@nokia.com>

�

Operations and Management Area Directors:

� � �Benoit Claise <bclaise@cisco.com>

� � �Joel Jaeggli <joelja@bogus.com>

�

Operations and Management Area Advisor:

� � �Benoit Claise <bclaise@cisco.com>

�

Mailing Lists:

� � �General Discussion: netconf@ietf.org

� � �To Subscribe: � � � https://www.ietf.org/mailman/listinfo/netconf

� � �Archive: � � � � � �https://mailarchive.ietf.org/arch/browse/netconf/

�

Description of Working Group:

� Configuration of networks of devices has become a critical requirement

� for operators in today's highly interconnected networks. Large and small

� operators alike have developed their own mechanisms or have used vendor

� specific mechanisms to transfer configuration data to and from a device

� and to examine device state information which may impact the

configuration. Each of these mechanisms may be different in various

� aspects, such as session establishment, user authentication,

� configuration data exchange, and error responses.

�

� The NETCONF protocol (RFC 6241) provides mechanisms to install, manipulate,

� and delete the configuration of network devices. NETCONF is based on the

� secure transport (SSH is mandatory to implement while TLS is an optional

� transport) and uses an XML-based data representation. The NETCONF protocol

� is data modeling language independent, but YANG (RFC 6020) is the recommended

� NETCONF modeling language, which introduces advanced

� language features for configuration management.

�

� Recently NETCONF WG define the Call Home mechanism for NETCONF and RESTCONF protocols

� as well as updated RFC5539 by adding the new message framing used by NETCONF 1.1.

�

� Based on the implementation, deployment experience and interoperability

� testing, the WG aims to produce a NETCONF status report in a later stage.

� The result may be clarifications for RFC6241 and RFC6242 and addressing

� any reported errata.

�

� In the current phase of NETCONF's incremental development the workgroup

� will focus on following items:

�

� 1. Combine the server configuration data models from the Call Home and RFC5539bis drafts in a separate Server Configuration YANG module by addressing the need for NETCONF as well as RESTCONF.

�

� 2. Develop RESTCONF, a protocol based on NETCONF in terms of capabilities, but over HTTP and with some REST characteristics, for accessing YANG data in NETCONF datastores. An "ordered edit list" approach is needed (the YANG patch) to provide client developers with a simpler edit request format that can be more efficient and also allow more precise client control of the transaction procedure than existing mechanisms. The YANG patch operation, based on the �HTTP PATCH method, will be prepared in a separate draft.

In addition develop a YANG library, which identifies the information about all YANG modules used by a server. Furthermore develop a collection resource for the RESTCONF protocol to provide enhanced filtering features for the retrieval of data nodes with the GET method.

RESTCONF should not deviate from the NETCONF capabilities unless proper justification is provided and documented. The RESTCONF work will consider requirements suggested by the other working groups (for example I2RS).

�

� � 3. Develop a zero touch configuration document (a technique to establish a secure network management relationship between a newly delivered network device configured with just its factory default settings, and the Network Management System), specific to the NETCONF use case.

�

� � 4. Develop a subscription and push mechanism that allows client applications to request notifications for changes in the datastore. These updates will be pushed by the server to the client based on a subscription policy.

�

� � 5. Update RFC 6536 (NETCONF Access Control Model) to introduce access control rights associated with actions.

�

� � 6.Enhance RFC 5277 with the ability to delete subscriptions without closing the client session, to modify existing subscriptions, and to have multiple subscriptions on a established client session. These changes should not affect older clients that do not support these particular subscription requirements. The RPCs and the data models in RFC 5277 should be converted to YANG.

�

Goals and Milestones:

�

� Done - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard

� Done - Submit NETCONF call home mechanism to AD/IESG for consideration as Proposed Standard

�

� Oct 2015 - WGLC for RESTCONF, YANG patch operation and YANG Library drafts

� Nov 2015 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard

�

� Jan 2016 - WGLC for RFC5277bis draft

� Jan 2016 - Submit RFC5277bis to AD/IESG for consideration as Proposed Standard

� Jan 2016 - WGLC for YANG datastore push update draft

� Feb 2016 - Submit YANG datastore push update to AD/IESG for consideration as Proposed Standard

�

� Feb 2016 - WGLC for RFC6536bis draft

� Feb 2016 - Submit RFC6536bis to AD/IESG for consideration as Proposed Standard

�

� Feb 2016 - WGLC for zero touch configuration

� Feb 2016 - WGLC for RESTCONF Collection Resource draft

� Mar 2016 - Submit zero touch configuration to AD/IESG for consideration as Proposed Standard

� Mar 2016 - Submit RESTCONF Collection to AD/IESG for consideration as Proposed Standard

�

� Mar 2016 - WGLC for NETCONF server configuration data model

� Apr 2016 - Submit server configuration data model to AD/IESG for consideration as

�

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

--------------040208020404070001060506-- From nobody Wed Sep 30 08:20:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FEA1B5EA2 for ; Wed, 30 Sep 2015 08:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3-zoqHENiWW for ; Wed, 30 Sep 2015 08:20:23 -0700 (PDT) Received: from ni.com (skprod2.natinst.com [130.164.80.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F322F1B5EA1 for ; Wed, 30 Sep 2015 08:20:22 -0700 (PDT) Received: from US-AUS-MAIL4.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod2.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id t8UFKHSS015939; Wed, 30 Sep 2015 10:20:17 -0500 In-Reply-To: <560BC1E0.6080601@cisco.com> References:

<560BC1E0.6080601@cisco.com> To: Benoit Claise MIME-Version: 1.0 X-KeepSent: E9D5675C:2385FF3E-86257ED0:0051DE65; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP6 November 22, 2013 From: Rodney Cummings Message-ID: Date: Wed, 30 Sep 2015 10:20:17 -0500 X-MIMETrack: Serialize by Router on US-AUS-MAIL4/AUS/M/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 09/30/2015 10:20:17 AM, Serialize complete at 09/30/2015 10:20:17 AM Content-Type: multipart/alternative; boundary="=_alternative 0054413586257ED0_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-30_11:, , signatures=0 Archived-At: Cc: Netconf Subject: Re: [Netconf] Draft charter update for review 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: