From nobody Mon May 2 07:06:18 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F31A12D534; Mon, 2 May 2016 07:06:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502140615.15715.33581.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 07:06:15 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-traceability-09.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:06:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : Interface to the Routing System (I2RS) Traceability: Framework and Information Model Authors : Joe Clarke Gonzalo Salgueiro Carlos Pignataro Filename : draft-ietf-i2rs-traceability-09.txt Pages : 14 Date : 2016-05-02 Abstract: This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-traceability-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 2 07:20:49 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B9B12D0AD for ; Mon, 2 May 2016 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.496 X-Spam-Level: X-Spam-Status: No, score=-14.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki66YjXfdCK9 for ; Mon, 2 May 2016 07:20:46 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB8412D0B9 for ; Mon, 2 May 2016 07:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2766; q=dns/txt; s=iport; t=1462198846; x=1463408446; h=subject:references:cc:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Jtw1VBu277GeBkBbdXOtaDj8t8fMOIttBBRg4eCIlRY=; b=DqXoeq5mZBi/AR6eM8lcX1hWiIS9MNNumvCg3wcCtmf4+E/8j8BYSxQp Or+4BIW+FfIHl/H7cjlii7WoQ18j/4jDB+/CHFMgeWdFhdrw1MJzD5xqI bE36k/eQrcBn9aJ7v1m/9oAUfeZ6eYaFhy9EQG7cMmjEvaji8doKPVugJ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AwCmYSdX/5NdJa1dgzhTK0YMpk2Jb?= =?us-ascii?q?4k5AQ2BdhcLhW4CKIEDOBQBAQEBAQEBZSeEOQkBAQQBAQE1NgsQCxIGLiciDhM?= =?us-ascii?q?GAgEBhW6COA65XAEBAQEBAQEDAQEBAQEBGoYhgXaCVodNgkYBBJgUhXyCd4Ulg?= =?us-ascii?q?WdOg3+DBoVXjzEeAQFChAcgMIkHAQEF?= X-IronPort-AV: E=Sophos;i="5.24,567,1454976000"; d="scan'208";a="267916694" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2016 14:20:45 +0000 Received: from [10.117.46.165] (rtp-jclarke-8914.cisco.com [10.117.46.165]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u42EKjO6008674 for ; Mon, 2 May 2016 14:20:45 GMT References: <20160502140615.15715.33581.idtracker@ietfa.amsl.com> Cc: i2rs@ietf.org From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <22db73b0-99dd-648c-2c7c-783891a5d236@cisco.com> Date: Mon, 2 May 2016 10:20:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160502140615.15715.33581.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-traceability-09.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:20:48 -0000 This latest version of the draft incorporates the routing directorate review. Of biggest note is that a new Request State field has been added in order to log different states of an operation request within the I2RS Agent state machine. By using this field, one could time how long a request remains queued, in active process, and the total time it takes for the request to move from reception to completion. An I2RS Agent MAY choose to log these individual state transitions, but it MUST log the COMPLETED state change. Additionally, while minor, we updated the "down arrowhead" from 'V' to 'v' given that now two people have commented on some confusion here. We hope it helps improve clarity. Joe On 5/2/16 10:06, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System of the IETF. > > Title : Interface to the Routing System (I2RS) Traceability: Framework and Information Model > Authors : Joe Clarke > Gonzalo Salgueiro > Carlos Pignataro > Filename : draft-ietf-i2rs-traceability-09.txt > Pages : 14 > Date : 2016-05-02 > > Abstract: > This document describes a framework for traceability in the Interface > to the Routing System (I2RS) and information model for that > framework. It specifies the motivation, requirements, use cases, and > defines an information model for recording interactions between > elements implementing the I2RS protocol. This framework provides a > consistent tracing interface for components implementing the I2RS > architecture to record what was done, by which component, and when. > It aims to improve the management of I2RS implementations, and can be > used for troubleshooting, auditing, forensics, and accounting > purposes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-traceability-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue May 3 01:52:46 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B81512D679; Tue, 3 May 2016 01:52:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503085242.7557.50387.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 01:52:42 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, jiangsheng@huawei.com Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 08:52:42 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-pub-sub-requirements-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Three DISCUSS points, which could be easily resolved IMO. 1. As mentioned on the NETMOD mailing list by Tom Petch, don't redefine the YANG datastore term: > I see that the definition of 'datastores' has cropped up in this AD > Review, as in the e-mail below. > > Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last > Call and redefines, or recreates, the term for us > > A YANG datastore is a conceptual datastore that contains hierarchical > data defined in YANG data models. It is what is referred in existing > RFCs as "NETCONF datastore". However, as the same datastore is no > longer tied to NETCONF as a specific transport, the term "YANG > datastore" is deemed more appropriate. > > I think that the concept of datastore has been troublesome to those > coming to YANG lately, such as openconfig and I2RS, and that this will > just muddy the waters more, especially as it is tucked away in an > Informational document. If I2RS want to define such terminology, then > it should be in the I2RS Architecture or some such; but IMHO they should > not be defining YANG datastores at all. 2. Maybe I read too much into this (at the time of specifying the operational state in NETMOD) ... A Subscription Service MUST be able support a Subtree Filter so that subscribed updates under a target node might publish only operational data, only configuration data, or both. Proposal: s/Subtree Filter/Filter 3. In the security considerations section Versioning MUST be supported. Versioning of what? Yang push protocol, subscription, transport session, state of of subscription, something else? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Editorial Based on current I2RS requirements, NETCONF should the initially supported transport based on the need for connection-oriented/unicast communication. s/should/should be - Editorial: A Subscription MAY include filters as defined s/filters/Filters Note: there are multiple instances of filter -> Filter - AND is not a RFC2119 keyword For "on-change" notifications, passing through the Filter requires that a subscribed object is now different that from the previous Push, AND at least one of the YANG objects being evaluated has changed since the last Update. - I always wonder what a MAY requirement means? Example: A Subscriber MAY check with a Subscription Service to validate the existence and monitored subtrees of a Subscription. Or: A Subscription Service MAY send Updates over Best Effort and Reliable transports. What if https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ doesn't address this requirement (I haven't checked), are we good or not? From nobody Tue May 3 06:22:28 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 948C012D809; Tue, 3 May 2016 06:22:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503132225.7451.45289.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 06:22:25 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, menachemdodge1@gmail.com Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 13:22:25 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-traceability-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to DISCUSS the following point. - From https:/https://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-06, section 2.1 From [i2rs-arch], there are references throughout the document beginning in section 6.2. Some specific examples include: ... o section 6.3 notes that when local config preempts I2RS, external notification might be necessary What about the local configuration, https://tools.ietf.org/html/draft-ietf-i2rs-architecture-15#section-6.3 ? Is this logged? >From the client address, it seems that local is not covered. Should it be? Client Address: This is the network address of the Client that connected to the Agent. For example, this may be an IPv4 or IPv6 address. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Syslog rfc5424 Let's make the RFC2119 sentence clear (include the "If", and remove "example") Background: last time I checked (about 6 months ago), RFC5424 was not implemented OLD: If syslog is used for trace log retrieval, then existing logging infrastructure and capabilities of syslog [RFC5424] should be leveraged without the need to define or extend existing formats. For example, the various fields described in Section 5.2 SHOULD be modeled and encoded as Structured Data Elements (referred to as "SD- ELEMENT"), as described in Section 6.3.1 of [RFC5424]. NEW: If syslog is used for trace log retrieval, then existing logging infrastructure and capabilities of syslog [RFC5424] should be leveraged without the need to define or extend existing formats. If syslog is used for trace log retrieval, the various fields described in Section 5.2 SHOULD be modeled and encoded as Structured Data Elements (referred to as "SD- ELEMENT"), as described in Section 6.3.1 of [RFC5424]. - Out of the 3 methods for trace log retrieval (section 7.4), I was expecting the pub-sub to be THE method, and was expecting a MUST requirement. Background: I just reviewed draft-ietf-i2rs-pub-sub-requirements-06. Do I miss anything? - Editorial PENDING: The request has been receieved and queued for processing. s/receieved/received - Below is Menachem's question, part of his OPS-DIR review: As section 5.2 is labeled "I2RS Trace Log Mandatory Fields", I am wondering whether it is allowed to have additional optional fields. For example an optional "Additional Text" field may be useful, to provide additional information in certain situations. From nobody Tue May 3 07:36:07 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D05C12D0CC; Tue, 3 May 2016 07:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8baPvtQ1bWzA; Tue, 3 May 2016 07:36:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D356D12D83F; Tue, 3 May 2016 07:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3742; q=dns/txt; s=iport; t=1462286148; x=1463495748; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ItJBHORv3vU00ZFOUVEpewnk/SZYlPpOooXBA21PRwQ=; b=PgW2A7nmRY4Jk0J+CiuKCDjsBdT7O6gbsNkSc0bWGmOC3dRtL+JQtfxd lbj5vEubenOkzBz5rE1y7Z//Z/TuJcQOrphlKy8Jtwv4iD841uEp7moNz y5iksJI5KslSIYBhOUdKTUcNnaErJp92LBVAHQz31Fos6w/YCzOyt3CgM 8=; X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="98589634" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 14:35:48 +0000 Received: from [10.117.46.165] (rtp-jclarke-8914.cisco.com [10.117.46.165]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u43EZl1i009409; Tue, 3 May 2016 14:35:47 GMT To: Benoit Claise , The IESG References: <20160503132225.7451.45289.idtracker@ietfa.amsl.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <86fc3f80-17ac-8449-67ac-3b9729942557@cisco.com> Date: Tue, 3 May 2016 10:35:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160503132225.7451.45289.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, menachemdodge1@gmail.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:36:06 -0000 On 5/3/16 09:22, Benoit Claise wrote: > I would like to DISCUSS the following point. Thanks for your comments, Benoit. See below. > - From > https:/https://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-06, > section 2.1 > > From [i2rs-arch], there are > references throughout the document beginning in section 6.2. > Some > specific examples include: > > ... > > o section 6.3 notes that when local config preempts I2RS, > external > notification might be necessary > > What about the local configuration, > https://tools.ietf.org/html/draft-ietf-i2rs-architecture-15#section-6.3 ? > Is this logged? >>From the client address, it seems that local is not covered. Should it > be? I am of the opinion that I2Rs-relevant preemptive changes to the running datastore should behave like an I2RS Client. I know this isn't the case now. The current traceability model requires logging to be done by the I2RS Agent. If an I2RS-relevant change to the running datastore is passed to the Agent, then the Agent MUST log it. In this manner I would say we should add some text to the description of Client Address that makes it clear that the Client can be the network element itself. What about: "...an IPv4 or IPv6 address. In the case where changes to the network element's running datastore preempt state set by the I2RS Agent, the Client Address will be an address of the network element itself." > - Syslog rfc5424 > > Let's make the RFC2119 sentence clear (include the "If", and remove > "example") > Background: last time I checked (about 6 months ago), RFC5424 was not > implemented > OLD: > If syslog is used for trace log retrieval, then existing logging > infrastructure and capabilities of syslog [RFC5424] should be > leveraged without the need to define or extend existing formats. For > example, the various fields described in Section 5.2 SHOULD be > modeled and encoded as Structured Data Elements (referred to as "SD- > ELEMENT"), as described in Section 6.3.1 of [RFC5424]. > > NEW: > If syslog is used for trace log retrieval, then existing logging > infrastructure and capabilities of syslog [RFC5424] should be > leveraged without the need to define or extend existing formats. > If syslog is used for trace log retrieval, the various fields > described in Section 5.2 SHOULD be modeled and encoded as > Structured Data Elements (referred to as "SD- > ELEMENT"), as described in Section 6.3.1 of [RFC5424]. Accepted. > > - Out of the 3 methods for trace log retrieval (section 7.4), I was > expecting the pub-sub to be THE method, and was expecting a MUST > requirement. > Background: I just reviewed draft-ietf-i2rs-pub-sub-requirements-06. > Do I miss anything? We can certainly make it a MUST. When our draft began, pub-sub was just getting started. I personally like having pub-sub as THE method. > > - Editorial > > PENDING: The request has been receieved and queued for > processing. > > s/receieved/received Accepted. > > - Below is Menachem's question, part of his OPS-DIR review: > As section 5.2 is labeled "I2RS Trace Log Mandatory Fields", I am > wondering whether it is allowed to have additional optional fields. For > example an optional "Additional Text" field may be useful, to provide > additional information in certain situations. It seems a bit nebulous to me. I know this isn't your comment, but I would appreciate an example of additional context one might want to log. I imagine if we added that others might ask, "like what? In what situations?" Joe From nobody Tue May 3 07:50:55 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE5912D82A; Tue, 3 May 2016 07:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWtPUxsQGfR9; Tue, 3 May 2016 07:50:51 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE301200A0; Tue, 3 May 2016 07:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2825; q=dns/txt; s=iport; t=1462287049; x=1463496649; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=djZRo7Hh57jpC/cmlLdQbiEgcEDIZhjtaECtP8jgmKM=; b=Io42U2DDRC9xFcC0AKTWuI73E/B3gmHuqz7YltvZBFD42azyi7auV2XJ zVvk+CJxCYqxGnTa3c4JRRXwXRMXpk+oHUq8QnpO+pvBqn+i3d+fLkCbG mZT5MfdWhjxiImvQvqih62QTfZUxIv8+ucRcqsRgBqHU/1nS2G2JO1Sc7 s=; X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="634437951" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 14:50:47 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u43Eokc2018802; Tue, 3 May 2016 14:50:46 GMT To: Joe Clarke , The IESG References: <20160503132225.7451.45289.idtracker@ietfa.amsl.com> <86fc3f80-17ac-8449-67ac-3b9729942557@cisco.com> From: Benoit Claise Message-ID: <5728BAC5.4000704@cisco.com> Date: Tue, 3 May 2016 16:50:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <86fc3f80-17ac-8449-67ac-3b9729942557@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, menachemdodge1@gmail.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:50:53 -0000 Hi Joe, Thanks for engaging. > >> - From >> https:/https://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-06, >> >> section 2.1 >> >> From [i2rs-arch], there are >> references throughout the document beginning in section 6.2. >> Some >> specific examples include: >> >> ... >> >> o section 6.3 notes that when local config preempts I2RS, >> external >> notification might be necessary >> >> What about the local configuration, >> https://tools.ietf.org/html/draft-ietf-i2rs-architecture-15#section-6.3 >> ? >> Is this logged? >>> From the client address, it seems that local is not covered. Should it >> be? > > I am of the opinion that I2Rs-relevant preemptive changes to the > running datastore should behave like an I2RS Client. I know this > isn't the case now. "I'll create a new management interface, and since all changes, ever, will come through my new management interface, I won't have any problem!" You and I heard that story a couple of time in our OPS careers, right :-) Did that behavior ever end up as expected? > The current traceability model requires logging to be done by the I2RS > Agent. If an I2RS-relevant change to the running datastore is passed > to the Agent, then the Agent MUST log it. In this manner I would say > we should add some text to the description of Client Address that > makes it clear that the Client can be the network element itself. > What about: > > "...an IPv4 or IPv6 address. In the case where changes to the network > element's running datastore preempt state set by the I2RS Agent, the > Client Address will be an address of the network element itself." That solves one aspect of the problem. The fact is that we have multiple management interfaces to manage what I2RS care about. At the very minimum two: CLI and the I2RS agent. The I2RS agent will log what it knows. Obviously, it doesn't know what it doesn't know. Assuming that someone uses the CLI, the log will be useless. At the very minimum, we need a big capital letter warning: your log might not be as useful as they pretend to be. > > > >> >> - Below is Menachem's question, part of his OPS-DIR review: >> As section 5.2 is labeled "I2RS Trace Log Mandatory Fields", I am >> wondering whether it is allowed to have additional optional fields. For >> example an optional "Additional Text" field may be useful, to provide >> additional information in certain situations. > > It seems a bit nebulous to me. I know this isn't your comment, but I > would appreciate an example of additional context one might want to > log. I imagine if we added that others might ask, "like what? In > what situations?" I let Menachem follow up on this one. Regards, Benoit From nobody Tue May 3 08:22:29 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A6812D8EE; Tue, 3 May 2016 08:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwwD2BL_c3Va; Tue, 3 May 2016 08:22:26 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B7D12D90D; Tue, 3 May 2016 08:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2211; q=dns/txt; s=iport; t=1462288850; x=1463498450; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=16GtdN/AED9KraYQ8MVcVcw41JDi11XcnM9o3q7k+dk=; b=MEnY/wfNz099ZVBG/9FtqXoE3x/TJBXyCLBQBIS9SSWd5b2NyypxdrPo qyEo4aS3ihfur76R/eVIdEsxprcQMstkVRXSdCIuukT6SMyDSBQPXJwEA 7Yjgxqae2dgInBJEcYStSXaUxG3Snal+qPmv5mzAlBnQZ1j2iq63OSbpk 0=; X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="267578823" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 15:20:49 +0000 Received: from [10.117.46.165] (rtp-jclarke-8914.cisco.com [10.117.46.165]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u43FKmf1027900; Tue, 3 May 2016 15:20:48 GMT To: Benoit Claise , The IESG References: <20160503132225.7451.45289.idtracker@ietfa.amsl.com> <86fc3f80-17ac-8449-67ac-3b9729942557@cisco.com> <5728BAC5.4000704@cisco.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <096a7e2d-2e5f-6ec7-88ad-4a1b95644239@cisco.com> Date: Tue, 3 May 2016 11:20:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <5728BAC5.4000704@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, menachemdodge1@gmail.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:22:28 -0000 On 5/3/16 10:50, Benoit Claise wrote: >> I am of the opinion that I2Rs-relevant preemptive changes to the >> running datastore should behave like an I2RS Client. I know this >> isn't the case now. > "I'll create a new management interface, and since all changes, ever, > will come through my new management interface, I won't have any problem!" > You and I heard that story a couple of time in our OPS careers, right > :-) Did that behavior ever end up as expected? Of course. I do everything via SNMP :-). >> The current traceability model requires logging to be done by the I2RS >> Agent. If an I2RS-relevant change to the running datastore is passed >> to the Agent, then the Agent MUST log it. In this manner I would say >> we should add some text to the description of Client Address that >> makes it clear that the Client can be the network element itself. >> What about: >> >> "...an IPv4 or IPv6 address. In the case where changes to the network >> element's running datastore preempt state set by the I2RS Agent, the >> Client Address will be an address of the network element itself." > That solves one aspect of the problem. > > The fact is that we have multiple management interfaces to manage what > I2RS care about. At the very minimum two: CLI and the I2RS agent. > The I2RS agent will log what it knows. Obviously, it doesn't know what > it doesn't know. Assuming that someone uses the CLI, the log will be > useless. > At the very minimum, we need a big capital letter warning: your log > might not be as useful as they pretend to be. Is that warning really required? Architecturally, the I2RS Agent is clearly in the path. If the I2RS Agent knows about a change (either via a northbound Client or the network element preempting state), then it logs it. If a network element chooses not to notify the Agent, then like you say, we can't log what we don't know. If you feel strongly that this be explicitly called out, I think the best section might be "Trace Log Creation". It could be stated that preemptive changes outside the I2RS protocol in which the network element does not notify the Agent of state will not be logged. Joe From nobody Tue May 3 14:23:42 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB8412D91C; Tue, 3 May 2016 14:23:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503212341.8280.41838.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 14:23:41 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-traceability-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 21:23:41 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-traceability-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5.2: Starting Timestamp and Ending Timestamp It is not clear what the terms 32-bit second and 32-bit microsecond mean here as the RFC3339 format seems to be a string representation (e.g. the seconds value will never be more than 59). It may be useful to restate these granularity requirements in terms of number of digits required after the decimal point instead Section 5.2: Entry ID Some more clarity as to how Entry IDs work would be useful. e.g. Is this a monotonically increasing integer? What happens when this wraps? What happens when the log file is rotated etc. From nobody Tue May 3 17:23:08 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A985F12DC0F; Tue, 3 May 2016 17:23:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504002307.8276.60759.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 17:23:07 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 00:23:07 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-pub-sub-requirements-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have what I hope are two very easily sorted things that I'd like to chat about: (1) 4.2.5, para2: Hang on - this is 2016 isn't it? :-) Why would we ever have a pub/sub service whose subscribers can pretend to be the service? (2) Don't you need a statement somewhere that commensurate security needs to be provided for pushed notifications as was used for the original subscription? That might be a little hard to phrase correctly but I hope we agree that the notifications ought not be significantly less secure than the subscription. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I wondered if this was maybe of interest to more than just i2rs, and if so, whether any effort had been made to try figure out if these requirements work for folks who don't care about i2rs? It'd seem a shame to work on this but stop one step short of being appropriately general. (But you probably already checked that I guess.) - 4.2.2, last para: The MUST here seems like it may be quite onerous, in general. Did someone think all of that through? For example, what if the reason for declining is that the Subscriber doesn't have sufficient privilege? Saying what privilege is needed would be a breach of least-privilege. Transient errors may also make this very hard to do well. I'd suggest s/MUST/MAY/ and to also turn the information returned into a hint and not a promise. - 4.2.5, para 1: saying there "MUST be mutual authentication" is odd - the usual terms would be "MUST implement" or "MUST use" which of those does "MUST be" mean? - 4.2.8: when you say fetch... by whom? Is there an implicit requirement in the title of the subsection? From nobody Wed May 4 03:11:56 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF4D12D120; Wed, 4 May 2016 03:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5FOLK-B3f8l; Wed, 4 May 2016 03:11:53 -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 1F37E12D106; Wed, 4 May 2016 03:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2643; q=dns/txt; s=iport; t=1462356712; x=1463566312; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=YsRIjlkF2C81advOvV+NWv4UkvdXYgtOG3HIEMy5IK8=; b=FT1wm+jRczM7SY4xsvqEHn20J9LR05LCBN3SdUZcxQHYR+sGcA5BCCKY jcZBWdQrXOTArgMm1FpApcWPzsHMNbRXJCoBTZCCKFRPhymmJFgvEGgbU 9tRQQ8e1syDma8EBnMy2Mp8wob+AcoZgMW8YdXriogNR8XQ3oj4eyyuCT c=; X-IronPort-AV: E=Sophos;i="5.24,576,1454976000"; d="scan'208";a="635471410" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2016 10:11:50 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u44ABn2j030242; Wed, 4 May 2016 10:11:49 GMT To: Joe Clarke , The IESG References: <20160503132225.7451.45289.idtracker@ietfa.amsl.com> <86fc3f80-17ac-8449-67ac-3b9729942557@cisco.com> <5728BAC5.4000704@cisco.com> <096a7e2d-2e5f-6ec7-88ad-4a1b95644239@cisco.com> From: Benoit Claise Message-ID: <5729CAE5.7030403@cisco.com> Date: Wed, 4 May 2016 12:11:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <096a7e2d-2e5f-6ec7-88ad-4a1b95644239@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, menachemdodge1@gmail.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 10:11:55 -0000 Joe, > On 5/3/16 10:50, Benoit Claise wrote: >>> I am of the opinion that I2Rs-relevant preemptive changes to the >>> running datastore should behave like an I2RS Client. I know this >>> isn't the case now. >> "I'll create a new management interface, and since all changes, ever, >> will come through my new management interface, I won't have any >> problem!" >> You and I heard that story a couple of time in our OPS careers, right >> :-) Did that behavior ever end up as expected? > > Of course. I do everything via SNMP :-). > >>> The current traceability model requires logging to be done by the I2RS >>> Agent. If an I2RS-relevant change to the running datastore is passed >>> to the Agent, then the Agent MUST log it. In this manner I would say >>> we should add some text to the description of Client Address that >>> makes it clear that the Client can be the network element itself. >>> What about: >>> >>> "...an IPv4 or IPv6 address. In the case where changes to the network >>> element's running datastore preempt state set by the I2RS Agent, the >>> Client Address will be an address of the network element itself." >> That solves one aspect of the problem. >> >> The fact is that we have multiple management interfaces to manage what >> I2RS care about. At the very minimum two: CLI and the I2RS agent. >> The I2RS agent will log what it knows. Obviously, it doesn't know what >> it doesn't know. Assuming that someone uses the CLI, the log will be >> useless. >> At the very minimum, we need a big capital letter warning: your log >> might not be as useful as they pretend to be. > > Is that warning really required? Architecturally, the I2RS Agent is > clearly in the path. If the I2RS Agent knows about a change (either > via a northbound Client or the network element preempting state), then > it logs it. If a network element chooses not to notify the Agent, > then like you say, we can't log what we don't know. The issue is that the I2RS architecture is not really an architecture. https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ballot/#benoit-claise Anyway ... > > If you feel strongly that this be explicitly called out, I think the > best section might be "Trace Log Creation". It could be stated that > preemptive changes outside the I2RS protocol, > in which the network element does not notify the Agent of state will > not be logged. Agreed that this is the best we can do. That would solve my DISCUSS. Please add "typically local configuration", as this is mentioned in different I2RS documents. Regards, B. > > Joe > . > From nobody Wed May 4 09:43:33 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F5012DA79; Wed, 4 May 2016 09:43:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504164332.8280.38602.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 09:43:32 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:43:32 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-traceability-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Intro: I don't agree that all data retention aspects are out of scope here. They are about as in-scope as log rotation I'd say. I do think it'd be worthwhile noting that if log content contains sensitive data (either security- or privacy-sensitive) then retaining that data for extended durations has a cost, in terms of creating risks if data leaks. While one cannot say here how to evaluate such risks, they do exist and should really be noted. It would also be sensible IMO to say that implementations SHOULD provide a way to purge ancient log content that is no longer needed or useful, but that the definition of when content is no longer needed or useful is out of scope. In saying this I do recognise that much or perhaps even most i2rs log content will not be security or privacy sensitive, but in some cases it can be, e.g. if an operation involved an address that is specific to a user or device carried by a user. In addition, some data retention regimes could impose a requirement to purge log content after a certain duration. I'd say a note about this in the intro or in the security considerations should be a fine way to handle this issue, and to acknowledge that not all data retention issues are out of scope for implementations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 5.2: Requested/Applied Operation Data - I would guess this can include sensitive values, e.g. keys/passwords. Shouldn’t you say to at least be careful of those, or perhaps to not log them, or to zero out known sensitive values before logging? - 7.2: how is privacy an implementation detail? - 7.4: What does "being preferred" mean in 2119 terms? Why is one of the three options not mandatory-to-implement? From nobody Wed May 4 11:49:00 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B53912D58E; Wed, 4 May 2016 11:48:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 11:48:56 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 18:48:56 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2rs-pub-sub-requirements-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple of points I would like to discuss. Hopefully they can be resolved easily: Are there really no requirements for privacy or integrity protection? Is there an expectation that this mechanism would ever carry privacy sensitive or otherwise sensitive information? - 4.2.5, 2nd to last paragraph: I am surprised to find that, when the receiver is not the subscriber, that the receiver is expected to opt-out. It seems like some form of opt-in or affirmative consent would be needed here. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - General: I support Stephen's DISCUSS -2.2: What is the real scope of this work? Is it expected to supplant the mentioned mechanisms? - 2.3: "We need a new pub-sub technology" The shepherd write up mentioned a goal to use existing technologies. Is the point of this sentence to suggest that is not feasible? - 4.1, 4th paragraph: The MAY doesn't seem right--is this a statement of fact that the subscriber may have to resubscribe, or a requirement of the form that the service MAY force the subscriber to resubscribe? (Be careful with MAYs in requirements language--they imply unexpected things. For example, several requirements say a SUBSCRIBE MAY do something--do those imply that the service MUST allow the subscriber to do it ?) -- 4.2.2, third bullet: The previous section said dampening periods MUST be supported. - 4.2.1, third paragraph: This is a bit ambiguous. I think it means to change the what subtrees the subscription applies to, but could be interpreted to change the subtrees themselves. - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but gave the subscriber a way to reconstruct the order fulfill this requirement? Nits: - The shepherd write up suggests this is standards track. The draft and tracker both say informational. Please update the shepherd writ up. -3, last paragraph: What's the difference between a "Push" and an "Update"? -4.1: A forward reference to the subscription QoS section would be helpful. -- Last paragraph, last sentence: Sentence doesn't parse. - 4.2.8, third paragraph: I don't think that should be a 2119 MAY From nobody Wed May 4 12:44:22 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2A512D1AF; Wed, 4 May 2016 12:44:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504194420.8362.76100.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 12:44:20 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-pub-sub-requirements-06: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 19:44:20 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-pub-sub-requirements-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Ben's and Stephen's DISCUSSes. From nobody Wed May 4 13:04:09 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC9E12D6B1; Wed, 4 May 2016 13:03:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504200358.8260.69796.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 13:03:58 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-traceability-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 20:03:58 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-traceability-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given that this is a framework document, rather than repeatedly declaring various operational aspects "out of scope" (7 times in 12 pages by my count), I would suggest just stating the requirements and guidance that are in scope. Readers should not be expecting to find lots of implementation details in this document. This would provide more clarity than saying that details are out of scope, but then specifying some of them anyway (e.g., for log trace rotation in 7.3). I agree with Stephen's DISCUSS and COMMENT. From nobody Wed May 4 14:59:06 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968EE12D9AE; Wed, 4 May 2016 14:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 005XYOgCyVrU; Wed, 4 May 2016 14:59:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D263012D909; Wed, 4 May 2016 14:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3217; q=dns/txt; s=iport; t=1462399143; x=1463608743; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=dzEutTncCHIY9Ett/ejI8iYu2wufxsemLuZfrLNBvxU=; b=C0yJL8bylEbABln0WXNTfGqR6Xf/JL+gwwdROZ+xmBJt/cUhQtIIlby3 I/KWHOBrc4XYYq2H0v624BExlmK2KrPs6GsNzwcv55kvS6HQtVN1qxAHX mmFvPIIzV7l15FGyERA/t8yXRRYXBNXXBU3D1QxnvXTg+lle3CouuRxda 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlBQCDbypX/5ldJa1egzh+uC6EE4YQA?= =?us-ascii?q?oE8OxEBAQEBAQEBZSeEQgEBBCMPAQUvEhALGgImAgJXBgEMCAEBiCatE5B3AQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBGHyDCIIcgXaCVoQrgxSCWQEEhWyCDJAhi1+COYFoh?= =?us-ascii?q?1MjhTWPNDYsggUbFoFRIIdMAR8EgRoBAQE?= X-IronPort-AV: E=Sophos;i="5.24,579,1454976000"; d="scan'208";a="104651017" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2016 21:59:02 +0000 Received: from [10.117.46.165] (rtp-jclarke-8914.cisco.com [10.117.46.165]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u44Lx1JI000952; Wed, 4 May 2016 21:59:01 GMT To: Stephen Farrell , The IESG References: <20160504164332.8280.38602.idtracker@ietfa.amsl.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <5c9b1a61-ade4-8f4c-f754-1b500d2b3b4b@cisco.com> Date: Wed, 4 May 2016 17:59:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160504164332.8280.38602.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 21:59:04 -0000 On 5/4/16 12:43, Stephen Farrell wrote: Thanks for your feedback, Stephen. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > Intro: I don't agree that all data retention aspects are > out of scope here. They are about as in-scope as log > rotation I'd say. I do think it'd be worthwhile noting that > if log content contains sensitive data (either security- or > privacy-sensitive) then retaining that data for extended > durations has a cost, in terms of creating risks if data > leaks. While one cannot say here how to evaluate such > risks, they do exist and should really be noted. It would > also be sensible IMO to say that implementations SHOULD > provide a way to purge ancient log content that is no > longer needed or useful, but that the definition of when > content is no longer needed or useful is out of scope. In > saying this I do recognise that much or perhaps even most > i2rs log content will not be security or privacy sensitive, > but in some cases it can be, e.g. if an operation involved > an address that is specific to a user or device carried by > a user. In addition, some data retention regimes could > impose a requirement to purge log content after a certain > duration. I'd say a note about this in the intro or in the > security considerations should be a fine way to handle this > issue, and to acknowledge that not all data retention > issues are out of scope for implementations. Would changing the Trace Log Temporary Storage section alone be sufficient? I have changed that section to read: "It is outside the scope of this document to specify the implementation details (i.e., size, throughput, data protection, etc.) for the physical storage of the I2RS log file. In terms of data retention, attention should be paid the length of time I2RS trace log data is kept when that data contains security or privacy-sensitive attributes. The longer this data is retained, the more risk is incurred if it were to be leaked." Would you prefer I make reference to this in the Security Considerations as well? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 5.2: Requested/Applied Operation Data - I would guess > this can include sensitive values, e.g. keys/passwords. > Shouldn’t you say to at least be careful of those, or > perhaps to not log them, or to zero out known sensitive > values before logging? There is text in the Security Considerations section that says: "Additionally, the potentially sensitive information contained in a log file SHOULD be adequately anonymized or obfuscated by operators to ensure its privacy." Are you suggesting we explicitly call out the Op Data fields here? > > - 7.2: how is privacy an implementation detail? I pulled out privacy. > > - 7.4: What does "being preferred" mean in 2119 terms? Why > is one of the three options not mandatory-to-implement? The current [un-published] version makes pub-sub MTI. Joe From nobody Wed May 4 15:11:57 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3396E12D18E; Wed, 4 May 2016 15:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjvWffXvXVfT; Wed, 4 May 2016 15:11:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F21712D516; Wed, 4 May 2016 15:11:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 000E6BE79; Wed, 4 May 2016 23:11:49 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVQDTxwChVNr; Wed, 4 May 2016 23:11:48 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.26.141]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A290CBE5C; Wed, 4 May 2016 23:11:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462399908; bh=Yu4XEufDQ079I0VsN8+roC1QvHIgHhVr2RgeVrGt8sg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=l/I2hx/C4QSZjtiAd6q9FG6HjzkVtrpCaswq/A5aYCivITYA6h5DRulXHf5xTxRcY khrvtdufUXJBxppmF/fPnzigY8fzio4GfgiIiCxsN+2vDRPPISP0d+q1rUaKfr76P6 4GkJVLqxOiutIXj91hyDcWEQes0MqvDpNR6gtdLo= To: Joe Clarke , The IESG References: <20160504164332.8280.38602.idtracker@ietfa.amsl.com> <5c9b1a61-ade4-8f4c-f754-1b500d2b3b4b@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <572A73A0.6080609@cs.tcd.ie> Date: Wed, 4 May 2016 23:11:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5c9b1a61-ade4-8f4c-f754-1b500d2b3b4b@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080406060902060107030906" Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 22:11:56 -0000 This is a cryptographically signed message in MIME format. --------------ms080406060902060107030906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joe, Those are all fine changes. Couple of tweaks suggested below. On 04/05/16 22:59, Joe Clarke wrote: > On 5/4/16 12:43, Stephen Farrell wrote: >=20 > Thanks for your feedback, Stephen. >=20 >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> Intro: I don't agree that all data retention aspects are >> out of scope here. They are about as in-scope as log >> rotation I'd say. I do think it'd be worthwhile noting that >> if log content contains sensitive data (either security- or >> privacy-sensitive) then retaining that data for extended >> durations has a cost, in terms of creating risks if data >> leaks. While one cannot say here how to evaluate such >> risks, they do exist and should really be noted. It would >> also be sensible IMO to say that implementations SHOULD >> provide a way to purge ancient log content that is no >> longer needed or useful, but that the definition of when >> content is no longer needed or useful is out of scope. In >> saying this I do recognise that much or perhaps even most >> i2rs log content will not be security or privacy sensitive, >> but in some cases it can be, e.g. if an operation involved >> an address that is specific to a user or device carried by >> a user. In addition, some data retention regimes could >> impose a requirement to purge log content after a certain >> duration. I'd say a note about this in the intro or in the >> security considerations should be a fine way to handle this >> issue, and to acknowledge that not all data retention >> issues are out of scope for implementations. >=20 > Would changing the Trace Log Temporary Storage section alone be > sufficient? I have changed that section to read: >=20 > "It is outside the scope of this document to specify the > implementation details (i.e., size, throughput, data > protection, etc.) for the physical storage of the > I2RS log file. In terms of data retention, > attention should be paid the length of time I2RS trace log > data is kept when that data contains security or privacy-sensitive > attributes. The longer this data is retained, the more risk is incurre= d > if it were to be leaked." Two things:- - the last bit isn't quite right, it's more the impact is greater if the leak happens (the risk of a leak is presumably proportional more to how long the system is operated). - you didn't mention that in some places there could be legislation imposing a min and/or max on retention of some kinds of data. So I'd suggest instead: "It is outside the scope of this document to specify the implementation details (i.e., size, throughput, data protection, etc.) for the physical storage of the I2RS log file. In terms of data retention, attention should be paid the length of time I2RS trace log data is kept when that data contains security or privacy-sensitive attributes. The longer this data is retained, the higher the impact it were to be leaked. It is also possible that legislation may impose some requirements on the minimum and/or maximum durations for which some kinds of data may be retained." If you think it's important to not say that last bit please do make that argument. (I'll clear the discuss when you post a revision with the above unless one of the other ADs who agreed with the discuss chimes in to say otherwise.) >=20 > Would you prefer I make reference to this in the Security Consideration= s > as well? Your call. So long as it's there somewhere I think we're sorted. And the rest below is fine. Cheers, S. >=20 >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> - 5.2: Requested/Applied Operation Data - I would guess >> this can include sensitive values, e.g. keys/passwords. >> Shouldn=E2=80=99t you say to at least be careful of those, or >> perhaps to not log them, or to zero out known sensitive >> values before logging? >=20 > There is text in the Security Considerations section that says: >=20 > "Additionally, the potentially sensitive information contained in a log= > file SHOULD be adequately anonymized or obfuscated by operators to > ensure its privacy." >=20 > Are you suggesting we explicitly call out the Op Data fields here? >=20 >> >> - 7.2: how is privacy an implementation detail? >=20 > I pulled out privacy. >> >> - 7.4: What does "being preferred" mean in 2119 terms? Why >> is one of the three options not mandatory-to-implement? >=20 > The current [un-published] version makes pub-sub MTI. >=20 > Joe >=20 --------------ms080406060902060107030906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDQy MjExNDRaMC8GCSqGSIb3DQEJBDEiBCBo5nWEviSmQKP+RquGh5XYJin8Teug8RZXSKGLjR9u dDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBo4Rv1yFylz4SOoFlDVSa88l+TwvAGMKEgqSVICyIFZNxHVK/vbFRq HjX4TUZ2yhSqHhhZuhjze43mnYjf5xCvacDjcs7HOo55Ns9oU7x/PN4BYs/2o4mhr/6EZPB3 Wyok4ivJMcC40/SeSq9vYpZkkMfOD/i846Txa7+4nrLJHxhh28sZdkhnMjHVrEFCyiJIPR0g vDX2gtSpcJypEoq++FxHX5cHE4vgerIm1IvQmdiyp+JZXIRlo8bgms3aNYKzd3PeDGFE6xCe M+QRYim0lLQSbztdNdHzlkIOZZvIIvWUXiCfS9/gO771BROtvTEhKwMLvfuh6r5uwxt//Xih AAAAAAAA --------------ms080406060902060107030906-- From nobody Wed May 4 16:20:18 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC0812D958; Wed, 4 May 2016 16:20:12 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEHJcKW3M5wL; Wed, 4 May 2016 16:20:11 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255D712D956; Wed, 4 May 2016 16:20:10 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id w36so32106458qge.3; Wed, 04 May 2016 16:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l3Tuhh7E4aDoT1WWhc38g4WhKSGiXcPow9D/1vLfS9c=; b=eo+ve72cItmWo43DItjRHLR67pWrGdT4VDvqz0CV9u+ybi0JbbfCwQB8KiuWxvloa1 0uwgKSW6yzs73GR623YWCdCG/CtZ+Ku1tc/Jtp0KyvDi7JpooCeY97cV6uMNJaEC4Mmu SDKsgEnED3plYzd8Kkq3kf88frSC86+SiTtuoxz2IOymRLllOLkMHf8I/H6s8mrMoLrv uU8BtuubnfxHKODquqI5u2RKTVUxoF8lnnZH/8cPjsTtudqK6MGvol57e0lkU4y+H8ud F7mh744Ct23vvSqcXy4z/pw6+XVBysSysCe94sxH6unvREBr/GJYSHGzDCoYPqre6EUD 6zbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l3Tuhh7E4aDoT1WWhc38g4WhKSGiXcPow9D/1vLfS9c=; b=RB3aDdLNDOqqZmkWLqwlqjKeS5XTrZDjrjXsP7pFFAlevvM4vkMpO/RU09sqfo7sK3 Z7i7Ybm7tUAnYSNm/fASAK79w1Ehczf86YJd7JdOdIeF+joTuYvmG1Sq0MfHC4F0Jlyg E6EtnGDIHttm6e6dyVbR/EFFfz1wsgnDHaaZsMeJdEnOLouUDUn5n637hekZDAYxDLZ4 UmdZswuXCPs4OKiFFC0lH1FbjOUz+kL9OtkbBFn1X4AIxXkAONhF2XUFatmtZqqAjHwN gNTLjfWEWgSAEJxResOUolWAJ14so+Sull+U9magzZ8+ftLDlB8/Wf1NCc2qEh4eTRIE uYVg== X-Gm-Message-State: AOPr4FVTiwY+uFtVDyap9yWKOJ124GSCPIfxjxBirAvaHTAbMsYUv8nKcsJIRbflPpkj/Q== X-Received: by 10.140.156.81 with SMTP id c78mr12043344qhc.58.1462404009105; Wed, 04 May 2016 16:20:09 -0700 (PDT) Received: from [192.168.1.3] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id g19sm2278639qgd.49.2016.05.04.16.20.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2016 16:20:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (12H143) In-Reply-To: <572A73A0.6080609@cs.tcd.ie> Date: Wed, 4 May 2016 19:20:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90774DBE-803F-4272-9D56-1FB0DC8C4772@gmail.com> References: <20160504164332.8280.38602.idtracker@ietfa.amsl.com> <5c9b1a61-ade4-8f4c-f754-1b500d2b3b4b@cisco.com> <572A73A0.6080609@cs.tcd.ie> To: Stephen Farrell Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , Joe Clarke , "i2rs-chairs@ietf.org" , The IESG , "shares@ndzh.com" Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 23:20:13 -0000 Sent from my iPhone > On May 4, 2016, at 6:11 PM, Stephen Farrell wr= ote: >=20 >=20 > Hi Joe, >=20 > Those are all fine changes. Couple of tweaks suggested below. >=20 >> On 04/05/16 22:59, Joe Clarke wrote: >> On 5/4/16 12:43, Stephen Farrell wrote: >>=20 >> Thanks for your feedback, Stephen. >>=20 >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>>=20 >>> Intro: I don't agree that all data retention aspects are >>> out of scope here. They are about as in-scope as log >>> rotation I'd say. I do think it'd be worthwhile noting that >>> if log content contains sensitive data (either security- or >>> privacy-sensitive) then retaining that data for extended >>> durations has a cost, in terms of creating risks if data >>> leaks. While one cannot say here how to evaluate such >>> risks, they do exist and should really be noted. It would >>> also be sensible IMO to say that implementations SHOULD >>> provide a way to purge ancient log content that is no >>> longer needed or useful, but that the definition of when >>> content is no longer needed or useful is out of scope. In >>> saying this I do recognise that much or perhaps even most >>> i2rs log content will not be security or privacy sensitive, >>> but in some cases it can be, e.g. if an operation involved >>> an address that is specific to a user or device carried by >>> a user. In addition, some data retention regimes could >>> impose a requirement to purge log content after a certain >>> duration. I'd say a note about this in the intro or in the >>> security considerations should be a fine way to handle this >>> issue, and to acknowledge that not all data retention >>> issues are out of scope for implementations. >>=20 >> Would changing the Trace Log Temporary Storage section alone be >> sufficient? I have changed that section to read: >>=20 >> "It is outside the scope of this document to specify the >> implementation details (i.e., size, throughput, data >> protection, etc.) for the physical storage of the >> I2RS log file. In terms of data retention, >> attention should be paid the length of time I2RS trace log >> data is kept when that data contains security or privacy-sensitive >> attributes. The longer this data is retained, the more risk is incurred >> if it were to be leaked." >=20 > Two things:- >=20 > - the last bit isn't quite right, it's more the impact is greater > if the leak happens (the risk of a leak is presumably proportional > more to how long the system is operated). > - you didn't mention that in some places there could be legislation > imposing a min and/or max on retention of some kinds of data. >=20 > So I'd suggest instead: >=20 > "It is outside the scope of this document to specify the > implementation details (i.e., size, throughput, data > protection, etc.) for the physical storage of the > I2RS log file. In terms of data retention, > attention should be paid the length of time I2RS trace log > data is kept when that data contains security or privacy-sensitive > attributes. The longer this data is retained, the higher the > impact it were to be leaked. It is also possible that > legislation may impose some requirements on the minimum and/or > maximum durations for which some kinds of data may be retained." >=20 I like the suggested text having led a number of information management proj= ects that included data retention, I agree with Stephen and appreciate the u= pdated text. Thanks, Kathleen=20 > If you think it's important to not say that last bit please > do make that argument. >=20 > (I'll clear the discuss when you post a revision with the > above unless one of the other ADs who agreed with the > discuss chimes in to say otherwise.) >=20 >>=20 >> Would you prefer I make reference to this in the Security Considerations >> as well? >=20 > Your call. So long as it's there somewhere I think we're sorted. > And the rest below is fine. >=20 > Cheers, > S. >=20 >=20 >>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>>=20 >>> - 5.2: Requested/Applied Operation Data - I would guess >>> this can include sensitive values, e.g. keys/passwords. >>> Shouldn=E2=80=99t you say to at least be careful of those, or >>> perhaps to not log them, or to zero out known sensitive >>> values before logging? >>=20 >> There is text in the Security Considerations section that says: >>=20 >> "Additionally, the potentially sensitive information contained in a log >> file SHOULD be adequately anonymized or obfuscated by operators to >> ensure its privacy." >>=20 >> Are you suggesting we explicitly call out the Op Data fields here? >>=20 >>>=20 >>> - 7.2: how is privacy an implementation detail? >>=20 >> I pulled out privacy. >>>=20 >>> - 7.4: What does "being preferred" mean in 2119 terms? Why >>> is one of the three options not mandatory-to-implement? >>=20 >> The current [un-published] version makes pub-sub MTI. >>=20 >> Joe >=20 From nobody Wed May 4 16:24:59 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C22F12D94E; Wed, 4 May 2016 16:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGEmPTZpC3pS; Wed, 4 May 2016 16:24:53 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E865612D943; Wed, 4 May 2016 16:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6446; q=dns/txt; s=iport; t=1462404293; x=1463613893; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jwA3Yn9MjP9ncpSfTwAe2UouTcOJKWQp4Hi49hIG2yc=; b=Mqn4aCH8BuPhm/mHIAXytYxuIUclDaC/yGWsjl+uR2A9ga5OSgt5OPVT v4Xhm0GyL65PNf2LfF2K4vTA44i+j+2ab+NfjWEsp+dasi0OZB/nFU+Gw i4ZE0h/zM4cYt23KxZMevPl8Db2dDrzMHdusImdWRwQk10FK5eD5I6Jha w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAwBnhCpX/4wNJK1egziBAVW3VoIPA?= =?us-ascii?q?Q2BdoYQAhyBGzgUAQEBAQEBAWUnhEEBAQEDASMRRQULAgEIFQUCCAEdAgICMBU?= =?us-ascii?q?QAgQBDQ0TiAcIrSWQagEBAQEBAQEBAQEBAQEBAQEBAQEBARV8hSSETIc/glkFh?= =?us-ascii?q?3iQIQGIcoUegW+ETYhehiaJDQEeAQFCggUbFoE1iEd/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,579,1454976000"; d="scan'208";a="268226416" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2016 23:24:52 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u44NOpja007679 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 23:24:52 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 19:24:51 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Wed, 4 May 2016 19:24:51 -0400 From: "Eric Voit (evoit)" To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRpjWgYDspbfuo4UOD+L2iwgAMip+pXpHA Date: Wed, 4 May 2016 23:24:50 +0000 Message-ID: <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> References: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> In-Reply-To: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 23:24:54 -0000 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50LiAgIEluLWxpbmUuLi4uDQoNCj4gRnJv bTogQmVuIENhbXBiZWxsLCBNYXkgMDQsIDIwMTYgMjo0OSBQTQ0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEkgaGF2ZSBhIGNvdXBsZSBvZiBwb2lu dHMgSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MuIEhvcGVmdWxseSB0aGV5IGNhbiBiZSByZXNvbHZl ZA0KPiBlYXNpbHk6DQo+IA0KPiBBcmUgdGhlcmUgcmVhbGx5IG5vIHJlcXVpcmVtZW50cyBmb3Ig cHJpdmFjeSBvciBpbnRlZ3JpdHkgcHJvdGVjdGlvbj8gSXMgdGhlcmUgYW4NCj4gZXhwZWN0YXRp b24gdGhhdCB0aGlzIG1lY2hhbmlzbSB3b3VsZCBldmVyIGNhcnJ5IHByaXZhY3kgc2Vuc2l0aXZl IG9yIG90aGVyd2lzZQ0KPiBzZW5zaXRpdmUgaW5mb3JtYXRpb24/DQoNCldoZW4gdGhlIHN1YnNj cmlwdGlvbiBpcyBlc3RhYmxpc2hlZCBkeW5hbWljYWxseSB2aWEgYW4gZXhpc3RpbmcgdHJhbnNw b3J0IHNlc3Npb24gKHdoaWNoIGlzIGV4cGVjdGVkIHRvIGJlIHRoZSBkb21pbmFudCBjYXNlKSB3 ZSBoYXZlIHRoZSBzYW1lIGV4cGVjdGF0aW9ucyBmb3IgUHJpdmFjeSBhbmQgaW50ZWdyaXR5IGFz IHdvdWxkIGJlIHByb3ZpZGVkIHZpYSBhICJHRVQiIGluc3RlYWQgb2YgYSAiUFVTSCIgb3ZlciB0 aGUgc2FtZSB0cmFuc3BvcnQuICAgV2UgY291bGQgaGF2ZSByZXBsaWNhdGVkIGFsbCB0aGVzZSBy ZXF1aXJlbWVudHMsIGJ1dCB0aGF0IHdhcyBzZWVuIGFzIHVubmVjZXNzYXJ5IGFuZCBsaWtlbHkg bGVzcyBzZWN1cmUgdGhhbiBhZG9wdGluZyBleGlzdGluZyBtZWNoYW5pc21zLg0KDQpXaGVuIHRo ZSBTdWJzY3JpYmVyIGFuZCBSZWNlaXZlciBhcmUgZGlmZmVyZW50LCB0aGVuIHRoZSB0cmFuc3Bv cnQgY29ubmVjdGlvbiB3aWxsIGhhdmUgY3JlZGVudGlhbHMgcGFzc2VkIGFzIHBhcnQgb2YgdGhl IGVzdGFibGlzaG1lbnQuICBUaGVzZSBjcmVkZW50aWFscyB3aWxsIGJlIHVzZWQgYXMgYSBTZWN1 cml0eSBHcm9vbWluZyBGaWx0ZXIganVzdCBsaWtlIHRoZSBhYm92ZSBjYXNlIHNvIHRoYXQgcHVz aGVkIG9iamVjdHMgd2lsbCBiZSBleGNsdWRlZCBmcm9tIGFuIFVwZGF0ZSBOb3RpZmljYXRpb24g YXMgcGVyIHRoZSBwZXJtaXNzaW9ucyBvZiB0aGUgUmVjZWl2ZXIuICAgKEkuZS4sIHRoaXMgaXMg aWRlbnRpY2FsIGJlaGF2aW9yIHRvIHRoZSBhYm92ZS4pICAgIEFzIHNldmVyYWwgcGVvcGxlIGhh dmUgaGFkIHF1ZXN0aW9ucyBhYm91dCB0aGlzLCB0aGUgbmV3IHYwNyB3aWxsIG1ha2UgdGhpcyBl eHBsaWNpdCBpbiB0aGUgU2VjdXJpdHkgc2VjdGlvbi4NCg0KIA0KPiAtIDQuMi41LCAybmQgdG8g bGFzdCBwYXJhZ3JhcGg6DQo+IEkgYW0gc3VycHJpc2VkIHRvIGZpbmQgdGhhdCwgd2hlbiB0aGUg cmVjZWl2ZXIgaXMgbm90IHRoZSBzdWJzY3JpYmVyLCB0aGF0IHRoZQ0KPiByZWNlaXZlciBpcyBl eHBlY3RlZCB0byBvcHQtb3V0LiBJdCBzZWVtcyBsaWtlIHNvbWUgZm9ybSBvZiBvcHQtaW4gb3Ig YWZmaXJtYXRpdmUNCj4gY29uc2VudCB3b3VsZCBiZSBuZWVkZWQgaGVyZS4NCg0KVGhlIHF1ZXN0 aW9uIHJlYWxseSB3YXMgaG93IGhlYXZ5LXdlaWdodCBzaG91bGQgdGhlIG1lY2hhbmlzbSBiZS4g IFRyYW5zcG9ydHMgYmVlbiBjb25zaWRlcmluZyBhcmUgYWxsIGVuY3J5cHRlZC4gIFNvIHRoZXJl IGlzIGFscmVhZHkgYSBsZXZlbCBvZiB0cnVzdCBiZXR3ZWVuIHRoZSBwZWVycy4gIEFuZCBhIHRh cmdldCBjYW4gYWx3YXlzIHB1bGwgZG93biB0aGUgY29ubmVjdGlvbiBpZiB0aGVyZSBhcmUgaXNz dWVzLiANCg0KSW4gYWRkaXRpb24sIG11bHRpY2FzdCB0cmFuc3BvcnRzIGFyZSB2aWFibGUgZm9y IHNvbWUgZnV0dXJlIGNhc2VzLiAgV2UgZGlkbid0IHdhbnQgbWVjaGFuaXNtcyB3aGljaCBjb21w bGljYXRlZCB0aGlzIHR5cGUgb2YgaW50ZXJhY3Rpb24sIGVzcGVjaWFsbHkgaW4gYSB3b3JsZCB3 aGVyZSBkdW1iIElvVCBkZXZpY2VzIG1heSBiZSBpbnZvbHZlZC4NCg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IC0gR2VuZXJhbDogSSBzdXBwb3J0 IFN0ZXBoZW4ncyBESVNDVVNTDQo+IA0KPiAtMi4yOiBXaGF0IGlzIHRoZSByZWFsIHNjb3BlIG9m IHRoaXMgd29yaz8gSXMgaXQgZXhwZWN0ZWQgdG8gc3VwcGxhbnQgdGhlDQo+IG1lbnRpb25lZCBt ZWNoYW5pc21zPw0KDQpOby4gICBJdCBpcyBqdXN0IHNob3dpbmcgdGhhdCBtYW55IHNwZWNpYWxp emVkIFB1c2ggbWVjaGFuaXNtIGV4aXN0LiAgVGhpcyBpcyBub3QgaW50ZW5kZWQgdG8gc3VwcGxh bnQgZXhpc3RpbmcgbWVjaGFuaXNtcywgYWx0aG91Z2ggcGVyaGFwcyBpdCBjYW4gaGVscCBhdm9p ZCBmdXR1cmUgZGVkaWNhdGVkIHNvbHV0aW9ucy4NCiANCj4gLSAyLjM6ICJXZSBuZWVkIGEgbmV3 IHB1Yi1zdWINCj4gICAgdGVjaG5vbG9neSINCj4gVGhlIHNoZXBoZXJkIHdyaXRlIHVwIG1lbnRp b25lZCBhIGdvYWwgdG8gdXNlIGV4aXN0aW5nIHRlY2hub2xvZ2llcy4gSXMgdGhlDQo+IHBvaW50 IG9mIHRoaXMgc2VudGVuY2UgdG8gc3VnZ2VzdCB0aGF0IGlzIG5vdCBmZWFzaWJsZT8NCg0KRXhp c3RpbmcgdGVjaG5vbG9naWVzIGNhbm5vdCBtZWV0IGFsbCB0aGUgcmVxdWlyZW1lbnRzIHNwZWNp ZmllZC4gIFRoZXJlIGFyZSB0ZWNobm9sb2d5IGRyYWZ0cyBwcm9ncmVzc2luZyBpbiBORVRDT05G IHdoaWNoIGNhbi4NCg0KPiAtIDQuMSwgNHRoIHBhcmFncmFwaDoNCj4gVGhlIE1BWSBkb2Vzbid0 IHNlZW0gcmlnaHQtLWlzIHRoaXMgYSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0IHRoZSBzdWJzY3Jp YmVyIG1heQ0KPiBoYXZlIHRvIHJlc3Vic2NyaWJlLCBvciBhIHJlcXVpcmVtZW50IG9mIHRoZSBm b3JtIHRoYXQgdGhlIHNlcnZpY2UgTUFZIGZvcmNlIHRoZQ0KPiBzdWJzY3JpYmVyIHRvIHJlc3Vi c2NyaWJlPyAoQmUgY2FyZWZ1bCB3aXRoIE1BWXMgaW4gcmVxdWlyZW1lbnRzIGxhbmd1YWdlLS10 aGV5DQo+IGltcGx5IHVuZXhwZWN0ZWQgdGhpbmdzLiBGb3IgZXhhbXBsZSwgc2V2ZXJhbCByZXF1 aXJlbWVudHMgc2F5IGEgU1VCU0NSSUJFDQo+IE1BWSBkbyBzb21ldGhpbmctLWRvIHRob3NlIGlt cGx5IHRoYXQgdGhlIHNlcnZpY2UgTVVTVCBhbGxvdyB0aGUgc3Vic2NyaWJlcg0KPiB0byBkbyBp dCA/KQ0KDQpHb29kIHBvaW50LiAgIFJld29yZGVkIGluIHYwNy4NCg0KPiAtLSA0LjIuMiwgdGhp cmQgYnVsbGV0OiBUaGUgcHJldmlvdXMgc2VjdGlvbiBzYWlkIGRhbXBlbmluZyBwZXJpb2RzIE1V U1QgYmUNCj4gc3VwcG9ydGVkLg0KDQpZZXMsIGJ1dCBkYW1wZW5pbmcgaXMgbmV2ZXIgZm9yIHBl cmlvZGljIHN1YnNjcmlwdGlvbnMuDQogDQo+IC0gNC4yLjEsIHRoaXJkIHBhcmFncmFwaDogVGhp cyBpcyBhIGJpdCBhbWJpZ3VvdXMuIEkgdGhpbmsgaXQgbWVhbnMgdG8gY2hhbmdlIHRoZQ0KPiB3 aGF0IHN1YnRyZWVzIHRoZSBzdWJzY3JpcHRpb24gYXBwbGllcyB0bywgYnV0IGNvdWxkIGJlIGlu dGVycHJldGVkIHRvIGNoYW5nZSB0aGUNCj4gc3VidHJlZXMgdGhlbXNlbHZlcy4NCg0KRml4ZWQN CiANCj4gLSA0LjIuNi40OiBXb3VsZCBhIG1lY2hhbmlzbSB0aGF0IGFsbG93ZWQgb3V0LW9mLW9y ZGVyIGRlbGl2ZXJ5IGJ1dCBnYXZlIHRoZQ0KPiBzdWJzY3JpYmVyIGEgd2F5IHRvIHJlY29uc3Ry dWN0IHRoZSBvcmRlciBmdWxmaWxsIHRoaXMgcmVxdWlyZW1lbnQ/DQoNClllcywgdGhlIHRpbWVz dGFtcCB3aXRoaW4gYW4gdXBkYXRlLiAgQnV0IHRoaXMgcmVxdWlyZW1lbnQgdGFyZ2V0cyBhIHNw ZWNpZmljIG9iamVjdCBpbiBhIHNwZWNpZmljIHN1YnNjcmlwdGlvbi4gIFNvIHRoZXJlIHNob3Vs ZCBiZSBubyBpc3N1ZXMuDQogDQo+IE5pdHM6DQo+IC0gVGhlIHNoZXBoZXJkIHdyaXRlIHVwIHN1 Z2dlc3RzIHRoaXMgaXMgc3RhbmRhcmRzIHRyYWNrLiBUaGUgZHJhZnQgYW5kIHRyYWNrZXINCj4g Ym90aCBzYXkgaW5mb3JtYXRpb25hbC4gUGxlYXNlIHVwZGF0ZSB0aGUgc2hlcGhlcmQgd3JpdCB1 cC4NCg0KRml4ZWQNCiANCj4gLTMsIGxhc3QgcGFyYWdyYXBoOiBXaGF0J3MgdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiBhICJQdXNoIiBhbmQgYW4gIlVwZGF0ZSI/DQoNClJld29yZGVkDQogDQo+IC00 LjE6IEEgZm9yd2FyZCByZWZlcmVuY2UgdG8gdGhlIHN1YnNjcmlwdGlvbiBRb1Mgc2VjdGlvbiB3 b3VsZCBiZSBoZWxwZnVsLg0KDQpNb3ZlZCB0aGUgcmVxdWlyZW1lbnQgaW4gcXVlc3Rpb24gdG8g NC4yLjYuDQogDQo+IC0tIExhc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlOiBTZW50ZW5jZSBk b2Vzbid0IHBhcnNlLg0KDQpGaXhlZA0KIA0KPiANCj4gLSA0LjIuOCwgdGhpcmQgcGFyYWdyYXBo OiBJIGRvbid0IHRoaW5rIHRoYXQgc2hvdWxkIGJlIGEgMjExOSBNQVkNCg0KRml4ZWQNCiANClRo YW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldyENCkVyaWMNCg== From nobody Wed May 4 16:25:13 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA23012D943; Wed, 4 May 2016 16:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCIfiK8gjc5h; Wed, 4 May 2016 16:24:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3F312D94B; Wed, 4 May 2016 16:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3766; q=dns/txt; s=iport; t=1462404293; x=1463613893; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JBy/4labRCm/xr0IIfXZwvDxOSSWbKlGI22EjGCtiSk=; b=FTqbu88td7J2reXMrhBPYXkmhJ5x2ChRDbvZ2p+o8eyQYP71Mha/h68G GsRS4O36QLIkFzaH3O10clRV71AT6rbq5c4T4UmPV3AfeQhgzmbxYzAvt rCKefhts4NtqL5igryOGLK+fEAi7J2qD3wXf8/oJEYKoRiTYhhYBF5hkG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgDngypX/5xdJa1egzhTfQa5ZQENg?= =?us-ascii?q?XYXC4VuAoE3OBQBAQEBAQEBZSeEQQEBAQMBAQEBJBM0CwULAgEIEhMRBQsnCxc?= =?us-ascii?q?OAgQBDQUIiBoIDr4DAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIIRMihgFh3iLL?= =?us-ascii?q?IR1AYV7iBWBb4d2hTWGJokNAR4BAUKCNoE1bIceJRh/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,579,1454976000"; d="scan'208";a="99187967" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2016 23:24:52 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u44NOq5s009067 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 23:24:52 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 19:24:51 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Wed, 4 May 2016 19:24:51 -0400 From: "Eric Voit (evoit)" To: "Benoit Claise (bclaise)" , The IESG Thread-Topic: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRpRktAbbtnYLN3kC4tRphXhjGVp+pXdmQ Date: Wed, 4 May 2016 23:24:51 +0000 Message-ID: References: <20160503085242.7557.50387.idtracker@ietfa.amsl.com> In-Reply-To: <20160503085242.7557.50387.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" , "jiangsheng@huawei.com" Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 23:24:56 -0000 Hi Benoit, Comments in-line... > Benoit Claise has entered the following ballot position for > draft-ietf-i2rs-pub-sub-requirements-06: Discuss >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Three DISCUSS points, which could be easily resolved IMO. >=20 > 1. As mentioned on the NETMOD mailing list by Tom Petch, don't redefine t= he > YANG datastore term: > > I see that the definition of 'datastores' has cropped up in this AD > > Review, as in the e-mail below. > > > > Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last > > Call and redefines, or recreates, the term for us > > > > A YANG datastore is a conceptual datastore that contains > hierarchical > > data defined in YANG data models. It is what is referred in > existing > > RFCs as "NETCONF datastore". However, as the same datastore is no > > longer tied to NETCONF as a specific transport, the term "YANG > > datastore" is deemed more appropriate. > > > > I think that the concept of datastore has been troublesome to those > > coming to YANG lately, such as openconfig and I2RS, and that this will > > just muddy the waters more, especially as it is tucked away in an > > Informational document. If I2RS want to define such terminology, then > > it should be in the I2RS Architecture or some such; but IMHO they > should > > not be defining YANG datastores at all. The new updated v07 includes a reference to the RFC6241 definition of datas= tore. =20 > 2. Maybe I read too much into this (at the time of specifying the operati= onal > state in NETMOD) ... >=20 > A Subscription Service MUST be able support a Subtree Filter so that > subscribed updates under a target node might publish only operational > data, only configuration data, or both. >=20 > Proposal: s/Subtree Filter/Filter Updated.=20 > 3. In the security considerations section >=20 > Versioning MUST be supported. >=20 > Versioning of what? Yang push protocol, subscription, transport session, = state of > of subscription, something else? Updated. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - Editorial > Based on > current I2RS requirements, NETCONF should the initially supported > transport based on the need for connection-oriented/unicast > communication. >=20 > s/should/should be Fixed =20 > - Editorial: > A Subscription MAY include filters as defined >=20 > s/filters/Filters >=20 > Note: there are multiple instances of filter -> Filter Fixed =20 > - AND is not a RFC2119 keyword > For "on-change" notifications, passing > through the Filter requires that a subscribed object is now different > that from the previous Push, AND at least one of the YANG objects > being evaluated has changed since the last Update. Fixed > - > I always wonder what a MAY requirement means? Example: >=20 > A Subscriber MAY check with a Subscription Service to validate the > existence and monitored subtrees of a Subscription. >=20 > Or: > A Subscription Service MAY send Updates over Best Effort and Reliable > transports. >=20 > What if https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ > doesn't address this requirement (I haven't checked), are we good or not? Yes. A MAY provides guidance, but is not required. Eric >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 4 16:25:38 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5152D12D87C; Wed, 4 May 2016 16:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhOyLDyQHlND; Wed, 4 May 2016 16:24:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9511A12D956; Wed, 4 May 2016 16:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10351; q=dns/txt; s=iport; t=1462404294; x=1463613894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HmksQ4TU7UouNx5MsQyoOVPGNU5tuVs3Rz0BEyiLfYM=; b=Rx5Goz+FPiG1PE3RVVWnYmZ2zbymkL/UfDFn82rcd7Dz0Jv1Ecs2XgQb 6cTLbovoNIDJtPxCmFW2X4zv/0j4pW64XiDf72De0uBwM5qWTH64Tqxnv ovOCiXIrlAVYnOcMPJiOVaPnpzEKHeEKiG4ScjHGfFj9Bfk1eSwIXIdOE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAwBvgypX/4oNJK1WAQeDOFN9AQW5Z?= =?us-ascii?q?QENgXYihW4CgTc4FAEBAQEBAQFlJ4RBAQEBAwE6LQsCBQULAgEIFAEPAREQMiU?= =?us-ascii?q?CBA4DCgyIDggOvgIBAQEBAQEBAQEBAQEBAQEBAQEBF4Ygg0mBA4QbAg+FbAWTJ?= =?us-ascii?q?IR1AYV7iBWBb06Df4hehiaJDQEeAQFCg2s/LocbAh4DBBh/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,579,1454976000"; d="scan'208";a="104676224" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2016 23:24:53 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u44NOrY2028136 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 23:24:53 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 19:24:51 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Wed, 4 May 2016 19:24:52 -0400 From: "Eric Voit (evoit)" To: Dan Frost Thread-Topic: RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06 Thread-Index: AQHRnwwwp5NeJzUz10S3mqOVd9uHg5+pN74g Date: Wed, 4 May 2016 23:24:51 +0000 Message-ID: <97eeb138efbf4b86b05065391fd0a71f@XCH-RTP-013.cisco.com> References: <1461600259.1868989.588979393.728AD1A2@webmail.messagingengine.com> In-Reply-To: <1461600259.1868989.588979393.728AD1A2@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements.all@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 23:24:58 -0000 Hi Dan, Thanks for the excellent comments. In-line below are what has been done f= or each of these... > From: Dan Frost, April 25, 2016 12:04 PM >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this draft. = The > Routing Directorate seeks to review all routing or routing-related drafts= as they > pass through IETF last call and IESG review, and sometimes on special req= uest. > The purpose of the review is to provide assistance to the Routing ADs. Fo= r more > information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs, it = would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion = or by > updating the draft. >=20 > Document: draft-ietf-i2rs-pub-sub-requirements-06 > Reviewer: Dan Frost > Review Date: 2016-04-25 > IETF LC End Date: 2016-04-29 > Intended Status: Informational (?) >=20 > Summary: >=20 > I have significant concerns about this document and recommend that the > Routing ADs discuss these issues further with the authors. >=20 > Comments: >=20 > Overall this is a clear and consistent requirements document that address= es an > important real-world problem domain, and is nearly ready for publication. > However, because this work may lead to significant changes in the mechani= cs of > network management and control, some extra care in the review stage is > warranted. I've marked some issues as major to indicate that they may de= serve > extra consideration by the ADs and/or the wider Internet community. >=20 >=20 > Major Issues: >=20 > 1. There seems to be some confusion as to the intended status of the docu= ment. > The draft itself lists its intended status as Informational, which is usu= ally > appropriate for a requirements document. On the other hand, the draft wa= s > submitted to the IESG with an Intended Status of Proposed Standard. > Furthermore, a quick check of other I2RS WG requirements docs shows them > split between Informational and Proposed Standard, so the confusion may > extend beyond this draft. I'd suggest the ADs and chairs agree on a cons= istent > policy. Fixed=20 > 2. The document concerns requirements for a publish/subscribe interface t= o, > among other things, real-time operational data. The text in Section > 2.3 indicates an awareness of the need to support potentially large numbe= rs of > subscribers and high volumes of data. However, the document doesn't seem= to > discuss the global network impact of continuously pushing a lot of data t= o many > subscribers. > > As the introduction of such a push system could lead to a qualitative shi= ft in the > total volume of management/control traffic, it seems important to begin > addressing this issue at the requirements stage. > > A possible resolution would be to add a brief section on network impact u= nder > large-scale conditions, and/or a set of requirements for minimizing this = impact. > Some of the listed requirements are germane to this, e.g. subscription fi= lters. > bundling, and dampening. Issues that are not addressed include support f= or > encoding formats that are efficient for high-volume transport and process= ing > (XML and JSON are usually considered not to be); appropriate selection of > transport protocols and features according to scale/use-case; and support= for > mechanisms to determine or restrict the bandwidth cost of a proposed or > ongoing subscription. Good point. We do have some relevant requirements as there are mechanisms = to: - Allow/deny/negotiate subscriptions so as not to overwhelm resources. Thi= s could include negotiation of the encoding and filters. See Section 4.2.2 - Notify subscribers that push updates are being suspended/resumed But there could be more. For example, there should be the ability of prior= itize some subscriptions over others for de-queuing towards recipients Therefore the new draft version '07' adds a Relative Prioritization section= 4.2.6.8 and requirements to ensure limited bandwidth environments are addr= essed. > 3. This work is being carried out in the I2RS WG, but the first sentence = of Section > 2.2 states that this document is intended to cover requirements beyond I2= RS. A > general question for the editors/chairs/ADs is whether it has received an= y review > by interested/affected parties outside I2RS? >=20 > 4. The Security Requirements make no mention of data integrity or > confidentiality. This is a potentially serious omission in today's netwo= rk > environment. I would expect at the least that subscribers have the abili= ty to > request a secure (authenticated, integrity-verified, > confidential) session, that publishers likewise have the ability to refus= e non- > secure sessions, and that the security status of a session is explicitly = signaled and > checked by both parties during negotiation. With subscriptions signaled in-band, any pushed updates will rely on the un= derlying transport layer protocols to ensure integrity and confidentiality.= This provides the same level of security as a traditional "GET". =20 >=20 > Minor Issues: >=20 > 1. The requirements in this document ought to be numbered for ease of > reference. Hoping to avoid this :-) =20 > 2. Section 3: > As this is a requirements doc, the RFC 2119 language paragraph could use = a > clarification sentence along the lines of the one in Section 1.1 of RFC 5= 654. Added=20 =20 > 3. Section 3: > It's not obvious to me from the text in this section what the distinction= and > intended relationship is between Receivers and Subscribers. Perhaps this= can be > clarified with an example? Also the statement "In general, the Receiver = and > Subscriber will be the same entity" doesn't sound right -- maybe you mean= t that > in general they can be different, but usually they will be the same? That is what is meant. =20 > 4. Section 3, last sentence: > What is the difference between the terms "previous Push" and "last Update= " > used in this sentence? Agree this was confusing. In fact it included a requirement in the definiti= on. Extracted this text in the -07 version, and added a reworded requireme= nt to section 4.2.7. > 5. Section 4.2.3, last paragraph: > This paragraph would be more useful if it explained what a persistence/re= play > capability was and how it might work. Updated text =20 > 6. Can a definition or reference be provided for the term "object propert= y" as > used in Sections 3 and 4.2.7? This terminology seems slightly different = from that > used in RFC 6020. I can see where people might get confused. I tweaked the text to better m= atch what can be seen with RFC6241 filtering. =20 > 7. Section 4.2.4: > What is the purpose of stating that a subscription service should support > "different" transports and encodings? This sounds too vague to be useful= . > Choice of transport and encoding are of great practical importance, but t= he > document has almost nothing to say on these topics. > Can the authors not provide a summary of options and some definite guidan= ce > here? This is tough. There are proposals for transports of NETCONF, RESTCONF, HT= TP, and HTTP2 in technology drafts. Other people have suggested COAP and = IPFIX. Some people want non-IETF transports like gRPC. We really don't w= ant to take a position. =20 > 8. Section 4.2.5, third paragraph: > Can you spell out in the document exactly what "Versioning" means here? Updated =20 > 9. When the underlying transport provides some form of security, should t= here > not be a requirement for alignment between transport security and pub/sub > protocol security? Can, for example, TLS certificate validation fulfil t= he pub/sub > authentication requirement? These requirements explore the security requirements for control plane mess= aging, anticipating that the data plane will be locked down as would a trad= itional "GET" for the same information. This is why in the Security requir= ements talk about filtering based on whatever mechanisms would in place for= a "GET" using that specific transport. I.e., we are attempting equivalenc= e for "GET" rather than new incremental mechanisms with perhaps different b= ehavior. > 10. An important use-case for such a pub/sub update service is a subscrib= er that > wants to maintain an up-to-date local copy of a datastore residing on the > publisher. This requires the ability to correlate the version of the dat= astore > obtained via an out-of-band full download with the version reflected by e= ach > published update. Do the authors intend to allow for this case, and have= they > considered the associated requirements? Yes. In summary, you can get deltas via on-change. And when you want to = ensure you haven't lost something, you can do a GET against any objects whe= re the remote datastore houses the primary copy. =20 >=20 > Nits: >=20 > Section 2.2, first paragraph: > - s/Switches and Routers/switches and routers/ > - s/past subscriptions includes/past subscription mechanisms includes/ Fixed =20 > Section 2.2, last paragraph: > - s/NETCONF should the/NETCONF should be the/ > - s/support Multicast and Broadcast/support for multicast and broadcast/ Fixed =20 > Section 3, 8th paragraph: > - s/referred in/referred to in/ > Section 3, 9th paragraph: > - s/which have been made/that have been made/ Section 3, last paragraph: > - s/propert(ies)/properties/ Fixed > - s/different that/different than that/ Couldn't find that one =20 > Section 4, first paragraph: > - s/morphed/adapted/ fixed =20 > Section 4.1, last paragraph: > - s/lease a Subscription/lease of a Subscription/ Fixed > Section 4.2.1, second and third paragraphs: > These two requirements seem to make more sense if "one or more" is replac= ed > by "multiple". Fixed > Section 4.2.8, third paragraph: > - s/us a failure/is a failure/ Fixed Eric >=20 > Cheers, > -d From nobody Wed May 4 16:28:47 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB1512D94B; Wed, 4 May 2016 16:28:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504232846.8315.93261.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 16:28:46 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-pub-sub-requirements-07.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 23:28:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : Requirements for Subscription to YANG Datastores Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Filename : draft-ietf-i2rs-pub-sub-requirements-07.txt Pages : 16 Date : 2016-05-04 Abstract: This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e. Netconf and Restconf). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-pub-sub-requirements-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 21:12:11 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6109912D1EB; Wed, 4 May 2016 21:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFplp9hKFUcF; Wed, 4 May 2016 21:12:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F3D7C12D19E; Wed, 4 May 2016 21:12:07 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u454C2lL062712 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 23:12:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Eric Voit" Date: Wed, 04 May 2016 23:12:02 -0500 Message-ID: <40A52DF0-AD6C-4B47-8F34-70D4DB6399FA@nostrum.com> In-Reply-To: <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> References: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , The IESG , "shares@ndzh.com" , "i2rs-chairs@ietf.org" Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 04:12:09 -0000 Hi, thanks for the response. Comments in line, with sections removed that do not seem to need further discussion: On 4 May 2016, at 18:24, Eric Voit (evoit) wrote: > Hi Ben, > > Thanks for the comment. In-line.... > >> From: Ben Campbell, May 04, 2016 2:49 PM >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I have a couple of points I would like to discuss. Hopefully they can >> be resolved >> easily: >> >> Are there really no requirements for privacy or integrity protection? >> Is there an >> expectation that this mechanism would ever carry privacy sensitive or >> otherwise >> sensitive information? > > When the subscription is established dynamically via an existing > transport session (which is expected to be the dominant case) we have > the same expectations for Privacy and integrity as would be provided > via a "GET" instead of a "PUSH" over the same transport. We could > have replicated all these requirements, but that was seen as > unnecessary and likely less secure than adopting existing mechanisms. Where do those requirements live now? I recall this draft mentioning that support for multiple transports is required, but I don't recall seeing anything about the required transport properties. (It's entirely possible I missed it, or just forgot.) > > When the Subscriber and Receiver are different, then the transport > connection will have credentials passed as part of the establishment. > These credentials will be used as a Security Grooming Filter just like > the above case so that pushed objects will be excluded from an Update > Notification as per the permissions of the Receiver. (I.e., this is > identical behavior to the above.) As several people have had > questions about this, the new v07 will make this explicit in the > Security section. That will likely resolve my concern, but there's not enough detail here to judge. I will watch for the update. > > >> - 4.2.5, 2nd to last paragraph: >> I am surprised to find that, when the receiver is not the subscriber, >> that the >> receiver is expected to opt-out. It seems like some form of opt-in or >> affirmative >> consent would be needed here. > > The question really was how heavy-weight should the mechanism be. > Transports been considering are all encrypted. So there is already a > level of trust between the peers. And a target can always pull down > the connection if there are issues. I think you are talking about solution, not requirements. If the solution is already known, what is the purpose of publishing the requirements? > > In addition, multicast transports are viable for some future cases. > We didn't want mechanisms which complicated this type of interaction, > especially in a world where dumb IoT devices may be involved. I think my response to this will depend on the details you mention are coming in 07. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- [...] >> -- 4.2.2, third bullet: The previous section said dampening periods >> MUST be >> supported. > > Yes, but dampening is never for periodic subscriptions. The third bullet is about on-change updates, not periodic publication. 4.2.1 says the service MUST support dampening for on-change updates. [...] From nobody Thu May 5 03:03:50 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6DB12D579; Thu, 5 May 2016 03:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8NZBYf4wjyR; Thu, 5 May 2016 03:03:44 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0654912D570; Thu, 5 May 2016 03:03:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , "'Dan Frost'" References: <1461600259.1868989.588979393.728AD1A2@webmail.messagingengine.com> <97eeb138efbf4b86b05065391fd0a71f@XCH-RTP-013.cisco.com> In-Reply-To: <97eeb138efbf4b86b05065391fd0a71f@XCH-RTP-013.cisco.com> Date: Thu, 5 May 2016 06:03:47 -0400 Message-ID: <06fc01d1a6b5$6b417b80$41c47280$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlXuo2JX8PXEdKa+QuqVobYuqg+AJ3++tfn+7rVBA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-i2rs-pub-sub-requirements.all@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 10:03:46 -0000 Dan: Regarding your major comments: Comment on #1 - The ADs agreed on informational after WG LC did standards. It is fixed to informational now. Comment on #2 - Has Eric's comment addressed your questions? Comment on #3 - NETCONF has adopted push mechanism. What other parties are you concerned about? Comment on #4 - Please see the security requirements for the I2RS protocol: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme nts https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/ These documents provide requirement for data integrity, confidentiality, protection against replay attacks, and DDoS. Do you feel you major comments have been addressed? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, May 04, 2016 7:25 PM To: Dan Frost Cc: rtg-ads@ietf.org; rtg-dir@ietf.org; draft-ietf-i2rs-pub-sub-requirements.all@ietf.org; i2rs@ietf.org Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06 Hi Dan, Thanks for the excellent comments. In-line below are what has been done for each of these... > From: Dan Frost, April 25, 2016 12:04 PM > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. > The purpose of the review is to provide assistance to the Routing ADs. > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-i2rs-pub-sub-requirements-06 > Reviewer: Dan Frost > Review Date: 2016-04-25 > IETF LC End Date: 2016-04-29 > Intended Status: Informational (?) > > Summary: > > I have significant concerns about this document and recommend that the > Routing ADs discuss these issues further with the authors. > > Comments: > > Overall this is a clear and consistent requirements document that > addresses an important real-world problem domain, and is nearly ready for publication. > However, because this work may lead to significant changes in the > mechanics of network management and control, some extra care in the > review stage is warranted. I've marked some issues as major to > indicate that they may deserve extra consideration by the ADs and/or the wider Internet community. > > > Major Issues: > > 1. There seems to be some confusion as to the intended status of the document. > The draft itself lists its intended status as Informational, which is > usually appropriate for a requirements document. On the other hand, > the draft was submitted to the IESG with an Intended Status of Proposed Standard. > Furthermore, a quick check of other I2RS WG requirements docs shows > them split between Informational and Proposed Standard, so the > confusion may extend beyond this draft. I'd suggest the ADs and > chairs agree on a consistent policy. Fixed > 2. The document concerns requirements for a publish/subscribe > interface to, among other things, real-time operational data. The > text in Section > 2.3 indicates an awareness of the need to support potentially large > numbers of subscribers and high volumes of data. However, the > document doesn't seem to discuss the global network impact of > continuously pushing a lot of data to many subscribers. > > As the introduction of such a push system could lead to a qualitative > shift in the total volume of management/control traffic, it seems > important to begin addressing this issue at the requirements stage. > > A possible resolution would be to add a brief section on network > impact under large-scale conditions, and/or a set of requirements for minimizing this impact. > Some of the listed requirements are germane to this, e.g. subscription filters. > bundling, and dampening. Issues that are not addressed include > support for encoding formats that are efficient for high-volume > transport and processing (XML and JSON are usually considered not to > be); appropriate selection of transport protocols and features > according to scale/use-case; and support for mechanisms to determine > or restrict the bandwidth cost of a proposed or ongoing subscription. Good point. We do have some relevant requirements as there are mechanisms to: - Allow/deny/negotiate subscriptions so as not to overwhelm resources. This could include negotiation of the encoding and filters. See Section 4.2.2 - Notify subscribers that push updates are being suspended/resumed But there could be more. For example, there should be the ability of prioritize some subscriptions over others for de-queuing towards recipients Therefore the new draft version '07' adds a Relative Prioritization section 4.2.6.8 and requirements to ensure limited bandwidth environments are addressed. > 3. This work is being carried out in the I2RS WG, but the first > sentence of Section > 2.2 states that this document is intended to cover requirements beyond > I2RS. A general question for the editors/chairs/ADs is whether it has > received any review by interested/affected parties outside I2RS? > > 4. The Security Requirements make no mention of data integrity or > confidentiality. This is a potentially serious omission in today's > network environment. I would expect at the least that subscribers > have the ability to request a secure (authenticated, > integrity-verified, > confidential) session, that publishers likewise have the ability to > refuse non- secure sessions, and that the security status of a session > is explicitly signaled and checked by both parties during negotiation. With subscriptions signaled in-band, any pushed updates will rely on the underlying transport layer protocols to ensure integrity and confidentiality. This provides the same level of security as a traditional "GET". > > Minor Issues: > > 1. The requirements in this document ought to be numbered for ease of > reference. Hoping to avoid this :-) > 2. Section 3: > As this is a requirements doc, the RFC 2119 language paragraph could > use a clarification sentence along the lines of the one in Section 1.1 of RFC 5654. Added > 3. Section 3: > It's not obvious to me from the text in this section what the > distinction and intended relationship is between Receivers and > Subscribers. Perhaps this can be clarified with an example? Also the > statement "In general, the Receiver and Subscriber will be the same > entity" doesn't sound right -- maybe you meant that in general they can be different, but usually they will be the same? That is what is meant. > 4. Section 3, last sentence: > What is the difference between the terms "previous Push" and "last Update" > used in this sentence? Agree this was confusing. In fact it included a requirement in the definition. Extracted this text in the -07 version, and added a reworded requirement to section 4.2.7. > 5. Section 4.2.3, last paragraph: > This paragraph would be more useful if it explained what a > persistence/replay capability was and how it might work. Updated text > 6. Can a definition or reference be provided for the term "object > property" as used in Sections 3 and 4.2.7? This terminology seems > slightly different from that used in RFC 6020. I can see where people might get confused. I tweaked the text to better match what can be seen with RFC6241 filtering. > 7. Section 4.2.4: > What is the purpose of stating that a subscription service should > support "different" transports and encodings? This sounds too vague to be useful. > Choice of transport and encoding are of great practical importance, > but the document has almost nothing to say on these topics. > Can the authors not provide a summary of options and some definite > guidance here? This is tough. There are proposals for transports of NETCONF, RESTCONF, HTTP, and HTTP2 in technology drafts. Other people have suggested COAP and IPFIX. Some people want non-IETF transports like gRPC. We really don't want to take a position. > 8. Section 4.2.5, third paragraph: > Can you spell out in the document exactly what "Versioning" means here? Updated > 9. When the underlying transport provides some form of security, > should there not be a requirement for alignment between transport > security and pub/sub protocol security? Can, for example, TLS > certificate validation fulfil the pub/sub authentication requirement? These requirements explore the security requirements for control plane messaging, anticipating that the data plane will be locked down as would a traditional "GET" for the same information. This is why in the Security requirements talk about filtering based on whatever mechanisms would in place for a "GET" using that specific transport. I.e., we are attempting equivalence for "GET" rather than new incremental mechanisms with perhaps different behavior. > 10. An important use-case for such a pub/sub update service is a > subscriber that wants to maintain an up-to-date local copy of a > datastore residing on the publisher. This requires the ability to > correlate the version of the datastore obtained via an out-of-band > full download with the version reflected by each published update. Do > the authors intend to allow for this case, and have they considered the associated requirements? Yes. In summary, you can get deltas via on-change. And when you want to ensure you haven't lost something, you can do a GET against any objects where the remote datastore houses the primary copy. > > Nits: > > Section 2.2, first paragraph: > - s/Switches and Routers/switches and routers/ > - s/past subscriptions includes/past subscription mechanisms includes/ Fixed > Section 2.2, last paragraph: > - s/NETCONF should the/NETCONF should be the/ > - s/support Multicast and Broadcast/support for multicast and > broadcast/ Fixed > Section 3, 8th paragraph: > - s/referred in/referred to in/ > Section 3, 9th paragraph: > - s/which have been made/that have been made/ Section 3, last paragraph: > - s/propert(ies)/properties/ Fixed > - s/different that/different than that/ Couldn't find that one > Section 4, first paragraph: > - s/morphed/adapted/ fixed > Section 4.1, last paragraph: > - s/lease a Subscription/lease of a Subscription/ Fixed > Section 4.2.1, second and third paragraphs: > These two requirements seem to make more sense if "one or more" is > replaced by "multiple". Fixed > Section 4.2.8, third paragraph: > - s/us a failure/is a failure/ Fixed Eric > > Cheers, > -d _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 5 03:15:16 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DEB12D5A4; Thu, 5 May 2016 03:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-231d_882hw; Thu, 5 May 2016 03:15:08 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 1DA2012D5B4; Thu, 5 May 2016 03:15:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , "'Ben Campbell'" , "'The IESG'" References: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> In-Reply-To: <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> Date: Thu, 5 May 2016 06:15:07 -0400 Message-ID: <06fe01d1a6b7$008d6ef0$01a84cd0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06FF_01D1A695.797D5590" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHJx9xjXwVK0KpUYwM2Ib+kCcb/YgKqFtf2n6SKu7A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 10:15:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06FF_01D1A695.797D5590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric, Ben and IESG members: The pub/sub requirements are part of a 5 part requirements. May I quote from the shepherd's report: --------------------- The requirements for the first version of I2RS are: 1) model driven ephemeral state - that is data models that do not survive a software or hardware reboot. https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ 2) a secure protocol - https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme nts/ 3) traceability - ability to record interactions between I2RS elements (Client, Agent, Routing system) https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ 4) notification publication via subscription https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ 5) Protocol to pass Data for Analytics The first version of these requirements does not include a separate analytical protocol requirements as the simple use cases may pass information via query/poll or the notifications. The I2RS protocol exists in an secure environment described by: https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/ ------------------------- Eric - Perhaps it would be good to point to: . draft-ietf-i2rs-protocol-security-requirements and . draft-ietf-i2rs-security-environment-reqs/ Ben - Can you tell me how the shepherd report could have been clearer? The I2rs protocol security requirements require: confidentiality, encryption, secure transport, protection against replay attack, protection against DDoS attack (if possible). Ben - On opting in, once the receive accepts a transport connection from the I2RS server - how is this not an opt-in to receive data? What are you looking for? Sue Hares (shepherd) -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, May 04, 2016 7:25 PM To: Ben Campbell; The IESG Cc: i2rs@ietf.org; draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org; shares@ndzh.com Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Hi Ben, Thanks for the comment. In-line.... > From: Ben Campbell, May 04, 2016 2:49 PM > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have a couple of points I would like to discuss. Hopefully they can > be resolved > easily: > > Are there really no requirements for privacy or integrity protection? > Is there an expectation that this mechanism would ever carry privacy > sensitive or otherwise sensitive information? [eric's comment: When the subscription is established dynamically via an existing transport session (which is expected to be the dominant case) we have the same expectations for Privacy and integrity as would be provided via a "GET" instead of a "PUSH" over the same transport. We could have replicated all these requirements, but that was seen as unnecessary and likely less secure than adopting existing mechanisms. When the Subscriber and Receiver are different, then the transport connection will have credentials passed as part of the establishment. These credentials will be used as a Security Grooming Filter just like the above case so that pushed objects will be excluded from an Update Notification as per the permissions of the Receiver. (I.e., this is identical behavior to the above.) As several people have had questions about this, the new v07 will make this explicit in the Security section. End of eric's comment] Sue: The transport provides for privacy, integrity protection. Most configuration in network boxes would need privacy. > - 4.2.5, 2nd to last paragraph: > I am surprised to find that, when the receiver is not the subscriber, > that the receiver is expected to opt-out. It seems like some form of > opt-in or affirmative consent would be needed here. The question really was how heavy-weight should the mechanism be. Transports been considering are all encrypted. So there is already a level of trust between the peers. And a target can always pull down the connection if there are issues. In addition, multicast transports are viable for some future cases. We didn't want mechanisms which complicated this type of interaction, especially in a world where dumb IoT devices may be involved. Sue: If the receiver accepts a secure transport set-up from the server, can you provide the reason why this is not an "opt-in" once it receives the connection from the I2RS agent? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - General: I support Stephen's DISCUSS > > -2.2: What is the real scope of this work? Is it expected to supplant > the mentioned mechanisms? No. It is just showing that many specialized Push mechanism exist. This is not intended to supplant existing mechanisms, although perhaps it can help avoid future dedicated solutions. > - 2.3: "We need a new pub-sub > technology" > The shepherd write up mentioned a goal to use existing technologies. > Is the point of this sentence to suggest that is not feasible? Existing technologies cannot meet all the requirements specified. There are technology drafts progressing in NETCONF which can. > - 4.1, 4th paragraph: > The MAY doesn't seem right--is this a statement of fact that the > subscriber may have to resubscribe, or a requirement of the form that > the service MAY force the subscriber to resubscribe? (Be careful with > MAYs in requirements language--they imply unexpected things. For > example, several requirements say a SUBSCRIBE MAY do something--do > those imply that the service MUST allow the subscriber to do it ?) Good point. Reworded in v07. > -- 4.2.2, third bullet: The previous section said dampening periods > MUST be supported. Yes, but dampening is never for periodic subscriptions. > - 4.2.1, third paragraph: This is a bit ambiguous. I think it means to > change the what subtrees the subscription applies to, but could be > interpreted to change the subtrees themselves. Fixed > - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but > gave the subscriber a way to reconstruct the order fulfill this requirement? Yes, the timestamp within an update. But this requirement targets a specific object in a specific subscription. So there should be no issues. > Nits: > - The shepherd write up suggests this is standards track. The draft > and tracker both say informational. Please update the shepherd writ up. Fixed > -3, last paragraph: What's the difference between a "Push" and an "Update"? Reworded > -4.1: A forward reference to the subscription QoS section would be helpful. Moved the requirement in question to 4.2.6. > -- Last paragraph, last sentence: Sentence doesn't parse. Fixed > > - 4.2.8, third paragraph: I don't think that should be a 2119 MAY Fixed Thanks again for the review! Eric _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_06FF_01D1A695.797D5590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric, = Ben and IESG members:

 

The = pub/sub requirements are part of a 5 part requirements.   May = I quote from the shepherd's report:

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

The requirements for the first version of I2RS are: =

1) model driven ephemeral state - = that is data models that do not survive

    a software or hardware = reboot. 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-eph= emeral-state/

 

2) a = secure protocol -

https://datatracker.ietf.org/doc/draft-ietf-i2rs-pro= tocol-security-requirements/

 

3) = traceability - ability to record interactions between I2RS elements =

(Client, Agent, Routing system) =

https://datatracker.ietf.org/doc/draft-ietf-i2rs-tra= ceability/

 

4) notification publication via subscription =

https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub= -sub-requirements/

 

5) = Protocol to pass Data for Analytics 

The first version of these requirements does not = include a

separate analytical = protocol requirements as the simple use cases may

pass information via query/poll or the = notifications.

 

The = I2RS protocol exists in an secure environment described by: =

https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-env= ironment-reqs/

 

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

 

Eric - = Perhaps it would be good to point to:

·         = draft-ietf-i2rs-protocol-security-requirem= ents and

·         = draft-ietf-i2rs-security-environment-reqs/=

 

Ben – Can you tell me how the shepherd report = could have been clearer?  The I2rs protocol security requirements = require:  confidentiality, encryption, secure transport, protection = against replay attack, protection against DDoS attack (if = possible). 

 

Ben - = On opting in, once the receive accepts a transport connection from the = I2RS server – how is this not an opt-in to receive data? What are = you looking for?

 

Sue = Hares

(shepherd) =

 

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: = Wednesday, May 04, 2016 7:25 PM
To: Ben Campbell; The IESG
Cc: = i2rs@ietf.org; draft-ietf-i2rs-pub-sub-requirements@ietf.org; = i2rs-chairs@ietf.org; shares@ndzh.com
Subject: Re: [i2rs] Ben = Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with = DISCUSS and COMMENT)

 

Hi Ben,

 

Thanks = for the comment.   In-line....

 

> = From: Ben Campbell, May 04, 2016 2:49 PM

> = ----------------------------------------------------------------------

> DISCUSS:

> = ----------------------------------------------------------------------

>

> I have a couple of points I would like to = discuss. Hopefully they can

> = be resolved

> = easily:

>

> Are there really no requirements for privacy = or integrity protection?

> Is = there an expectation that this mechanism would ever carry privacy =

> sensitive or otherwise = sensitive information?

 

[eric’s comment:

When the subscription is established dynamically = via an existing transport session (which is expected to be the dominant = case) we have the same expectations for Privacy and integrity as would = be provided via a "GET" instead of a "PUSH" over the = same transport.   We could have replicated all these = requirements, but that was seen as unnecessary and likely less secure = than adopting existing mechanisms.

 

When = the Subscriber and Receiver are different, then the transport connection = will have credentials passed as part of the establishment.  These = credentials will be used as a Security Grooming Filter just like the = above case so that pushed objects will be excluded from an Update = Notification as per the permissions of the Receiver.   (I.e., = this is identical behavior to the above.)    As several = people have had questions about this, the new v07 will make this = explicit in the Security section.

End of eric’s comment]

 

Sue: The transport provides for privacy, integrity = protection.   Most configuration in network boxes would need = privacy.

 

> - = 4.2.5, 2nd to last paragraph:

> = I am surprised to find that, when the receiver is not the subscriber, =

> that the receiver is = expected to opt-out. It seems like some form of

> opt-in or affirmative consent would be needed = here.

 

The question really was how heavy-weight should the = mechanism be.  Transports been considering are all encrypted.  = So there is already a level of trust between the peers.  And a = target can always pull down the connection if there are issues. =

 

In addition, multicast transports are viable for = some future cases.  We didn't want mechanisms which complicated = this type of interaction, especially in a world where dumb IoT devices = may be involved.

 

Sue: If the receiver accepts a secure transport = set-up from the server, can you provide the reason why this is not an = “opt-in” once it receives the connection from the I2RS = agent?

 

 

> = ----------------------------------------------------------------------

> COMMENT:

> = ----------------------------------------------------------------------

>

> - General: I support Stephen's = DISCUSS

>

> -2.2: What is the real scope of this work? Is = it expected to supplant

> the = mentioned mechanisms?

 

No.   It is just showing that many = specialized Push mechanism exist.  This is not intended to supplant = existing mechanisms, although perhaps it can help avoid future dedicated = solutions.

> - 2.3: "We need a new = pub-sub

>    = technology"

> The shepherd = write up mentioned a goal to use existing technologies. =

> Is the point of this = sentence to suggest that is not feasible?

 

Existing technologies cannot meet all the = requirements specified.  There are technology drafts progressing in = NETCONF which can.

 

> - = 4.1, 4th paragraph:

> The MAY = doesn't seem right--is this a statement of fact that the =

> subscriber may have to = resubscribe, or a requirement of the form that

> the service MAY force the subscriber to = resubscribe? (Be careful with

> MAYs in requirements language--they imply = unexpected things. For

> = example, several requirements say a SUBSCRIBE MAY do something--do =

> those imply that the service = MUST allow the subscriber to do it ?)

 

Good = point.   Reworded in v07.

 

> = -- 4.2.2, third bullet: The previous section said dampening periods =

> MUST be = supported.

 

Yes, but dampening is never for periodic = subscriptions.

> - 4.2.1, third paragraph: This is a bit = ambiguous. I think it means to

> change the what subtrees the subscription = applies to, but could be

> = interpreted to change the subtrees themselves.

 

Fixed

=

> - 4.2.6.4: Would a mechanism = that allowed out-of-order delivery but

> gave the subscriber a way to reconstruct the = order fulfill this requirement?

 

Yes, = the timestamp within an update.  But this requirement targets a = specific object in a specific subscription.  So there should be no = issues.

> Nits:

> - The shepherd write up suggests this is = standards track. The draft

> = and tracker both say informational. Please update the shepherd writ = up.

 

Fixed

=

> -3, last paragraph: What's = the difference between a "Push" and an = "Update"?

 

Reworded

=

> -4.1: A forward reference to = the subscription QoS section would be helpful.

 

Moved = the requirement in question to 4.2.6.

> -- = Last paragraph, last sentence: Sentence doesn't parse.

 

Fixed

=

>

> - 4.2.8, third paragraph: I don't think that = should be a 2119 MAY

 

Fixed

=

Thanks again for the = review!

Eric

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_06FF_01D1A695.797D5590-- From nobody Thu May 5 06:19:04 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7A212D11E; Thu, 5 May 2016 06:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I14w4OUWn-9; Thu, 5 May 2016 06:18:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CA312D626; Thu, 5 May 2016 06:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5771; q=dns/txt; s=iport; t=1462454335; x=1463663935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RpIKhxBM3jQhz5H1Axqrjb+NCI8zza41xpheUuhvo80=; b=k6Qa0zPdRqB5EdeYMPOEaiEwMKGkDvGd3PRjDckgQAiehlLRuIW4qDTr /uDjZw/N/A3r8NcpAOEos8x+0yqm74p5l7uoERdDM+0jZiFldVHVY27es /MCPWktQHMGNt+ScqGtvn65BlGs3DOoK8dzb1uNVwubqZtvyNgluefug0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAwArRytX/4wNJK1dgzhTLlW3HIIPA?= =?us-ascii?q?Q2BdiSFbAKBMjgUAQEBAQEBAWUnhEEBAQEDATo/BQsCAQgVAwwBERAyJQIEDg0?= =?us-ascii?q?TiAcIDr8ZAQEBAQEBAQEBAQEBAQEBAQEBAQESBIYghEyEEREBhXUFh3mLLIR1A?= =?us-ascii?q?YV7iBaBb40rhiaJDQEeAQFCggUbFoE1iBE2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,582,1454976000"; d="scan'208";a="101160712" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2016 13:18:53 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u45DIr4C027787 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 13:18:53 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 09:18:52 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Thu, 5 May 2016 09:18:52 -0400 From: "Eric Voit (evoit)" To: Ben Campbell Thread-Topic: Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRpjWgYDspbfuo4UOD+L2iwgAMip+pXpHAgACgngCAAElsIA== Date: Thu, 5 May 2016 13:18:52 +0000 Message-ID: References: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> <40A52DF0-AD6C-4B47-8F34-70D4DB6399FA@nostrum.com> In-Reply-To: <40A52DF0-AD6C-4B47-8F34-70D4DB6399FA@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , The IESG , "shares@ndzh.com" , "i2rs-chairs@ietf.org" Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 13:18:57 -0000 Hi Ben Thanks, more in-line... > From: Ben Campbell, May 05, 2016 12:12 AM >=20 > Hi, thanks for the response. Comments in line, with sections removed that= do > not seem to need further discussion: >=20 >=20 > On 4 May 2016, at 18:24, Eric Voit (evoit) wrote: >=20 > > Hi Ben, > > > > Thanks for the comment. In-line.... > > > >> From: Ben Campbell, May 04, 2016 2:49 PM > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> I have a couple of points I would like to discuss. Hopefully they can > >> be resolved > >> easily: > >> > >> Are there really no requirements for privacy or integrity protection? > >> Is there an > >> expectation that this mechanism would ever carry privacy sensitive or > >> otherwise > >> sensitive information? > > > > When the subscription is established dynamically via an existing > > transport session (which is expected to be the dominant case) we have > > the same expectations for Privacy and integrity as would be provided > > via a "GET" instead of a "PUSH" over the same transport. We could > > have replicated all these requirements, but that was seen as > > unnecessary and likely less secure than adopting existing mechanisms. >=20 > Where do those requirements live now? I recall this draft mentioning > that support for multiple transports is required, but I don't recall > seeing anything about the required transport properties. (It's entirely > possible I missed it, or just forgot.) In Susan's email, she points out other I2RS documents with such requirement= s such as: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirem= ents/ The authors do hope that these subscription requirements will be applicable= beyond I2RS protocols. Therefore decoupling from transport to the degree = possible seemed wise. Therefore we didn't list some of the many documents = which talk about ways to lock down existing and potential transports over w= hich subscription updates might be pushed. These exist elsewhere. Example= documents which could have been linked include:=20 - RFC5539: NETCONF over Transport Layer Security - RFC6242: Using the NETCONF Protocol over Secure Shell - others relating to Restconf, HTTP, IPFIX, etc. =20 So in summary, it seems duplicative to bind in transport security reference= s here when these should be picked up when a transport protocol selection i= s made. But we can include if directed by the IESG. > > > > When the Subscriber and Receiver are different, then the transport > > connection will have credentials passed as part of the establishment. > > These credentials will be used as a Security Grooming Filter just like > > the above case so that pushed objects will be excluded from an Update > > Notification as per the permissions of the Receiver. (I.e., this is > > identical behavior to the above.) As several people have had > > questions about this, the new v07 will make this explicit in the > > Security section. >=20 > That will likely resolve my concern, but there's not enough detail here > to judge. I will watch for the update. Update posted. > > > > > >> - 4.2.5, 2nd to last paragraph: > >> I am surprised to find that, when the receiver is not the subscriber, > >> that the > >> receiver is expected to opt-out. It seems like some form of opt-in or > >> affirmative > >> consent would be needed here. > > > > The question really was how heavy-weight should the mechanism be. > > Transports been considering are all encrypted. So there is already a > > level of trust between the peers. And a target can always pull down > > the connection if there are issues. >=20 > I think you are talking about solution, not requirements. If the > solution is already known, what is the purpose of publishing the > requirements? One technology solution is being worked in the NETCONF WG, but this is in f= lux. Other solutions which don't meet the majority of these requirements = are being worked elsewhere (e.g., OC-Telemetry.yang). There is value in l= isting the requirements in of themselves. =20 > > > > In addition, multicast transports are viable for some future cases. > > We didn't want mechanisms which complicated this type of interaction, > > especially in a world where dumb IoT devices may be involved. >=20 > I think my response to this will depend on the details you mention are > coming in 07. This gets back to the point above about trying to maximally decouple subscr= iption establishment security (discussed in this document) with transport p= ayload security (which we believe is best left to the transports themselves= to reference). > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- >=20 > [...] >=20 >=20 > >> -- 4.2.2, third bullet: The previous section said dampening periods > >> MUST be > >> supported. > > > > Yes, but dampening is never for periodic subscriptions. >=20 > The third bullet is about on-change updates, not periodic publication. > 4.2.1 says the service MUST support dampening for on-change updates. Yes, but on-change itself is as SHOULD. See the requirement: A Subscription Service SHOULD support the ability to subscribe to updates "on-change", i.e., whenever values of subscribed data objects change. IF on-change is supported, then dampening is a MUST. The requirement in question must be written in a way which handles implemen= tations which don't support on-change. Eric > [...] From nobody Thu May 5 14:31:22 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB2F12D5AE; Thu, 5 May 2016 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnfsocA6Em7P; Thu, 5 May 2016 14:31:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CA1D512D5A9; Thu, 5 May 2016 14:31:17 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u45LVCwE093068 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 5 May 2016 16:31:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Susan Hares" Date: Thu, 05 May 2016 16:31:12 -0500 Message-ID: In-Reply-To: <06fe01d1a6b7$008d6ef0$01a84cd0$@ndzh.com> References: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> <06fe01d1a6b7$008d6ef0$01a84cd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, Eric Voit , The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 21:31:21 -0000 On 5 May 2016, at 5:15, Susan Hares wrote: > Eric, Ben and IESG members: > > > > The pub/sub requirements are part of a 5 part requirements. May I > quote > from the shepherd's report: > > --------------------- > > The requirements for the first version of I2RS are: > > 1) model driven ephemeral state - that is data models that do not > survive > > a software or hardware reboot. > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > > > 2) a secure protocol - > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme > nts/ > > > > 3) traceability - ability to record interactions between I2RS elements > > (Client, Agent, Routing system) > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ > > > > 4) notification publication via subscription > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ > > > > 5) Protocol to pass Data for Analytics > > The first version of these requirements does not include a > > separate analytical protocol requirements as the simple use cases may > > pass information via query/poll or the notifications. > > > > The I2RS protocol exists in an secure environment described by: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/ > > > > ------------------------- > > > > Eric - Perhaps it would be good to point to: > > . draft-ietf-i2rs-protocol-security-requirements and > > . draft-ietf-i2rs-security-environment-reqs/ > > > > Ben - Can you tell me how the shepherd report could have been clearer? > The > I2rs protocol security requirements require: confidentiality, > encryption, > secure transport, protection against replay attack, protection against > DDoS > attack (if possible). I think my confusion lies in the fact that, while the shepherd's writeup styles this draft as part of the I2RS protocol requirements, the draft itself claims to describe requirements for a generally useful pub-sub interface to a yang datastore. It's not clear to me how and when the I2RS protocol security requirements apply to it. If the described interface is intended to be useful in contexts other than I2RS (and the draft explicitly sets that expectation in 2.2), it needs to talk more generally about security and privacy. For example, it might make sense to say that certain security requirements apply in environments where the mechanism might carry privacy sensitive data, and then point to the i2rs requirements for when the mechanism is used in an I2RS context. A different approach might be to more tightly constrain this to i2rs > > > > Ben - On opting in, once the receive accepts a transport connection > from the > I2RS server - how is this not an opt-in to receive data? What are you > looking for? I guess that depends on the transport. The transport requirements say the mechanism has to work over multiple transports. The last paragraph in 4.2.4 says "In the case of connection-oriented transports..." which suggests that non-connection-oriented transports are possible. Even with a connection-oriented transport, this may depend on how connection-management is handled, and whether the receiver might be receiving things it _wants_ to receive on the same transport. > > > > Sue Hares > > (shepherd) > > > > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit > (evoit) > Sent: Wednesday, May 04, 2016 7:25 PM > To: Ben Campbell; The IESG > Cc: i2rs@ietf.org; draft-ietf-i2rs-pub-sub-requirements@ietf.org; > i2rs-chairs@ietf.org; shares@ndzh.com > Subject: Re: [i2rs] Ben Campbell's Discuss on > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > > > Hi Ben, > > > > Thanks for the comment. In-line.... > > > >> From: Ben Campbell, May 04, 2016 2:49 PM > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> I have a couple of points I would like to discuss. Hopefully they can > >> be resolved > >> easily: > >> > >> Are there really no requirements for privacy or integrity protection? > >> Is there an expectation that this mechanism would ever carry privacy > >> sensitive or otherwise sensitive information? > > > > [eric's comment: > > When the subscription is established dynamically via an existing > transport > session (which is expected to be the dominant case) we have the same > expectations for Privacy and integrity as would be provided via a > "GET" > instead of a "PUSH" over the same transport. We could have > replicated all > these requirements, but that was seen as unnecessary and likely less > secure > than adopting existing mechanisms. > > > > When the Subscriber and Receiver are different, then the transport > connection will have credentials passed as part of the establishment. > These > credentials will be used as a Security Grooming Filter just like the > above > case so that pushed objects will be excluded from an Update > Notification as > per the permissions of the Receiver. (I.e., this is identical > behavior to > the above.) As several people have had questions about this, the > new v07 > will make this explicit in the Security section. > > End of eric's comment] > > > > Sue: The transport provides for privacy, integrity protection. Most > configuration in network boxes would need privacy. > > > >> - 4.2.5, 2nd to last paragraph: > >> I am surprised to find that, when the receiver is not the subscriber, > >> that the receiver is expected to opt-out. It seems like some form of > >> opt-in or affirmative consent would be needed here. > > > > The question really was how heavy-weight should the mechanism be. > Transports been considering are all encrypted. So there is already a > level > of trust between the peers. And a target can always pull down the > connection if there are issues. > > > > In addition, multicast transports are viable for some future cases. > We > didn't want mechanisms which complicated this type of interaction, > especially in a world where dumb IoT devices may be involved. > > > > Sue: If the receiver accepts a secure transport set-up from the > server, can > you provide the reason why this is not an "opt-in" once it receives > the > connection from the I2RS agent? > > > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> - General: I support Stephen's DISCUSS > >> > >> -2.2: What is the real scope of this work? Is it expected to supplant > >> the mentioned mechanisms? > > > > No. It is just showing that many specialized Push mechanism exist. > This > is not intended to supplant existing mechanisms, although perhaps it > can > help avoid future dedicated solutions. > >> - 2.3: "We need a new pub-sub > >> technology" > >> The shepherd write up mentioned a goal to use existing technologies. > >> Is the point of this sentence to suggest that is not feasible? > > > > Existing technologies cannot meet all the requirements specified. > There are > technology drafts progressing in NETCONF which can. > > > >> - 4.1, 4th paragraph: > >> The MAY doesn't seem right--is this a statement of fact that the > >> subscriber may have to resubscribe, or a requirement of the form that > >> the service MAY force the subscriber to resubscribe? (Be careful with > >> MAYs in requirements language--they imply unexpected things. For > >> example, several requirements say a SUBSCRIBE MAY do something--do > >> those imply that the service MUST allow the subscriber to do it ?) > > > > Good point. Reworded in v07. > > > >> -- 4.2.2, third bullet: The previous section said dampening periods > >> MUST be supported. > > > > Yes, but dampening is never for periodic subscriptions. > >> - 4.2.1, third paragraph: This is a bit ambiguous. I think it means >> to > >> change the what subtrees the subscription applies to, but could be > >> interpreted to change the subtrees themselves. > > > > Fixed > >> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but > >> gave the subscriber a way to reconstruct the order fulfill this > requirement? > > > > Yes, the timestamp within an update. But this requirement targets a > specific object in a specific subscription. So there should be no > issues. > >> Nits: > >> - The shepherd write up suggests this is standards track. The draft > >> and tracker both say informational. Please update the shepherd writ >> up. > > > > Fixed > >> -3, last paragraph: What's the difference between a "Push" and an > "Update"? > > > > Reworded > >> -4.1: A forward reference to the subscription QoS section would be > helpful. > > > > Moved the requirement in question to 4.2.6. > >> -- Last paragraph, last sentence: Sentence doesn't parse. > > > > Fixed > >> > >> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY > > > > Fixed > > Thanks again for the review! > > Eric > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 5 14:58:16 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E1A12D13F; Thu, 5 May 2016 14:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szm77giB3EXY; Thu, 5 May 2016 14:58:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8730D12D0EC; Thu, 5 May 2016 14:58:12 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u45LwA89095496 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 5 May 2016 16:58:10 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Eric Voit" Date: Thu, 05 May 2016 16:58:09 -0500 Message-ID: <8EFC7B43-619D-40AB-ABD4-39AC4923349B@nostrum.com> In-Reply-To: References: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> <40A52DF0-AD6C-4B47-8F34-70D4DB6399FA@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , The IESG , "shares@ndzh.com" , "i2rs-chairs@ietf.org" Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 21:58:14 -0000 Hi Eric, same here. On 5 May 2016, at 8:18, Eric Voit (evoit) wrote: > Hi Ben > > Thanks, more in-line... > >> From: Ben Campbell, May 05, 2016 12:12 AM >> [...] >>>> --------------------------------------------------------------------= -- >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> I have a couple of points I would like to discuss. Hopefully they = >>>> can >>>> be resolved >>>> easily: >>>> >>>> Are there really no requirements for privacy or integrity = >>>> protection? >>>> Is there an >>>> expectation that this mechanism would ever carry privacy sensitive = >>>> or >>>> otherwise >>>> sensitive information? >>> >>> When the subscription is established dynamically via an existing >>> transport session (which is expected to be the dominant case) we = >>> have >>> the same expectations for Privacy and integrity as would be provided >>> via a "GET" instead of a "PUSH" over the same transport. We could >>> have replicated all these requirements, but that was seen as >>> unnecessary and likely less secure than adopting existing = >>> mechanisms. >> >> Where do those requirements live now? I recall this draft mentioning >> that support for multiple transports is required, but I don't recall >> seeing anything about the required transport properties. (It's = >> entirely >> possible I missed it, or just forgot.) > > In Susan's email, she points out other I2RS documents with such = > requirements such as: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requ= irements/ > > The authors do hope that these subscription requirements will be = > applicable beyond I2RS protocols. Therefore decoupling from transport = > to the degree possible seemed wise. Therefore we didn't list some of = > the many documents which talk about ways to lock down existing and = > potential transports over which subscription updates might be pushed. = > These exist elsewhere. Example documents which could have been linked = > include: > - RFC5539: NETCONF over Transport Layer Security > - RFC6242: Using the NETCONF Protocol over Secure Shell > - others relating to Restconf, HTTP, IPFIX, etc. > > So in summary, it seems duplicative to bind in transport security = > references here when these should be picked up when a transport = > protocol selection is made. But we can include if directed by the = > IESG. (See my comments to Susan.) My concern here is that there are a = assumptions about the security properties of the environment that need = to be explicit. You don't have to restate everything, but pointing to = those documents would help. But there's still a fundemental conflict between the idea that this = mechanism should be useful beyond the i2rs context, and the assumption = of i2rs security mechanisms. > >>> >>> When the Subscriber and Receiver are different, then the transport >>> connection will have credentials passed as part of the = >>> establishment. >>> These credentials will be used as a Security Grooming Filter just = >>> like >>> the above case so that pushed objects will be excluded from an = >>> Update >>> Notification as per the permissions of the Receiver. (I.e., this = >>> is >>> identical behavior to the above.) As several people have had >>> questions about this, the new v07 will make this explicit in the >>> Security section. >> >> That will likely resolve my concern, but there's not enough detail = >> here >> to judge. I will watch for the update. > > Update posted. Thanks, I saw that shortly after I sent this, but have not yet had time = to look at it. I will do so as soon as I can. > >>> >>> >>>> - 4.2.5, 2nd to last paragraph: >>>> I am surprised to find that, when the receiver is not the = >>>> subscriber, >>>> that the >>>> receiver is expected to opt-out. It seems like some form of opt-in = >>>> or >>>> affirmative >>>> consent would be needed here. >>> >>> The question really was how heavy-weight should the mechanism be. >>> Transports been considering are all encrypted. So there is already = >>> a >>> level of trust between the peers. And a target can always pull down >>> the connection if there are issues. >> >> I think you are talking about solution, not requirements. If the >> solution is already known, what is the purpose of publishing the >> requirements? > > One technology solution is being worked in the NETCONF WG, but this is = > in flux. Other solutions which don't meet the majority of these = > requirements are being worked elsewhere (e.g., OC-Telemetry.yang). = > There is value in listing the requirements in of themselves. I accept that--but if that is the case, it doesn't seem wise for the = requirements to assume something is not a problem because it's not a = problem for a particular solution. > >>> >>> In addition, multicast transports are viable for some future cases. >>> We didn't want mechanisms which complicated this type of = >>> interaction, >>> especially in a world where dumb IoT devices may be involved. >> >> I think my response to this will depend on the details you mention = >> are >> coming in 07. > > This gets back to the point above about trying to maximally decouple = > subscription establishment security (discussed in this document) with = > transport payload security (which we believe is best left to the = > transports themselves to reference). > Hmm. I infer from that that requirements about how Updates are carried = (as opposed to when and to whom they are carried) are not in scope here? = But that still ties back to whether this is expected to be a general = mechanism, vs just an i2rs or netconf mechanism. >>> >>>> --------------------------------------------------------------------= -- >>>> COMMENT: >>>> --------------------------------------------------------------------= -- >> >> [...] >> >> >>>> -- 4.2.2, third bullet: The previous section said dampening periods >>>> MUST be >>>> supported. >>> >>> Yes, but dampening is never for periodic subscriptions. >> >> The third bullet is about on-change updates, not periodic = >> publication. >> 4.2.1 says the service MUST support dampening for on-change updates. > > Yes, but on-change itself is as SHOULD. See the requirement: > A Subscription Service SHOULD support the ability to subscribe to > updates "on-change", i.e., whenever values of subscribed data = > objects > change. > IF on-change is supported, then dampening is a MUST. > > The requirement in question must be written in a way which handles = > implementations which don't support on-change. Ah, there lies the confusion. I interpreted the "(if supported)" part to = be about whether the dampening period was supported, not about whether = on-change was supported. I suggest something to the effect of: OLD The dampening period, for on-change update policy (if supported) NEW The on-change policy dampening period (if the on-change policy is = supported). From nobody Thu May 5 19:13:48 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435F112D7DA; Thu, 5 May 2016 19:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldTAELe03lDz; Thu, 5 May 2016 19:13:44 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B8012D19B; Thu, 5 May 2016 19:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8536; q=dns/txt; s=iport; t=1462500823; x=1463710423; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3WDQ+/Onanv90in03hpVEaWu2x5JidWNRHVB5OVmlvc=; b=YgX5+rPtg9hkMcN4Knkm63214KADPpsvgfD+/ePUztlbDiFNrUbjU79O gsglDBFYP6LJ14+0i5bczhEI0uFxcjb7HP1egg6roRXYFEsozy90m5P4S dgz1uFyOYJgRTsZCgK+RBbm/1L8Gr0WDSxDx26LrsokKWKsGlvXHJW1sb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AgCA/StX/40NJK1egzhTLlW3D4IPA?= =?us-ascii?q?Q2BdiKFbgKBNjgUAQEBAQEBAWUnhEEBAQEDATotEgULAgEIFQMMAREQMiUCBA4?= =?us-ascii?q?NE4gHCA6+SQEBAQEBAQEBAQEBAQEBAQEBAQEBEgSGIIRMhBERAYV1BYd5kCEBh?= =?us-ascii?q?XuIFoFvjSuGJokNAR4BAUKCBRsWgTWHZDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,585,1454976000"; d="scan'208";a="270170692" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 May 2016 02:13:42 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u462DgPU007762 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 May 2016 02:13:42 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 22:13:41 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Thu, 5 May 2016 22:13:41 -0400 From: "Eric Voit (evoit)" To: Ben Campbell Thread-Topic: Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRpjWgYDspbfuo4UOD+L2iwgAMip+pXpHAgACgngCAAElsIIAA4HOA///KDDA= Date: Fri, 6 May 2016 02:13:41 +0000 Message-ID: References: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> <40A52DF0-AD6C-4B47-8F34-70D4DB6399FA@nostrum.com> <8EFC7B43-619D-40AB-ABD4-39AC4923349B@nostrum.com> In-Reply-To: <8EFC7B43-619D-40AB-ABD4-39AC4923349B@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , The IESG , "shares@ndzh.com" , "i2rs-chairs@ietf.org" Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 02:13:46 -0000 + more... > From: Ben Campbell, May 05, 2016 5:58 PM >=20 > Hi Eric, same here. >=20 > On 5 May 2016, at 8:18, Eric Voit (evoit) wrote: >=20 > > Hi Ben > > > > Thanks, more in-line... > > > >> From: Ben Campbell, May 05, 2016 12:12 AM > >> >=20 > [...] >=20 > >>>> ------------------------------------------------------------------- > >>>> --- > >>>> DISCUSS: > >>>> ------------------------------------------------------------------- > >>>> --- > >>>> > >>>> I have a couple of points I would like to discuss. Hopefully they > >>>> can be resolved > >>>> easily: > >>>> > >>>> Are there really no requirements for privacy or integrity > >>>> protection? > >>>> Is there an > >>>> expectation that this mechanism would ever carry privacy sensitive > >>>> or otherwise sensitive information? > >>> > >>> When the subscription is established dynamically via an existing > >>> transport session (which is expected to be the dominant case) we > >>> have the same expectations for Privacy and integrity as would be > >>> provided > >>> via a "GET" instead of a "PUSH" over the same transport. We could > >>> have replicated all these requirements, but that was seen as > >>> unnecessary and likely less secure than adopting existing > >>> mechanisms. > >> > >> Where do those requirements live now? I recall this draft mentioning > >> that support for multiple transports is required, but I don't recall > >> seeing anything about the required transport properties. (It's > >> entirely possible I missed it, or just forgot.) > > > > In Susan's email, she points out other I2RS documents with such > > requirements such as: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req > > uirements/ > > > > The authors do hope that these subscription requirements will be > > applicable beyond I2RS protocols. Therefore decoupling from transport > > to the degree possible seemed wise. Therefore we didn't list some of > > the many documents which talk about ways to lock down existing and > > potential transports over which subscription updates might be pushed. > > These exist elsewhere. Example documents which could have been linked > > include: > > - RFC5539: NETCONF over Transport Layer Security > > - RFC6242: Using the NETCONF Protocol over Secure Shell > > - others relating to Restconf, HTTP, IPFIX, etc. > > > > So in summary, it seems duplicative to bind in transport security > > references here when these should be picked up when a transport > > protocol selection is made. But we can include if directed by the > > IESG. >=20 > (See my comments to Susan.) My concern here is that there are a assumptio= ns > about the security properties of the environment that need to be explicit= . You > don't have to restate everything, but pointing to those documents would h= elp. I have just inserted the following text into the start of Section 4.2.4.: "= It is possible for updates coming from a Subscription Service to be pushed = over different types of transports. Good deployment practices will bind th= e Subscription Service into secure, encrypted transport layer mechanisms. = For example if NETCONF is used then RFC5523 would be a valid option to secu= re the transported information." Do this meet your intent? =20 > But there's still a fundemental conflict between the idea that this mecha= nism > should be useful beyond the i2rs context, and the assumption of i2rs secu= rity > mechanisms. I see no conflict because I2RS security mechanisms apply to I2RS deployment= s. Existing transport security mechanisms can be applied for other deploym= ent types. This hopefully is highlighted/supported via the text just propo= sed above. >From day 1 we have been aggregating requirements from beyond the I2RS domai= n. Discussion across ADs for Routing and Ops and with multiple WG chairs = have pointed us to an aggregated requirements draft. These requirements= are useful for I2RS deployment cases. These requirements are useful for o= ther use cases as well. This draft has been reviewed with NETCONF and NET= MOD, and the NETCONF has draft-ietf-netconf-yang-push (not bound to I2RS pr= otocols) based on these requirements.=20 =20 > >>>> - 4.2.5, 2nd to last paragraph: > >>>> I am surprised to find that, when the receiver is not the > >>>> subscriber, > >>>> that the > >>>> receiver is expected to opt-out. It seems like some form of opt-in > >>>> or > >>>> affirmative > >>>> consent would be needed here. > >>> > >>> The question really was how heavy-weight should the mechanism be. > >>> Transports been considering are all encrypted. So there is already > >>> a > >>> level of trust between the peers. And a target can always pull down > >>> the connection if there are issues. > >> > >> I think you are talking about solution, not requirements. If the > >> solution is already known, what is the purpose of publishing the > >> requirements? > > > > One technology solution is being worked in the NETCONF WG, but this is > > in flux. Other solutions which don't meet the majority of these > > requirements are being worked elsewhere (e.g., OC-Telemetry.yang). > > There is value in listing the requirements in of themselves. >=20 > I accept that--but if that is the case, it doesn't seem wise for the > requirements to assume something is not a problem because it's not a > problem for a particular solution. In the NETCONF WG we are doing our very best to decouple the subscription e= stablishment and maintenance technology draft from the underlying transport= drafts. This is being well received; independent drafts for NETCONF, REST= CONF/HTTP subscription transport are on a path to adoption. Broadband Foru= m members attending IETF96 have suggested we consider IPFIX transport. Oth= ers have suggested COAP transport. Still others are thinking about how to = integrate it into GPB/GRPC. =20 By avoiding transport specifics, the Subscription Service becomes more wide= ly applicable.=20 =20 > > > >>> > >>> In addition, multicast transports are viable for some future cases. > >>> We didn't want mechanisms which complicated this type of > >>> interaction, > >>> especially in a world where dumb IoT devices may be involved. > >> > >> I think my response to this will depend on the details you mention > >> are > >> coming in 07. > > > > This gets back to the point above about trying to maximally decouple > > subscription establishment security (discussed in this document) with > > transport payload security (which we believe is best left to the > > transports themselves to reference). > > >=20 > Hmm. I infer from that that requirements about how Updates are carried > (as opposed to when and to whom they are carried) are not in scope here? > But that still ties back to whether this is expected to be a general > mechanism, vs just an i2rs or netconf mechanism. Hopefully this is addressed above. > >>> > >>>> --------------------------------------------------------------------= -- > >>>> COMMENT: > >>>> --------------------------------------------------------------------= -- > >> > >> [...] > >> > >> > >>>> -- 4.2.2, third bullet: The previous section said dampening periods > >>>> MUST be > >>>> supported. > >>> > >>> Yes, but dampening is never for periodic subscriptions. > >> > >> The third bullet is about on-change updates, not periodic > >> publication. > >> 4.2.1 says the service MUST support dampening for on-change updates. > > > > Yes, but on-change itself is as SHOULD. See the requirement: > > A Subscription Service SHOULD support the ability to subscribe to > > updates "on-change", i.e., whenever values of subscribed data > > objects > > change. > > IF on-change is supported, then dampening is a MUST. > > > > The requirement in question must be written in a way which handles > > implementations which don't support on-change. >=20 > Ah, there lies the confusion. I interpreted the "(if supported)" part to > be about whether the dampening period was supported, not about whether > on-change was supported. >=20 > I suggest something to the effect of: > OLD > The dampening period, for on-change update policy (if supported) > NEW > The on-change policy dampening period (if the on-change policy is sup= ported). Makes sense. Updated per your suggestion in the '-08' working copy. Eric >=20 From nobody Thu May 5 22:59:02 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2551212D1E9; Thu, 5 May 2016 22:59:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160506055901.26792.54292.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 22:59:01 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 05:59:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-06.txt Pages : 16 Date : 2016-05-05 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 5 23:01:01 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCE712D1E9; Thu, 5 May 2016 23:00:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160506060057.26827.78647.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 23:00:57 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-protocol-security-requirements-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 06:00:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Security Related Requirements Authors : Susan Hares Daniel Migault Joel Halpern Filename : draft-ietf-i2rs-protocol-security-requirements-04.txt Pages : 14 Date : 2016-05-05 Abstract: This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-protocol-security-requirements-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-protocol-security-requirements-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 5 23:06:34 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844A912D1CD; Thu, 5 May 2016 23:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLQ_IlEth-n0; Thu, 5 May 2016 23:06:30 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 3D09E12D1A4; Thu, 5 May 2016 23:06:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Ben Campbell'" References: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> <06fe01d1a6b7$008d6ef0$01a84cd0$@ndzh.com> In-Reply-To: Date: Fri, 6 May 2016 02:06:24 -0400 Message-ID: <00b201d1a75d$6c13a940$443afbc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHJx9xjXwVK0KpUYwM2Ib+kCcb/YgKqFtf2Ac02IqECXpljeZ+EU6Rg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, 'Eric Voit' , 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 06:06:32 -0000 Ben: This is the first of the "re-use" management protocols. The requirements are set-up so that we can suggest additions to the NETCONF and RESTCONF for this first of I2RS. The I2RS ephemeral work, pub/sub, traceability, and security are target at the I2RS protocol definition with the I2RS use case. However, since these are general additions to NETCONF/RESTCONF, this work can be used elsewhere. I think the text you are highlighting has this larger context. Now, one of the really important things to chat with Alia and Benoit is how do we handle the wider use case. Do we mention the wider context? The WG thought mentioning it was important. Sue -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com] Sent: Thursday, May 05, 2016 5:31 PM To: Susan Hares Cc: Eric Voit; The IESG; i2rs@ietf.org; draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) On 5 May 2016, at 5:15, Susan Hares wrote: > Eric, Ben and IESG members: > > > > The pub/sub requirements are part of a 5 part requirements. May I > quote > from the shepherd's report: > > --------------------- > > The requirements for the first version of I2RS are: > > 1) model driven ephemeral state - that is data models that do not > survive > > a software or hardware reboot. > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > > > 2) a secure protocol - > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req > uireme > nts/ > > > > 3) traceability - ability to record interactions between I2RS elements > > (Client, Agent, Routing system) > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ > > > > 4) notification publication via subscription > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ > > > > 5) Protocol to pass Data for Analytics > > The first version of these requirements does not include a > > separate analytical protocol requirements as the simple use cases may > > pass information via query/poll or the notifications. > > > > The I2RS protocol exists in an secure environment described by: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment- > reqs/ > > > > ------------------------- > > > > Eric - Perhaps it would be good to point to: > > . draft-ietf-i2rs-protocol-security-requirements and > > . draft-ietf-i2rs-security-environment-reqs/ > > > > Ben - Can you tell me how the shepherd report could have been clearer? > The > I2rs protocol security requirements require: confidentiality, > encryption, secure transport, protection against replay attack, > protection against DDoS attack (if possible). I think my confusion lies in the fact that, while the shepherd's writeup styles this draft as part of the I2RS protocol requirements, the draft itself claims to describe requirements for a generally useful pub-sub interface to a yang datastore. It's not clear to me how and when the I2RS protocol security requirements apply to it. If the described interface is intended to be useful in contexts other than I2RS (and the draft explicitly sets that expectation in 2.2), it needs to talk more generally about security and privacy. For example, it might make sense to say that certain security requirements apply in environments where the mechanism might carry privacy sensitive data, and then point to the i2rs requirements for when the mechanism is used in an I2RS context. A different approach might be to more tightly constrain this to i2rs > > > > Ben - On opting in, once the receive accepts a transport connection > from the I2RS server - how is this not an opt-in to receive data? What > are you looking for? I guess that depends on the transport. The transport requirements say the mechanism has to work over multiple transports. The last paragraph in 4.2.4 says "In the case of connection-oriented transports..." which suggests that non-connection-oriented transports are possible. Even with a connection-oriented transport, this may depend on how connection-management is handled, and whether the receiver might be receiving things it _wants_ to receive on the same transport. > > > > Sue Hares > > (shepherd) > > > > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit > (evoit) > Sent: Wednesday, May 04, 2016 7:25 PM > To: Ben Campbell; The IESG > Cc: i2rs@ietf.org; draft-ietf-i2rs-pub-sub-requirements@ietf.org; > i2rs-chairs@ietf.org; shares@ndzh.com > Subject: Re: [i2rs] Ben Campbell's Discuss on > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > > > Hi Ben, > > > > Thanks for the comment. In-line.... > > > >> From: Ben Campbell, May 04, 2016 2:49 PM > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> I have a couple of points I would like to discuss. Hopefully they can > >> be resolved > >> easily: > >> > >> Are there really no requirements for privacy or integrity protection? > >> Is there an expectation that this mechanism would ever carry privacy > >> sensitive or otherwise sensitive information? > > > > [eric's comment: > > When the subscription is established dynamically via an existing > transport > session (which is expected to be the dominant case) we have the same > expectations for Privacy and integrity as would be provided via a > "GET" > instead of a "PUSH" over the same transport. We could have > replicated all > these requirements, but that was seen as unnecessary and likely less > secure > than adopting existing mechanisms. > > > > When the Subscriber and Receiver are different, then the transport > connection will have credentials passed as part of the establishment. > These > credentials will be used as a Security Grooming Filter just like the > above > case so that pushed objects will be excluded from an Update > Notification as > per the permissions of the Receiver. (I.e., this is identical > behavior to > the above.) As several people have had questions about this, the > new v07 > will make this explicit in the Security section. > > End of eric's comment] > > > > Sue: The transport provides for privacy, integrity protection. Most > configuration in network boxes would need privacy. > > > >> - 4.2.5, 2nd to last paragraph: > >> I am surprised to find that, when the receiver is not the subscriber, > >> that the receiver is expected to opt-out. It seems like some form of > >> opt-in or affirmative consent would be needed here. > > > > The question really was how heavy-weight should the mechanism be. > Transports been considering are all encrypted. So there is already a > level > of trust between the peers. And a target can always pull down the > connection if there are issues. > > > > In addition, multicast transports are viable for some future cases. > We > didn't want mechanisms which complicated this type of interaction, > especially in a world where dumb IoT devices may be involved. > > > > Sue: If the receiver accepts a secure transport set-up from the > server, can > you provide the reason why this is not an "opt-in" once it receives > the > connection from the I2RS agent? > > > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> - General: I support Stephen's DISCUSS > >> > >> -2.2: What is the real scope of this work? Is it expected to supplant > >> the mentioned mechanisms? > > > > No. It is just showing that many specialized Push mechanism exist. > This > is not intended to supplant existing mechanisms, although perhaps it > can > help avoid future dedicated solutions. > >> - 2.3: "We need a new pub-sub > >> technology" > >> The shepherd write up mentioned a goal to use existing technologies. > >> Is the point of this sentence to suggest that is not feasible? > > > > Existing technologies cannot meet all the requirements specified. > There are > technology drafts progressing in NETCONF which can. > > > >> - 4.1, 4th paragraph: > >> The MAY doesn't seem right--is this a statement of fact that the > >> subscriber may have to resubscribe, or a requirement of the form that > >> the service MAY force the subscriber to resubscribe? (Be careful with > >> MAYs in requirements language--they imply unexpected things. For > >> example, several requirements say a SUBSCRIBE MAY do something--do > >> those imply that the service MUST allow the subscriber to do it ?) > > > > Good point. Reworded in v07. > > > >> -- 4.2.2, third bullet: The previous section said dampening periods > >> MUST be supported. > > > > Yes, but dampening is never for periodic subscriptions. > >> - 4.2.1, third paragraph: This is a bit ambiguous. I think it means >> to > >> change the what subtrees the subscription applies to, but could be > >> interpreted to change the subtrees themselves. > > > > Fixed > >> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but > >> gave the subscriber a way to reconstruct the order fulfill this > requirement? > > > > Yes, the timestamp within an update. But this requirement targets a > specific object in a specific subscription. So there should be no > issues. > >> Nits: > >> - The shepherd write up suggests this is standards track. The draft > >> and tracker both say informational. Please update the shepherd writ >> up. > > > > Fixed > >> -3, last paragraph: What's the difference between a "Push" and an > "Update"? > > > > Reworded > >> -4.1: A forward reference to the subscription QoS section would be > helpful. > > > > Moved the requirement in question to 4.2.6. > >> -- Last paragraph, last sentence: Sentence doesn't parse. > > > > Fixed > >> > >> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY > > > > Fixed > > Thanks again for the review! > > Eric > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 5 23:20:36 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFED512D1C9; Thu, 5 May 2016 23:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNmqY6kx2VXp; Thu, 5 May 2016 23:20:29 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 B086412D4FF; Thu, 5 May 2016 23:13:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> In-Reply-To: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> Date: Fri, 6 May 2016 02:13:34 -0400 Message-ID: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4phi8G66fo2y5TGN4Rlmg6MU68J9db/mw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netconf@ietf.org Subject: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 06:20:33 -0000 =20 This version of the protocol strawman is the result of all the = suggestions from the I2RS meeting and inputs from other reviews. =20 Please let us know if you have additional reviews.=20 Sue, Amit, and Andy=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, May 06, 2016 2:11 AM To: Amit Daas; amit.dass@ericsson.com; Andy Bierman; Susan Hares Subject: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-hares-i2rs-protocol-strawman Revision: 02 Title: I2RS protocol strawman Document date: 2016-05-05 Group: Individual Submission Pages: 52 URL: = https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-0= 2.txt Status: = https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/ Htmlized: = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-protocol-strawman-02= Abstract: This strawman proposal for the I2RS protocol supports I2RS requirements for ephemeral data store, management data flows, and protocol security. It proposes additions to the NETCONF, RESTCONF, and YANG for these requirements. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Fri May 6 00:34:58 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B304412D879 for ; Fri, 6 May 2016 00:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNjX2ZiA9Lp6 for ; Fri, 6 May 2016 00:34: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 84CEF12D871 for ; Fri, 6 May 2016 00:34:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A434F1084 for ; Fri, 6 May 2016 09:34: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 mA-1NMphwECu for ; Fri, 6 May 2016 09:34:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 6 May 2016 09:34:50 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B05DB20AAD for ; Fri, 6 May 2016 09:34: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 yD-iqwXP7WKP; Fri, 6 May 2016 09:34:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BA3420859; Fri, 6 May 2016 09:34:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 175F63AC8B34; Fri, 6 May 2016 09:34:45 +0200 (CEST) Date: Fri, 6 May 2016 09:34:45 +0200 From: Juergen Schoenwaelder To: i2rs@ietf.org Message-ID: <20160506073445.GA42286@elstar.local> Mail-Followup-To: i2rs@ietf.org References: <20160506055901.26792.54292.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160506055901.26792.54292.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 07:34:57 -0000 I have a hard time with this document. Section 3 is labelled requirements but it actually details solution and I disagree with a significant number of the solution elements. To name an example: Indicating in a data model with which protocols it should be used and which secure transports underneath the protocol should be used. I do not want to discuss all the details here since obviously this is not a requirements document. /js On Thu, May 05, 2016 at 10:59:01PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System of the IETF. > > Title : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-06.txt > Pages : 16 > Date : 2016-05-05 > > Abstract: > This document covers requests to the netmod and netconf Working > Groups for functionality to support the ephemeral state requirements > to implement the I2RS architecture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri May 6 00:44:29 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C1412D14D; Fri, 6 May 2016 00:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CT-0pvuAznY; Fri, 6 May 2016 00:44:23 -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 D3BB012B03A; Fri, 6 May 2016 00:44:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9976E1084; Fri, 6 May 2016 09:44:21 +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 NazF4JPJN6Sf; Fri, 6 May 2016 09:44:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 May 2016 09:44:20 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B38B120961; Fri, 6 May 2016 09:44:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 66P85M2KPFW2; Fri, 6 May 2016 09:44:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D38F20960; Fri, 6 May 2016 09:44:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0057C3AC8BA1; Fri, 6 May 2016 09:44:18 +0200 (CEST) Date: Fri, 6 May 2016 09:44:18 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160506074418.GB42286@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, netconf@ietf.org References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, netconf@ietf.org Subject: Re: [i2rs] [Netconf] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 07:44:25 -0000 I disagree with many things in the document. For example, a data model must not detail things like o encoding [XML | JSON] o protocol [RESTCONF | NETCONF] o protocol-transport [ssh, tls, tcp] o transport-ports [ports] because of layering and modularity concerns and of deployment flexibility. There are many more of these. Overall, it would help if there were fewer documents and not so many overlapping documents. /js On Fri, May 06, 2016 at 02:13:34AM -0400, Susan Hares wrote: > > This version of the protocol strawman is the result of all the suggestions from the I2RS meeting and inputs from other reviews. > Please let us know if you have additional reviews. > > Sue, Amit, and Andy > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, May 06, 2016 2:11 AM > To: Amit Daas; amit.dass@ericsson.com; Andy Bierman; Susan Hares > Subject: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt > > > A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt > has been successfully submitted by Susan Hares and posted to the IETF repository. > > Name: draft-hares-i2rs-protocol-strawman > Revision: 02 > Title: I2RS protocol strawman > Document date: 2016-05-05 > Group: Individual Submission > Pages: 52 > URL: https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-02.txt > Status: https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/ > Htmlized: https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-protocol-strawman-02 > > Abstract: > This strawman proposal for the I2RS protocol supports I2RS > requirements for ephemeral data store, management data flows, and > protocol security. It proposes additions to the NETCONF, RESTCONF, > and YANG for these requirements. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri May 6 08:51:49 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBFB12B03D; Fri, 6 May 2016 08:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYZ3MdPUr45j; Fri, 6 May 2016 08:51:46 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C81A12B010; Fri, 6 May 2016 08:51:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C847925834D; Fri, 6 May 2016 08:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462549905; bh=htiioxMo1Xck2pbcXRkKHjtJI1xWVNbuY80iMKiqDzQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jKLagFBwIvfMRb/LfLG0BpmLqgU6sA9c8A/vUwtGTikW+v/3xBKMyFH7aXvfSb+4q RttCEfNphJJB7EG8WrdDrG8o3oXX4zWy4G3EA9nxtidGMHq9d6kwo9/pR/hU1Gz2af WJQJx7qQ/iSNqNXcCFuXm2J6zfWmkeAjYH72+wHM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4EA6C2466C2; Fri, 6 May 2016 08:51:45 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 6 May 2016 11:51:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 15:51:48 -0000 Reading the latest revision, in section 3.1.1, the text in bullet 5 says that the data model indicates which portions are ephemeral. That makes sense to me. Then bullet 6 says that the management protocol needs to signal (in its yang library) which parts are ephemeral. Why the second requirement? If the data model is supported, and the data model states that certain items are ephemeral, what would it mean if the signaling did not also say that. Conversely, what would it mean if the signaling said something was ephemeral that the model does not define as ephemeral? It may be that I am misreading bullet 6. Please explain. Thank you, Joel From nobody Fri May 6 08:57:47 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F0712D0B2; Fri, 6 May 2016 08:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxeHKBWwnm4P; Fri, 6 May 2016 08:57:42 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32FE12D097; Fri, 6 May 2016 08:57:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9CEBD2409E3; Fri, 6 May 2016 08:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462550262; bh=Yl0xnnijh3Ewd4JTdOrm+ncFnGK8vQGPwv9rdAjG6zU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=QjWubDTe/5nFRzciXKdJ3nLbh7bh21jpHuH+SULm0JaQ/BomR99Q9SSt5QYkYyZwY sl8BjusfLdDZ7rqf/367uU2LC7c1v2m5oie2RtyIp3AaEY2M7JkjC3gOytWb0rp402 xfo3kCzlOjPDc4SSFsVuY7qwsshIRJgu3zKWN3JA= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1751E24B2DF; Fri, 6 May 2016 08:57:42 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> From: "Joel M. Halpern" Message-ID: <914099bb-bbec-5005-90bf-e3ebf2578135@joelhalpern.com> Date: Fri, 6 May 2016 11:57:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.3 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 15:57:44 -0000 Section 3.1.3 requirements 6 and 7 introduce the marking that the protocol used by YANG / NetConf is i2RS specific. From one important angle, this makes good sense. It avoids confusing the I2RS communication with other NetConf or RestConf usage. On the other hand, it seems to create a difficulty when YANG evolves beyond YANG 1.1. Do we have to explicitly decide each time if I2RS will support the new version, and assign a new i2rs version number? This seems unfortunate. Could there not be some other way to indicate that the protocol is YANG 1.1, but that the usage of the channel is I2RS? Thank you, Joel From nobody Fri May 6 09:08:57 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A0C12B04B; Fri, 6 May 2016 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZlp-F8HRa14; Fri, 6 May 2016 09:08:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A58D12B01B; Fri, 6 May 2016 09:08:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 542662409E3; Fri, 6 May 2016 09:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462550932; bh=WAWjRFL5rLws6bypDydIbECYyScTTV3v3AyrBIzdEn4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qaiPEC0xRMzDtGjvkKzbzcW74vLOCAdpipSpcja82/QQhvtvIRHUIVf3ueYM6dN+G 6IB9VrWiaOfVYk6kJRRiK6XBJ1VY8bLby0MHEJrIVqkEsawrcHLHJt7LmUCcZMkEfw 07sA6spgn13sifbQb+drLeuNqD/h1qZkcRsJhXRQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id CF7F4250D2A; Fri, 6 May 2016 09:08:51 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> From: "Joel M. Halpern" Message-ID: <4a316713-0cc9-55ae-79a2-1b0c2ce3ff06@joelhalpern.com> Date: Fri, 6 May 2016 12:08:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.4.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 16:08:53 -0000 The text at the end of this section talks about the I2RS agent re-evaluating a set of writes done by a client when the assigned priority of the client changes. Dealing with such changes makes sense. I am confused by the specific proposal. What is being reevaluated, and why are notifications being sent? Since the I2RS agent does not store operations from clients which are not active, there is no way that changing the priority can cause a previously ignored operation to be applied. Equally, if the priority is lowered, there is now way that any other I2RS cleint operation will suddenly take precedence. The only case I can construct is if the routing system is using priority to decide between local config and I2RS (which earlier changes seem to rule out). IN that case, a change could cause an I2RS client operation to be removed in favor of local config. Even that case would seem to cause only a single notification of that event, not a whole series of notifications. Yours, somewhat confused, Joel From nobody Fri May 6 12:38:17 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4708D12D0FB; Fri, 6 May 2016 12:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1jtAFWnHQCx; Fri, 6 May 2016 12:38:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 294C112B017; Fri, 6 May 2016 12:38:10 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u46Jc5AE035299 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 May 2016 14:38:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Susan Hares" Date: Fri, 06 May 2016 14:38:05 -0500 Message-ID: <9B92308C-F1ED-4131-89B3-403046348D42@nostrum.com> In-Reply-To: <00b201d1a75d$6c13a940$443afbc0$@ndzh.com> References: <20160504184856.8272.48818.idtracker@ietfa.amsl.com> <0c66a6eacb9a4fceb28e02c88a631ce8@XCH-RTP-013.cisco.com> <06fe01d1a6b7$008d6ef0$01a84cd0$@ndzh.com> <00b201d1a75d$6c13a940$443afbc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, Eric Voit , The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 19:38:12 -0000 Hi Susan, To be clear, I do not object to the wider context per se. My concern is that the security and privacy requirements are left as implicit, based on the more narrow i2rs/netconf context. I only mentioned the potential of restricting the contextas one possible way forward; I am certainly not wedded to it. My suggestion for a way forward would be to document the high level security and privacy requirements in this document. IIUC, the larger context includes potentially unknown contexts, so some of this may need to be conditional. For example, language like the following might be helpful (this is just an example--I don't mean to say that it is true or applicable): "Some uses of this mechanism may carry privacy-sensitive information, or generate privacy-sensitive metadata through the subscription mechanism. In contexts where this is true, the following requirements apply..." It might also be reasonable to say that, for the context of i2rs, these requirements are documented in [references] and are expected to be fulfilled by the [transport and or protocol] Eric's email also suggested that the actual transport of data from the Yang datastore may be out of scope for these requirements. I don't object to that, either, as long as it is clear and explicit, although it would be good to point to where it is _in_ scope. Thanks! Ben. On 6 May 2016, at 1:06, Susan Hares wrote: > Ben: > > This is the first of the "re-use" management protocols. The > requirements > are set-up so that we can suggest additions to the NETCONF and > RESTCONF for > this first of I2RS. > > The I2RS ephemeral work, pub/sub, traceability, and security are > target at > the I2RS protocol definition with the I2RS use case. However, since > these > are general additions to NETCONF/RESTCONF, this work can be used > elsewhere. > > I think the text you are highlighting has this larger context. Now, > one of > the really important things to chat with Alia and Benoit is how do we > handle > the wider use case. Do we mention the wider context? > > The WG thought mentioning it was important. > > Sue > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Thursday, May 05, 2016 5:31 PM > To: Susan Hares > Cc: Eric Voit; The IESG; i2rs@ietf.org; > draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ben Campbell's Discuss on > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > On 5 May 2016, at 5:15, Susan Hares wrote: > >> Eric, Ben and IESG members: >> >> >> >> The pub/sub requirements are part of a 5 part requirements. May I >> quote >> from the shepherd's report: >> >> --------------------- >> >> The requirements for the first version of I2RS are: >> >> 1) model driven ephemeral state - that is data models that do not >> survive >> >> a software or hardware reboot. >> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >> >> >> >> 2) a secure protocol - >> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req >> uireme >> nts/ >> >> >> >> 3) traceability - ability to record interactions between I2RS >> elements >> >> (Client, Agent, Routing system) >> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ >> >> >> >> 4) notification publication via subscription >> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ >> >> >> >> 5) Protocol to pass Data for Analytics >> >> The first version of these requirements does not include a >> >> separate analytical protocol requirements as the simple use cases may >> >> pass information via query/poll or the notifications. >> >> >> >> The I2RS protocol exists in an secure environment described by: >> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment- >> reqs/ >> >> >> >> ------------------------- >> >> >> >> Eric - Perhaps it would be good to point to: >> >> . draft-ietf-i2rs-protocol-security-requirements and >> >> . draft-ietf-i2rs-security-environment-reqs/ >> >> >> >> Ben - Can you tell me how the shepherd report could have been >> clearer? >> The >> I2rs protocol security requirements require: confidentiality, >> encryption, secure transport, protection against replay attack, >> protection against DDoS attack (if possible). > > I think my confusion lies in the fact that, while the shepherd's > writeup > styles this draft as part of the I2RS protocol requirements, the draft > itself claims to describe requirements for a generally useful pub-sub > interface to a yang datastore. It's not clear to me how and when the > I2RS > protocol security requirements apply to it. If the described interface > is > intended to be useful in contexts other than I2RS (and the draft > explicitly > sets that expectation in 2.2), it needs to talk more generally about > security and privacy. > > For example, it might make sense to say that certain security > requirements > apply in environments where the mechanism might carry privacy > sensitive > data, and then point to the i2rs requirements for when the mechanism > is used > in an I2RS context. > > A different approach might be to more tightly constrain this to i2rs > >> >> >> >> Ben - On opting in, once the receive accepts a transport connection >> from the I2RS server - how is this not an opt-in to receive data? >> What >> are you looking for? > > I guess that depends on the transport. The transport requirements say > the > mechanism has to work over multiple transports. The last paragraph in > 4.2.4 > says "In the case of connection-oriented transports..." which suggests > that > non-connection-oriented transports are possible. > > Even with a connection-oriented transport, this may depend on how > connection-management is handled, and whether the receiver might be > receiving things it _wants_ to receive on the same transport. > >> >> >> >> Sue Hares >> >> (shepherd) >> >> >> >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit >> (evoit) >> Sent: Wednesday, May 04, 2016 7:25 PM >> To: Ben Campbell; The IESG >> Cc: i2rs@ietf.org; draft-ietf-i2rs-pub-sub-requirements@ietf.org; >> i2rs-chairs@ietf.org; shares@ndzh.com >> Subject: Re: [i2rs] Ben Campbell's Discuss on >> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) >> >> >> >> Hi Ben, >> >> >> >> Thanks for the comment. In-line.... >> >> >> >>> From: Ben Campbell, May 04, 2016 2:49 PM >> >>> ---------------------------------------------------------------------- >> >>> DISCUSS: >> >>> ---------------------------------------------------------------------- >> >>> >> >>> I have a couple of points I would like to discuss. Hopefully they >>> can >> >>> be resolved >> >>> easily: >> >>> >> >>> Are there really no requirements for privacy or integrity >>> protection? >> >>> Is there an expectation that this mechanism would ever carry privacy >> >>> sensitive or otherwise sensitive information? >> >> >> >> [eric's comment: >> >> When the subscription is established dynamically via an existing >> transport >> session (which is expected to be the dominant case) we have the same >> expectations for Privacy and integrity as would be provided via a >> "GET" >> instead of a "PUSH" over the same transport. We could have >> replicated all >> these requirements, but that was seen as unnecessary and likely less >> secure >> than adopting existing mechanisms. >> >> >> >> When the Subscriber and Receiver are different, then the transport >> connection will have credentials passed as part of the establishment. >> These >> credentials will be used as a Security Grooming Filter just like the >> above >> case so that pushed objects will be excluded from an Update >> Notification as >> per the permissions of the Receiver. (I.e., this is identical >> behavior to >> the above.) As several people have had questions about this, the >> new v07 >> will make this explicit in the Security section. >> >> End of eric's comment] >> >> >> >> Sue: The transport provides for privacy, integrity protection. Most >> configuration in network boxes would need privacy. >> >> >> >>> - 4.2.5, 2nd to last paragraph: >> >>> I am surprised to find that, when the receiver is not the >>> subscriber, >> >>> that the receiver is expected to opt-out. It seems like some form of >> >>> opt-in or affirmative consent would be needed here. >> >> >> >> The question really was how heavy-weight should the mechanism be. >> Transports been considering are all encrypted. So there is already a >> level >> of trust between the peers. And a target can always pull down the >> connection if there are issues. >> >> >> >> In addition, multicast transports are viable for some future cases. >> We >> didn't want mechanisms which complicated this type of interaction, >> especially in a world where dumb IoT devices may be involved. >> >> >> >> Sue: If the receiver accepts a secure transport set-up from the >> server, can >> you provide the reason why this is not an "opt-in" once it receives >> the >> connection from the I2RS agent? >> >> >> >> >> >>> ---------------------------------------------------------------------- >> >>> COMMENT: >> >>> ---------------------------------------------------------------------- >> >>> >> >>> - General: I support Stephen's DISCUSS >> >>> >> >>> -2.2: What is the real scope of this work? Is it expected to >>> supplant >> >>> the mentioned mechanisms? >> >> >> >> No. It is just showing that many specialized Push mechanism exist. >> This >> is not intended to supplant existing mechanisms, although perhaps it >> can >> help avoid future dedicated solutions. >> >>> - 2.3: "We need a new pub-sub >> >>> technology" >> >>> The shepherd write up mentioned a goal to use existing technologies. >> >>> Is the point of this sentence to suggest that is not feasible? >> >> >> >> Existing technologies cannot meet all the requirements specified. >> There are >> technology drafts progressing in NETCONF which can. >> >> >> >>> - 4.1, 4th paragraph: >> >>> The MAY doesn't seem right--is this a statement of fact that the >> >>> subscriber may have to resubscribe, or a requirement of the form >>> that >> >>> the service MAY force the subscriber to resubscribe? (Be careful >>> with >> >>> MAYs in requirements language--they imply unexpected things. For >> >>> example, several requirements say a SUBSCRIBE MAY do something--do >> >>> those imply that the service MUST allow the subscriber to do it ?) >> >> >> >> Good point. Reworded in v07. >> >> >> >>> -- 4.2.2, third bullet: The previous section said dampening periods >> >>> MUST be supported. >> >> >> >> Yes, but dampening is never for periodic subscriptions. >> >>> - 4.2.1, third paragraph: This is a bit ambiguous. I think it means >>> to >> >>> change the what subtrees the subscription applies to, but could be >> >>> interpreted to change the subtrees themselves. >> >> >> >> Fixed >> >>> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but >> >>> gave the subscriber a way to reconstruct the order fulfill this >> requirement? >> >> >> >> Yes, the timestamp within an update. But this requirement targets a >> specific object in a specific subscription. So there should be no >> issues. >> >>> Nits: >> >>> - The shepherd write up suggests this is standards track. The draft >> >>> and tracker both say informational. Please update the shepherd writ >>> up. >> >> >> >> Fixed >> >>> -3, last paragraph: What's the difference between a "Push" and an >> "Update"? >> >> >> >> Reworded >> >>> -4.1: A forward reference to the subscription QoS section would be >> helpful. >> >> >> >> Moved the requirement in question to 4.2.6. >> >>> -- Last paragraph, last sentence: Sentence doesn't parse. >> >> >> >> Fixed >> >>> >> >>> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY >> >> >> >> Fixed >> >> Thanks again for the review! >> >> Eric >> >> _______________________________________________ >> >> i2rs mailing list >> >> i2rs@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri May 6 13:28:37 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD3D12D53E; Fri, 6 May 2016 13:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPNc4KBU1Yja; Fri, 6 May 2016 13:28:20 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DC612D52C; Fri, 6 May 2016 13:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5158; q=dns/txt; s=iport; t=1462566500; x=1463776100; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=B8LPn8qeSDUqK0aG70VEGyHtJD2RIXoSTCDrXkCq/O8=; b=MPMKnQbTYvhoXlynObqi7n57ogrC8Egwhol6OoJrfkvltxhGtoxliuj6 tnkqhZNRJjZXq5PZp1Gs/5t+itWqZ5GhUwOSymfJqOE3LSYUt5jKSVhNL 9dgWX0OrvCbuDuQfjag7PAaO8IAMwBVPhU6MGuAQdJjgk6PUdZI2hDlTj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPBQAp/ixX/5pdJa1egzhVK1K2fYQTJ?= =?us-ascii?q?IVsAoE4OxEBAQEBAQEBZSeEQQEBAQMBIw8BBS8SEAsYAgImAgJXBgEMCAEBiB8?= =?us-ascii?q?IDq0+kQoBAQEBAQEBAQEBAQEBAQEBAQEBARZ8gwiCHIF2CIJOhCuDFIJZAQSFb?= =?us-ascii?q?oINkCSIMIMwgjuBaoROgwYjhTWPNjYsggUbFoFRIDIBAQGGXwEfBIEaAQEB?= X-IronPort-AV: E=Sophos;i="5.24,587,1454976000"; d="scan'208";a="269863940" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 May 2016 20:28:10 +0000 Received: from [10.24.183.36] ([10.24.183.36]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u46KSABC010543; Fri, 6 May 2016 20:28:10 GMT To: Stephen Farrell , The IESG References: <20160504164332.8280.38602.idtracker@ietfa.amsl.com> <5c9b1a61-ade4-8f4c-f754-1b500d2b3b4b@cisco.com> <572A73A0.6080609@cs.tcd.ie> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <925b83b8-fa61-3153-911d-8111a690ac03@cisco.com> Date: Fri, 6 May 2016 16:28:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <572A73A0.6080609@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 20:28:32 -0000 On 5/4/16 18:11, Stephen Farrell wrote: > Hi Joe, > > Those are all fine changes. Couple of tweaks suggested below. Thank you for your suggestions, Stephen. Please find a new proposed set of text changes at http://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html . We believe they satisfy your discuss items. Joe > > On 04/05/16 22:59, Joe Clarke wrote: >> On 5/4/16 12:43, Stephen Farrell wrote: >> >> Thanks for your feedback, Stephen. >> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> Intro: I don't agree that all data retention aspects are >>> out of scope here. They are about as in-scope as log >>> rotation I'd say. I do think it'd be worthwhile noting that >>> if log content contains sensitive data (either security- or >>> privacy-sensitive) then retaining that data for extended >>> durations has a cost, in terms of creating risks if data >>> leaks. While one cannot say here how to evaluate such >>> risks, they do exist and should really be noted. It would >>> also be sensible IMO to say that implementations SHOULD >>> provide a way to purge ancient log content that is no >>> longer needed or useful, but that the definition of when >>> content is no longer needed or useful is out of scope. In >>> saying this I do recognise that much or perhaps even most >>> i2rs log content will not be security or privacy sensitive, >>> but in some cases it can be, e.g. if an operation involved >>> an address that is specific to a user or device carried by >>> a user. In addition, some data retention regimes could >>> impose a requirement to purge log content after a certain >>> duration. I'd say a note about this in the intro or in the >>> security considerations should be a fine way to handle this >>> issue, and to acknowledge that not all data retention >>> issues are out of scope for implementations. >> >> Would changing the Trace Log Temporary Storage section alone be >> sufficient? I have changed that section to read: >> >> "It is outside the scope of this document to specify the >> implementation details (i.e., size, throughput, data >> protection, etc.) for the physical storage of the >> I2RS log file. In terms of data retention, >> attention should be paid the length of time I2RS trace log >> data is kept when that data contains security or privacy-sensitive >> attributes. The longer this data is retained, the more risk is incurred >> if it were to be leaked." > > Two things:- > > - the last bit isn't quite right, it's more the impact is greater > if the leak happens (the risk of a leak is presumably proportional > more to how long the system is operated). > - you didn't mention that in some places there could be legislation > imposing a min and/or max on retention of some kinds of data. > > So I'd suggest instead: > > "It is outside the scope of this document to specify the > implementation details (i.e., size, throughput, data > protection, etc.) for the physical storage of the > I2RS log file. In terms of data retention, > attention should be paid the length of time I2RS trace log > data is kept when that data contains security or privacy-sensitive > attributes. The longer this data is retained, the higher the > impact it were to be leaked. It is also possible that > legislation may impose some requirements on the minimum and/or > maximum durations for which some kinds of data may be retained." > > If you think it's important to not say that last bit please > do make that argument. > > (I'll clear the discuss when you post a revision with the > above unless one of the other ADs who agreed with the > discuss chimes in to say otherwise.) > >> >> Would you prefer I make reference to this in the Security Considerations >> as well? > > Your call. So long as it's there somewhere I think we're sorted. > And the rest below is fine. > > Cheers, > S. > > >> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> - 5.2: Requested/Applied Operation Data - I would guess >>> this can include sensitive values, e.g. keys/passwords. >>> Shouldn’t you say to at least be careful of those, or >>> perhaps to not log them, or to zero out known sensitive >>> values before logging? >> >> There is text in the Security Considerations section that says: >> >> "Additionally, the potentially sensitive information contained in a log >> file SHOULD be adequately anonymized or obfuscated by operators to >> ensure its privacy." >> >> Are you suggesting we explicitly call out the Op Data fields here? >> >>> >>> - 7.2: how is privacy an implementation detail? >> >> I pulled out privacy. >>> >>> - 7.4: What does "being preferred" mean in 2119 terms? Why >>> is one of the three options not mandatory-to-implement? >> >> The current [un-published] version makes pub-sub MTI. >> >> Joe >> From nobody Fri May 6 13:31:41 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DFF12D52C; Fri, 6 May 2016 13:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCuU0DHPOWPr; Fri, 6 May 2016 13:31:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D4412D5A5; Fri, 6 May 2016 13:31:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4006EBE38; Fri, 6 May 2016 21:31:31 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyOYaFEK-bWX; Fri, 6 May 2016 21:31:29 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.26.141]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DF23ABE2F; Fri, 6 May 2016 21:31:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462566689; bh=4SD0mBJP6qrgZAYR0AUUmihEVnO4mN6tSC9A2fuN8pY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=zDsqnGI+CrSAumSyLFlxLjKFacEk+L240FsD9eK+o+GPbqY4Puc5H8DkKmdfq0lac muq9ZRQcn6/psLKNM3HgCzi8KR5Z66PhYmyxfXse8TSwCHm2Y/DHJ5dKCiQ1mzDfLt 3rwPRSZSDUwMS+pVtjAf2t4g1EdiZF2MRIK3NMD8= To: Joe Clarke , The IESG References: <20160504164332.8280.38602.idtracker@ietfa.amsl.com> <5c9b1a61-ade4-8f4c-f754-1b500d2b3b4b@cisco.com> <572A73A0.6080609@cs.tcd.ie> <925b83b8-fa61-3153-911d-8111a690ac03@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <572CFF20.10708@cs.tcd.ie> Date: Fri, 6 May 2016 21:31:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <925b83b8-fa61-3153-911d-8111a690ac03@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070601020205010902080700" Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 20:31:36 -0000 This is a cryptographically signed message in MIME format. --------------ms070601020205010902080700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/05/16 21:28, Joe Clarke wrote: > On 5/4/16 18:11, Stephen Farrell wrote: >> Hi Joe, >> >> Those are all fine changes. Couple of tweaks suggested below. >=20 > Thank you for your suggestions, Stephen. Please find a new proposed se= t > of text changes at > http://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.di= ff.html > . We believe they satisfy your discuss items. Yep, post that and I'll clear, Cheers, S. >=20 > Joe >=20 >> >> On 04/05/16 22:59, Joe Clarke wrote: >>> On 5/4/16 12:43, Stephen Farrell wrote: >>> >>> Thanks for your feedback, Stephen. >>> >>>> --------------------------------------------------------------------= -- >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> Intro: I don't agree that all data retention aspects are >>>> out of scope here. They are about as in-scope as log >>>> rotation I'd say. I do think it'd be worthwhile noting that >>>> if log content contains sensitive data (either security- or >>>> privacy-sensitive) then retaining that data for extended >>>> durations has a cost, in terms of creating risks if data >>>> leaks. While one cannot say here how to evaluate such >>>> risks, they do exist and should really be noted. It would >>>> also be sensible IMO to say that implementations SHOULD >>>> provide a way to purge ancient log content that is no >>>> longer needed or useful, but that the definition of when >>>> content is no longer needed or useful is out of scope. In >>>> saying this I do recognise that much or perhaps even most >>>> i2rs log content will not be security or privacy sensitive, >>>> but in some cases it can be, e.g. if an operation involved >>>> an address that is specific to a user or device carried by >>>> a user. In addition, some data retention regimes could >>>> impose a requirement to purge log content after a certain >>>> duration. I'd say a note about this in the intro or in the >>>> security considerations should be a fine way to handle this >>>> issue, and to acknowledge that not all data retention >>>> issues are out of scope for implementations. >>> >>> Would changing the Trace Log Temporary Storage section alone be >>> sufficient? I have changed that section to read: >>> >>> "It is outside the scope of this document to specify the >>> implementation details (i.e., size, throughput, data >>> protection, etc.) for the physical storage of the >>> I2RS log file. In terms of data retention, >>> attention should be paid the length of time I2RS trace log >>> data is kept when that data contains security or privacy-sensitive >>> attributes. The longer this data is retained, the more risk is incur= red >>> if it were to be leaked." >> >> Two things:- >> >> - the last bit isn't quite right, it's more the impact is greater >> if the leak happens (the risk of a leak is presumably proportional >> more to how long the system is operated). >> - you didn't mention that in some places there could be legislation >> imposing a min and/or max on retention of some kinds of data. >> >> So I'd suggest instead: >> >> "It is outside the scope of this document to specify the >> implementation details (i.e., size, throughput, data >> protection, etc.) for the physical storage of the >> I2RS log file. In terms of data retention, >> attention should be paid the length of time I2RS trace log >> data is kept when that data contains security or privacy-sensitive >> attributes. The longer this data is retained, the higher the >> impact it were to be leaked. It is also possible that >> legislation may impose some requirements on the minimum and/or >> maximum durations for which some kinds of data may be retained." >> >> If you think it's important to not say that last bit please >> do make that argument. >> >> (I'll clear the discuss when you post a revision with the >> above unless one of the other ADs who agreed with the >> discuss chimes in to say otherwise.) >> >>> >>> Would you prefer I make reference to this in the Security Considerati= ons >>> as well? >> >> Your call. So long as it's there somewhere I think we're sorted. >> And the rest below is fine. >> >> Cheers, >> S. >> >> >>> >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> COMMENT: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> - 5.2: Requested/Applied Operation Data - I would guess >>>> this can include sensitive values, e.g. keys/passwords. >>>> Shouldn=E2=80=99t you say to at least be careful of those, or >>>> perhaps to not log them, or to zero out known sensitive >>>> values before logging? >>> >>> There is text in the Security Considerations section that says: >>> >>> "Additionally, the potentially sensitive information contained in a l= og >>> file SHOULD be adequately anonymized or obfuscated by operators to >>> ensure its privacy." >>> >>> Are you suggesting we explicitly call out the Op Data fields here? >>> >>>> >>>> - 7.2: how is privacy an implementation detail? >>> >>> I pulled out privacy. >>>> >>>> - 7.4: What does "being preferred" mean in 2119 terms? Why >>>> is one of the three options not mandatory-to-implement? >>> >>> The current [un-published] version makes pub-sub MTI. >>> >>> Joe >>> >=20 --------------ms070601020205010902080700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDYy MDMxMjhaMC8GCSqGSIb3DQEJBDEiBCAonSnmDFsv7p9yL9pshqMTvYYHdSgLL7zFJT0t5u4Q ITBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAT5zOSJALkgVrNOh47esO1sSM8cei6YyDw9WVr4DA421/AHZc3JAjy m+ecYu5u77WDo+Yy3tiyKjolH96WlyM2lK4Gz6mbk3Qw2CXwxmGsOtngULb31F1K6D5J5o8B 8UcE8NrwTM1gIW6on3+fDFCIhOw1SjrHmLt/bAwDRs41RfrhuY/JE4aTOacWc6E0Vf9p2FY6 2TynQ3Um64d0a+2XRzs04tMEaukYzQUmO8Mhn2DOCbkpO9qQxktNEm5h0bNuRE/t1EYwxbUh yac+LUkJomsA8EVHrEFkkVW1MYGMrVEQJzJxk4VgFxXa/uSu3jeuFRhKFdM/XTCd9lQsGKCx AAAAAAAA --------------ms070601020205010902080700-- From nobody Fri May 6 16:09:28 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8F012D15D; Fri, 6 May 2016 16:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjp_tb6S9HEJ; Fri, 6 May 2016 16:09:23 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 CC14012D12F; Fri, 6 May 2016 16:09:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.123.121; Date: Fri, 06 May 2016 18:09:13 -0500 Message-ID: Importance: normal From: Susan Hares To: Ben Campbell MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1128317882336420" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, Eric Voit , The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 23:09:26 -0000 ----_com.samsung.android.email_1128317882336420 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QmVuOgpUaGlzIGlzIHdpc2UgaWRlYS4gwqBJIHdpbGwgc3VnZ2VzdCBzb21lIHRleHQgdG8gRXJp YyBhbmQgeW91IGluIHRoZSBtb3JuaW5nLgpTdWUKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxh eHkgTm90ZTUsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBtZXNz YWdlIC0tLS0tLS0tRnJvbTogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+IERhdGU6IDUv Ni8yMDE2ICAyOjM4IFBNICAoR01ULTA2OjAwKSBUbzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpo LmNvbT4gQ2M6IEVyaWMgVm9pdCA8ZXZvaXRAY2lzY28uY29tPiwgVGhlIElFU0cgPGllc2dAaWV0 Zi5vcmc+LCBpMnJzQGlldGYub3JnLCBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVu dHNAaWV0Zi5vcmcsIGkycnMtY2hhaXJzQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbaTJyc10gQmVu IENhbXBiZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVu dHMtMDY6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpIApIaSBTdXNhbiwKClRvIGJlIGNsZWFy LCBJIGRvIG5vdCBvYmplY3QgdG8gdGhlIHdpZGVyIGNvbnRleHQgcGVyIHNlLiBNeSBjb25jZXJu IGlzIAp0aGF0IHRoZSBzZWN1cml0eSBhbmQgcHJpdmFjeSByZXF1aXJlbWVudHMgYXJlIGxlZnQg YXMgaW1wbGljaXQsIGJhc2VkIApvbiB0aGUgbW9yZSBuYXJyb3cgaTJycy9uZXRjb25mIGNvbnRl eHQuIEkgb25seSBtZW50aW9uZWQgdGhlIHBvdGVudGlhbCAKb2YgcmVzdHJpY3RpbmcgdGhlIGNv bnRleHRhcyBvbmUgcG9zc2libGUgd2F5IGZvcndhcmQ7IEkgYW0gY2VydGFpbmx5IApub3Qgd2Vk ZGVkIHRvIGl0LgoKTXkgc3VnZ2VzdGlvbiBmb3IgYSB3YXkgZm9yd2FyZCB3b3VsZCBiZSB0byBk b2N1bWVudCB0aGUgaGlnaCBsZXZlbCAKc2VjdXJpdHkgYW5kIHByaXZhY3kgcmVxdWlyZW1lbnRz IGluIHRoaXMgZG9jdW1lbnQuIElJVUMsIHRoZSBsYXJnZXIgCmNvbnRleHQgaW5jbHVkZXMgcG90 ZW50aWFsbHkgdW5rbm93biBjb250ZXh0cywgc28gc29tZSBvZiB0aGlzIG1heSBuZWVkIAp0byBi ZSBjb25kaXRpb25hbC4gRm9yIGV4YW1wbGUsIGxhbmd1YWdlIGxpa2UgdGhlIGZvbGxvd2luZyBt aWdodCBiZSAKaGVscGZ1bCAodGhpcyBpcyBqdXN0IGFuIGV4YW1wbGUtLUkgZG9uJ3QgbWVhbiB0 byBzYXkgdGhhdCBpdCBpcyB0cnVlIG9yIAphcHBsaWNhYmxlKToKCsKgICJTb21lIHVzZXMgb2Yg dGhpcyBtZWNoYW5pc20gbWF5IGNhcnJ5IHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uLCAK b3IgZ2VuZXJhdGXCoMKgwqAgcHJpdmFjeS1zZW5zaXRpdmUgbWV0YWRhdGEgdGhyb3VnaCB0aGUg c3Vic2NyaXB0aW9uIAptZWNoYW5pc20uIEluIGNvbnRleHRzIHdoZXJlIHRoaXMgaXMgdHJ1ZSwg dGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHMgCmFwcGx5Li4uIgoKSXQgbWlnaHQgYWxzbyBiZSBy ZWFzb25hYmxlIHRvIHNheSB0aGF0LCBmb3IgdGhlIGNvbnRleHQgb2YgaTJycywgdGhlc2UgCnJl cXVpcmVtZW50cyBhcmUgZG9jdW1lbnRlZCBpbiBbcmVmZXJlbmNlc10gYW5kIGFyZSBleHBlY3Rl ZCB0byBiZSAKZnVsZmlsbGVkIGJ5IHRoZSBbdHJhbnNwb3J0IGFuZCBvciBwcm90b2NvbF0KCkVy aWMncyBlbWFpbCBhbHNvIHN1Z2dlc3RlZCB0aGF0IHRoZSBhY3R1YWwgdHJhbnNwb3J0IG9mIGRh dGEgZnJvbSB0aGUgCllhbmcgZGF0YXN0b3JlIG1heSBiZSBvdXQgb2Ygc2NvcGUgZm9yIHRoZXNl IHJlcXVpcmVtZW50cy4gSSBkb24ndCAKb2JqZWN0IHRvIHRoYXQsIGVpdGhlciwgYXMgbG9uZyBh cyBpdCBpcyBjbGVhciBhbmQgZXhwbGljaXQsIGFsdGhvdWdoIGl0IAp3b3VsZCBiZSBnb29kIHRv IHBvaW50IHRvIHdoZXJlIGl0IGlzIF9pbl8gc2NvcGUuCgpUaGFua3MhCgpCZW4uCgpPbiA2IE1h eSAyMDE2LCBhdCAxOjA2LCBTdXNhbiBIYXJlcyB3cm90ZToKCj4gQmVuOgo+Cj4gVGhpcyBpcyB0 aGUgZmlyc3Qgb2YgdGhlICJyZS11c2UiIG1hbmFnZW1lbnQgcHJvdG9jb2xzLsKgIFRoZSAKPiBy ZXF1aXJlbWVudHMKPiBhcmUgc2V0LXVwIHNvIHRoYXQgd2UgY2FuIHN1Z2dlc3QgYWRkaXRpb25z IHRvIHRoZSBORVRDT05GIGFuZCAKPiBSRVNUQ09ORiBmb3IKPiB0aGlzIGZpcnN0IG9mIEkyUlMu Cj4KPiBUaGUgSTJSUyBlcGhlbWVyYWwgd29yaywgcHViL3N1YiwgdHJhY2VhYmlsaXR5LCBhbmQg c2VjdXJpdHkgYXJlIAo+IHRhcmdldCBhdAo+IHRoZSBJMlJTIHByb3RvY29sIGRlZmluaXRpb24g d2l0aCB0aGUgSTJSUyB1c2UgY2FzZS7CoCBIb3dldmVyLCBzaW5jZSAKPiB0aGVzZQo+IGFyZSBn ZW5lcmFsIGFkZGl0aW9ucyB0byBORVRDT05GL1JFU1RDT05GLCB0aGlzIHdvcmsgY2FuIGJlIHVz ZWQgCj4gZWxzZXdoZXJlLgo+Cj4gSSB0aGluayB0aGUgdGV4dCB5b3UgYXJlIGhpZ2hsaWdodGlu ZyBoYXMgdGhpcyBsYXJnZXIgY29udGV4dC7CoMKgIE5vdywgCj4gb25lIG9mCj4gdGhlIHJlYWxs eSBpbXBvcnRhbnQgdGhpbmdzIHRvIGNoYXQgd2l0aCBBbGlhIGFuZCBCZW5vaXQgaXMgaG93IGRv IHdlIAo+IGhhbmRsZQo+IHRoZSB3aWRlciB1c2UgY2FzZS7CoMKgIERvIHdlIG1lbnRpb24gdGhl IHdpZGVyIGNvbnRleHQ/Cj4KPiBUaGUgV0cgdGhvdWdodCBtZW50aW9uaW5nIGl0IHdhcyBpbXBv cnRhbnQuCj4KPiBTdWUKPgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogQmVu IENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkg MDUsIDIwMTYgNTozMSBQTQo+IFRvOiBTdXNhbiBIYXJlcwo+IENjOiBFcmljIFZvaXQ7IFRoZSBJ RVNHOyBpMnJzQGlldGYub3JnOwo+IGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50 c0BpZXRmLm9yZzsgaTJycy1jaGFpcnNAaWV0Zi5vcmcKPiBTdWJqZWN0OiBSZTogW2kycnNdIEJl biBDYW1wYmVsbCdzIERpc2N1c3Mgb24KPiBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJl bWVudHMtMDY6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpCj4KPiBPbiA1IE1heSAyMDE2LCBh dCA1OjE1LCBTdXNhbiBIYXJlcyB3cm90ZToKPgo+PiBFcmljLCBCZW4gYW5kIElFU0cgbWVtYmVy czoKPj4KPj4KPj4KPj4gVGhlIHB1Yi9zdWIgcmVxdWlyZW1lbnRzIGFyZSBwYXJ0IG9mIGEgNSBw YXJ0IHJlcXVpcmVtZW50cy7CoMKgIE1heSBJCj4+IHF1b3RlCj4+IGZyb20gdGhlIHNoZXBoZXJk J3MgcmVwb3J0Ogo+Pgo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4KPj4gVGhlIHJlcXVpcmVt ZW50cyBmb3IgdGhlIGZpcnN0IHZlcnNpb24gb2YgSTJSUyBhcmU6Cj4+Cj4+IDEpIG1vZGVsIGRy aXZlbiBlcGhlbWVyYWwgc3RhdGUgLSB0aGF0IGlzIGRhdGEgbW9kZWxzIHRoYXQgZG8gbm90Cj4+ IHN1cnZpdmUKPj4KPj7CoMKgwqDCoCBhIHNvZnR3YXJlIG9yIGhhcmR3YXJlIHJlYm9vdC4KPj4K Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLWVwaGVt ZXJhbC1zdGF0ZS8KPj4KPj4KPj4KPj4gMikgYSBzZWN1cmUgcHJvdG9jb2wgLQo+Pgo+PiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2Vj dXJpdHktcmVxCj4+IHVpcmVtZQo+PiBudHMvCj4+Cj4+Cj4+Cj4+IDMpIHRyYWNlYWJpbGl0eSAt IGFiaWxpdHkgdG8gcmVjb3JkIGludGVyYWN0aW9ucyBiZXR3ZWVuIEkyUlMgCj4+IGVsZW1lbnRz Cj4+Cj4+IChDbGllbnQsIEFnZW50LCBSb3V0aW5nIHN5c3RlbSkKPj4KPj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXRyYWNlYWJpbGl0eS8KPj4KPj4K Pj4KPj4gNCkgbm90aWZpY2F0aW9uIHB1YmxpY2F0aW9uIHZpYSBzdWJzY3JpcHRpb24KPj4KPj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWIt cmVxdWlyZW1lbnRzLwo+Pgo+Pgo+Pgo+PiA1KSBQcm90b2NvbCB0byBwYXNzIERhdGEgZm9yIEFu YWx5dGljcwo+Pgo+PiBUaGUgZmlyc3QgdmVyc2lvbiBvZiB0aGVzZSByZXF1aXJlbWVudHMgZG9l cyBub3QgaW5jbHVkZSBhCj4+Cj4+IHNlcGFyYXRlIGFuYWx5dGljYWwgcHJvdG9jb2wgcmVxdWly ZW1lbnRzIGFzIHRoZSBzaW1wbGUgdXNlIGNhc2VzIG1heQo+Pgo+PiBwYXNzIGluZm9ybWF0aW9u IHZpYSBxdWVyeS9wb2xsIG9yIHRoZSBub3RpZmljYXRpb25zLgo+Pgo+Pgo+Pgo+PiBUaGUgSTJS UyBwcm90b2NvbCBleGlzdHMgaW4gYW4gc2VjdXJlIGVudmlyb25tZW50IGRlc2NyaWJlZCBieToK Pj4KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXNl Y3VyaXR5LWVudmlyb25tZW50LQo+PiByZXFzLwo+Pgo+Pgo+Pgo+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCj4+Cj4+Cj4+Cj4+IEVyaWMgLSBQZXJoYXBzIGl0IHdvdWxkIGJlIGdvb2QgdG8g cG9pbnQgdG86Cj4+Cj4+IC7CoMKgwqDCoMKgwqDCoMKgIGRyYWZ0LWlldGYtaTJycy1wcm90b2Nv bC1zZWN1cml0eS1yZXF1aXJlbWVudHMgYW5kCj4+Cj4+IC7CoMKgwqDCoMKgwqDCoMKgIGRyYWZ0 LWlldGYtaTJycy1zZWN1cml0eS1lbnZpcm9ubWVudC1yZXFzLwo+Pgo+Pgo+Pgo+PiBCZW4gLSBD YW4geW91IHRlbGwgbWUgaG93IHRoZSBzaGVwaGVyZCByZXBvcnQgY291bGQgaGF2ZSBiZWVuIAo+ PiBjbGVhcmVyPwo+PsKgIFRoZQo+PiBJMnJzIHByb3RvY29sIHNlY3VyaXR5IHJlcXVpcmVtZW50 cyByZXF1aXJlOsKgIGNvbmZpZGVudGlhbGl0eSwKPj4gZW5jcnlwdGlvbiwgc2VjdXJlIHRyYW5z cG9ydCwgcHJvdGVjdGlvbiBhZ2FpbnN0IHJlcGxheSBhdHRhY2ssCj4+IHByb3RlY3Rpb24gYWdh aW5zdCBERG9TIGF0dGFjayAoaWYgcG9zc2libGUpLgo+Cj4gSSB0aGluayBteSBjb25mdXNpb24g bGllcyBpbiB0aGUgZmFjdCB0aGF0LCB3aGlsZSB0aGUgc2hlcGhlcmQncyAKPiB3cml0ZXVwCj4g c3R5bGVzIHRoaXMgZHJhZnQgYXMgcGFydCBvZiB0aGUgSTJSUyBwcm90b2NvbCByZXF1aXJlbWVu dHMsIHRoZSBkcmFmdAo+IGl0c2VsZiBjbGFpbXMgdG8gZGVzY3JpYmUgcmVxdWlyZW1lbnRzIGZv ciBhIGdlbmVyYWxseSB1c2VmdWwgcHViLXN1Ygo+IGludGVyZmFjZSB0byBhIHlhbmcgZGF0YXN0 b3JlLiBJdCdzIG5vdCBjbGVhciB0byBtZSBob3cgYW5kIHdoZW4gdGhlIAo+IEkyUlMKPiBwcm90 b2NvbCBzZWN1cml0eSByZXF1aXJlbWVudHMgYXBwbHkgdG8gaXQuIElmIHRoZSBkZXNjcmliZWQg aW50ZXJmYWNlIAo+IGlzCj4gaW50ZW5kZWQgdG8gYmUgdXNlZnVsIGluIGNvbnRleHRzIG90aGVy IHRoYW4gSTJSUyAoYW5kIHRoZSBkcmFmdCAKPiBleHBsaWNpdGx5Cj4gc2V0cyB0aGF0IGV4cGVj dGF0aW9uIGluIDIuMiksIGl0IG5lZWRzIHRvIHRhbGsgbW9yZSBnZW5lcmFsbHkgYWJvdXQKPiBz ZWN1cml0eSBhbmQgcHJpdmFjeS4KPgo+IEZvciBleGFtcGxlLCBpdCBtaWdodCBtYWtlIHNlbnNl IHRvIHNheSB0aGF0IGNlcnRhaW4gc2VjdXJpdHkgCj4gcmVxdWlyZW1lbnRzCj4gYXBwbHkgaW4g ZW52aXJvbm1lbnRzIHdoZXJlIHRoZSBtZWNoYW5pc20gbWlnaHQgY2FycnkgcHJpdmFjeSAKPiBz ZW5zaXRpdmUKPiBkYXRhLCBhbmQgdGhlbiBwb2ludCB0byB0aGUgaTJycyByZXF1aXJlbWVudHMg Zm9yIHdoZW4gdGhlIG1lY2hhbmlzbSAKPiBpcyB1c2VkCj4gaW4gYW4gSTJSUyBjb250ZXh0Lgo+ Cj4gQSBkaWZmZXJlbnQgYXBwcm9hY2ggbWlnaHQgYmUgdG8gbW9yZSB0aWdodGx5IGNvbnN0cmFp biB0aGlzIHRvIGkycnMKPgo+Pgo+Pgo+Pgo+PiBCZW4gLSBPbiBvcHRpbmcgaW4sIG9uY2UgdGhl IHJlY2VpdmUgYWNjZXB0cyBhIHRyYW5zcG9ydCBjb25uZWN0aW9uCj4+IGZyb20gdGhlIEkyUlMg c2VydmVyIC0gaG93IGlzIHRoaXMgbm90IGFuIG9wdC1pbiB0byByZWNlaXZlIGRhdGE/IAo+PiBX aGF0Cj4+IGFyZSB5b3UgbG9va2luZyBmb3I/Cj4KPiBJIGd1ZXNzIHRoYXQgZGVwZW5kcyBvbiB0 aGUgdHJhbnNwb3J0LiBUaGUgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBzYXkgCj4gdGhlCj4gbWVj aGFuaXNtIGhhcyB0byB3b3JrIG92ZXIgbXVsdGlwbGUgdHJhbnNwb3J0cy4gVGhlIGxhc3QgcGFy YWdyYXBoIGluIAo+IDQuMi40Cj4gc2F5cyAiSW4gdGhlIGNhc2Ugb2YgY29ubmVjdGlvbi1vcmll bnRlZCB0cmFuc3BvcnRzLi4uIiB3aGljaCBzdWdnZXN0cyAKPiB0aGF0Cj4gbm9uLWNvbm5lY3Rp b24tb3JpZW50ZWQgdHJhbnNwb3J0cyBhcmUgcG9zc2libGUuCj4KPiBFdmVuIHdpdGggYSBjb25u ZWN0aW9uLW9yaWVudGVkIHRyYW5zcG9ydCwgdGhpcyBtYXkgZGVwZW5kIG9uIGhvdwo+IGNvbm5l Y3Rpb24tbWFuYWdlbWVudCBpcyBoYW5kbGVkLCBhbmQgd2hldGhlciB0aGUgcmVjZWl2ZXIgbWln aHQgYmUKPiByZWNlaXZpbmcgdGhpbmdzIGl0IF93YW50c18gdG8gcmVjZWl2ZSBvbiB0aGUgc2Ft ZSB0cmFuc3BvcnQuCj4KPj4KPj4KPj4KPj4gU3VlIEhhcmVzCj4+Cj4+IChzaGVwaGVyZCkKPj4K Pj4KPj4KPj4KPj4KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPj4gRnJvbTogaTJycyBb bWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgVm9pdAo+PiAo ZXZvaXQpCj4+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDc6MjUgUE0KPj4gVG86IEJl biBDYW1wYmVsbDsgVGhlIElFU0cKPj4gQ2M6IGkycnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaTJy cy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZzsKPj4gaTJycy1jaGFpcnNAaWV0Zi5vcmc7 IHNoYXJlc0BuZHpoLmNvbQo+PiBTdWJqZWN0OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERp c2N1c3Mgb24KPj4gZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2OiAod2l0 aCBESVNDVVNTIGFuZCBDT01NRU5UKQo+Pgo+Pgo+Pgo+PiBIaSBCZW4sCj4+Cj4+Cj4+Cj4+IFRo YW5rcyBmb3IgdGhlIGNvbW1lbnQuwqDCoCBJbi1saW5lLi4uLgo+Pgo+Pgo+Pgo+Pj4gRnJvbTog QmVuIENhbXBiZWxsLCBNYXkgMDQsIDIwMTYgMjo0OSBQTQo+Pgo+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ Pgo+Pj4gRElTQ1VTUzoKPj4KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4KPj4+Cj4+Cj4+PiBJIGhhdmUg YSBjb3VwbGUgb2YgcG9pbnRzIEkgd291bGQgbGlrZSB0byBkaXNjdXNzLiBIb3BlZnVsbHkgdGhl eSAKPj4+IGNhbgo+Pgo+Pj4gYmUgcmVzb2x2ZWQKPj4KPj4+IGVhc2lseToKPj4KPj4+Cj4+Cj4+ PiBBcmUgdGhlcmUgcmVhbGx5IG5vIHJlcXVpcmVtZW50cyBmb3IgcHJpdmFjeSBvciBpbnRlZ3Jp dHkgCj4+PiBwcm90ZWN0aW9uPwo+Pgo+Pj4gSXMgdGhlcmUgYW4gZXhwZWN0YXRpb24gdGhhdCB0 aGlzIG1lY2hhbmlzbSB3b3VsZCBldmVyIGNhcnJ5IHByaXZhY3kKPj4KPj4+IHNlbnNpdGl2ZSBv ciBvdGhlcndpc2Ugc2Vuc2l0aXZlIGluZm9ybWF0aW9uPwo+Pgo+Pgo+Pgo+PiBbZXJpYydzIGNv bW1lbnQ6Cj4+Cj4+IFdoZW4gdGhlIHN1YnNjcmlwdGlvbiBpcyBlc3RhYmxpc2hlZCBkeW5hbWlj YWxseSB2aWEgYW4gZXhpc3RpbmcKPj4gdHJhbnNwb3J0Cj4+IHNlc3Npb24gKHdoaWNoIGlzIGV4 cGVjdGVkIHRvIGJlIHRoZSBkb21pbmFudCBjYXNlKSB3ZSBoYXZlIHRoZSBzYW1lCj4+IGV4cGVj dGF0aW9ucyBmb3IgUHJpdmFjeSBhbmQgaW50ZWdyaXR5IGFzIHdvdWxkIGJlIHByb3ZpZGVkIHZp YSBhCj4+ICJHRVQiCj4+IGluc3RlYWQgb2YgYSAiUFVTSCIgb3ZlciB0aGUgc2FtZSB0cmFuc3Bv cnQuwqDCoCBXZSBjb3VsZCBoYXZlCj4+IHJlcGxpY2F0ZWQgYWxsCj4+IHRoZXNlIHJlcXVpcmVt ZW50cywgYnV0IHRoYXQgd2FzIHNlZW4gYXMgdW5uZWNlc3NhcnkgYW5kIGxpa2VseSBsZXNzCj4+ IHNlY3VyZQo+PiB0aGFuIGFkb3B0aW5nIGV4aXN0aW5nIG1lY2hhbmlzbXMuCj4+Cj4+Cj4+Cj4+ IFdoZW4gdGhlIFN1YnNjcmliZXIgYW5kIFJlY2VpdmVyIGFyZSBkaWZmZXJlbnQsIHRoZW4gdGhl IHRyYW5zcG9ydAo+PiBjb25uZWN0aW9uIHdpbGwgaGF2ZSBjcmVkZW50aWFscyBwYXNzZWQgYXMg cGFydCBvZiB0aGUgZXN0YWJsaXNobWVudC4KPj4gVGhlc2UKPj4gY3JlZGVudGlhbHMgd2lsbCBi ZSB1c2VkIGFzIGEgU2VjdXJpdHkgR3Jvb21pbmcgRmlsdGVyIGp1c3QgbGlrZSB0aGUKPj4gYWJv dmUKPj4gY2FzZSBzbyB0aGF0IHB1c2hlZCBvYmplY3RzIHdpbGwgYmUgZXhjbHVkZWQgZnJvbSBh biBVcGRhdGUKPj4gTm90aWZpY2F0aW9uIGFzCj4+IHBlciB0aGUgcGVybWlzc2lvbnMgb2YgdGhl IFJlY2VpdmVyLsKgwqAgKEkuZS4sIHRoaXMgaXMgaWRlbnRpY2FsCj4+IGJlaGF2aW9yIHRvCj4+ IHRoZSBhYm92ZS4pwqDCoMKgIEFzIHNldmVyYWwgcGVvcGxlIGhhdmUgaGFkIHF1ZXN0aW9ucyBh Ym91dCB0aGlzLCB0aGUKPj4gbmV3IHYwNwo+PiB3aWxsIG1ha2UgdGhpcyBleHBsaWNpdCBpbiB0 aGUgU2VjdXJpdHkgc2VjdGlvbi4KPj4KPj4gRW5kIG9mIGVyaWMncyBjb21tZW50XQo+Pgo+Pgo+ Pgo+PiBTdWU6IFRoZSB0cmFuc3BvcnQgcHJvdmlkZXMgZm9yIHByaXZhY3ksIGludGVncml0eSBw cm90ZWN0aW9uLsKgwqAgTW9zdAo+PiBjb25maWd1cmF0aW9uIGluIG5ldHdvcmsgYm94ZXMgd291 bGQgbmVlZCBwcml2YWN5Lgo+Pgo+Pgo+Pgo+Pj4gLSA0LjIuNSwgMm5kIHRvIGxhc3QgcGFyYWdy YXBoOgo+Pgo+Pj4gSSBhbSBzdXJwcmlzZWQgdG8gZmluZCB0aGF0LCB3aGVuIHRoZSByZWNlaXZl ciBpcyBub3QgdGhlIAo+Pj4gc3Vic2NyaWJlciwKPj4KPj4+IHRoYXQgdGhlIHJlY2VpdmVyIGlz IGV4cGVjdGVkIHRvIG9wdC1vdXQuIEl0IHNlZW1zIGxpa2Ugc29tZSBmb3JtIG9mCj4+Cj4+PiBv cHQtaW4gb3IgYWZmaXJtYXRpdmUgY29uc2VudCB3b3VsZCBiZSBuZWVkZWQgaGVyZS4KPj4KPj4K Pj4KPj4gVGhlIHF1ZXN0aW9uIHJlYWxseSB3YXMgaG93IGhlYXZ5LXdlaWdodCBzaG91bGQgdGhl IG1lY2hhbmlzbSBiZS4KPj4gVHJhbnNwb3J0cyBiZWVuIGNvbnNpZGVyaW5nIGFyZSBhbGwgZW5j cnlwdGVkLsKgIFNvIHRoZXJlIGlzIGFscmVhZHkgYQo+PiBsZXZlbAo+PiBvZiB0cnVzdCBiZXR3 ZWVuIHRoZSBwZWVycy7CoCBBbmQgYSB0YXJnZXQgY2FuIGFsd2F5cyBwdWxsIGRvd24gdGhlCj4+ IGNvbm5lY3Rpb24gaWYgdGhlcmUgYXJlIGlzc3Vlcy4KPj4KPj4KPj4KPj4gSW4gYWRkaXRpb24s IG11bHRpY2FzdCB0cmFuc3BvcnRzIGFyZSB2aWFibGUgZm9yIHNvbWUgZnV0dXJlIGNhc2VzLgo+ PiBXZQo+PiBkaWRuJ3Qgd2FudCBtZWNoYW5pc21zIHdoaWNoIGNvbXBsaWNhdGVkIHRoaXMgdHlw ZSBvZiBpbnRlcmFjdGlvbiwKPj4gZXNwZWNpYWxseSBpbiBhIHdvcmxkIHdoZXJlIGR1bWIgSW9U IGRldmljZXMgbWF5IGJlIGludm9sdmVkLgo+Pgo+Pgo+Pgo+PiBTdWU6IElmIHRoZSByZWNlaXZl ciBhY2NlcHRzIGEgc2VjdXJlIHRyYW5zcG9ydCBzZXQtdXAgZnJvbSB0aGUKPj4gc2VydmVyLCBj YW4KPj4geW91IHByb3ZpZGUgdGhlIHJlYXNvbiB3aHkgdGhpcyBpcyBub3QgYW4gIm9wdC1pbiIg b25jZSBpdCByZWNlaXZlcwo+PiB0aGUKPj4gY29ubmVjdGlvbiBmcm9tIHRoZSBJMlJTIGFnZW50 Pwo+Pgo+Pgo+Pgo+Pgo+Pgo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pgo+Pj4gQ09NTUVOVDoKPj4KPj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KPj4KPj4+Cj4+Cj4+PiAtIEdlbmVyYWw6IEkgc3VwcG9ydCBTdGVwaGVu J3MgRElTQ1VTUwo+Pgo+Pj4KPj4KPj4+IC0yLjI6IFdoYXQgaXMgdGhlIHJlYWwgc2NvcGUgb2Yg dGhpcyB3b3JrPyBJcyBpdCBleHBlY3RlZCB0byAKPj4+IHN1cHBsYW50Cj4+Cj4+PiB0aGUgbWVu dGlvbmVkIG1lY2hhbmlzbXM/Cj4+Cj4+Cj4+Cj4+IE5vLsKgwqAgSXQgaXMganVzdCBzaG93aW5n IHRoYXQgbWFueSBzcGVjaWFsaXplZCBQdXNoIG1lY2hhbmlzbSBleGlzdC4KPj4gVGhpcwo+PiBp cyBub3QgaW50ZW5kZWQgdG8gc3VwcGxhbnQgZXhpc3RpbmcgbWVjaGFuaXNtcywgYWx0aG91Z2gg cGVyaGFwcyBpdAo+PiBjYW4KPj4gaGVscCBhdm9pZCBmdXR1cmUgZGVkaWNhdGVkIHNvbHV0aW9u cy4KPj4KPj4+IC0gMi4zOiAiV2UgbmVlZCBhIG5ldyBwdWItc3ViCj4+Cj4+PsKgwqDCoCB0ZWNo bm9sb2d5Igo+Pgo+Pj4gVGhlIHNoZXBoZXJkIHdyaXRlIHVwIG1lbnRpb25lZCBhIGdvYWwgdG8g dXNlIGV4aXN0aW5nIHRlY2hub2xvZ2llcy4KPj4KPj4+IElzIHRoZSBwb2ludCBvZiB0aGlzIHNl bnRlbmNlIHRvIHN1Z2dlc3QgdGhhdCBpcyBub3QgZmVhc2libGU/Cj4+Cj4+Cj4+Cj4+IEV4aXN0 aW5nIHRlY2hub2xvZ2llcyBjYW5ub3QgbWVldCBhbGwgdGhlIHJlcXVpcmVtZW50cyBzcGVjaWZp ZWQuCj4+IFRoZXJlIGFyZQo+PiB0ZWNobm9sb2d5IGRyYWZ0cyBwcm9ncmVzc2luZyBpbiBORVRD T05GIHdoaWNoIGNhbi4KPj4KPj4KPj4KPj4+IC0gNC4xLCA0dGggcGFyYWdyYXBoOgo+Pgo+Pj4g VGhlIE1BWSBkb2Vzbid0IHNlZW0gcmlnaHQtLWlzIHRoaXMgYSBzdGF0ZW1lbnQgb2YgZmFjdCB0 aGF0IHRoZQo+Pgo+Pj4gc3Vic2NyaWJlciBtYXkgaGF2ZSB0byByZXN1YnNjcmliZSwgb3IgYSBy ZXF1aXJlbWVudCBvZiB0aGUgZm9ybSAKPj4+IHRoYXQKPj4KPj4+IHRoZSBzZXJ2aWNlIE1BWSBm b3JjZSB0aGUgc3Vic2NyaWJlciB0byByZXN1YnNjcmliZT8gKEJlIGNhcmVmdWwgCj4+PiB3aXRo Cj4+Cj4+PiBNQVlzIGluIHJlcXVpcmVtZW50cyBsYW5ndWFnZS0tdGhleSBpbXBseSB1bmV4cGVj dGVkIHRoaW5ncy4gRm9yCj4+Cj4+PiBleGFtcGxlLCBzZXZlcmFsIHJlcXVpcmVtZW50cyBzYXkg YSBTVUJTQ1JJQkUgTUFZIGRvIHNvbWV0aGluZy0tZG8KPj4KPj4+IHRob3NlIGltcGx5IHRoYXQg dGhlIHNlcnZpY2UgTVVTVCBhbGxvdyB0aGUgc3Vic2NyaWJlciB0byBkbyBpdCA/KQo+Pgo+Pgo+ Pgo+PiBHb29kIHBvaW50LsKgwqAgUmV3b3JkZWQgaW4gdjA3Lgo+Pgo+Pgo+Pgo+Pj4gLS0gNC4y LjIsIHRoaXJkIGJ1bGxldDogVGhlIHByZXZpb3VzIHNlY3Rpb24gc2FpZCBkYW1wZW5pbmcgcGVy aW9kcwo+Pgo+Pj4gTVVTVCBiZSBzdXBwb3J0ZWQuCj4+Cj4+Cj4+Cj4+IFllcywgYnV0IGRhbXBl bmluZyBpcyBuZXZlciBmb3IgcGVyaW9kaWMgc3Vic2NyaXB0aW9ucy4KPj4KPj4+IC0gNC4yLjEs IHRoaXJkIHBhcmFncmFwaDogVGhpcyBpcyBhIGJpdCBhbWJpZ3VvdXMuIEkgdGhpbmsgaXQgbWVh bnMKPj4+IHRvCj4+Cj4+PiBjaGFuZ2UgdGhlIHdoYXQgc3VidHJlZXMgdGhlIHN1YnNjcmlwdGlv biBhcHBsaWVzIHRvLCBidXQgY291bGQgYmUKPj4KPj4+IGludGVycHJldGVkIHRvIGNoYW5nZSB0 aGUgc3VidHJlZXMgdGhlbXNlbHZlcy4KPj4KPj4KPj4KPj4gRml4ZWQKPj4KPj4+IC0gNC4yLjYu NDogV291bGQgYSBtZWNoYW5pc20gdGhhdCBhbGxvd2VkIG91dC1vZi1vcmRlciBkZWxpdmVyeSBi dXQKPj4KPj4+IGdhdmUgdGhlIHN1YnNjcmliZXIgYSB3YXkgdG8gcmVjb25zdHJ1Y3QgdGhlIG9y ZGVyIGZ1bGZpbGwgdGhpcwo+PiByZXF1aXJlbWVudD8KPj4KPj4KPj4KPj4gWWVzLCB0aGUgdGlt ZXN0YW1wIHdpdGhpbiBhbiB1cGRhdGUuwqAgQnV0IHRoaXMgcmVxdWlyZW1lbnQgdGFyZ2V0cyBh Cj4+IHNwZWNpZmljIG9iamVjdCBpbiBhIHNwZWNpZmljIHN1YnNjcmlwdGlvbi7CoCBTbyB0aGVy ZSBzaG91bGQgYmUgbm8KPj4gaXNzdWVzLgo+Pgo+Pj4gTml0czoKPj4KPj4+IC0gVGhlIHNoZXBo ZXJkIHdyaXRlIHVwIHN1Z2dlc3RzIHRoaXMgaXMgc3RhbmRhcmRzIHRyYWNrLiBUaGUgZHJhZnQK Pj4KPj4+IGFuZCB0cmFja2VyIGJvdGggc2F5IGluZm9ybWF0aW9uYWwuIFBsZWFzZSB1cGRhdGUg dGhlIHNoZXBoZXJkIHdyaXQKPj4+IHVwLgo+Pgo+Pgo+Pgo+PiBGaXhlZAo+Pgo+Pj4gLTMsIGxh c3QgcGFyYWdyYXBoOiBXaGF0J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhICJQdXNoIiBhbmQg YW4KPj4gIlVwZGF0ZSI/Cj4+Cj4+Cj4+Cj4+IFJld29yZGVkCj4+Cj4+PiAtNC4xOiBBIGZvcndh cmQgcmVmZXJlbmNlIHRvIHRoZSBzdWJzY3JpcHRpb24gUW9TIHNlY3Rpb24gd291bGQgYmUKPj4g aGVscGZ1bC4KPj4KPj4KPj4KPj4gTW92ZWQgdGhlIHJlcXVpcmVtZW50IGluIHF1ZXN0aW9uIHRv IDQuMi42Lgo+Pgo+Pj4gLS0gTGFzdCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2U6IFNlbnRlbmNl IGRvZXNuJ3QgcGFyc2UuCj4+Cj4+Cj4+Cj4+IEZpeGVkCj4+Cj4+Pgo+Pgo+Pj4gLSA0LjIuOCwg dGhpcmQgcGFyYWdyYXBoOiBJIGRvbid0IHRoaW5rIHRoYXQgc2hvdWxkIGJlIGEgMjExOSBNQVkK Pj4KPj4KPj4KPj4gRml4ZWQKPj4KPj4gVGhhbmtzIGFnYWluIGZvciB0aGUgcmV2aWV3IQo+Pgo+ PiBFcmljCj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCj4+Cj4+IGkycnMgbWFpbGluZyBsaXN0Cj4+Cj4+wqAgPG1haWx0bzppMnJzQGlldGYub3Jn PiBpMnJzQGlldGYub3JnCj4+Cj4+wqAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaTJycz4KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJz Cg== ----_com.samsung.android.email_1128317882336420 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkJlbjo8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PlRoaXMgaXMgd2lzZSBpZGVhLiAmbmJzcDtJIHdpbGwgc3VnZ2VzdCBzb21l IHRleHQgdG8gRXJpYyBhbmQgeW91IGluIHRoZSBtb3JuaW5nLjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+U3VlPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUl O2NvbG9yOiM1NzU3NTciPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQm YW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6 MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0t IE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IEJlbiBDYW1wYmVsbCAm bHQ7YmVuQG5vc3RydW0uY29tJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDUvNi8yMDE2ICAyOjM4IFBN ICAoR01ULTA2OjAwKSA8L2Rpdj48ZGl2PlRvOiBTdXNhbiBIYXJlcyAmbHQ7c2hhcmVzQG5kemgu Y29tJmd0OyA8L2Rpdj48ZGl2PkNjOiBFcmljIFZvaXQgJmx0O2V2b2l0QGNpc2NvLmNvbSZndDss IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OywgaTJyc0BpZXRmLm9yZywgZHJhZnQtaWV0 Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnLCBpMnJzLWNoYWlyc0BpZXRmLm9y ZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbaTJyc10gQmVuIENhbXBiZWxsJ3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDY6ICh3aXRoIERJU0NVU1Mg YW5kIENPTU1FTlQpIDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PkhpIFN1c2FuLDxicj48YnI+ VG8gYmUgY2xlYXIsIEkgZG8gbm90IG9iamVjdCB0byB0aGUgd2lkZXIgY29udGV4dCBwZXIgc2Uu IE15IGNvbmNlcm4gaXMgPGJyPnRoYXQgdGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IHJlcXVpcmVt ZW50cyBhcmUgbGVmdCBhcyBpbXBsaWNpdCwgYmFzZWQgPGJyPm9uIHRoZSBtb3JlIG5hcnJvdyBp MnJzL25ldGNvbmYgY29udGV4dC4gSSBvbmx5IG1lbnRpb25lZCB0aGUgcG90ZW50aWFsIDxicj5v ZiByZXN0cmljdGluZyB0aGUgY29udGV4dGFzIG9uZSBwb3NzaWJsZSB3YXkgZm9yd2FyZDsgSSBh bSBjZXJ0YWlubHkgPGJyPm5vdCB3ZWRkZWQgdG8gaXQuPGJyPjxicj5NeSBzdWdnZXN0aW9uIGZv ciBhIHdheSBmb3J3YXJkIHdvdWxkIGJlIHRvIGRvY3VtZW50IHRoZSBoaWdoIGxldmVsIDxicj5z ZWN1cml0eSBhbmQgcHJpdmFjeSByZXF1aXJlbWVudHMgaW4gdGhpcyBkb2N1bWVudC4gSUlVQywg dGhlIGxhcmdlciA8YnI+Y29udGV4dCBpbmNsdWRlcyBwb3RlbnRpYWxseSB1bmtub3duIGNvbnRl eHRzLCBzbyBzb21lIG9mIHRoaXMgbWF5IG5lZWQgPGJyPnRvIGJlIGNvbmRpdGlvbmFsLiBGb3Ig ZXhhbXBsZSwgbGFuZ3VhZ2UgbGlrZSB0aGUgZm9sbG93aW5nIG1pZ2h0IGJlIDxicj5oZWxwZnVs ICh0aGlzIGlzIGp1c3QgYW4gZXhhbXBsZS0tSSBkb24ndCBtZWFuIHRvIHNheSB0aGF0IGl0IGlz IHRydWUgb3IgPGJyPmFwcGxpY2FibGUpOjxicj48YnI+Jm5ic3A7ICJTb21lIHVzZXMgb2YgdGhp cyBtZWNoYW5pc20gbWF5IGNhcnJ5IHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uLCA8YnI+ b3IgZ2VuZXJhdGUmbmJzcDsmbmJzcDsmbmJzcDsgcHJpdmFjeS1zZW5zaXRpdmUgbWV0YWRhdGEg dGhyb3VnaCB0aGUgc3Vic2NyaXB0aW9uIDxicj5tZWNoYW5pc20uIEluIGNvbnRleHRzIHdoZXJl IHRoaXMgaXMgdHJ1ZSwgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHMgPGJyPmFwcGx5Li4uIjxi cj48YnI+SXQgbWlnaHQgYWxzbyBiZSByZWFzb25hYmxlIHRvIHNheSB0aGF0LCBmb3IgdGhlIGNv bnRleHQgb2YgaTJycywgdGhlc2UgPGJyPnJlcXVpcmVtZW50cyBhcmUgZG9jdW1lbnRlZCBpbiBb cmVmZXJlbmNlc10gYW5kIGFyZSBleHBlY3RlZCB0byBiZSA8YnI+ZnVsZmlsbGVkIGJ5IHRoZSBb dHJhbnNwb3J0IGFuZCBvciBwcm90b2NvbF08YnI+PGJyPkVyaWMncyBlbWFpbCBhbHNvIHN1Z2dl c3RlZCB0aGF0IHRoZSBhY3R1YWwgdHJhbnNwb3J0IG9mIGRhdGEgZnJvbSB0aGUgPGJyPllhbmcg ZGF0YXN0b3JlIG1heSBiZSBvdXQgb2Ygc2NvcGUgZm9yIHRoZXNlIHJlcXVpcmVtZW50cy4gSSBk b24ndCA8YnI+b2JqZWN0IHRvIHRoYXQsIGVpdGhlciwgYXMgbG9uZyBhcyBpdCBpcyBjbGVhciBh bmQgZXhwbGljaXQsIGFsdGhvdWdoIGl0IDxicj53b3VsZCBiZSBnb29kIHRvIHBvaW50IHRvIHdo ZXJlIGl0IGlzIF9pbl8gc2NvcGUuPGJyPjxicj5UaGFua3MhPGJyPjxicj5CZW4uPGJyPjxicj5P biA2IE1heSAyMDE2LCBhdCAxOjA2LCBTdXNhbiBIYXJlcyB3cm90ZTo8YnI+PGJyPiZndDsgQmVu Ojxicj4mZ3Q7PGJyPiZndDsgVGhpcyBpcyB0aGUgZmlyc3Qgb2YgdGhlICJyZS11c2UiIG1hbmFn ZW1lbnQgcHJvdG9jb2xzLiZuYnNwOyBUaGUgPGJyPiZndDsgcmVxdWlyZW1lbnRzPGJyPiZndDsg YXJlIHNldC11cCBzbyB0aGF0IHdlIGNhbiBzdWdnZXN0IGFkZGl0aW9ucyB0byB0aGUgTkVUQ09O RiBhbmQgPGJyPiZndDsgUkVTVENPTkYgZm9yPGJyPiZndDsgdGhpcyBmaXJzdCBvZiBJMlJTLjxi cj4mZ3Q7PGJyPiZndDsgVGhlIEkyUlMgZXBoZW1lcmFsIHdvcmssIHB1Yi9zdWIsIHRyYWNlYWJp bGl0eSwgYW5kIHNlY3VyaXR5IGFyZSA8YnI+Jmd0OyB0YXJnZXQgYXQ8YnI+Jmd0OyB0aGUgSTJS UyBwcm90b2NvbCBkZWZpbml0aW9uIHdpdGggdGhlIEkyUlMgdXNlIGNhc2UuJm5ic3A7IEhvd2V2 ZXIsIHNpbmNlIDxicj4mZ3Q7IHRoZXNlPGJyPiZndDsgYXJlIGdlbmVyYWwgYWRkaXRpb25zIHRv IE5FVENPTkYvUkVTVENPTkYsIHRoaXMgd29yayBjYW4gYmUgdXNlZCA8YnI+Jmd0OyBlbHNld2hl cmUuPGJyPiZndDs8YnI+Jmd0OyBJIHRoaW5rIHRoZSB0ZXh0IHlvdSBhcmUgaGlnaGxpZ2h0aW5n IGhhcyB0aGlzIGxhcmdlciBjb250ZXh0LiZuYnNwOyZuYnNwOyBOb3csIDxicj4mZ3Q7IG9uZSBv Zjxicj4mZ3Q7IHRoZSByZWFsbHkgaW1wb3J0YW50IHRoaW5ncyB0byBjaGF0IHdpdGggQWxpYSBh bmQgQmVub2l0IGlzIGhvdyBkbyB3ZSA8YnI+Jmd0OyBoYW5kbGU8YnI+Jmd0OyB0aGUgd2lkZXIg dXNlIGNhc2UuJm5ic3A7Jm5ic3A7IERvIHdlIG1lbnRpb24gdGhlIHdpZGVyIGNvbnRleHQ/PGJy PiZndDs8YnI+Jmd0OyBUaGUgV0cgdGhvdWdodCBtZW50aW9uaW5nIGl0IHdhcyBpbXBvcnRhbnQu PGJyPiZndDs8YnI+Jmd0OyBTdWU8YnI+Jmd0Ozxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPiZndDsgRnJvbTogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29t XTxicj4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCBNYXkgMDUsIDIwMTYgNTozMSBQTTxicj4mZ3Q7IFRv OiBTdXNhbiBIYXJlczxicj4mZ3Q7IENjOiBFcmljIFZvaXQ7IFRoZSBJRVNHOyBpMnJzQGlldGYu b3JnOzxicj4mZ3Q7IGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9y ZzsgaTJycy1jaGFpcnNAaWV0Zi5vcmc8YnI+Jmd0OyBTdWJqZWN0OiBSZTogW2kycnNdIEJlbiBD YW1wYmVsbCdzIERpc2N1c3Mgb248YnI+Jmd0OyBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1 aXJlbWVudHMtMDY6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPGJyPiZndDs8YnI+Jmd0OyBP biA1IE1heSAyMDE2LCBhdCA1OjE1LCBTdXNhbiBIYXJlcyB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7 Jmd0OyBFcmljLCBCZW4gYW5kIElFU0cgbWVtYmVyczo8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8 YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgVGhlIHB1Yi9zdWIgcmVxdWlyZW1lbnRzIGFyZSBwYXJ0 IG9mIGEgNSBwYXJ0IHJlcXVpcmVtZW50cy4mbmJzcDsmbmJzcDsgTWF5IEk8YnI+Jmd0OyZndDsg cXVvdGU8YnI+Jmd0OyZndDsgZnJvbSB0aGUgc2hlcGhlcmQncyByZXBvcnQ6PGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyBUaGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgZmlyc3QgdmVyc2lvbiBvZiBJMlJTIGFyZTo8YnI+ Jmd0OyZndDs8YnI+Jmd0OyZndDsgMSkgbW9kZWwgZHJpdmVuIGVwaGVtZXJhbCBzdGF0ZSAtIHRo YXQgaXMgZGF0YSBtb2RlbHMgdGhhdCBkbyBub3Q8YnI+Jmd0OyZndDsgc3Vydml2ZTxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIHNvZnR3YXJlIG9yIGhh cmR3YXJlIHJlYm9vdC48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS88YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgMikgYSBzZWN1cmUgcHJvdG9j b2wgLTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxPGJyPiZndDsmZ3Q7IHVp cmVtZTxicj4mZ3Q7Jmd0OyBudHMvPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7IDMpIHRyYWNlYWJpbGl0eSAtIGFiaWxpdHkgdG8gcmVjb3JkIGludGVyYWN0 aW9ucyBiZXR3ZWVuIEkyUlMgPGJyPiZndDsmZ3Q7IGVsZW1lbnRzPGJyPiZndDsmZ3Q7PGJyPiZn dDsmZ3Q7IChDbGllbnQsIEFnZW50LCBSb3V0aW5nIHN5c3RlbSk8YnI+Jmd0OyZndDs8YnI+Jmd0 OyZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXRy YWNlYWJpbGl0eS88YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZn dDsgNCkgbm90aWZpY2F0aW9uIHB1YmxpY2F0aW9uIHZpYSBzdWJzY3JpcHRpb248YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLzxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyA1KSBQcm90b2NvbCB0byBwYXNzIERhdGEgZm9yIEFuYWx5dGlj czxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBUaGUgZmlyc3QgdmVyc2lvbiBvZiB0aGVzZSByZXF1 aXJlbWVudHMgZG9lcyBub3QgaW5jbHVkZSBhPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IHNlcGFy YXRlIGFuYWx5dGljYWwgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGFzIHRoZSBzaW1wbGUgdXNlIGNh c2VzIG1heTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBwYXNzIGluZm9ybWF0aW9uIHZpYSBxdWVy eS9wb2xsIG9yIHRoZSBub3RpZmljYXRpb25zLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBUaGUgSTJSUyBwcm90b2NvbCBleGlzdHMgaW4gYW4gc2VjdXJl IGVudmlyb25tZW50IGRlc2NyaWJlZCBieTo8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXNlY3VyaXR5LWVudmly b25tZW50LTxicj4mZ3Q7Jmd0OyByZXFzLzxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsmZ3Q7PGJy PiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEVyaWMgLSBQZXJoYXBzIGl0IHdvdWxk IGJlIGdvb2QgdG8gcG9pbnQgdG86PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IC4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1pMnJzLXBy b3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50cyBhbmQ8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsg LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1p ZXRmLWkycnMtc2VjdXJpdHktZW52aXJvbm1lbnQtcmVxcy88YnI+Jmd0OyZndDs8YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgQmVuIC0gQ2FuIHlvdSB0ZWxsIG1lIGhvdyB0aGUg c2hlcGhlcmQgcmVwb3J0IGNvdWxkIGhhdmUgYmVlbiA8YnI+Jmd0OyZndDsgY2xlYXJlcj88YnI+ Jmd0OyZndDsmbmJzcDsgVGhlPGJyPiZndDsmZ3Q7IEkycnMgcHJvdG9jb2wgc2VjdXJpdHkgcmVx dWlyZW1lbnRzIHJlcXVpcmU6Jm5ic3A7IGNvbmZpZGVudGlhbGl0eSw8YnI+Jmd0OyZndDsgZW5j cnlwdGlvbiwgc2VjdXJlIHRyYW5zcG9ydCwgcHJvdGVjdGlvbiBhZ2FpbnN0IHJlcGxheSBhdHRh Y2ssPGJyPiZndDsmZ3Q7IHByb3RlY3Rpb24gYWdhaW5zdCBERG9TIGF0dGFjayAoaWYgcG9zc2li bGUpLjxicj4mZ3Q7PGJyPiZndDsgSSB0aGluayBteSBjb25mdXNpb24gbGllcyBpbiB0aGUgZmFj dCB0aGF0LCB3aGlsZSB0aGUgc2hlcGhlcmQncyA8YnI+Jmd0OyB3cml0ZXVwPGJyPiZndDsgc3R5 bGVzIHRoaXMgZHJhZnQgYXMgcGFydCBvZiB0aGUgSTJSUyBwcm90b2NvbCByZXF1aXJlbWVudHMs IHRoZSBkcmFmdDxicj4mZ3Q7IGl0c2VsZiBjbGFpbXMgdG8gZGVzY3JpYmUgcmVxdWlyZW1lbnRz IGZvciBhIGdlbmVyYWxseSB1c2VmdWwgcHViLXN1Yjxicj4mZ3Q7IGludGVyZmFjZSB0byBhIHlh bmcgZGF0YXN0b3JlLiBJdCdzIG5vdCBjbGVhciB0byBtZSBob3cgYW5kIHdoZW4gdGhlIDxicj4m Z3Q7IEkyUlM8YnI+Jmd0OyBwcm90b2NvbCBzZWN1cml0eSByZXF1aXJlbWVudHMgYXBwbHkgdG8g aXQuIElmIHRoZSBkZXNjcmliZWQgaW50ZXJmYWNlIDxicj4mZ3Q7IGlzPGJyPiZndDsgaW50ZW5k ZWQgdG8gYmUgdXNlZnVsIGluIGNvbnRleHRzIG90aGVyIHRoYW4gSTJSUyAoYW5kIHRoZSBkcmFm dCA8YnI+Jmd0OyBleHBsaWNpdGx5PGJyPiZndDsgc2V0cyB0aGF0IGV4cGVjdGF0aW9uIGluIDIu MiksIGl0IG5lZWRzIHRvIHRhbGsgbW9yZSBnZW5lcmFsbHkgYWJvdXQ8YnI+Jmd0OyBzZWN1cml0 eSBhbmQgcHJpdmFjeS48YnI+Jmd0Ozxicj4mZ3Q7IEZvciBleGFtcGxlLCBpdCBtaWdodCBtYWtl IHNlbnNlIHRvIHNheSB0aGF0IGNlcnRhaW4gc2VjdXJpdHkgPGJyPiZndDsgcmVxdWlyZW1lbnRz PGJyPiZndDsgYXBwbHkgaW4gZW52aXJvbm1lbnRzIHdoZXJlIHRoZSBtZWNoYW5pc20gbWlnaHQg Y2FycnkgcHJpdmFjeSA8YnI+Jmd0OyBzZW5zaXRpdmU8YnI+Jmd0OyBkYXRhLCBhbmQgdGhlbiBw b2ludCB0byB0aGUgaTJycyByZXF1aXJlbWVudHMgZm9yIHdoZW4gdGhlIG1lY2hhbmlzbSA8YnI+ Jmd0OyBpcyB1c2VkPGJyPiZndDsgaW4gYW4gSTJSUyBjb250ZXh0Ljxicj4mZ3Q7PGJyPiZndDsg QSBkaWZmZXJlbnQgYXBwcm9hY2ggbWlnaHQgYmUgdG8gbW9yZSB0aWdodGx5IGNvbnN0cmFpbiB0 aGlzIHRvIGkycnM8YnI+Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyBCZW4gLSBPbiBvcHRpbmcgaW4sIG9uY2UgdGhlIHJlY2VpdmUgYWNjZXB0cyBh IHRyYW5zcG9ydCBjb25uZWN0aW9uPGJyPiZndDsmZ3Q7IGZyb20gdGhlIEkyUlMgc2VydmVyIC0g aG93IGlzIHRoaXMgbm90IGFuIG9wdC1pbiB0byByZWNlaXZlIGRhdGE/IDxicj4mZ3Q7Jmd0OyBX aGF0PGJyPiZndDsmZ3Q7IGFyZSB5b3UgbG9va2luZyBmb3I/PGJyPiZndDs8YnI+Jmd0OyBJIGd1 ZXNzIHRoYXQgZGVwZW5kcyBvbiB0aGUgdHJhbnNwb3J0LiBUaGUgdHJhbnNwb3J0IHJlcXVpcmVt ZW50cyBzYXkgPGJyPiZndDsgdGhlPGJyPiZndDsgbWVjaGFuaXNtIGhhcyB0byB3b3JrIG92ZXIg bXVsdGlwbGUgdHJhbnNwb3J0cy4gVGhlIGxhc3QgcGFyYWdyYXBoIGluIDxicj4mZ3Q7IDQuMi40 PGJyPiZndDsgc2F5cyAiSW4gdGhlIGNhc2Ugb2YgY29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3Bv cnRzLi4uIiB3aGljaCBzdWdnZXN0cyA8YnI+Jmd0OyB0aGF0PGJyPiZndDsgbm9uLWNvbm5lY3Rp b24tb3JpZW50ZWQgdHJhbnNwb3J0cyBhcmUgcG9zc2libGUuPGJyPiZndDs8YnI+Jmd0OyBFdmVu IHdpdGggYSBjb25uZWN0aW9uLW9yaWVudGVkIHRyYW5zcG9ydCwgdGhpcyBtYXkgZGVwZW5kIG9u IGhvdzxicj4mZ3Q7IGNvbm5lY3Rpb24tbWFuYWdlbWVudCBpcyBoYW5kbGVkLCBhbmQgd2hldGhl ciB0aGUgcmVjZWl2ZXIgbWlnaHQgYmU8YnI+Jmd0OyByZWNlaXZpbmcgdGhpbmdzIGl0IF93YW50 c18gdG8gcmVjZWl2ZSBvbiB0aGUgc2FtZSB0cmFuc3BvcnQuPGJyPiZndDs8YnI+Jmd0OyZndDs8 YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgU3VlIEhhcmVzPGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7IChzaGVwaGVyZCk8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+Jmd0OyZndDsgRnJvbTogaTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgVm9pdDxicj4mZ3Q7Jmd0OyAoZXZvaXQpPGJyPiZndDsm Z3Q7IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDc6MjUgUE08YnI+Jmd0OyZndDsgVG86 IEJlbiBDYW1wYmVsbDsgVGhlIElFU0c8YnI+Jmd0OyZndDsgQ2M6IGkycnNAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZzs8YnI+Jmd0OyZndDsg aTJycy1jaGFpcnNAaWV0Zi5vcmc7IHNoYXJlc0BuZHpoLmNvbTxicj4mZ3Q7Jmd0OyBTdWJqZWN0 OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb248YnI+Jmd0OyZndDsgZHJhZnQt aWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2OiAod2l0aCBESVNDVVNTIGFuZCBDT01N RU5UKTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBIaSBC ZW4sPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFRoYW5r cyBmb3IgdGhlIGNvbW1lbnQuJm5ic3A7Jm5ic3A7IEluLWxpbmUuLi4uPGJyPiZndDsmZ3Q7PGJy PiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBGcm9tOiBCZW4gQ2FtcGJlbGws IE1heSAwNCwgMjAxNiAyOjQ5IFBNPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBESVNDVVNTOjxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEkgaGF2ZSBhIGNvdXBsZSBvZiBwb2ludHMgSSB3 b3VsZCBsaWtlIHRvIGRpc2N1c3MuIEhvcGVmdWxseSB0aGV5IDxicj4mZ3Q7Jmd0OyZndDsgY2Fu PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBiZSByZXNvbHZlZDxicj4mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsgZWFzaWx5Ojxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7IEFyZSB0aGVyZSByZWFsbHkgbm8gcmVxdWlyZW1lbnRzIGZvciBw cml2YWN5IG9yIGludGVncml0eSA8YnI+Jmd0OyZndDsmZ3Q7IHByb3RlY3Rpb24/PGJyPiZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyBJcyB0aGVyZSBhbiBleHBlY3RhdGlvbiB0aGF0IHRoaXMgbWVj aGFuaXNtIHdvdWxkIGV2ZXIgY2FycnkgcHJpdmFjeTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZn dDsgc2Vuc2l0aXZlIG9yIG90aGVyd2lzZSBzZW5zaXRpdmUgaW5mb3JtYXRpb24/PGJyPiZndDsm Z3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFtlcmljJ3MgY29tbWVudDo8 YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgV2hlbiB0aGUgc3Vic2NyaXB0aW9uIGlzIGVzdGFibGlz aGVkIGR5bmFtaWNhbGx5IHZpYSBhbiBleGlzdGluZzxicj4mZ3Q7Jmd0OyB0cmFuc3BvcnQ8YnI+ Jmd0OyZndDsgc2Vzc2lvbiAod2hpY2ggaXMgZXhwZWN0ZWQgdG8gYmUgdGhlIGRvbWluYW50IGNh c2UpIHdlIGhhdmUgdGhlIHNhbWU8YnI+Jmd0OyZndDsgZXhwZWN0YXRpb25zIGZvciBQcml2YWN5 IGFuZCBpbnRlZ3JpdHkgYXMgd291bGQgYmUgcHJvdmlkZWQgdmlhIGE8YnI+Jmd0OyZndDsgIkdF VCI8YnI+Jmd0OyZndDsgaW5zdGVhZCBvZiBhICJQVVNIIiBvdmVyIHRoZSBzYW1lIHRyYW5zcG9y dC4mbmJzcDsmbmJzcDsgV2UgY291bGQgaGF2ZTxicj4mZ3Q7Jmd0OyByZXBsaWNhdGVkIGFsbDxi cj4mZ3Q7Jmd0OyB0aGVzZSByZXF1aXJlbWVudHMsIGJ1dCB0aGF0IHdhcyBzZWVuIGFzIHVubmVj ZXNzYXJ5IGFuZCBsaWtlbHkgbGVzczxicj4mZ3Q7Jmd0OyBzZWN1cmU8YnI+Jmd0OyZndDsgdGhh biBhZG9wdGluZyBleGlzdGluZyBtZWNoYW5pc21zLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBXaGVuIHRoZSBTdWJzY3JpYmVyIGFuZCBSZWNlaXZlciBh cmUgZGlmZmVyZW50LCB0aGVuIHRoZSB0cmFuc3BvcnQ8YnI+Jmd0OyZndDsgY29ubmVjdGlvbiB3 aWxsIGhhdmUgY3JlZGVudGlhbHMgcGFzc2VkIGFzIHBhcnQgb2YgdGhlIGVzdGFibGlzaG1lbnQu PGJyPiZndDsmZ3Q7IFRoZXNlPGJyPiZndDsmZ3Q7IGNyZWRlbnRpYWxzIHdpbGwgYmUgdXNlZCBh cyBhIFNlY3VyaXR5IEdyb29taW5nIEZpbHRlciBqdXN0IGxpa2UgdGhlPGJyPiZndDsmZ3Q7IGFi b3ZlPGJyPiZndDsmZ3Q7IGNhc2Ugc28gdGhhdCBwdXNoZWQgb2JqZWN0cyB3aWxsIGJlIGV4Y2x1 ZGVkIGZyb20gYW4gVXBkYXRlPGJyPiZndDsmZ3Q7IE5vdGlmaWNhdGlvbiBhczxicj4mZ3Q7Jmd0 OyBwZXIgdGhlIHBlcm1pc3Npb25zIG9mIHRoZSBSZWNlaXZlci4mbmJzcDsmbmJzcDsgKEkuZS4s IHRoaXMgaXMgaWRlbnRpY2FsPGJyPiZndDsmZ3Q7IGJlaGF2aW9yIHRvPGJyPiZndDsmZ3Q7IHRo ZSBhYm92ZS4pJm5ic3A7Jm5ic3A7Jm5ic3A7IEFzIHNldmVyYWwgcGVvcGxlIGhhdmUgaGFkIHF1 ZXN0aW9ucyBhYm91dCB0aGlzLCB0aGU8YnI+Jmd0OyZndDsgbmV3IHYwNzxicj4mZ3Q7Jmd0OyB3 aWxsIG1ha2UgdGhpcyBleHBsaWNpdCBpbiB0aGUgU2VjdXJpdHkgc2VjdGlvbi48YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDsgRW5kIG9mIGVyaWMncyBjb21tZW50XTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBTdWU6IFRoZSB0cmFuc3BvcnQgcHJvdmlkZXMg Zm9yIHByaXZhY3ksIGludGVncml0eSBwcm90ZWN0aW9uLiZuYnNwOyZuYnNwOyBNb3N0PGJyPiZn dDsmZ3Q7IGNvbmZpZ3VyYXRpb24gaW4gbmV0d29yayBib3hlcyB3b3VsZCBuZWVkIHByaXZhY3ku PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyAtIDQu Mi41LCAybmQgdG8gbGFzdCBwYXJhZ3JhcGg6PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBJ IGFtIHN1cnByaXNlZCB0byBmaW5kIHRoYXQsIHdoZW4gdGhlIHJlY2VpdmVyIGlzIG5vdCB0aGUg PGJyPiZndDsmZ3Q7Jmd0OyBzdWJzY3JpYmVyLDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsg dGhhdCB0aGUgcmVjZWl2ZXIgaXMgZXhwZWN0ZWQgdG8gb3B0LW91dC4gSXQgc2VlbXMgbGlrZSBz b21lIGZvcm0gb2Y8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IG9wdC1pbiBvciBhZmZpcm1h dGl2ZSBjb25zZW50IHdvdWxkIGJlIG5lZWRlZCBoZXJlLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBUaGUgcXVlc3Rpb24gcmVhbGx5IHdhcyBob3cgaGVh dnktd2VpZ2h0IHNob3VsZCB0aGUgbWVjaGFuaXNtIGJlLjxicj4mZ3Q7Jmd0OyBUcmFuc3BvcnRz IGJlZW4gY29uc2lkZXJpbmcgYXJlIGFsbCBlbmNyeXB0ZWQuJm5ic3A7IFNvIHRoZXJlIGlzIGFs cmVhZHkgYTxicj4mZ3Q7Jmd0OyBsZXZlbDxicj4mZ3Q7Jmd0OyBvZiB0cnVzdCBiZXR3ZWVuIHRo ZSBwZWVycy4mbmJzcDsgQW5kIGEgdGFyZ2V0IGNhbiBhbHdheXMgcHVsbCBkb3duIHRoZTxicj4m Z3Q7Jmd0OyBjb25uZWN0aW9uIGlmIHRoZXJlIGFyZSBpc3N1ZXMuPGJyPiZndDsmZ3Q7PGJyPiZn dDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEluIGFkZGl0aW9uLCBtdWx0aWNhc3QgdHJh bnNwb3J0cyBhcmUgdmlhYmxlIGZvciBzb21lIGZ1dHVyZSBjYXNlcy48YnI+Jmd0OyZndDsgV2U8 YnI+Jmd0OyZndDsgZGlkbid0IHdhbnQgbWVjaGFuaXNtcyB3aGljaCBjb21wbGljYXRlZCB0aGlz IHR5cGUgb2YgaW50ZXJhY3Rpb24sPGJyPiZndDsmZ3Q7IGVzcGVjaWFsbHkgaW4gYSB3b3JsZCB3 aGVyZSBkdW1iIElvVCBkZXZpY2VzIG1heSBiZSBpbnZvbHZlZC48YnI+Jmd0OyZndDs8YnI+Jmd0 OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgU3VlOiBJZiB0aGUgcmVjZWl2ZXIgYWNjZXB0 cyBhIHNlY3VyZSB0cmFuc3BvcnQgc2V0LXVwIGZyb20gdGhlPGJyPiZndDsmZ3Q7IHNlcnZlciwg Y2FuPGJyPiZndDsmZ3Q7IHlvdSBwcm92aWRlIHRoZSByZWFzb24gd2h5IHRoaXMgaXMgbm90IGFu ICJvcHQtaW4iIG9uY2UgaXQgcmVjZWl2ZXM8YnI+Jmd0OyZndDsgdGhlPGJyPiZndDsmZ3Q7IGNv bm5lY3Rpb24gZnJvbSB0aGUgSTJSUyBhZ2VudD88YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+ Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IENPTU1FTlQ6PGJyPiZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgLSBHZW5lcmFsOiBJIHN1cHBvcnQgU3RlcGhlbidz IERJU0NVU1M8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyAtMi4yOiBXaGF0IGlzIHRoZSByZWFsIHNjb3BlIG9mIHRoaXMgd29yaz8gSXMgaXQg ZXhwZWN0ZWQgdG8gPGJyPiZndDsmZ3Q7Jmd0OyBzdXBwbGFudDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyZndDsgdGhlIG1lbnRpb25lZCBtZWNoYW5pc21zPzxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBOby4mbmJzcDsmbmJzcDsgSXQgaXMganVzdCBzaG93 aW5nIHRoYXQgbWFueSBzcGVjaWFsaXplZCBQdXNoIG1lY2hhbmlzbSBleGlzdC48YnI+Jmd0OyZn dDsgVGhpczxicj4mZ3Q7Jmd0OyBpcyBub3QgaW50ZW5kZWQgdG8gc3VwcGxhbnQgZXhpc3Rpbmcg bWVjaGFuaXNtcywgYWx0aG91Z2ggcGVyaGFwcyBpdDxicj4mZ3Q7Jmd0OyBjYW48YnI+Jmd0OyZn dDsgaGVscCBhdm9pZCBmdXR1cmUgZGVkaWNhdGVkIHNvbHV0aW9ucy48YnI+Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7IC0gMi4zOiAiV2UgbmVlZCBhIG5ldyBwdWItc3ViPGJyPiZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0ZWNobm9sb2d5Ijxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsgVGhlIHNoZXBoZXJkIHdyaXRlIHVwIG1lbnRpb25lZCBhIGdvYWwgdG8g dXNlIGV4aXN0aW5nIHRlY2hub2xvZ2llcy48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IElz IHRoZSBwb2ludCBvZiB0aGlzIHNlbnRlbmNlIHRvIHN1Z2dlc3QgdGhhdCBpcyBub3QgZmVhc2li bGU/PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEV4aXN0 aW5nIHRlY2hub2xvZ2llcyBjYW5ub3QgbWVldCBhbGwgdGhlIHJlcXVpcmVtZW50cyBzcGVjaWZp ZWQuPGJyPiZndDsmZ3Q7IFRoZXJlIGFyZTxicj4mZ3Q7Jmd0OyB0ZWNobm9sb2d5IGRyYWZ0cyBw cm9ncmVzc2luZyBpbiBORVRDT05GIHdoaWNoIGNhbi48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8 YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IC0gNC4xLCA0dGggcGFyYWdyYXBoOjxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgVGhlIE1BWSBkb2Vzbid0IHNlZW0gcmlnaHQtLWlzIHRoaXMg YSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0IHRoZTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsg c3Vic2NyaWJlciBtYXkgaGF2ZSB0byByZXN1YnNjcmliZSwgb3IgYSByZXF1aXJlbWVudCBvZiB0 aGUgZm9ybSA8YnI+Jmd0OyZndDsmZ3Q7IHRoYXQ8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 IHRoZSBzZXJ2aWNlIE1BWSBmb3JjZSB0aGUgc3Vic2NyaWJlciB0byByZXN1YnNjcmliZT8gKEJl IGNhcmVmdWwgPGJyPiZndDsmZ3Q7Jmd0OyB3aXRoPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0 OyBNQVlzIGluIHJlcXVpcmVtZW50cyBsYW5ndWFnZS0tdGhleSBpbXBseSB1bmV4cGVjdGVkIHRo aW5ncy4gRm9yPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBleGFtcGxlLCBzZXZlcmFsIHJl cXVpcmVtZW50cyBzYXkgYSBTVUJTQ1JJQkUgTUFZIGRvIHNvbWV0aGluZy0tZG88YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7IHRob3NlIGltcGx5IHRoYXQgdGhlIHNlcnZpY2UgTVVTVCBhbGxv dyB0aGUgc3Vic2NyaWJlciB0byBkbyBpdCA/KTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBHb29kIHBvaW50LiZuYnNwOyZuYnNwOyBSZXdvcmRlZCBpbiB2 MDcuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyAt LSA0LjIuMiwgdGhpcmQgYnVsbGV0OiBUaGUgcHJldmlvdXMgc2VjdGlvbiBzYWlkIGRhbXBlbmlu ZyBwZXJpb2RzPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBNVVNUIGJlIHN1cHBvcnRlZC48 YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgWWVzLCBidXQg ZGFtcGVuaW5nIGlzIG5ldmVyIGZvciBwZXJpb2RpYyBzdWJzY3JpcHRpb25zLjxicj4mZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyZndDsgLSA0LjIuMSwgdGhpcmQgcGFyYWdyYXBoOiBUaGlzIGlzIGEgYml0 IGFtYmlndW91cy4gSSB0aGluayBpdCBtZWFuczxicj4mZ3Q7Jmd0OyZndDsgdG88YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7IGNoYW5nZSB0aGUgd2hhdCBzdWJ0cmVlcyB0aGUgc3Vic2NyaXB0 aW9uIGFwcGxpZXMgdG8sIGJ1dCBjb3VsZCBiZTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsg aW50ZXJwcmV0ZWQgdG8gY2hhbmdlIHRoZSBzdWJ0cmVlcyB0aGVtc2VsdmVzLjxicj4mZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBGaXhlZDxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsgLSA0LjIuNi40OiBXb3VsZCBhIG1lY2hhbmlzbSB0aGF0IGFsbG93ZWQg b3V0LW9mLW9yZGVyIGRlbGl2ZXJ5IGJ1dDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgZ2F2 ZSB0aGUgc3Vic2NyaWJlciBhIHdheSB0byByZWNvbnN0cnVjdCB0aGUgb3JkZXIgZnVsZmlsbCB0 aGlzPGJyPiZndDsmZ3Q7IHJlcXVpcmVtZW50Pzxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBZZXMsIHRoZSB0aW1lc3RhbXAgd2l0aGluIGFuIHVwZGF0ZS4m bmJzcDsgQnV0IHRoaXMgcmVxdWlyZW1lbnQgdGFyZ2V0cyBhPGJyPiZndDsmZ3Q7IHNwZWNpZmlj IG9iamVjdCBpbiBhIHNwZWNpZmljIHN1YnNjcmlwdGlvbi4mbmJzcDsgU28gdGhlcmUgc2hvdWxk IGJlIG5vPGJyPiZndDsmZ3Q7IGlzc3Vlcy48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IE5p dHM6PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyAtIFRoZSBzaGVwaGVyZCB3cml0ZSB1cCBz dWdnZXN0cyB0aGlzIGlzIHN0YW5kYXJkcyB0cmFjay4gVGhlIGRyYWZ0PGJyPiZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyBhbmQgdHJhY2tlciBib3RoIHNheSBpbmZvcm1hdGlvbmFsLiBQbGVhc2Ug dXBkYXRlIHRoZSBzaGVwaGVyZCB3cml0PGJyPiZndDsmZ3Q7Jmd0OyB1cC48YnI+Jmd0OyZndDs8 YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgRml4ZWQ8YnI+Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7IC0zLCBsYXN0IHBhcmFncmFwaDogV2hhdCdzIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gYSAiUHVzaCIgYW5kIGFuPGJyPiZndDsmZ3Q7ICJVcGRhdGUiPzxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBSZXdvcmRlZDxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsgLTQuMTogQSBmb3J3YXJkIHJlZmVyZW5jZSB0byB0aGUgc3Vic2NyaXB0 aW9uIFFvUyBzZWN0aW9uIHdvdWxkIGJlPGJyPiZndDsmZ3Q7IGhlbHBmdWwuPGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IE1vdmVkIHRoZSByZXF1aXJlbWVu dCBpbiBxdWVzdGlvbiB0byA0LjIuNi48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IC0tIExh c3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlOiBTZW50ZW5jZSBkb2Vzbid0IHBhcnNlLjxicj4m Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBGaXhlZDxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IC0gNC4yLjgs IHRoaXJkIHBhcmFncmFwaDogSSBkb24ndCB0aGluayB0aGF0IHNob3VsZCBiZSBhIDIxMTkgTUFZ PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEZpeGVkPGJy PiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldyE8YnI+Jmd0 OyZndDs8YnI+Jmd0OyZndDsgRXJpYzxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyBpMnJzIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZuYnNwOyAmbHQ7 bWFpbHRvOmkycnNAaWV0Zi5vcmcmZ3Q7IGkycnNAaWV0Zi5vcmc8YnI+Jmd0OyZndDs8YnI+Jmd0 OyZndDsmbmJzcDsgJmx0O2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy cyZndDs8YnI+Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p MnJzPGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_1128317882336420-- From nobody Fri May 6 16:15:46 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564CA12D15D for ; Fri, 6 May 2016 16:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9grenKBSfrn3 for ; Fri, 6 May 2016 16:15:39 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 826E612B017 for ; Fri, 6 May 2016 16:15:38 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id y84so147643944lfc.0 for ; Fri, 06 May 2016 16:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wQY1EXFR2w1ADqiTABa5CRXeL+9+nsRf2U2zz/Gm0K4=; b=r84hSJa3dut2ocpyGgwG+DtLgES7sX95pj1VaVoL0L2AdBFZE3t67JjOIADe6IEkcO NlFi3LQCUz5dz1U58cEpCm+gSnTDzGQE35bwfbtzFeMTLBxKzq1l6UvO0aU9e0BVcPGW ils+QL71oKWBeEDUZT4aqbXenItFrTMCvuccwzwYKi0V4Gx5tB+jdGSJDw1fSDHxmrMC NIGmB8gTpwHWPpyRZsl008SW+k/CRDCFgrlghHH0RLEK9liRSH83FlosmQziGVv6bnJq Rqc3HNr++hZQ4GfmSTwj+wiBo2WCIxs0yDp6ArxykJ4hYGZW8TYL0PS1RCNG4MJKn4eC HwGA== 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; bh=wQY1EXFR2w1ADqiTABa5CRXeL+9+nsRf2U2zz/Gm0K4=; b=K4qYbbmHZjHpyQcA1q0vZt6rGotDMKcEl4QJt2BOMfzPa7bWww4Ytu5ELdIas70nTP rtaX5EDLAZbenwNUdHhaTOoh+7tHCkLqiLESNPhm5o4jBquUD8/FbsdwqPjUWHGGJyYm /yU+18ARPCQz2rVgGb31CpAcrnOSrWW1yCuWAVtovNS6cnguI1Yd/8T64bLpGqJIAz93 oQp/Ju9E5Ao1gHIdPczWi7Uci/31R5AV9alH7aIhvW3dsxA+TOyT2lkuAsdNMahMYlrT sTRI7gj1bw7DrRWoFjGbMI+CMFzBJPMbn//2eIPw6IKS6jv2ZFynsplqx+rkh3Xg1OkV Bszw== X-Gm-Message-State: AOPr4FUOoDQg/vePFT8Jix0yPdyX0baYAspzdVDGtZOUnart5TSqXc/FjVfOFuoJfi0oRRr9PmT67CiUm5NLRw== MIME-Version: 1.0 X-Received: by 10.25.141.131 with SMTP id p125mr11346773lfd.8.1462576536751; Fri, 06 May 2016 16:15:36 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Fri, 6 May 2016 16:15:36 -0700 (PDT) In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Date: Fri, 6 May 2016 16:15:36 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a1140242cee28bd053234a267 Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [i2rs] [Netconf] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 23:15:42 -0000 --001a1140242cee28bd053234a267 Content-Type: text/plain; charset=UTF-8 Hi, I have not have enough time to work on this draft yet, but here are my initial concerns. I won't comment on the details yet. 1) datastores There is an opstate design team working on everything except ephemeral. We need 1 RPC defining the datastore framework and each specific datastore (known at this time). The I2RS protocol should not be that document. 2) requirements There should not be any duplication of requirements. There should just be normative text defining the protocol, and non-normative examples. 3) YANG validation As stated in BA, I am strongly against protocol documents redefining how YANG works for their spot solution. The YANG designer and operator want the data models to be as protocol-independent as possible. Andy On Thu, May 5, 2016 at 11:13 PM, Susan Hares wrote: > > This version of the protocol strawman is the result of all the suggestions > from the I2RS meeting and inputs from other reviews. > Please let us know if you have additional reviews. > > Sue, Amit, and Andy > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, May 06, 2016 2:11 AM > To: Amit Daas; amit.dass@ericsson.com; Andy Bierman; Susan Hares > Subject: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt > > > A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt > has been successfully submitted by Susan Hares and posted to the IETF > repository. > > Name: draft-hares-i2rs-protocol-strawman > Revision: 02 > Title: I2RS protocol strawman > Document date: 2016-05-05 > Group: Individual Submission > Pages: 52 > URL: > https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-02.txt > Status: > https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/ > Htmlized: > https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-protocol-strawman-02 > > Abstract: > This strawman proposal for the I2RS protocol supports I2RS > requirements for ephemeral data store, management data flows, and > protocol security. It proposes additions to the NETCONF, RESTCONF, > and YANG for these requirements. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1140242cee28bd053234a267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have not have enough time to work= on this draft yet, but here are my initial concerns.
I won't= comment on the details yet.

1) datastores

There is an opstate design team working on everything exc= ept ephemeral.
We need 1 RPC defining the datastore framework and= each specific datastore (known at this time).
The I2RS protocol = should not be that document.

2) requirements
=

There should not be any duplication of requirements.
There should just be normative text defining the protocol, and non-= normative examples.

3) YANG validation
<= br>
As stated in BA, I am strongly against protocol documents red= efining how YANG works
for their spot solution.=C2=A0 The YANG de= signer and operator want the data models to be as
protocol-indepe= ndent as possible.



A= ndy


On Thu, May 5, 2016 at 11:13 PM, Susan Hares = <shares@ndzh.com> wrote:
<WG chair hat off,= co-author hat on>
This version of the protocol strawman is the result of all the suggestions = from the I2RS meeting and inputs from other reviews.
Please let us know if you have additional reviews.

Sue, Amit, and Andy

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Friday, May 06, 2016 2:11 AM
To: Amit Daas; amit.dass@ericsson= .com; Andy Bierman; Susan Hares
Subject: New Version Notification for draft-hares-i2rs-protocol-strawman-02= .txt


A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt
has been successfully submitted by Susan Hares and posted to the IETF repos= itory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hares-i2rs-protocol-str= awman
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I2RS protocol strawman
Document date:=C2=A0 2016-05-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 52
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hares-i2= rs-protocol-strawman-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawma= n/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-pro= tocol-strawman-02

Abstract:
=C2=A0 =C2=A0This strawman proposal for the I2RS protocol supports I2RS
=C2=A0 =C2=A0requirements for ephemeral data store, management data flows, = and
=C2=A0 =C2=A0protocol security.=C2=A0 It proposes additions to the NETCONF,= RESTCONF,
=C2=A0 =C2=A0and YANG for these requirements.




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

The IETF Secretariat


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

--001a1140242cee28bd053234a267-- From nobody Sat May 7 09:53:47 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFB012B04B for ; Sat, 7 May 2016 09:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzmg3mpqvhdO for ; Sat, 7 May 2016 09:53:43 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 608CE12B01B for ; Sat, 7 May 2016 09:53:43 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id j8so161167588lfd.2 for ; Sat, 07 May 2016 09:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vkMO5VbUSgMeSbaUl3qblaUr1/bCIKzYH6DK1nGkQCs=; b=h1UQvhEY4OvcTobJH1rpWDPZNwrFd/var0eFJC/lemImON3zoIbDCqqdg6vF4oqOgC GQt2ffmn7dyfEuHKu9ZhlTRPtFYBNRWVgJttOE7zdSnG8rKRM3gWrJ+LhPLW+Nyiscn7 TZBSFv/Jzz1l1AqZG8/v0Dt6Rwuutqwms5hraaRHz8GM8wcWtNj9KxVNhI2UPJlJgblF 3ng/vPXoEkpsj4wenSMKIjw5i8I6lYjcAESH2I8Yqto4s+VlzzAfEPeB/IF6CA6cK2Hs 3nSrY2J0+W2zYKKfW6e0mnNjD4r+uM6FZ8qS+oP1FBCS/zetpNM8S6DCXKSIvVPbOBl+ fVdQ== 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; bh=vkMO5VbUSgMeSbaUl3qblaUr1/bCIKzYH6DK1nGkQCs=; b=jwNOd2qgEbWhrt053Q8rFYw4NhpDB5nhFRyiiCaKypqF7MlpHZXq/i2t7M/3exJfU8 6k8nyvJaEqKVUSZnYs++AOfcS2IdLDm3sb4nO5D5VWrCX1bXgEIFAG2576SzsIWpsrM4 OZwpC1XIVx4/G5hSaobBpk55Fw8psUQCAUZmGL9BVSFmcEjnLN8I7rXCqXt3Zk5I58BL RmMNnOcIbydSl6wn6Wj5gq+JEATurdOmdiPHnTFJJohxxH+DeibvDc3zh/1HCSrFx1/U wWrVDoX4LRjlCyYFdpsuzO0OamuaQgEpSP4YFOngy3TOLSK3TjV3F0Q79W5vArYIom5P hyQw== X-Gm-Message-State: AOPr4FU8lnpqHmODOxxObvdwvf5EfpvfBLBHQryaQ4b1LU9wXE3+aMKTSqZI21Px90U/uB58nAs1ba2UAsz7ng== MIME-Version: 1.0 X-Received: by 10.25.64.212 with SMTP id n203mr12505341lfa.54.1462640021542; Sat, 07 May 2016 09:53:41 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Sat, 7 May 2016 09:53:41 -0700 (PDT) In-Reply-To: References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Date: Sat, 7 May 2016 09:53:41 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a113fc26aeb36cf0532436ac1 Archived-At: Cc: "i2rs@ietf.org" , Netconf , Susan Hares Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 16:53:46 -0000 --001a113fc26aeb36cf0532436ac1 Content-Type: text/plain; charset=UTF-8 On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern wrote: > Reading the latest revision, in section 3.1.1, the text in bullet 5 says > that the data model indicates which portions are ephemeral. That makes > sense to me. > > Then bullet 6 says that the management protocol needs to signal (in its > yang library) which parts are ephemeral. > > Why the second requirement? If the data model is supported, and the data > model states that certain items are ephemeral, what would it mean if the > signaling did not also say that. Conversely, what would it mean if the > signaling said something was ephemeral that the model does not define as > ephemeral? > > It may be that I am misreading bullet 6. Please explain. > > I think you are correct that the YANG library does not need any changes to identify ephemeral data. Only the variable components of YANG conformance are contained in the library. Thank you, > Joel > > Andy > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a113fc26aeb36cf0532436ac1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern <<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">jmh@joelhalpern.com= > wrote:
Reading the latest= revision, in section 3.1.1, the text in bullet 5 says that the data model = indicates which portions are ephemeral.=C2=A0 That makes sense to me.

Then bullet 6 says that the management protocol needs to signal (in its yan= g library) which parts are ephemeral.

Why the second requirement?=C2=A0 If the data model is supported, and the d= ata model states that certain items are ephemeral, what would it mean if th= e signaling did not also say that.=C2=A0 Conversely, what would it mean if = the signaling said something was ephemeral that the model does not define a= s ephemeral?

It may be that I am misreading bullet 6.=C2=A0 Please explain.



I think you are correct= that the YANG library does not need any changes
to identify ephe= meral data.=C2=A0 Only the variable components of
YANG conformanc= e are contained in the library.


Thank you,
Joel



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

--001a113fc26aeb36cf0532436ac1-- From nobody Sun May 8 00:50:23 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D8E12D12A; Sun, 8 May 2016 00:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh8Gb_F0S6uE; Sun, 8 May 2016 00:50:18 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C214D12B015; Sun, 8 May 2016 00:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6393; q=dns/txt; s=iport; t=1462693818; x=1463903418; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=xzWFKG6Ju98LvRKFwEzlEo8OxbSJtKtxaKg/ZyqKG+s=; b=TyCXe+V+S9LhqB1erqPAvFh8rQIz6cPv8rval04SqbclIDJ71ohE/QCe mc9oaTOBWdprtbskJVO6aVsGJMJJMqO+nWjWCI2FFmDC/Vvppb6zLKV0X NhGdRwIf+s9ELTs8AE1Zc6un0UMiPThmArHO9yuIvLdYa2uHcIYDzmIJP k=; X-IronPort-AV: E=Sophos;i="5.24,594,1454976000"; d="scan'208,217";a="677097275" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2016 07:50:16 +0000 Received: from [10.61.195.58] ([10.61.195.58]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u487oFGT018141; Sun, 8 May 2016 07:50:15 GMT To: "Eric Voit (evoit)" , The IESG References: <20160503085242.7557.50387.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <572EEFB7.6000509@cisco.com> Date: Sun, 8 May 2016 09:50:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020101020904020302060500" Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" , "jiangsheng@huawei.com" Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 07:50:21 -0000 This is a multi-part message in MIME format. --------------020101020904020302060500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, See in line. > Hi Benoit, > > Comments in-line... > >> Benoit Claise has entered the following ballot position for >> draft-ietf-i2rs-pub-sub-requirements-06: Discuss >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Three DISCUSS points, which could be easily resolved IMO. >> >> 1. As mentioned on the NETMOD mailing list by Tom Petch, don't redefine the >> YANG datastore term: >>> I see that the definition of 'datastores' has cropped up in this AD >>> Review, as in the e-mail below. >>> >>> Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last >>> Call and redefines, or recreates, the term for us >>> >>> A YANG datastore is a conceptual datastore that contains >> hierarchical >>> data defined in YANG data models. It is what is referred in >> existing >>> RFCs as "NETCONF datastore". However, as the same datastore is no >>> longer tied to NETCONF as a specific transport, the term "YANG >>> datastore" is deemed more appropriate. >>> >>> I think that the concept of datastore has been troublesome to those >>> coming to YANG lately, such as openconfig and I2RS, and that this will >>> just muddy the waters more, especially as it is tucked away in an >>> Informational document. If I2RS want to define such terminology, then >>> it should be in the I2RS Architecture or some such; but IMHO they >> should >>> not be defining YANG datastores at all. > The new updated v07 includes a reference to the RFC6241 definition of datastore. Thanks. Minor editorial point. A datastore is defined in [RFC6241] and is not redefined here. The second part of the sentence is unnecessary IMO. > >> 3. In the security considerations section >> >> Versioning MUST be supported. >> >> Versioning of what? Yang push protocol, subscription, transport session, state of >> of subscription, something else? > Updated. You have not addressed my point Your new sentence is: Versioning MUST be supported so that the capabilities and behaviors expected of specific technology implementations can be exposed. Versioning of what? Yang push protocol, subscription, transport session, state of of subscription, something else? Regards, Benoit --------------020101020904020302060500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Eric,

See in line.
Hi Benoit,

Comments in-line...


Benoit Claise has entered the following ballot position for
draft-ietf-i2rs-pub-sub-requirements-06: Discuss

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Three DISCUSS points, which could be easily resolved IMO.

1. As mentioned on the NETMOD mailing list by Tom Petch, don't redefine the
YANG datastore term:

I see that the definition of 'datastores' has cropped up in this AD
Review, as in the e-mail below.

Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last
Call and redefines, or recreates, the term for us

    A YANG datastore is a conceptual datastore that contains

hierarchical

    data defined in YANG data models.  It is what is referred in

existing

    RFCs as "NETCONF datastore".  However, as the same datastore is no
    longer tied to NETCONF as a specific transport, the term "YANG
    datastore" is deemed more appropriate.

I think that the concept of datastore has been troublesome to those
coming to YANG lately, such as openconfig and I2RS, and that this will
just muddy the waters more, especially as it is tucked away in an
Informational document.  If I2RS want to define such terminology, then
it should be in the I2RS Architecture or some such; but IMHO they

should

not be defining YANG datastores at all.

The new updated v07 includes a reference to the RFC6241 definition of datastore.
Thanks. Minor editorial point.

    A datastore is defined in [RFC6241] and is not redefined here.

The second part of the sentence is unnecessary IMO.


3. In the security considerations section

   Versioning MUST be supported.

Versioning of what? Yang push protocol, subscription, transport session, state of
of subscription, something else?

Updated.
You have not addressed my point
Your new sentence is:
   Versioning MUST be supported so that the capabilities and behaviors
   expected of specific technology implementations can be exposed.
Versioning of what? Yang push protocol, subscription, transport session, state of of subscription, something else?

Regards, Benoit
--------------020101020904020302060500-- From nobody Sun May 8 19:17:19 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53A12D197; Sun, 8 May 2016 19:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buGQZOsummpf; Sun, 8 May 2016 19:17:13 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 33EC212D18D; Sun, 8 May 2016 19:17:10 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id f66so50171681vkh.2; Sun, 08 May 2016 19:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kJwUVmztqHgDad3+5ENFC9e4+3UHElC3yqkwbDXnbTQ=; b=xWrhDsxYF11lCCjeY8S8+CLvjHmnFy7vs4eiDX948kh1+Qm58dUcuDzXbUXLXFdPTe cfFZGmuCt3nzAHjTdc95l9M7VqqOgbVCuHYn+KXbD3j8E1gpPLmxBEcggorZaSAKLByt t6nL8TfHvGrxxJL3ma+Xaov1BC50w7OsV0f8arfjkIQIhHsP+ZtTNdY3hUt6ra8jj0vd hJ/D8LJ36fh3V+Xch4LSCBQ5yHvR60KtMEDhn7Cr+ePj8zNhEWPWWSuWn/eZoiis0tt2 sqQrZiZhiXyjLzO5hd8wcD6ovIiEXX/yj8FIgWWg20eieVIx7nreTopNtFGzvRbivk3+ 6Z8g== 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; bh=kJwUVmztqHgDad3+5ENFC9e4+3UHElC3yqkwbDXnbTQ=; b=HMvSvSTgue78CX6RPLZdN/TIupJkGdfWfNUTX7v550XL907chiqzZvNIqErk0CxxYT dZbbeS8j+vnk2l/4CRZtWS9ZnPd9iwnZyRdnaT8XRhCHEw6V21zDpbCP/og5cvYAgZCN 1C6akv/LyXMtWZfX2r2LD+5o2rXnZJCf2ENSe1CdGJBjU6H3QDQuc+v5UFo7vqw3PMt+ M3nh8bATfBbUlzvTqbRZvzgDXX7Bibh2HzcRL6po3LmLPYXn7wTflCdewKwMEd4ibVL4 +JtmBTciAo7jk0qSKPTnx5xA61N/34gZ+JjhlRCwNR4YAMS8uEOocP+33wIv7Dwgd1gh Tj4w== X-Gm-Message-State: AOPr4FW3Dd/oOsPxhNQ/Nsig2yqLFDvqzAsY2bAm56RkgWITnuT/AhEynUi7dv0hsiJZyOYSpBG7hTFbCH9v+w== MIME-Version: 1.0 X-Received: by 10.159.55.207 with SMTP id q73mr18922343uaq.71.1462760229149; Sun, 08 May 2016 19:17:09 -0700 (PDT) Received: by 10.176.69.211 with HTTP; Sun, 8 May 2016 19:17:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2016 05:17:09 +0300 Message-ID: From: Ines Robles To: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org Content-Type: multipart/alternative; boundary=94eb2c03fa6ad9a34805325f670a Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , Susan Hares , Jon Hudson Subject: Re: [i2rs] Routing directorate QA review of draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 02:17:15 -0000 --94eb2c03fa6ad9a34805325f670a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, QA review related to Data Model for Network Topologies I-D: Document: draft-ietf-i2rs-yang-network-topo-02.txt Reviewer: Ines Robles Review Date: May 9, 2016 Intended Status: Standards Track Summary: I have some minor concerns about this document that should be resolved before publication. Comments: I believe the draft is technically good. Thinking how it could be extended for constrained topology networks, e.g. RPL build a DODAG (Destination-Oriented Directed Acyclic Graph) and I like that the links are point-to-point and unidirectional, and like "One common requirement concerns the ability to represent that the same device can be part of multiple networks and topologies." a RPL node can participate in several DODAGs and in each one can have different role. Major Issues: I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. Minor Issues and Nits: 1- Section 1, following Figure 2: 1.1- " X1 and X2 - mapping onto... ", I think it would be "X1 and X3 mapping onto..." 1.2- " a single L3 network element", I would add in this case [Y2] "a single L3 [Y2] network element", the same for "The figure shows a single "L3" network element mapped onto multiple "Optical" network elements.", I would add "The figure shows a single "L3" [Y2] network element mapped onto multiple "Optical" network elements [Z] and [Z1]." 2- Section 2: 2.1- I would add a reference to RFC 6020, since the document uses terminology e.g container, augment, etc. which are defined in 6020. Even if this RFC is mentioned in the normative reference, still I would add it here as well. 2.2- In terminology you mention ReST, for this I would add the reference for further information. "Fielding, Roy Thomas. "Architectural styles and the design of network-based software architectures." PhD diss., University of California, Irvine, 2000.". ReST is mentioned here but not in the rest of the draft, is it correct? 3- Section 5: What about add the security considerations mentioned in 6020? 4- In general: I would mention as related work and the relation with this draft: draft-ietf-i2rs-yang-l2-network-topology-02, draft-ietf-i2rs-yang-l3-topology-01 and draft-contreras-supa-yang-network-topo-03 (this one is expired) Thank you, Ines. --94eb2c03fa6ad9a34805325f670a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,<= /div>

QA rev= iew related to Data Model for Network Topologies I-D:


Document: draft-ietf-i2rs-yang-network-topo-02.txt

Reviewer: Ines Roble= s

Revi= ew Date: May 9, 2016

Intended Status: Standards Track



Summary:

=C2=A0I have some minor conce= rns about this document that should be resolved before publication.


Comments:

I believe the draft is technically good. Thinki= ng how it could be extended for constrained topology networks, e.g. RPL bui= ld a DODAG (Destination-Oriented Directed Acyclic Graph) and I like that th= e links =C2=A0are point-to-point and unidirectional, and like "One com= mon requirement concerns the ability to represent that the same device can = be part of multiple networks and topologies." a RPL node can participa= te in several DODAGs and in each one can have different role.


Major Issues:

<= div class=3D"gmail_extra">I have no =E2=80=9CMajor=E2=80=9D issues with thi= s I-D.

Minor Issues and Nits:

1- Section 1, following Figure 2:

=C2=A01.1- " X1 and X2 -= mapping onto... ", =C2=A0I think it would be "X1 and X3 mapping = onto..."
=C2=A01.2- " a single L3= network element", I would add in this case [Y2] "a single L3 [Y2= ] network element", the same for "The figure shows a single "= ;L3" network element mapped onto multiple "Optical" network = elements.", I would add "The figure shows a single "L3"= [Y2] network element mapped onto multiple "Optical" network elem= ents [Z] and [Z1]."

2- Section 2:

=
=C2=A02.1- I would add a reference to RFC 6020, = since the document uses terminology e.g container, augment, etc. which are = defined in 6020. Even if this RFC is mentioned in the normative reference, = still I would add it here as well.=C2=A0
=C2=A02.2- In terminology you mention Re= ST, for this I would add the reference for further information. "Field= ing, Roy Thomas. "Architectural styles and the design of network-based= software architectures." PhD diss., University of California, Irvine,= 2000.".=C2=A0
ReST is mentioned here = but not in the rest of the draft, is it correct?


3- Section 5: What about add the security considerations mentioned in = 6020?

=
4- In general: I would mention as rela= ted work and the relation with this draft: draft-ietf-i2rs-yang-l2-network-= topology-02, draft-ietf-i2rs-yang-l3-topology-01 and draft-contreras-supa-y= ang-network-topo-03 (this one is expired)
<= br>

Th= ank you,

Ines.
--94eb2c03fa6ad9a34805325f670a-- From nobody Mon May 9 09:20:17 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B1112D09D; Mon, 9 May 2016 09:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtYUBXcnoujF; Mon, 9 May 2016 09:20:12 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 D6A3512D535; Mon, 9 May 2016 09:20:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Ines Robles'" , , References: In-Reply-To: Date: Mon, 9 May 2016 12:20:01 -0400 Message-ID: <016901d1aa0e$a3a48fb0$eaedaf10$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016A_01D1A9ED.1C95FCF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKvZPF3zDxstev4wPdQHgNIenot2gJu0abhAgTMek0BNJ8aeAF+C2MbAq41G2adpq9T0A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jonathan Hardwick' , rtg-dir@ietf.org, "'Zhangxian \(Xian\)'" , 'Jon Hudson' Subject: Re: [i2rs] Routing directorate QA review of draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 16:20:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_016A_01D1A9ED.1C95FCF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ines:=20 =20 Thank you for the excellent review. We appreciate your hard work.=20 =20 Sue=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ines Robles Sent: Sunday, May 08, 2016 10:17 PM To: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org Cc: Jonathan Hardwick; rtg-dir@ietf.org; Zhangxian (Xian); Susan Hares; = Jon Hudson Subject: Re: [i2rs] Routing directorate QA review of = draft-ietf-i2rs-yang-network-topo =20 Hi, =20 QA review related to Data Model for Network Topologies I-D: =20 =20 Document: draft-ietf-i2rs-yang-network-topo-02.txt =20 Reviewer: Ines Robles =20 Review Date: May 9, 2016 =20 Intended Status: Standards Track =20 =20 =20 Summary: =20 I have some minor concerns about this document that should be resolved = before publication. =20 =20 Comments: =20 I believe the draft is technically good. Thinking how it could be = extended for constrained topology networks, e.g. RPL build a DODAG = (Destination-Oriented Directed Acyclic Graph) and I like that the links = are point-to-point and unidirectional, and like "One common requirement = concerns the ability to represent that the same device can be part of = multiple networks and topologies." a RPL node can participate in several = DODAGs and in each one can have different role. =20 =20 Major Issues: =20 I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. =20 Minor Issues and Nits: =20 1- Section 1, following Figure 2: =20 1.1- " X1 and X2 - mapping onto... ", I think it would be "X1 and X3 = mapping onto..." 1.2- " a single L3 network element", I would add in this case [Y2] "a = single L3 [Y2] network element", the same for "The figure shows a single = "L3" network element mapped onto multiple "Optical" network elements.", = I would add "The figure shows a single "L3" [Y2] network element mapped = onto multiple "Optical" network elements [Z] and [Z1]." =20 2- Section 2: =20 2.1- I would add a reference to RFC 6020, since the document uses = terminology e.g container, augment, etc. which are defined in 6020. Even = if this RFC is mentioned in the normative reference, still I would add = it here as well.=20 =20 2.2- In terminology you mention ReST, for this I would add the = reference for further information. "Fielding, Roy Thomas. "Architectural = styles and the design of network-based software architectures." PhD = diss., University of California, Irvine, 2000.".=20 ReST is mentioned here but not in the rest of the draft, is it correct? =20 =20 3- Section 5: What about add the security considerations mentioned in = 6020? =20 =20 4- In general: I would mention as related work and the relation with = this draft: draft-ietf-i2rs-yang-l2-network-topology-02, = draft-ietf-i2rs-yang-l3-topology-01 and = draft-contreras-supa-yang-network-topo-03 (this one is expired) =20 =20 Thank you, =20 Ines. ------=_NextPart_000_016A_01D1A9ED.1C95FCF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ines:

 

Thank you for the excellent review.=C2=A0 We appreciate your hard = work.

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ines = Robles
Sent: Sunday, May 08, 2016 10:17 PM
To: = i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org
Cc: = Jonathan Hardwick; rtg-dir@ietf.org; Zhangxian (Xian); Susan Hares; Jon = Hudson
Subject: Re: [i2rs] Routing directorate QA review of = draft-ietf-i2rs-yang-network-topo

 

Hi,

 

QA review related to Data Model for Network Topologies = I-D:

 

 

Document: = draft-ietf-i2rs-yang-network-topo-02.txt

 

Reviewer: Ines Robles

 

Review Date: May 9, 2016

 

Intended Status: Standards = Track

 

 

 

Summary:

 

 I have some minor concerns about this document = that should be resolved before publication.

 

 

Comments:

 

I = believe the draft is technically good. Thinking how it could be extended = for constrained topology networks, e.g. RPL build a DODAG = (Destination-Oriented Directed Acyclic Graph) and I like that the links =  are point-to-point and unidirectional, and like "One common = requirement concerns the ability to represent that the same device can = be part of multiple networks and topologies." a RPL node can = participate in several DODAGs and in each one can have different = role.

 

 

Major Issues:

 

I = have no =E2=80=9CMajor=E2=80=9D issues with this = I-D.

 

Minor Issues and Nits:

 

1- Section 1, following Figure = 2:

 

 1.1- " X1 and X2 - mapping onto... ", =  I think it would be "X1 and X3 mapping = onto..."

 1.2- = " a single L3 network element", I would add in this case [Y2] = "a single L3 [Y2] network element", the same for "The = figure shows a single "L3" network element mapped onto = multiple "Optical" network elements.", I would add = "The figure shows a single "L3" [Y2] network element = mapped onto multiple "Optical" network elements [Z] and = [Z1]."

 

2- Section 2:

 

 2.1- I would add a reference to RFC 6020, since = the document uses terminology e.g container, augment, etc. which are = defined in 6020. Even if this RFC is mentioned in the normative = reference, still I would add it here as = well. 

 

 2.2- In terminology you mention ReST, for this I = would add the reference for further information. "Fielding, Roy = Thomas. "Architectural styles and the design of network-based = software architectures." PhD diss., University of California, = Irvine, 2000.". 

ReST is mentioned here but not in the rest of the = draft, is it correct?

 

 

3- Section 5: What about add the security = considerations mentioned in 6020?

 

 

4- In general: I would mention as related work and the = relation with this draft: draft-ietf-i2rs-yang-l2-network-topology-02, = draft-ietf-i2rs-yang-l3-topology-01 and = draft-contreras-supa-yang-network-topo-03 (this one is = expired)

 

 

Thank you,

 

Ines.

------=_NextPart_000_016A_01D1A9ED.1C95FCF0-- From nobody Mon May 9 12:51:46 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A7712D147; Mon, 9 May 2016 12:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.506 X-Spam-Level: X-Spam-Status: No, score=-15.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypjire6YPZai; Mon, 9 May 2016 12:51:42 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F5812D521; Mon, 9 May 2016 12:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6644; q=dns/txt; s=iport; t=1462823502; x=1464033102; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HYSog8L29ZbabyP+piP7KyfCR6qrsKBgu+JODmj1Btk=; b=P9ZeuPkpFDUtS7cLbs+f2iimW9+jl67rdF/2fN5VlAbMrGTeedHlJNUo eWkUdxwGCYwcoszWSvIom8tXvh0M+MQcVnSaQ2knw7nAKstXG5gHDY+c0 OpIS/W6aO6BRqRiqvEOo2m7Ux+podjw9plE5/+DH0CJxmzFmTnn6yXr3F c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgCk6TBX/5hdJa1dgmxMVYEDtByCZ?= =?us-ascii?q?YIPAQ2BdoYQAoE5OBQBAQEBAQEBZSeEQQEBAQQtTBACAQgVEBYLMiUCBAENDYg?= =?us-ascii?q?jvyoBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiCETIRNhUsFkyyEdgGOFIFwjS6LW?= =?us-ascii?q?x2DQgEeAQFCgjaBNYh1fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,601,1454976000"; d="scan'208,217";a="271551354" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2016 19:51:40 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u49JpdI5018743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 May 2016 19:51:39 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 May 2016 15:51:38 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Mon, 9 May 2016 15:51:38 -0400 From: "Eric Voit (evoit)" To: "Benoit Claise (bclaise)" , The IESG Thread-Topic: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRpRktAbbtnYLN3kC4tRphXhjGVp+pXdmQgAWXhoCAAhapMA== Date: Mon, 9 May 2016 19:51:38 +0000 Message-ID: References: <20160503085242.7557.50387.idtracker@ietfa.amsl.com> <572EEFB7.6000509@cisco.com> In-Reply-To: <572EEFB7.6000509@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_d9849bf9f0e5460cbe3eb56f7196e87dXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" , "jiangsheng@huawei.com" Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 19:51:45 -0000 --_000_d9849bf9f0e5460cbe3eb56f7196e87dXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Benoit Claise, May 08, 2016 3:50 AM The new updated v07 includes a reference to the RFC6241 definition of datas= tore. Thanks. Minor editorial point. A datastore is defined in [RFC6241] and is not redefined here. The second part of the sentence is unnecessary IMO. now says: A datastore is defined in [RFC6241]. 3. In the security considerations section Versioning MUST be supported. Versioning of what? Yang push protocol, subscription, transport session, st= ate of of subscription, something else? Updated. You have not addressed my point Your new sentence is: Versioning MUST be supported so that the capabilities and behaviors expected of specific technology implementations can be exposed. Versioning of what? Yang push protocol, subscription, transport session, st= ate of of subscription, something else? now says: Versioning of any subscription protocols MUST be supported so that the capa= bilities and behaviors expected of specific technology implementations can = be exposed. Eric Regards, Benoit --_000_d9849bf9f0e5460cbe3eb56f7196e87dXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Benoit Claise, May 08= , 2016 3:50 AM

The new updated v07 includes a reference to the RFC6241 definition of =
datastore.

Thanks. Minor editorial point.

    A datastore is defined in [RFC624= 1] and is not redefined here.

The second part of the sentence is unnecessary IMO.<= /span>
<EV> now says:

    A d= atastore is defined in [RFC6241].



3. In the security considerations section
 
   Versioning MUST be supported.
 
Versioning of what? Yang push protocol, subscription, transport sessio=
n, state of
of subscription, something else?
 
Updated.

You have not addressed my point
Your new sentence is:

   Versioning MUST be supported so that the capabilities and=
 behaviors
   expected of specific technology implementations can be ex=
posed.

Versioning of what? Yang push protocol, subscription= , transport session, state of of subscription, something else?

 <= /p> 

<EV> now says:
Versioning of any subscription protocols MUST be suppo=
rted so that the capabilities and behaviors expected of specific technology=
 implementations can be exposed.

 

Eric=

 <= /p>

 <= /p>


Regards, Benoit

--_000_d9849bf9f0e5460cbe3eb56f7196e87dXCHRTP013ciscocom_-- From nobody Mon May 9 13:21:31 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4419A12D0A4; Mon, 9 May 2016 13:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.506 X-Spam-Level: X-Spam-Status: No, score=-15.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp-aLKgOoEFP; Mon, 9 May 2016 13:21:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131FB12D62F; Mon, 9 May 2016 13:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7040; q=dns/txt; s=iport; t=1462825270; x=1464034870; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=m93swU9KgMa6K2F8ef16Sl2zfpik4iYWeRYNJynX3xk=; b=AVXIO9GESNmAT6r7FTzdfrmsK694mV2ARQl3WDNUTNn8UYpAElVctJaS wWehdbu9YTUpGUAkFeB2tNRcKavqw11HDwQA0rrsSinsnguwp88dc+j/N Aofo0bIvNlrEXp6jK1MSdH+FX2iJJxivZK8POAkhIMiGvqEUnDHbhNzmp 8=; X-IronPort-AV: E=Sophos;i="5.24,601,1454976000"; d="scan'208,217";a="106195400" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2016 20:21:09 +0000 Received: from [10.86.252.90] ([10.86.252.90]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u49KL8rn031101; Mon, 9 May 2016 20:21:08 GMT To: "Eric Voit (evoit)" , The IESG References: <20160503085242.7557.50387.idtracker@ietfa.amsl.com> <572EEFB7.6000509@cisco.com> From: Benoit Claise Message-ID: <5730F133.8050103@cisco.com> Date: Mon, 9 May 2016 16:21:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020009020407040904070705" Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" , "jiangsheng@huawei.com" Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 20:21:19 -0000 This is a multi-part message in MIME format. --------------020009020407040904070705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Eric, Perfect. Thank you. Regards, Benoit > > *From:*Benoit Claise, May 08, 2016 3:50 AM > > The new updated v07 includes a reference to the RFC6241 definition of datastore. > > Thanks. Minor editorial point. > > A datastore is defined in [RFC6241] and is not redefined here. > > The second part of the sentence is unnecessary IMO. > now says: > > A datastore is defined in [RFC6241]. > > > > 3. In the security considerations section > Versioning MUST be supported. > Versioning of what? Yang push protocol, subscription, transport session, state of > of subscription, something else? > Updated. > > You have not addressed my point > Your new sentence is: > > Versioning MUST be supported so that the capabilities and behaviors > expected of specific technology implementations can be exposed. > > Versioning of what? Yang push protocol, subscription, transport > session, state of of subscription, something else? > > now says: > Versioning of any subscription protocols MUST be supported so that the > capabilities and behaviors expected of specific technology > implementations can be exposed. > > Eric > > > Regards, Benoit > > . --------------020009020407040904070705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Eric,

Perfect. Thank you.

Regards, Benoit

From: Benoit Claise, May 08, 2016 3:50 AM

The new updated v07 includes a reference to the RFC6241 definition of datastore.

Thanks. Minor editorial point.

    A datastore is defined in [RFC6241] and is not redefined here.

The second part of the sentence is unnecessary IMO.
<EV> now says:

    A datastore is defined in [RFC6241].



3. In the security considerations section
 
   Versioning MUST be supported.
 
Versioning of what? Yang push protocol, subscription, transport session, state of
of subscription, something else?
 
Updated.

You have not addressed my point
Your new sentence is:

   Versioning MUST be supported so that the capabilities and behaviors
   expected of specific technology implementations can be exposed.

Versioning of what? Yang push protocol, subscription, transport session, state of of subscription, something else?

 

<EV> now says:
Versioning of any subscription protocols MUST be supported so that the capabilities and behaviors expected of specific technology implementations can be exposed.

 

Eric

 

 


Regards, Benoit

.

--------------020009020407040904070705-- From nobody Mon May 9 16:04:01 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84A12D0E6 for ; Mon, 9 May 2016 16:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plrORbAS3YBX for ; Mon, 9 May 2016 16:03:58 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0344A12D097 for ; Mon, 9 May 2016 16:03:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.172.62.119; Date: Mon, 09 May 2016 17:43:10 -0400 Message-ID: Importance: normal From: Susan Hares To: Juergen Schoenwaelder , i2rs@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_2010152757552590" X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:04:00 -0000 ----_com.samsung.android.email_2010152757552590 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SnVlcmdlbjpXZSBjb3VsZCBtb3ZlIHRoZSBzb2x1dGlvbnMgaW50byB0aGUgcHJvdG9jb2wgc3Ry YXdtYW4uIMKgQXMgZGlzY3Vzc2VkIGluIGlldGYgOTMgYW5kIGlldGYgOTQgdGhlIHNvbHV0aW9u cyBhcmUgc2ltcGx5IGV4YW1wbGVzIHRvIHByb3ZpZGUgaGludHMgb24gdGhlIGkycnMgcmVxdWly ZW1lbnRzLiDCoEp1c3QgdG8gYmUgY2xlYXIsIGF0IG1pbmltdW0geW91IHdvdWxkIHN1Z2dlc3Qg dGhlIHlhbmcsIE5FVENPTkYgYW5kIFJFU1RDT05GIHNlY3Rpb25zIHRvIHByb3RvY29sIHN0cmF3 bWFuLiDCoApUaGUgaXNzdWUgcmVnYXJkaW5nIHRoZSBwcm90b2NvbHMgaGFzIG9uZSBpc3N1ZSBv ZiBhbGxvd2luZyBhbiBpbnNlY3VyZSBwcm90b2NvbCAodG8gYmUgZGVmaW5lZCBlbHNld2hlcmUp IHRvIGJlIHV0aWxpemVkLiDCoElzIHRoaXMgd2hhdCB5b3UgYXJlIG9iamVjdGluZyB0bz8gwqBU aGUgb3RoZXIgaXNzdWUgaXMgdGhlIHNwZWNpZmljYXRpb24gb2Ygc3NoIG9yIFRMUyBmb3IgTkVU Q09ORi4gwqAKVGhlIGZpcnN0IGlzc3VlIHRyaWVzIHRvIGNyZWF0ZSBhIG5hcnJvdyBzY29wZSBm b3IgYW55IGRhdGEgaW4gYSBkYXRhbW9kZWwgc2VudCBvdmVyIGluc2VjdXJlIHRyYW5zcG9ydC4g wqAKT24gdGhlIHNlY29uZCBpc3N1ZSwgdGhlIHRleHQgd2FzIG5vdCB0cnlpbmcgdG8gdGllIGl0 IHRvIGEgZGF0YSBtb2RlbCBidXQgdG8gYWxsb3cgY2xpZW50cyB0byBrbm93IHdoYXQgb3B0aW9u cyB3ZXJlIHRvIGNvbW11bmljYXRlIHdpdGggYWdlbnRzLiDCoApUaGFuayB5b3UgZm9yIHlvdXIg cXVpY2sgcmVzcG9uc2UuClN1ZQoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBh biBBVCZUIDRHIExURSBzbWFydHBob25lLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t LUZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPiBEYXRlOiA1LzYvMjAxNiAgMzozNCBBTSAgKEdNVC0wNTowMCkgVG86IGkycnNA aWV0Zi5vcmcgU3ViamVjdDogUmU6IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWkycnMt ZXBoZW1lcmFsLXN0YXRlLTA2LnR4dCAKSSBoYXZlIGEgaGFyZCB0aW1lIHdpdGggdGhpcyBkb2N1 bWVudC4gU2VjdGlvbiAzIGlzIGxhYmVsbGVkCnJlcXVpcmVtZW50cyBidXQgaXQgYWN0dWFsbHkg ZGV0YWlscyBzb2x1dGlvbiBhbmQgSSBkaXNhZ3JlZSB3aXRoIGEKc2lnbmlmaWNhbnQgbnVtYmVy IG9mIHRoZSBzb2x1dGlvbiBlbGVtZW50cy4gVG8gbmFtZSBhbiBleGFtcGxlOgpJbmRpY2F0aW5n IGluIGEgZGF0YSBtb2RlbCB3aXRoIHdoaWNoIHByb3RvY29scyBpdCBzaG91bGQgYmUgdXNlZCBh bmQKd2hpY2ggc2VjdXJlIHRyYW5zcG9ydHMgdW5kZXJuZWF0aCB0aGUgcHJvdG9jb2wgc2hvdWxk IGJlIHVzZWQuIEkgZG8Kbm90IHdhbnQgdG8gZGlzY3VzcyBhbGwgdGhlIGRldGFpbHMgaGVyZSBz aW5jZSBvYnZpb3VzbHkgdGhpcyBpcyBub3QgYQpyZXF1aXJlbWVudHMgZG9jdW1lbnQuCgovanMK Ck9uIFRodSwgTWF5IDA1LCAyMDE2IGF0IDEwOjU5OjAxUE0gLTA3MDAsIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyB3cm90ZToKPiAKPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuCj4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXJmYWNlIHRvIHRoZSBSb3V0aW5nIFN5c3RlbSBv ZiB0aGUgSUVURi4KPiAKPsKgwqDCoMKgwqDCoMKgwqAgVGl0bGXCoMKgwqDCoMKgwqDCoMKgwqDC oCA6IEkyUlMgRXBoZW1lcmFsIFN0YXRlIFJlcXVpcmVtZW50cwo+wqDCoMKgwqDCoMKgwqDCoCBB dXRob3JzwqDCoMKgwqDCoMKgwqDCoCA6IEplZmYgSGFhcwo+wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBTdXNhbiBIYXJlcwo+IAlGaWxlbmFtZcKg wqDCoMKgwqDCoMKgIDogZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wNi50eHQKPiAJ UGFnZXPCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDE2Cj4gCURhdGXCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDogMjAxNi0wNS0wNQo+IAo+IEFic3RyYWN0Ogo+wqDCoMKgIFRoaXMgZG9jdW1lbnQgY292 ZXJzIHJlcXVlc3RzIHRvIHRoZSBuZXRtb2QgYW5kIG5ldGNvbmYgV29ya2luZwo+wqDCoMKgIEdy b3VwcyBmb3IgZnVuY3Rpb25hbGl0eSB0byBzdXBwb3J0IHRoZSBlcGhlbWVyYWwgc3RhdGUgcmVx dWlyZW1lbnRzCj7CoMKgwqAgdG8gaW1wbGVtZW50IHRoZSBJMlJTIGFyY2hpdGVjdHVyZS4KPiAK PiAKPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoK PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtZXBoZW1l cmFsLXN0YXRlLwo+IAo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxl IGF0Ogo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWkycnMtZXBoZW1l cmFsLXN0YXRlLTA2Cj4gCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Ogo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LWkycnMtZXBoZW1lcmFsLXN0YXRlLTA2Cj4gCj4gCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbgo+IHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuCj4gCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Ogo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvCj4gCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBpMnJzIG1h aWxpbmcgbGlzdAo+IGkycnNAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2kycnMKCi0tIApKdWVyZ2VuIFNjaG9lbndhZWxkZXLCoMKgwqDCoMKgwqDCoMKg wqDCoCBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgKUGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODfCoMKgwqDCoMKgwqDCoMKgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55 CkZheDrCoMKgICs0OSA0MjEgMjAwIDMxMDPCoMKgwqDCoMKgwqDCoMKgIDxodHRwOi8vd3d3Lmph Y29icy11bml2ZXJzaXR5LmRlLz4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmkycnMgbWFpbGluZyBsaXN0CmkycnNAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzCg== ----_com.samsung.android.email_2010152757552590 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pkp1ZXJnZW46PC9kaXY+PGRp dj5XZSBjb3VsZCBtb3ZlIHRoZSBzb2x1dGlvbnMgaW50byB0aGUgcHJvdG9jb2wgc3RyYXdtYW4u ICZuYnNwO0FzIGRpc2N1c3NlZCBpbiBpZXRmIDkzIGFuZCBpZXRmIDk0IHRoZSBzb2x1dGlvbnMg YXJlIHNpbXBseSBleGFtcGxlcyB0byBwcm92aWRlIGhpbnRzIG9uIHRoZSBpMnJzIHJlcXVpcmVt ZW50cy4gJm5ic3A7SnVzdCB0byBiZSBjbGVhciwgYXQgbWluaW11bSB5b3Ugd291bGQgc3VnZ2Vz dCB0aGUgeWFuZywgTkVUQ09ORiBhbmQgUkVTVENPTkYgc2VjdGlvbnMgdG8gcHJvdG9jb2wgc3Ry YXdtYW4uICZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIGlzc3VlIHJlZ2FyZGlu ZyB0aGUgcHJvdG9jb2xzIGhhcyBvbmUgaXNzdWUgb2YgYWxsb3dpbmcgYW4gaW5zZWN1cmUgcHJv dG9jb2wgKHRvIGJlIGRlZmluZWQgZWxzZXdoZXJlKSB0byBiZSB1dGlsaXplZC4gJm5ic3A7SXMg dGhpcyB3aGF0IHlvdSBhcmUgb2JqZWN0aW5nIHRvPyAmbmJzcDtUaGUgb3RoZXIgaXNzdWUgaXMg dGhlIHNwZWNpZmljYXRpb24gb2Ygc3NoIG9yIFRMUyBmb3IgTkVUQ09ORi4gJm5ic3A7PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgZmlyc3QgaXNzdWUgdHJpZXMgdG8gY3JlYXRlIGEgbmFy cm93IHNjb3BlIGZvciBhbnkgZGF0YSBpbiBhIGRhdGFtb2RlbCBzZW50IG92ZXIgaW5zZWN1cmUg dHJhbnNwb3J0LiAmbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9uIHRoZSBzZWNvbmQg aXNzdWUsIHRoZSB0ZXh0IHdhcyBub3QgdHJ5aW5nIHRvIHRpZSBpdCB0byBhIGRhdGEgbW9kZWwg YnV0IHRvIGFsbG93IGNsaWVudHMgdG8ga25vdyB3aGF0IG9wdGlvbnMgd2VyZSB0byBjb21tdW5p Y2F0ZSB3aXRoIGFnZW50cy4gJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFuayB5 b3UgZm9yIHlvdXIgcXVpY2sgcmVzcG9uc2UuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5TdWU8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWdu YXR1cmUiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyI+U2VudCB2aWEg dGhlIFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTwv ZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwvZGl2 PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxN ZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2Pjxk aXY+RnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGUmZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogNS82LzIwMTYgIDM6MzQgQU0gIChH TVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IGkycnNAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0 OiBSZTogW2kycnNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUt MDYudHh0IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PkkgaGF2ZSBhIGhhcmQgdGltZSB3aXRo IHRoaXMgZG9jdW1lbnQuIFNlY3Rpb24gMyBpcyBsYWJlbGxlZDxicj5yZXF1aXJlbWVudHMgYnV0 IGl0IGFjdHVhbGx5IGRldGFpbHMgc29sdXRpb24gYW5kIEkgZGlzYWdyZWUgd2l0aCBhPGJyPnNp Z25pZmljYW50IG51bWJlciBvZiB0aGUgc29sdXRpb24gZWxlbWVudHMuIFRvIG5hbWUgYW4gZXhh bXBsZTo8YnI+SW5kaWNhdGluZyBpbiBhIGRhdGEgbW9kZWwgd2l0aCB3aGljaCBwcm90b2NvbHMg aXQgc2hvdWxkIGJlIHVzZWQgYW5kPGJyPndoaWNoIHNlY3VyZSB0cmFuc3BvcnRzIHVuZGVybmVh dGggdGhlIHByb3RvY29sIHNob3VsZCBiZSB1c2VkLiBJIGRvPGJyPm5vdCB3YW50IHRvIGRpc2N1 c3MgYWxsIHRoZSBkZXRhaWxzIGhlcmUgc2luY2Ugb2J2aW91c2x5IHRoaXMgaXMgbm90IGE8YnI+ cmVxdWlyZW1lbnRzIGRvY3VtZW50Ljxicj48YnI+L2pzPGJyPjxicj5PbiBUaHUsIE1heSAwNSwg MjAxNiBhdCAxMDo1OTowMVBNIC0wNzAwLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6 PGJyPiZndDsgPGJyPiZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4mZ3Q7IFRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVyZmFjZSB0byB0aGUgUm91dGluZyBTeXN0ZW0g b2YgdGhlIElFVEYuPGJyPiZndDsgPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBJMlJTIEVwaGVtZXJhbCBTdGF0ZSBSZXF1 aXJlbWVudHM8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBBdXRob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDogSmVmZiBIYWFzPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgU3VzYW4gSGFyZXM8YnI+Jmd0OyAJRmlsZW5hbWUmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBkcmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0 YXRlLTA2LnR4dDxicj4mZ3Q7IAlQYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDE2PGJyPiZndDsgCURhdGUmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg OiAyMDE2LTA1LTA1PGJyPiZndDsgPGJyPiZndDsgQWJzdHJhY3Q6PGJyPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsgVGhpcyBkb2N1bWVudCBjb3ZlcnMgcmVxdWVzdHMgdG8gdGhlIG5ldG1vZCBhbmQg bmV0Y29uZiBXb3JraW5nPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JvdXBzIGZvciBmdW5j dGlvbmFsaXR5IHRvIHN1cHBvcnQgdGhlIGVwaGVtZXJhbCBzdGF0ZSByZXF1aXJlbWVudHM8YnI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0byBpbXBsZW1lbnQgdGhlIEkyUlMgYXJjaGl0ZWN0dXJl Ljxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4mZ3Q7IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUvPGJyPiZndDsgPGJyPiZndDsg VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPiZndDsgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUt MDY8YnI+Jmd0OyA8YnI+Jmd0OyBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6PGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUtMDY8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0 OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPiZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+Jmd0OyA8YnI+Jmd0 OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 PGJyPiZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+Jmd0OyA8YnI+ Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4m Z3Q7IGkycnMgbWFpbGluZyBsaXN0PGJyPiZndDsgaTJyc0BpZXRmLm9yZzxicj4mZ3Q7IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczxicj48YnI+LS0gPGJyPkp1ZXJn ZW4gU2Nob2Vud2FlbGRlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+UGhv bmU6ICs0OSA0MjEgMjAwIDM1ODcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+RmF4 OiZuYnNwOyZuYnNwOyArNDkgNDIxIDIwMCAzMTAzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl LyZndDs8YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPmkycnMgbWFpbGluZyBsaXN0PGJyPmkycnNAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_2010152757552590-- From nobody Mon May 9 16:04:28 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFEF12D556; Mon, 9 May 2016 16:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE60hZ3WUkDJ; Mon, 9 May 2016 16:04:25 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 C0B1112D17F; Mon, 9 May 2016 16:04:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.172.62.119; Date: Mon, 09 May 2016 18:09:18 -0400 Message-ID: Importance: normal From: Susan Hares To: Andy Bierman , "Joel M. Halpern" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_2010411323284380" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:04:27 -0000 ----_com.samsung.android.email_2010411323284380 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QW5keSBhbmQgSm9lbDoKVGhlc2UgYXJlIGdvb2QgcG9pbnRzLgpXaGF0IGhhcHBlbnMgaWYgdGhl IGRhdGEgbW9kZWwgaGFzIHNvbWUgZXBoZW1lcmFsIHNlY3Rpb25zIGFuZCB0aGUgSTJSUyBhZ2Vu dCBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSByb3V0aW5nIHN5c3RlbS4gwqBUaGUgZGF0YSBtb2Rl bCB3b3VsZCBzcGVjaWZ5IHRoZSBlcGhlbWVyYWwgc2VjdGlvbiwgYnV0IHRoZXJlIHdvdWxkIGJl IG5vIHN1cHBvcnQgYnkgaTJycy4gwqBJcyB0aGUgc3VwcG9ydCBvZiB0aGUgZXBoZW1lcmFsIG5v dCBhIHZhcmlhYmxlIMKgY29uZGl0aW9uIHRvIGJlIGluZGljYXRlZCBpbiBZYW5nIG1vZHVsZSBs aWJyYXJ5PwpTdWVTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJlQgNEcg TFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogQW5k eSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IERhdGU6IDUvNy8yMDE2ICAxMjo1MyBQTSAg KEdNVC0wNTowMCkgVG86ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiBD YzogaTJyc0BpZXRmLm9yZywgTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4sIFN1c2FuIEhhcmVz IDxzaGFyZXNAbmR6aC5jb20+IFN1YmplY3Q6IFJlOiBbaTJyc10gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJycy1wcm90b2NvbC1zdHJhd21hbi0wMi50eHQg LSAzLjEuMSAKCgpPbiBGcmksIE1heSA2LCAyMDE2IGF0IDg6NTEgQU0sIEpvZWwgTS4gSGFscGVy biA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6ClJlYWRpbmcgdGhlIGxhdGVzdCByZXZpc2lv biwgaW4gc2VjdGlvbiAzLjEuMSwgdGhlIHRleHQgaW4gYnVsbGV0IDUgc2F5cyB0aGF0IHRoZSBk YXRhIG1vZGVsIGluZGljYXRlcyB3aGljaCBwb3J0aW9ucyBhcmUgZXBoZW1lcmFsLsKgIFRoYXQg bWFrZXMgc2Vuc2UgdG8gbWUuCgoKClRoZW4gYnVsbGV0IDYgc2F5cyB0aGF0IHRoZSBtYW5hZ2Vt ZW50IHByb3RvY29sIG5lZWRzIHRvIHNpZ25hbCAoaW4gaXRzIHlhbmcgbGlicmFyeSkgd2hpY2gg cGFydHMgYXJlIGVwaGVtZXJhbC4KCgoKV2h5IHRoZSBzZWNvbmQgcmVxdWlyZW1lbnQ/wqAgSWYg dGhlIGRhdGEgbW9kZWwgaXMgc3VwcG9ydGVkLCBhbmQgdGhlIGRhdGEgbW9kZWwgc3RhdGVzIHRo YXQgY2VydGFpbiBpdGVtcyBhcmUgZXBoZW1lcmFsLCB3aGF0IHdvdWxkIGl0IG1lYW4gaWYgdGhl IHNpZ25hbGluZyBkaWQgbm90IGFsc28gc2F5IHRoYXQuwqAgQ29udmVyc2VseSwgd2hhdCB3b3Vs ZCBpdCBtZWFuIGlmIHRoZSBzaWduYWxpbmcgc2FpZCBzb21ldGhpbmcgd2FzIGVwaGVtZXJhbCB0 aGF0IHRoZSBtb2RlbCBkb2VzIG5vdCBkZWZpbmUgYXMgZXBoZW1lcmFsPwoKCgpJdCBtYXkgYmUg dGhhdCBJIGFtIG1pc3JlYWRpbmcgYnVsbGV0IDYuwqAgUGxlYXNlIGV4cGxhaW4uCgoKCgpJIHRo aW5rIHlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBZQU5HIGxpYnJhcnkgZG9lcyBub3QgbmVlZCBh bnkgY2hhbmdlc3RvIGlkZW50aWZ5IGVwaGVtZXJhbCBkYXRhLsKgIE9ubHkgdGhlIHZhcmlhYmxl IGNvbXBvbmVudHMgb2ZZQU5HIGNvbmZvcm1hbmNlIGFyZSBjb250YWluZWQgaW4gdGhlIGxpYnJh cnkuCgoKVGhhbmsgeW91LAoKSm9lbAoKCgoKQW5kecKgCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCgppMnJzIG1haWxpbmcgbGlzdAoKaTJyc0BpZXRmLm9y ZwoKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzCgoKCg== ----_com.samsung.android.email_2010411323284380 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkFuZHkgYW5kIEpvZWw6PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGVzZSBhcmUgZ29vZCBwb2ludHMuPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5XaGF0IGhhcHBlbnMgaWYgdGhlIGRhdGEgbW9kZWwgaGFzIHNvbWUgZXBo ZW1lcmFsIHNlY3Rpb25zIGFuZCB0aGUgSTJSUyBhZ2VudCBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRo ZSByb3V0aW5nIHN5c3RlbS4gJm5ic3A7VGhlIGRhdGEgbW9kZWwgd291bGQgc3BlY2lmeSB0aGUg ZXBoZW1lcmFsIHNlY3Rpb24sIGJ1dCB0aGVyZSB3b3VsZCBiZSBubyBzdXBwb3J0IGJ5IGkycnMu ICZuYnNwO0lzIHRoZSBzdXBwb3J0IG9mIHRoZSBlcGhlbWVyYWwgbm90IGEgdmFyaWFibGUgJm5i c3A7Y29uZGl0aW9uIHRvIGJlIGluZGljYXRlZCBpbiBZYW5nIG1vZHVsZSBsaWJyYXJ5PzwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+U3VlPC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJl Ij48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciPlNlbnQgdmlhIHRoZSBT YW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdp bmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rp dj48ZGl2PkZyb206IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8L2Rp dj48ZGl2PkRhdGU6IDUvNy8yMDE2ICAxMjo1MyBQTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5U bzogIkpvZWwgTS4gSGFscGVybiIgJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7IDwvZGl2Pjxk aXY+Q2M6IGkycnNAaWV0Zi5vcmcsIE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCBT dXNhbiBIYXJlcyAmbHQ7c2hhcmVzQG5kemguY29tJmd0OyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJl OiBbaTJyc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJy cy1wcm90b2NvbC1zdHJhd21hbi0wMi50eHQgLSAzLjEuMSA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48 L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBNYXkgNiwgMjAxNiBhdCA4OjUxIEFNLCBKb2Vs IE0uIEhhbHBlcm4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPlJlYWRpbmcgdGhlIGxhdGVzdCByZXZpc2lvbiwgaW4gc2VjdGlvbiAzLjEuMSwgdGhlIHRl eHQgaW4gYnVsbGV0IDUgc2F5cyB0aGF0IHRoZSBkYXRhIG1vZGVsIGluZGljYXRlcyB3aGljaCBw b3J0aW9ucyBhcmUgZXBoZW1lcmFsLiZuYnNwOyBUaGF0IG1ha2VzIHNlbnNlIHRvIG1lLjxicj4K PGJyPgpUaGVuIGJ1bGxldCA2IHNheXMgdGhhdCB0aGUgbWFuYWdlbWVudCBwcm90b2NvbCBuZWVk cyB0byBzaWduYWwgKGluIGl0cyB5YW5nIGxpYnJhcnkpIHdoaWNoIHBhcnRzIGFyZSBlcGhlbWVy YWwuPGJyPgo8YnI+CldoeSB0aGUgc2Vjb25kIHJlcXVpcmVtZW50PyZuYnNwOyBJZiB0aGUgZGF0 YSBtb2RlbCBpcyBzdXBwb3J0ZWQsIGFuZCB0aGUgZGF0YSBtb2RlbCBzdGF0ZXMgdGhhdCBjZXJ0 YWluIGl0ZW1zIGFyZSBlcGhlbWVyYWwsIHdoYXQgd291bGQgaXQgbWVhbiBpZiB0aGUgc2lnbmFs aW5nIGRpZCBub3QgYWxzbyBzYXkgdGhhdC4mbmJzcDsgQ29udmVyc2VseSwgd2hhdCB3b3VsZCBp dCBtZWFuIGlmIHRoZSBzaWduYWxpbmcgc2FpZCBzb21ldGhpbmcgd2FzIGVwaGVtZXJhbCB0aGF0 IHRoZSBtb2RlbCBkb2VzIG5vdCBkZWZpbmUgYXMgZXBoZW1lcmFsPzxicj4KPGJyPgpJdCBtYXkg YmUgdGhhdCBJIGFtIG1pc3JlYWRpbmcgYnVsbGV0IDYuJm5ic3A7IFBsZWFzZSBleHBsYWluLjxi cj4KPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkkg dGhpbmsgeW91IGFyZSBjb3JyZWN0IHRoYXQgdGhlIFlBTkcgbGlicmFyeSBkb2VzIG5vdCBuZWVk IGFueSBjaGFuZ2VzPC9kaXY+PGRpdj50byBpZGVudGlmeSBlcGhlbWVyYWwgZGF0YS4mbmJzcDsg T25seSB0aGUgdmFyaWFibGUgY29tcG9uZW50cyBvZjwvZGl2PjxkaXY+WUFORyBjb25mb3JtYW5j ZSBhcmUgY29udGFpbmVkIGluIHRoZSBsaWJyYXJ5LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgpU aGFuayB5b3UsPGJyPgpKb2VsPGJyPgo8YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+QW5keTwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+Cl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPgppMnJzIG1haWxpbmcgbGlzdDxicj4KPGEgaHJl Zj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pMnJzQGlldGYub3JnPC9h Pjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJz IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2kycnM8L2E+PGJyPgo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2 PjwvZGl2Pgo8L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_2010411323284380-- From nobody Mon May 9 16:11:12 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DC212D0A2 for ; Mon, 9 May 2016 16:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGoypmIGKt_I for ; Mon, 9 May 2016 16:11:06 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 5F23D12D097 for ; Mon, 9 May 2016 16:11:06 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id u64so217452150lff.3 for ; Mon, 09 May 2016 16:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HaStY+pNmp4LwkTkcVWBirbt5QHJ0zf5ZVqTC3h6q9U=; b=c2uLHFF/QB9JoT63RFY4DyfTrUqImX0FN11btReP7TIW7K9wi0TlS2kp2NHFvO+7NC JF/aX/Ai6+lHXpvVtKVHxPHzJhGV0RehBpbuoCZxkRADdyvxEpTVH1+sPQUGdaAg5dKo 7GQqqim4rT2QeoeWKc3ICueB8wS4KBKO8funutwwNpQotyHdqyQjVC74+KMRnOjHkzKa Q8o4qlicy9p83jaff6C6c8szbZqZgH+nihW8SbZHwP8QAKzK1bho1nlLJHgSSjkmGbvC +3tja/0DDWkd2W0vC4D51UuXIrPiMH8p2/vTEPCIcT2z9XLG4EHPYVHL5OFy60OcNOWw ZRiA== 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; bh=HaStY+pNmp4LwkTkcVWBirbt5QHJ0zf5ZVqTC3h6q9U=; b=PtSOpj+MwUR1RUpHPfSpLcXfBWr8SOY2LPfA0bfwnp8NlztdpkvxlWZQk4do2tqfYy b8Tg+Pqdyp33UGKE8yW6/qctBQJ3trAEbTAmfBDEAAWvj6M32gNN0UQxSK9n4ey0rgen lwY/jy9u4aDBGnxVJ6f31OP3vWZyuhGuhivRgtfU0DS2u1LLg44QDXARif3C/z42ULqe QEC3ajdJyRFmeMhxtfTd6HA+SKLNYVr7lIYt1qj1hK4yXyzKhRyXxvg9e5x1fQoNhydp GsQGXowgLdCt5miF+7nlGRrl1WAla1EBRFJ1s1oYoR1XuYanAy5qeQm9/+njsht+nfAZ G2Xw== X-Gm-Message-State: AOPr4FW7XXPoMajTFGCiftjLa/Dn7RZxQm/fKrW5VKbd8SZr/xVkQyu1P4KhpYlWC6zeMRXPKZXBvLUPPXwkow== MIME-Version: 1.0 X-Received: by 10.112.144.168 with SMTP id sn8mr15410376lbb.65.1462835464559; Mon, 09 May 2016 16:11:04 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Mon, 9 May 2016 16:11:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2016 16:11:04 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=047d7b343ef43afa3c053270ec07 Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Netconf Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:11:10 -0000 --047d7b343ef43afa3c053270ec07 Content-Type: text/plain; charset=UTF-8 On Mon, May 9, 2016 at 3:09 PM, Susan Hares wrote: > Andy and Joel: > > These are good points. > > What happens if the data model has some ephemeral sections and the I2RS > agent is not supported by the routing system. The data model would specify > the ephemeral section, but there would be no support by i2rs. Is the > support of the ephemeral not a variable condition to be indicated in Yang > module library? > > The server should have a deviations file for the parts it does not support. deviation /some/ephemeral/node { deviate delete { i2rs:ephemeral; } } Sue > Andy > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/7/2016 12:53 PM (GMT-05:00) > To: "Joel M. Halpern" > Cc: i2rs@ietf.org, Netconf , Susan Hares < > shares@ndzh.com> > Subject: Re: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern > wrote: > >> Reading the latest revision, in section 3.1.1, the text in bullet 5 says >> that the data model indicates which portions are ephemeral. That makes >> sense to me. >> >> Then bullet 6 says that the management protocol needs to signal (in its >> yang library) which parts are ephemeral. >> >> Why the second requirement? If the data model is supported, and the data >> model states that certain items are ephemeral, what would it mean if the >> signaling did not also say that. Conversely, what would it mean if the >> signaling said something was ephemeral that the model does not define as >> ephemeral? >> >> It may be that I am misreading bullet 6. Please explain. >> >> > > I think you are correct that the YANG library does not need any changes > to identify ephemeral data. Only the variable components of > YANG conformance are contained in the library. > > > Thank you, >> Joel >> >> > > Andy > > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > --047d7b343ef43afa3c053270ec07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 9, 2016 at 3:09 PM, Susan Hares <shares@ndzh.com> wrote:
Andy and Joel:
=

These are good points.

What ha= ppens if the data model has some ephemeral sections and the I2RS agent is n= ot supported by the routing system.=C2=A0 The data model would specify the = ephemeral section, but there would be no support by i2rs.=C2=A0 Is the supp= ort of the ephemeral not a variable =C2=A0condition to be indicated in Yang= module library?


The server should have a deviations file for the parts it does not support= .

=C2=A0 =C2=A0deviation /some/ephemeral/node {
=C2=A0 =C2=A0 =C2=A0 deviate delete {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0i2rs:ephemeral;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0}


Sue


Andy

=C2=A0
Sent via= the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
-------- Original message -------= -
From: Andy Bierman <andy@yumaworks.com>
Date: 5/7/2016 12:53= PM (GMT-05:00)
To: "Joel M. Halpern" <jmh@joelhalpern.com> <= /div>
Cc: i2rs@ietf.= org, Netconf <= netconf@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [i2rs] = FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt = - 3.1.1



On Fri, May 6, 2016 at 8:51 AM, Joel= M. Halpern <jmh@joelhalpern.com> wrote:
Reading the latest revision, in section 3.1.1, the text in= bullet 5 says that the data model indicates which portions are ephemeral.= =C2=A0 That makes sense to me.

Then bullet 6 says that the management protocol needs to signal (in its yan= g library) which parts are ephemeral.

Why the second requirement?=C2=A0 If the data model is supported, and the d= ata model states that certain items are ephemeral, what would it mean if th= e signaling did not also say that.=C2=A0 Conversely, what would it mean if = the signaling said something was ephemeral that the model does not define a= s ephemeral?

It may be that I am misreading bullet 6.=C2=A0 Please explain.



I think you are correct= that the YANG library does not need any changes
to identify ephe= meral data.=C2=A0 Only the variable components of
YANG conformanc= e are contained in the library.


Thank you,
Joel



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


--047d7b343ef43afa3c053270ec07-- From nobody Mon May 9 16:24:49 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ACA12B05D; Mon, 9 May 2016 16:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ7MBTyz5noD; Mon, 9 May 2016 16:24:43 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 C909E12D156; Mon, 9 May 2016 16:24:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.172.62.119; Date: Mon, 09 May 2016 19:24:25 -0400 Message-ID: Importance: normal From: Susan Hares To: Andy Bierman MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_2017789250749970" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Netconf Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:24:46 -0000 ----_com.samsung.android.email_2017789250749970 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QW5keQpHcmVhdC4gwqBUaGlzIHNvbHZlcyB0aGUgTm90dGluZ2hhbSBidWx0IGZvciBpMnJzLiDC oERvZXMgdGhlIHNhbWUgZGV2aWF0aW9uIHdvcmsgZm9yIGkycnMgaW5jbHVkZWQgYnV0IGNvbmZp Z3VyZWQgb2ZmLgpTdWUKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFU JlQgNEcgTFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJv bTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IERhdGU6IDUvOS8yMDE2ICA3OjEx IFBNICAoR01ULTA1OjAwKSBUbzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4gQ2M6IGky cnNAaWV0Zi5vcmcsICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiwgTmV0 Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4gU3ViamVjdDogUmU6IFtpMnJzXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJzLXByb3RvY29sLXN0cmF3bWFuLTAy LnR4dCAtIDMuMS4xIAoKCk9uIE1vbiwgTWF5IDksIDIwMTYgYXQgMzowOSBQTSwgU3VzYW4gSGFy ZXMgPHNoYXJlc0BuZHpoLmNvbT4gd3JvdGU6CkFuZHkgYW5kIEpvZWw6ClRoZXNlIGFyZSBnb29k IHBvaW50cy4KV2hhdCBoYXBwZW5zIGlmIHRoZSBkYXRhIG1vZGVsIGhhcyBzb21lIGVwaGVtZXJh bCBzZWN0aW9ucyBhbmQgdGhlIEkyUlMgYWdlbnQgaXMgbm90IHN1cHBvcnRlZCBieSB0aGUgcm91 dGluZyBzeXN0ZW0uwqAgVGhlIGRhdGEgbW9kZWwgd291bGQgc3BlY2lmeSB0aGUgZXBoZW1lcmFs IHNlY3Rpb24sIGJ1dCB0aGVyZSB3b3VsZCBiZSBubyBzdXBwb3J0IGJ5IGkycnMuwqAgSXMgdGhl IHN1cHBvcnQgb2YgdGhlIGVwaGVtZXJhbCBub3QgYSB2YXJpYWJsZSDCoGNvbmRpdGlvbiB0byBi ZSBpbmRpY2F0ZWQgaW4gWWFuZyBtb2R1bGUgbGlicmFyeT8KClRoZSBzZXJ2ZXIgc2hvdWxkIGhh dmUgYSBkZXZpYXRpb25zIGZpbGUgZm9yIHRoZSBwYXJ0cyBpdCBkb2VzIG5vdCBzdXBwb3J0LgrC oCDCoGRldmlhdGlvbiAvc29tZS9lcGhlbWVyYWwvbm9kZSB7wqAgwqAgwqAgZGV2aWF0ZSBkZWxl dGUge8KgIMKgIMKgIMKgIMKgaTJyczplcGhlbWVyYWw7wqAgwqAgwqAgfcKgIMKgfQoKU3VlCgpB bmR5CsKgU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZUIDRHIExURSBz bWFydHBob25lLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiBEYXRlOiA1LzcvMjAxNiAgMTI6NTMgUE0gIChHTVQt MDU6MDApIFRvOiAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gQ2M6IGky cnNAaWV0Zi5vcmcsIE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+LCBTdXNhbiBIYXJlcyA8c2hh cmVzQG5kemguY29tPiBTdWJqZWN0OiBSZTogW2kycnNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWhhcmVzLWkycnMtcHJvdG9jb2wtc3RyYXdtYW4tMDIudHh0IC0gMy4x LjEgCgoKT24gRnJpLCBNYXkgNiwgMjAxNiBhdCA4OjUxIEFNLCBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb20+IHdyb3RlOgpSZWFkaW5nIHRoZSBsYXRlc3QgcmV2aXNpb24sIGlu IHNlY3Rpb24gMy4xLjEsIHRoZSB0ZXh0IGluIGJ1bGxldCA1IHNheXMgdGhhdCB0aGUgZGF0YSBt b2RlbCBpbmRpY2F0ZXMgd2hpY2ggcG9ydGlvbnMgYXJlIGVwaGVtZXJhbC7CoCBUaGF0IG1ha2Vz IHNlbnNlIHRvIG1lLgoKCgpUaGVuIGJ1bGxldCA2IHNheXMgdGhhdCB0aGUgbWFuYWdlbWVudCBw cm90b2NvbCBuZWVkcyB0byBzaWduYWwgKGluIGl0cyB5YW5nIGxpYnJhcnkpIHdoaWNoIHBhcnRz IGFyZSBlcGhlbWVyYWwuCgoKCldoeSB0aGUgc2Vjb25kIHJlcXVpcmVtZW50P8KgIElmIHRoZSBk YXRhIG1vZGVsIGlzIHN1cHBvcnRlZCwgYW5kIHRoZSBkYXRhIG1vZGVsIHN0YXRlcyB0aGF0IGNl cnRhaW4gaXRlbXMgYXJlIGVwaGVtZXJhbCwgd2hhdCB3b3VsZCBpdCBtZWFuIGlmIHRoZSBzaWdu YWxpbmcgZGlkIG5vdCBhbHNvIHNheSB0aGF0LsKgIENvbnZlcnNlbHksIHdoYXQgd291bGQgaXQg bWVhbiBpZiB0aGUgc2lnbmFsaW5nIHNhaWQgc29tZXRoaW5nIHdhcyBlcGhlbWVyYWwgdGhhdCB0 aGUgbW9kZWwgZG9lcyBub3QgZGVmaW5lIGFzIGVwaGVtZXJhbD8KCgoKSXQgbWF5IGJlIHRoYXQg SSBhbSBtaXNyZWFkaW5nIGJ1bGxldCA2LsKgIFBsZWFzZSBleHBsYWluLgoKCgoKSSB0aGluayB5 b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgWUFORyBsaWJyYXJ5IGRvZXMgbm90IG5lZWQgYW55IGNo YW5nZXN0byBpZGVudGlmeSBlcGhlbWVyYWwgZGF0YS7CoCBPbmx5IHRoZSB2YXJpYWJsZSBjb21w b25lbnRzIG9mWUFORyBjb25mb3JtYW5jZSBhcmUgY29udGFpbmVkIGluIHRoZSBsaWJyYXJ5LgoK ClRoYW5rIHlvdSwKCkpvZWwKCgoKCkFuZHnCoApfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwoKaTJycyBtYWlsaW5nIGxpc3QKCmkycnNAaWV0Zi5vcmcKCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycwoKCgoKCg== ----_com.samsung.android.email_2017789250749970 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkFuZHk8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PkdyZWF0LiAmbmJzcDtUaGlzIHNvbHZlcyB0aGUgTm90dGluZ2hhbSBidWx0 IGZvciBpMnJzLiAmbmJzcDtEb2VzIHRoZSBzYW1lIGRldmlhdGlvbiB3b3JrIGZvciBpMnJzIGlu Y2x1ZGVkIGJ1dCBjb25maWd1cmVkIG9mZi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlN1ZTwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9 ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1 NzU3Ij5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJmFtcDtUIDRHIExU RSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6 IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBt ZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVt YXdvcmtzLmNvbSZndDsgPC9kaXY+PGRpdj5EYXRlOiA1LzkvMjAxNiAgNzoxMSBQTSAgKEdNVC0w NTowMCkgPC9kaXY+PGRpdj5UbzogU3VzYW4gSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDsg PC9kaXY+PGRpdj5DYzogaTJyc0BpZXRmLm9yZywgIkpvZWwgTS4gSGFscGVybiIgJmx0O2ptaEBq b2VsaGFscGVybi5jb20mZ3Q7LCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OyA8L2Rp dj48ZGl2PlN1YmplY3Q6IFJlOiBbaTJyc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaGFyZXMtaTJycy1wcm90b2NvbC1zdHJhd21hbi0wMi50eHQgLSAzLjEuMSA8L2Rp dj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PGRpdiBjbGFzcz0iZ21h aWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBNYXkgOSwgMjAx NiBhdCAzOjA5IFBNLCBTdXNhbiBIYXJlcyA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1h aWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5zaGFyZXNAbmR6aC5jb208L2E+ Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPjxkaXY+PGRpdj5BbmR5IGFuZCBKb2VsOjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+VGhlc2UgYXJlIGdvb2QgcG9pbnRzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+V2hhdCBo YXBwZW5zIGlmIHRoZSBkYXRhIG1vZGVsIGhhcyBzb21lIGVwaGVtZXJhbCBzZWN0aW9ucyBhbmQg dGhlIEkyUlMgYWdlbnQgaXMgbm90IHN1cHBvcnRlZCBieSB0aGUgcm91dGluZyBzeXN0ZW0uJm5i c3A7IFRoZSBkYXRhIG1vZGVsIHdvdWxkIHNwZWNpZnkgdGhlIGVwaGVtZXJhbCBzZWN0aW9uLCBi dXQgdGhlcmUgd291bGQgYmUgbm8gc3VwcG9ydCBieSBpMnJzLiZuYnNwOyBJcyB0aGUgc3VwcG9y dCBvZiB0aGUgZXBoZW1lcmFsIG5vdCBhIHZhcmlhYmxlICZuYnNwO2NvbmRpdGlvbiB0byBiZSBp bmRpY2F0ZWQgaW4gWWFuZyBtb2R1bGUgbGlicmFyeT88L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgc2VydmVyIHNob3VsZCBoYXZl IGEgZGV2aWF0aW9ucyBmaWxlIGZvciB0aGUgcGFydHMgaXQgZG9lcyBub3Qgc3VwcG9ydC48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PiZuYnNwOyAmbmJzcDtkZXZpYXRpb24gL3NvbWUvZXBoZW1l cmFsL25vZGUgezwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZGV2aWF0ZSBkZWxldGUg ezwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2kycnM6ZXBoZW1l cmFsOzwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfTwvZGl2PjxkaXY+Jm5ic3A7ICZu YnNwO308L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2PjxkaXY+PC9kaXY+PGRpdj5TdWU8L2Rp dj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5B bmR5PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2PjxkaXY+PGRpdiBzdHlsZT0iZm9udC1z aXplOjg1JTtjb2xvcjojNTc1NzU3Ij5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUs IGFuIEFUJmFtcDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9u dC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdl IC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208 L2E+Jmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDUvNy8yMDE2ICAxMjo1MyBQTSAgKEdNVC0wNTowMCkg PC9kaXY+PGRpdj5UbzogIkpvZWwgTS4gSGFscGVybiIgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4m Z3Q7IDwvZGl2PjxkaXY+Q2M6IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aTJyc0BpZXRmLm9yZzwvYT4sIE5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpu ZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mZ3Q7 LCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7IDwvZGl2PjxkaXY+U3ViamVjdDogUmU6 IFtpMnJzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJz LXByb3RvY29sLXN0cmF3bWFuLTAyLnR4dCAtIDMuMS4xIDwvZGl2PjxkaXY+PGJyPjwvZGl2Pjwv ZGl2PjxkaXYgZGlyPSJsdHIiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIE1heSA2LCAyMDE2IGF0IDg6NTEgQU0sIEpvZWwg TS4gSGFscGVybiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PC9z cGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+UmVhZGluZyB0aGUgbGF0ZXN0IHJldmlzaW9uLCBpbiBzZWN0aW9uIDMuMS4xLCB0aGUgdGV4 dCBpbiBidWxsZXQgNSBzYXlzIHRoYXQgdGhlIGRhdGEgbW9kZWwgaW5kaWNhdGVzIHdoaWNoIHBv cnRpb25zIGFyZSBlcGhlbWVyYWwuJm5ic3A7IFRoYXQgbWFrZXMgc2Vuc2UgdG8gbWUuPGJyPgo8 YnI+ClRoZW4gYnVsbGV0IDYgc2F5cyB0aGF0IHRoZSBtYW5hZ2VtZW50IHByb3RvY29sIG5lZWRz IHRvIHNpZ25hbCAoaW4gaXRzIHlhbmcgbGlicmFyeSkgd2hpY2ggcGFydHMgYXJlIGVwaGVtZXJh bC48YnI+Cjxicj4KV2h5IHRoZSBzZWNvbmQgcmVxdWlyZW1lbnQ/Jm5ic3A7IElmIHRoZSBkYXRh IG1vZGVsIGlzIHN1cHBvcnRlZCwgYW5kIHRoZSBkYXRhIG1vZGVsIHN0YXRlcyB0aGF0IGNlcnRh aW4gaXRlbXMgYXJlIGVwaGVtZXJhbCwgd2hhdCB3b3VsZCBpdCBtZWFuIGlmIHRoZSBzaWduYWxp bmcgZGlkIG5vdCBhbHNvIHNheSB0aGF0LiZuYnNwOyBDb252ZXJzZWx5LCB3aGF0IHdvdWxkIGl0 IG1lYW4gaWYgdGhlIHNpZ25hbGluZyBzYWlkIHNvbWV0aGluZyB3YXMgZXBoZW1lcmFsIHRoYXQg dGhlIG1vZGVsIGRvZXMgbm90IGRlZmluZSBhcyBlcGhlbWVyYWw/PGJyPgo8YnI+Ckl0IG1heSBi ZSB0aGF0IEkgYW0gbWlzcmVhZGluZyBidWxsZXQgNi4mbmJzcDsgUGxlYXNlIGV4cGxhaW4uPGJy Pgo8YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSB0 aGluayB5b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgWUFORyBsaWJyYXJ5IGRvZXMgbm90IG5lZWQg YW55IGNoYW5nZXM8L2Rpdj48ZGl2PnRvIGlkZW50aWZ5IGVwaGVtZXJhbCBkYXRhLiZuYnNwOyBP bmx5IHRoZSB2YXJpYWJsZSBjb21wb25lbnRzIG9mPC9kaXY+PGRpdj5ZQU5HIGNvbmZvcm1hbmNl IGFyZSBjb250YWluZWQgaW4gdGhlIGxpYnJhcnkuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ClRo YW5rIHlvdSw8YnI+CkpvZWw8YnI+Cjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5BbmR5PC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+CmkycnMgbWFpbGluZyBsaXN0PGJyPgo8YSBocmVm PSJtYWlsdG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkycnNAaWV0Zi5vcmc8L2E+ PGJyPgo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaTJyczwvYT48YnI+CjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+ PC9kaXY+CjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+CjwvYm9keT48 L2h0bWw+ ----_com.samsung.android.email_2017789250749970-- From nobody Mon May 9 16:32:09 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A8E12D185 for ; Mon, 9 May 2016 16:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acw8BRf90Vko for ; Mon, 9 May 2016 16:32:02 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A974612B05D for ; Mon, 9 May 2016 16:32:01 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id y84so217913782lfc.0 for ; Mon, 09 May 2016 16:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/TRR8u5JSGFkTJmxtpyZf2/VHiFl7Thz/eB6zlPwXbc=; b=KQlrnDrfQ6KlhPWu1xGsVonrrFEALVHaArRsS7A7XyTujf1YioYGiobmwEKkbJkkO6 mti3lwO+Trio1Sy7l5gjvVHHP9XGRsu9LyJZgl3foZf543he8B0V6Og7eAkQYS7E43cv TxZu0HEBZIRsq5BM5BCRQTVcDIyGWZ6WMafUIGWlvVjjVsX4+xR5NJsblOkjQHxWJmbl /Hvdwg5jqEreS0LRQ6eHzM+CAi/dVu4HWwYtE2DbfUkMMUbP4rkzBA+cFp/uaKMWRGj1 eneUYuEP9YS1sOxGuc0Xnt/8MBBfO91fsxIYXPKYVaRgg+GSCeVmJU+8RiaemDOa1vVE q2Hw== 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; bh=/TRR8u5JSGFkTJmxtpyZf2/VHiFl7Thz/eB6zlPwXbc=; b=USFs5df+gl+CC/KIxKLCZCP9YwGrXBHubB1eakOF6Pfj74hhWdNZJQ6SqgDHMztnYG PdUpCqepnOOJkxB4R1dxV6BEwXnusRVlAW7hZgvaCvu0Py745r3sak+Dvk1VB2nIhc6m aX3X1sToEDzXhfQj3a+CiLrtFE0NQHRQk3YIgJ6oC3XEMQyBvQB3vXmzr8sxRHtCQSE0 +jcQG3+4Rmooy8Z4m0aHj5pnCNfi870Q51pegsSf1dMUF9k6E/5BouXx1KYt8KBN5di+ wRvJxjMGJ5iqBpcPH3GSaui1gbmLCkowSzb+JlWPCR/YEm5/n2PTlot66lbOqVMaRWtL 6LPw== X-Gm-Message-State: AOPr4FVZipvdeYp5AIXQIHZAhEWY6AVl81kicjjsiF5DJGnurdMfhLScf6A7jeA/eujV+jbE/j+oRlq2BRN/9w== MIME-Version: 1.0 X-Received: by 10.112.184.79 with SMTP id es15mr15373089lbc.30.1462836719942; Mon, 09 May 2016 16:31:59 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Mon, 9 May 2016 16:31:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2016 16:31:59 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a1133ac900e996a053271379f Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Netconf Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:32:05 -0000 --001a1133ac900e996a053271379f Content-Type: text/plain; charset=UTF-8 On Mon, May 9, 2016 at 4:24 PM, Susan Hares wrote: > Andy > > Great. This solves the Nottingham bult for i2rs. Does the same deviation > work for i2rs included but configured off. > > I don't understand the point of specifying this property in the YANG module if the operator is allowed to configure it on/off. Deviations alter the schema definition. Configuration alters instances of the data. IMO I2RS does not need such complex configuration. Access control can be used to configure I2RS on or off on specific data nodes. Sue > > Andy > > > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/9/2016 7:11 PM (GMT-05:00) > To: Susan Hares > Cc: i2rs@ietf.org, "Joel M. Halpern" , Netconf < > netconf@ietf.org> > Subject: Re: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Mon, May 9, 2016 at 3:09 PM, Susan Hares wrote: > >> Andy and Joel: >> >> These are good points. >> >> What happens if the data model has some ephemeral sections and the I2RS >> agent is not supported by the routing system. The data model would specify >> the ephemeral section, but there would be no support by i2rs. Is the >> support of the ephemeral not a variable condition to be indicated in Yang >> module library? >> >> > The server should have a deviations file for the parts it does not support. > > deviation /some/ephemeral/node { > deviate delete { > i2rs:ephemeral; > } > } > > > Sue >> > > > Andy > > > >> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone >> -------- Original message -------- >> From: Andy Bierman >> Date: 5/7/2016 12:53 PM (GMT-05:00) >> To: "Joel M. Halpern" >> Cc: i2rs@ietf.org, Netconf , Susan Hares < >> shares@ndzh.com> >> Subject: Re: [i2rs] FW: New Version Notification for >> draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 >> >> >> >> On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern >> wrote: >> >>> Reading the latest revision, in section 3.1.1, the text in bullet 5 says >>> that the data model indicates which portions are ephemeral. That makes >>> sense to me. >>> >>> Then bullet 6 says that the management protocol needs to signal (in its >>> yang library) which parts are ephemeral. >>> >>> Why the second requirement? If the data model is supported, and the >>> data model states that certain items are ephemeral, what would it mean if >>> the signaling did not also say that. Conversely, what would it mean if the >>> signaling said something was ephemeral that the model does not define as >>> ephemeral? >>> >>> It may be that I am misreading bullet 6. Please explain. >>> >>> >> >> I think you are correct that the YANG library does not need any changes >> to identify ephemeral data. Only the variable components of >> YANG conformance are contained in the library. >> >> >> Thank you, >>> Joel >>> >>> >> >> Andy >> >> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> > --001a1133ac900e996a053271379f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 9, 2016 at 4:24 PM, Susan Hares <shares@ndzh.com> wrote:
Andy

<= /div>
Great.=C2=A0 This solves the Nottingham bult for i2rs.=C2=A0 Does= the same deviation work for i2rs included but configured off.

I don't understand the p= oint of specifying this property in the YANG module
if the operat= or is allowed to configure it on/off.

Deviations a= lter the schema definition.
Configuration alters instances of the= data.

IMO I2RS does not need such complex configu= ration.
Access control can be used to configure I2RS on or off on= specific data nodes.



Sue



Andy
=C2=A0


=
Sent via the Samsung = Galaxy Note5, an AT&T 4G LTE smartphone
-------- Original message --------
F= rom: Andy Bierman <andy@yumaworks.com>
Date: 5/9/2016 7:11 PM (GMT-05:0= 0)
To: Susan Hares <shares@ndzh.com>
Cc: i2rs@ietf.org, "Joel M. Halpern" &= lt;jmh@joelhalpern= .com>, Netconf <netconf@ietf.org>
Subject: Re: [i2rs] FW: New Versio= n Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1
=



On Mon, May 9, 2016 at 3:09 PM, Susan Hares <shares= @ndzh.com> wrote:
Andy and Joel:

These are good points.
=
What happens if the data model has some ephemeral sections a= nd the I2RS agent is not supported by the routing system.=C2=A0 The data mo= del would specify the ephemeral section, but there would be no support by i= 2rs.=C2=A0 Is the support of the ephemeral not a variable =C2=A0condition t= o be indicated in Yang module library?


The server should have a deviations file for the par= ts it does not support.

=C2=A0 =C2=A0deviation /so= me/ephemeral/node {
=C2=A0 =C2=A0 =C2=A0 deviate delete {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i2rs:ephemeral;
=C2=A0 =C2= =A0 =C2=A0 }
=C2=A0 =C2=A0}


Sue


Andy

=C2=A0<= /div>
Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartph= one
-------- Or= iginal message --------
From: Andy Bierman <andy@yumaworks.com>
Date: 5/7/2016 12:53 PM (GMT-05:00)
To: "Joel M. Halpern= " <jmh@joe= lhalpern.com>
Cc: i2rs@ietf.org, Netconf <netconf@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-pro= tocol-strawman-02.txt - 3.1.1

<= br>

On Fri, May 6,= 2016 at 8:51 AM, Joel M. Halpern <jmh@joelhalpern.com> wr= ote:
Reading the latest revision, in sect= ion 3.1.1, the text in bullet 5 says that the data model indicates which po= rtions are ephemeral.=C2=A0 That makes sense to me.

Then bullet 6 says that the management protocol needs to signal (in its yan= g library) which parts are ephemeral.

Why the second requirement?=C2=A0 If the data model is supported, and the d= ata model states that certain items are ephemeral, what would it mean if th= e signaling did not also say that.=C2=A0 Conversely, what would it mean if = the signaling said something was ephemeral that the model does not define a= s ephemeral?

It may be that I am misreading bullet 6.=C2=A0 Please explain.



I think you are correct= that the YANG library does not need any changes
to identify ephe= meral data.=C2=A0 Only the variable components of
YANG conformanc= e are contained in the library.


Thank you,
Joel



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



--001a1133ac900e996a053271379f-- From nobody Mon May 9 22:34:37 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368D912B004; Mon, 9 May 2016 22:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4kujqMjCMVl; Mon, 9 May 2016 22:34:32 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2544F12B02C; Mon, 9 May 2016 22:34:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0BD70245B51; Mon, 9 May 2016 22:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462858472; bh=BZ5jwnwqHBBu3dnaG4A08SvLTOSrdDvY1Frp39O01XA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=GNwvaXRqqFwqvtFfG6qrlMy7rFgL41aeFAdD/mPS7MVxpd988y7icq5FoZJnbqDpl GNTEXlgy5PSFROW9MPGSkA0+iQrPsDrUIbAIDoPgs3Rsuku/X5So3YjpXQ6CK7deqd QAgr0qYxZ219Evq2jWwV+iW2DUx1CWLKcuOcWBrI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [88.131.14.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 313C82409E3; Mon, 9 May 2016 22:34:20 -0700 (PDT) To: Susan Hares , Andy Bierman References: From: "Joel M. Halpern" Message-ID: <0fa49ba0-0a56-21fb-4878-e95adfcd1b49@joelhalpern.com> Date: Tue, 10 May 2016 01:34:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 05:34:34 -0000 As I understand it, if a model requires ephemeral elements, and the agent does not support ephemeral, then the agent can not claim to support the model. Yes, deviations allow you to specify this, as Andy says. But this is specifying a failure to conform. I would go far as to say that such an agent is not an I2RS agent, but that is a step beyond the NetConf compliance definitions. Yours, Joel On 5/9/16 6:09 PM, Susan Hares wrote: > Andy and Joel: > > These are good points. > > What happens if the data model has some ephemeral sections and the I2RS > agent is not supported by the routing system. The data model would > specify the ephemeral section, but there would be no support by i2rs. > Is the support of the ephemeral not a variable condition to be > indicated in Yang module library? > > Sue > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/7/2016 12:53 PM (GMT-05:00) > To: "Joel M. Halpern" > Cc: i2rs@ietf.org, Netconf , Susan Hares > > Subject: Re: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern > wrote: > > Reading the latest revision, in section 3.1.1, the text in bullet 5 > says that the data model indicates which portions are ephemeral. > That makes sense to me. > > Then bullet 6 says that the management protocol needs to signal (in > its yang library) which parts are ephemeral. > > Why the second requirement? If the data model is supported, and the > data model states that certain items are ephemeral, what would it > mean if the signaling did not also say that. Conversely, what would > it mean if the signaling said something was ephemeral that the model > does not define as ephemeral? > > It may be that I am misreading bullet 6. Please explain. > > > > I think you are correct that the YANG library does not need any changes > to identify ephemeral data. Only the variable components of > YANG conformance are contained in the library. > > > Thank you, > Joel > > > > Andy > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Tue May 10 04:25:38 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA6E12B045; Tue, 10 May 2016 04:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbgRcceaKjzE; Tue, 10 May 2016 04:25:35 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 48F6312B03A; Tue, 10 May 2016 04:25:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.91.193.41; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Andy Bierman'" References: <0fa49ba0-0a56-21fb-4878-e95adfcd1b49@joelhalpern.com> In-Reply-To: <0fa49ba0-0a56-21fb-4878-e95adfcd1b49@joelhalpern.com> Date: Tue, 10 May 2016 07:25:29 -0400 Message-ID: <000301d1aaae$aa9be570$ffd3b050$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIojh5uyd+OkF1XWRDRkYAVtqAd8AKJO+xTnu/28RA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Netconf' Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 11:25:38 -0000 Joel:=20 What happens if the code supports the I2RS agent, but the I2RS agent is = configured to be "off"? Is this covered by the deviations or is this = variable configuration?=20 Sue=20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, May 10, 2016 1:34 AM To: Susan Hares; Andy Bierman Cc: i2rs@ietf.org; Netconf Subject: Re: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 As I understand it, if a model requires ephemeral elements, and the = agent does not support ephemeral, then the agent can not claim to = support the model. Yes, deviations allow you to specify this, as Andy says. But this is = specifying a failure to conform. I would go far as to say that such an agent is not an I2RS agent, but = that is a step beyond the NetConf compliance definitions. Yours, Joel On 5/9/16 6:09 PM, Susan Hares wrote: > Andy and Joel: > > These are good points. > > What happens if the data model has some ephemeral sections and the=20 > I2RS agent is not supported by the routing system. The data model=20 > would specify the ephemeral section, but there would be no support by = i2rs. > Is the support of the ephemeral not a variable condition to be=20 > indicated in Yang module library? > > Sue > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/7/2016 12:53 PM (GMT-05:00) > To: "Joel M. Halpern" > Cc: i2rs@ietf.org, Netconf , Susan Hares=20 > > Subject: Re: [i2rs] FW: New Version Notification for=20 > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern > wrote: > > Reading the latest revision, in section 3.1.1, the text in bullet = 5 > says that the data model indicates which portions are ephemeral. > That makes sense to me. > > Then bullet 6 says that the management protocol needs to signal = (in > its yang library) which parts are ephemeral. > > Why the second requirement? If the data model is supported, and = the > data model states that certain items are ephemeral, what would it > mean if the signaling did not also say that. Conversely, what = would > it mean if the signaling said something was ephemeral that the = model > does not define as ephemeral? > > It may be that I am misreading bullet 6. Please explain. > > > > I think you are correct that the YANG library does not need any=20 > changes to identify ephemeral data. Only the variable components of=20 > YANG conformance are contained in the library. > > > Thank you, > Joel > > > > Andy > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Tue May 10 05:11:53 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA68212B031; Tue, 10 May 2016 05:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUOCfpqrzUeR; Tue, 10 May 2016 05:11:47 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE8E12D0C1; Tue, 10 May 2016 05:11:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A4EE9240C4F; Tue, 10 May 2016 05:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462882306; bh=h4ROFC1g3Mgm2/06PBzIdGUSon+UdC4fEmy+cG4v68k=; h=Date:Subject:From:To:Cc:From; b=gqaqoLhhuQyNNzBKU/DS0eYBqzHb7pspBFT7vXOi0kSuodm1M+q2giw10XsKY343Y UtQbWZU3skqNkVrsWTNRBHDJeXAAvvasXAXKDKhsW5hA2qSQNMstzTCkgGin+34ZAl MezKhfLFCnGX7NionF0HngMIHzyIjBOxOqSgvuBI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.148.56.111] (sessfw99-sesbfw99-95.ericsson.net [192.176.1.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 618C02409E3; Tue, 10 May 2016 05:11:45 -0700 (PDT) Date: Tue, 10 May 2016 14:11:41 +0200 Message-ID: <7eqdbrhnm368w3aqvlarweoi.1462882301561@email.android.com> Importance: normal From: "jmh.direct" To: Susan Hares , "'Joel M. Halpern'" , 'Andy Bierman' MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_934795023916920" Archived-At: Cc: i2rs@ietf.org, 'Netconf' Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 12:11:48 -0000 ----_com.samsung.android.email_934795023916920 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SWYgdGhlIEkyUlMgYXJlbid0IGlzIG9mZiB0aGVuIHRoZSBzeXN0ZW0gZG9lcyBub3QgY3VycmVu dGx5IHN1cHBvcnQgdGhpcyBtb2RlbHMuIMKgVGhpcyBpcyBqdXN0IGxpa2UgYW55IG90aGVyIG9w dGlvbmFsIFlBTkcgbW9kdWxlLiDCoElmIHlvdSBhcmUgbm90IGN1cnJlbnRseSBwcmVwYXJlZCB0 byB1c2UgaXQsIHlvdSBkb24ndCBjbGFpbSB0byBzdXBwb3J0IGl0LgpDYXZlYXQ6IFRoZSBOZXRN b2QgZm9sa3MgbWF5IGhhdmUgY29tZSB1cCB3aXRoIGEgbW9yZSBudWFuY2VkIG1lY2hhbmlzbS4g wqAKWW91cnMsSm9lbAoKClNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQm VCA0RyBMVEUgc21hcnRwaG9uZS0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9t OiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPiBEYXRlOiA1LzEwLzIwMTYgIDE6MjUgUE0g IChHTVQrMDE6MDApIFRvOiAiJ0pvZWwgTS4gSGFscGVybiciIDxqbWhAam9lbGhhbHBlcm4uY29t PiwgJ0FuZHkgQmllcm1hbicgPGFuZHlAeXVtYXdvcmtzLmNvbT4gQ2M6IGkycnNAaWV0Zi5vcmcs ICdOZXRjb25mJyA8bmV0Y29uZkBpZXRmLm9yZz4gU3ViamVjdDogUkU6IFtpMnJzXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJzLXByb3RvY29sLXN0cmF3 bWFuLTAyLnR4dCAtIDMuMS4xIApKb2VsOiAKCldoYXQgaGFwcGVucyBpZiB0aGUgY29kZSBzdXBw b3J0cyB0aGUgSTJSUyBhZ2VudCwgYnV0IHRoZSBJMlJTIGFnZW50IGlzIGNvbmZpZ3VyZWQgdG8g YmUgIm9mZiI/wqAgSXMgdGhpcyBjb3ZlcmVkIGJ5IHRoZSBkZXZpYXRpb25zIG9yIGlzIHRoaXMg dmFyaWFibGUgY29uZmlndXJhdGlvbj8gCgpTdWUgCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSAKU2Vu dDogVHVlc2RheSwgTWF5IDEwLCAyMDE2IDE6MzQgQU0KVG86IFN1c2FuIEhhcmVzOyBBbmR5IEJp ZXJtYW4KQ2M6IGkycnNAaWV0Zi5vcmc7IE5ldGNvbmYKU3ViamVjdDogUmU6IFtpMnJzXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJzLXByb3RvY29sLXN0 cmF3bWFuLTAyLnR4dCAtIDMuMS4xCgpBcyBJIHVuZGVyc3RhbmQgaXQsIGlmIGEgbW9kZWwgcmVx dWlyZXMgZXBoZW1lcmFsIGVsZW1lbnRzLCBhbmQgdGhlIGFnZW50IGRvZXMgbm90IHN1cHBvcnQg ZXBoZW1lcmFsLCB0aGVuIHRoZSBhZ2VudCBjYW4gbm90IGNsYWltIHRvIHN1cHBvcnQgdGhlIG1v ZGVsLgoKWWVzLCBkZXZpYXRpb25zIGFsbG93IHlvdSB0byBzcGVjaWZ5IHRoaXMsIGFzIEFuZHkg c2F5cy7CoCBCdXQgdGhpcyBpcyBzcGVjaWZ5aW5nIGEgZmFpbHVyZSB0byBjb25mb3JtLgoKSSB3 b3VsZCBnbyBmYXIgYXMgdG8gc2F5IHRoYXQgc3VjaCBhbiBhZ2VudCBpcyBub3QgYW4gSTJSUyBh Z2VudCwgYnV0IHRoYXQgaXMgYSBzdGVwIGJleW9uZCB0aGUgTmV0Q29uZiBjb21wbGlhbmNlIGRl ZmluaXRpb25zLgoKWW91cnMsCkpvZWwKCk9uIDUvOS8xNiA2OjA5IFBNLCBTdXNhbiBIYXJlcyB3 cm90ZToKPiBBbmR5IGFuZCBKb2VsOgo+Cj4gVGhlc2UgYXJlIGdvb2QgcG9pbnRzLgo+Cj4gV2hh dCBoYXBwZW5zIGlmIHRoZSBkYXRhIG1vZGVsIGhhcyBzb21lIGVwaGVtZXJhbCBzZWN0aW9ucyBh bmQgdGhlIAo+IEkyUlMgYWdlbnQgaXMgbm90IHN1cHBvcnRlZCBieSB0aGUgcm91dGluZyBzeXN0 ZW0uwqAgVGhlIGRhdGEgbW9kZWwgCj4gd291bGQgc3BlY2lmeSB0aGUgZXBoZW1lcmFsIHNlY3Rp b24sIGJ1dCB0aGVyZSB3b3VsZCBiZSBubyBzdXBwb3J0IGJ5IGkycnMuCj7CoCBJcyB0aGUgc3Vw cG9ydCBvZiB0aGUgZXBoZW1lcmFsIG5vdCBhIHZhcmlhYmxlwqAgY29uZGl0aW9uIHRvIGJlIAo+ IGluZGljYXRlZCBpbiBZYW5nIG1vZHVsZSBsaWJyYXJ5Pwo+Cj4gU3VlCj4gU2VudCB2aWEgdGhl IFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lCj4gLS0tLS0t LS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQo+IEZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5 dW1hd29ya3MuY29tPgo+IERhdGU6IDUvNy8yMDE2IDEyOjUzIFBNIChHTVQtMDU6MDApCj4gVG86 ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPgo+IENjOiBpMnJzQGlldGYu b3JnLCBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgU3VzYW4gSGFyZXMgCj4gPHNoYXJlc0Bu ZHpoLmNvbT4KPiBTdWJqZWN0OiBSZTogW2kycnNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIAo+IGRyYWZ0LWhhcmVzLWkycnMtcHJvdG9jb2wtc3RyYXdtYW4tMDIudHh0IC0gMy4x LjEKPgo+Cj4KPiBPbiBGcmksIE1heSA2LCAyMDE2IGF0IDg6NTEgQU0sIEpvZWwgTS4gSGFscGVy biA8am1oQGpvZWxoYWxwZXJuLmNvbSAKPiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3 cm90ZToKPgo+wqDCoMKgwqAgUmVhZGluZyB0aGUgbGF0ZXN0IHJldmlzaW9uLCBpbiBzZWN0aW9u IDMuMS4xLCB0aGUgdGV4dCBpbiBidWxsZXQgNQo+wqDCoMKgwqAgc2F5cyB0aGF0IHRoZSBkYXRh IG1vZGVsIGluZGljYXRlcyB3aGljaCBwb3J0aW9ucyBhcmUgZXBoZW1lcmFsLgo+wqDCoMKgwqAg VGhhdCBtYWtlcyBzZW5zZSB0byBtZS4KPgo+wqDCoMKgwqAgVGhlbiBidWxsZXQgNiBzYXlzIHRo YXQgdGhlIG1hbmFnZW1lbnQgcHJvdG9jb2wgbmVlZHMgdG8gc2lnbmFsIChpbgo+wqDCoMKgwqAg aXRzIHlhbmcgbGlicmFyeSkgd2hpY2ggcGFydHMgYXJlIGVwaGVtZXJhbC4KPgo+wqDCoMKgwqAg V2h5IHRoZSBzZWNvbmQgcmVxdWlyZW1lbnQ/wqAgSWYgdGhlIGRhdGEgbW9kZWwgaXMgc3VwcG9y dGVkLCBhbmQgdGhlCj7CoMKgwqDCoCBkYXRhIG1vZGVsIHN0YXRlcyB0aGF0IGNlcnRhaW4gaXRl bXMgYXJlIGVwaGVtZXJhbCwgd2hhdCB3b3VsZCBpdAo+wqDCoMKgwqAgbWVhbiBpZiB0aGUgc2ln bmFsaW5nIGRpZCBub3QgYWxzbyBzYXkgdGhhdC7CoCBDb252ZXJzZWx5LCB3aGF0IHdvdWxkCj7C oMKgwqDCoCBpdCBtZWFuIGlmIHRoZSBzaWduYWxpbmcgc2FpZCBzb21ldGhpbmcgd2FzIGVwaGVt ZXJhbCB0aGF0IHRoZSBtb2RlbAo+wqDCoMKgwqAgZG9lcyBub3QgZGVmaW5lIGFzIGVwaGVtZXJh bD8KPgo+wqDCoMKgwqAgSXQgbWF5IGJlIHRoYXQgSSBhbSBtaXNyZWFkaW5nIGJ1bGxldCA2LsKg IFBsZWFzZSBleHBsYWluLgo+Cj4KPgo+IEkgdGhpbmsgeW91IGFyZSBjb3JyZWN0IHRoYXQgdGhl IFlBTkcgbGlicmFyeSBkb2VzIG5vdCBuZWVkIGFueSAKPiBjaGFuZ2VzIHRvIGlkZW50aWZ5IGVw aGVtZXJhbCBkYXRhLsKgIE9ubHkgdGhlIHZhcmlhYmxlIGNvbXBvbmVudHMgb2YgCj4gWUFORyBj b25mb3JtYW5jZSBhcmUgY29udGFpbmVkIGluIHRoZSBsaWJyYXJ5Lgo+Cj4KPsKgwqDCoMKgIFRo YW5rIHlvdSwKPsKgwqDCoMKgIEpvZWwKPgo+Cj4KPiBBbmR5Cj4KPgo+wqDCoMKgwqAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPsKgwqDCoMKgIGkycnMg bWFpbGluZyBsaXN0Cj7CoMKgwqDCoCBpMnJzQGlldGYub3JnIDxtYWlsdG86aTJyc0BpZXRmLm9y Zz4KPsKgwqDCoMKgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycwo+ Cj4KCg== ----_com.samsung.android.email_934795023916920 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PklmIHRoZSBJMlJTIGFyZW4n dCBpcyBvZmYgdGhlbiB0aGUgc3lzdGVtIGRvZXMgbm90IGN1cnJlbnRseSBzdXBwb3J0IHRoaXMg bW9kZWxzLiAmbmJzcDtUaGlzIGlzIGp1c3QgbGlrZSBhbnkgb3RoZXIgb3B0aW9uYWwgWUFORyBt b2R1bGUuICZuYnNwO0lmIHlvdSBhcmUgbm90IGN1cnJlbnRseSBwcmVwYXJlZCB0byB1c2UgaXQs IHlvdSBkb24ndCBjbGFpbSB0byBzdXBwb3J0IGl0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ Q2F2ZWF0OiBUaGUgTmV0TW9kIGZvbGtzIG1heSBoYXZlIGNvbWUgdXAgd2l0aCBhIG1vcmUgbnVh bmNlZCBtZWNoYW5pc20uICZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91cnMsPC9k aXY+PGRpdj5Kb2VsPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6 ODUlO2NvbG9yOiM1NzU3NTciPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4g QVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNp emU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0t LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFN1c2FuIEhhcmVz ICZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogNS8xMC8yMDE2ICAxOjI1 IFBNICAoR01UKzAxOjAwKSA8L2Rpdj48ZGl2PlRvOiAiJ0pvZWwgTS4gSGFscGVybiciICZsdDtq bWhAam9lbGhhbHBlcm4uY29tJmd0OywgJ0FuZHkgQmllcm1hbicgJmx0O2FuZHlAeXVtYXdvcmtz LmNvbSZndDsgPC9kaXY+PGRpdj5DYzogaTJyc0BpZXRmLm9yZywgJ05ldGNvbmYnICZsdDtuZXRj b25mQGlldGYub3JnJmd0OyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJFOiBbaTJyc10gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJycy1wcm90b2NvbC1zdHJhd21h bi0wMi50eHQgLSAzLjEuMSA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5Kb2VsOiA8YnI+PGJy PldoYXQgaGFwcGVucyBpZiB0aGUgY29kZSBzdXBwb3J0cyB0aGUgSTJSUyBhZ2VudCwgYnV0IHRo ZSBJMlJTIGFnZW50IGlzIGNvbmZpZ3VyZWQgdG8gYmUgIm9mZiI/Jm5ic3A7IElzIHRoaXMgY292 ZXJlZCBieSB0aGUgZGV2aWF0aW9ucyBvciBpcyB0aGlzIHZhcmlhYmxlIGNvbmZpZ3VyYXRpb24/ IDxicj48YnI+U3VlIDxicj48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTog Sm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0gPGJyPlNlbnQ6IFR1 ZXNkYXksIE1heSAxMCwgMjAxNiAxOjM0IEFNPGJyPlRvOiBTdXNhbiBIYXJlczsgQW5keSBCaWVy bWFuPGJyPkNjOiBpMnJzQGlldGYub3JnOyBOZXRjb25mPGJyPlN1YmplY3Q6IFJlOiBbaTJyc10g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJycy1wcm90b2Nv bC1zdHJhd21hbi0wMi50eHQgLSAzLjEuMTxicj48YnI+QXMgSSB1bmRlcnN0YW5kIGl0LCBpZiBh IG1vZGVsIHJlcXVpcmVzIGVwaGVtZXJhbCBlbGVtZW50cywgYW5kIHRoZSBhZ2VudCBkb2VzIG5v dCBzdXBwb3J0IGVwaGVtZXJhbCwgdGhlbiB0aGUgYWdlbnQgY2FuIG5vdCBjbGFpbSB0byBzdXBw b3J0IHRoZSBtb2RlbC48YnI+PGJyPlllcywgZGV2aWF0aW9ucyBhbGxvdyB5b3UgdG8gc3BlY2lm eSB0aGlzLCBhcyBBbmR5IHNheXMuJm5ic3A7IEJ1dCB0aGlzIGlzIHNwZWNpZnlpbmcgYSBmYWls dXJlIHRvIGNvbmZvcm0uPGJyPjxicj5JIHdvdWxkIGdvIGZhciBhcyB0byBzYXkgdGhhdCBzdWNo IGFuIGFnZW50IGlzIG5vdCBhbiBJMlJTIGFnZW50LCBidXQgdGhhdCBpcyBhIHN0ZXAgYmV5b25k IHRoZSBOZXRDb25mIGNvbXBsaWFuY2UgZGVmaW5pdGlvbnMuPGJyPjxicj5Zb3Vycyw8YnI+Sm9l bDxicj48YnI+T24gNS85LzE2IDY6MDkgUE0sIFN1c2FuIEhhcmVzIHdyb3RlOjxicj4mZ3Q7IEFu ZHkgYW5kIEpvZWw6PGJyPiZndDs8YnI+Jmd0OyBUaGVzZSBhcmUgZ29vZCBwb2ludHMuPGJyPiZn dDs8YnI+Jmd0OyBXaGF0IGhhcHBlbnMgaWYgdGhlIGRhdGEgbW9kZWwgaGFzIHNvbWUgZXBoZW1l cmFsIHNlY3Rpb25zIGFuZCB0aGUgPGJyPiZndDsgSTJSUyBhZ2VudCBpcyBub3Qgc3VwcG9ydGVk IGJ5IHRoZSByb3V0aW5nIHN5c3RlbS4mbmJzcDsgVGhlIGRhdGEgbW9kZWwgPGJyPiZndDsgd291 bGQgc3BlY2lmeSB0aGUgZXBoZW1lcmFsIHNlY3Rpb24sIGJ1dCB0aGVyZSB3b3VsZCBiZSBubyBz dXBwb3J0IGJ5IGkycnMuPGJyPiZndDsmbmJzcDsgSXMgdGhlIHN1cHBvcnQgb2YgdGhlIGVwaGVt ZXJhbCBub3QgYSB2YXJpYWJsZSZuYnNwOyBjb25kaXRpb24gdG8gYmUgPGJyPiZndDsgaW5kaWNh dGVkIGluIFlhbmcgbW9kdWxlIGxpYnJhcnk/PGJyPiZndDs8YnI+Jmd0OyBTdWU8YnI+Jmd0OyBT ZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJmFtcDtUIDRHIExURSBzbWFy dHBob25lPGJyPiZndDsgLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj4mZ3Q7 IEZyb206IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ozxicj4mZ3Q7IERh dGU6IDUvNy8yMDE2IDEyOjUzIFBNIChHTVQtMDU6MDApPGJyPiZndDsgVG86ICJKb2VsIE0uIEhh bHBlcm4iICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0Ozxicj4mZ3Q7IENjOiBpMnJzQGlldGYu b3JnLCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgU3VzYW4gSGFyZXMgPGJyPiZn dDsgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs8YnI+Jmd0OyBTdWJqZWN0OiBSZTogW2kycnNdIEZX OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIDxicj4mZ3Q7IGRyYWZ0LWhhcmVzLWkycnMt cHJvdG9jb2wtc3RyYXdtYW4tMDIudHh0IC0gMy4xLjE8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8 YnI+Jmd0OyBPbiBGcmksIE1heSA2LCAyMDE2IGF0IDg6NTEgQU0sIEpvZWwgTS4gSGFscGVybiAm bHQ7am1oQGpvZWxoYWxwZXJuLmNvbSA8YnI+Jmd0OyAmbHQ7bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20mZ3Q7Jmd0OyB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFJlYWRpbmcgdGhlIGxhdGVzdCByZXZpc2lvbiwgaW4gc2VjdGlvbiAzLjEuMSwgdGhlIHRl eHQgaW4gYnVsbGV0IDU8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzYXlzIHRoYXQg dGhlIGRhdGEgbW9kZWwgaW5kaWNhdGVzIHdoaWNoIHBvcnRpb25zIGFyZSBlcGhlbWVyYWwuPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhdCBtYWtlcyBzZW5zZSB0byBtZS48YnI+ Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZW4gYnVsbGV0IDYgc2F5cyB0 aGF0IHRoZSBtYW5hZ2VtZW50IHByb3RvY29sIG5lZWRzIHRvIHNpZ25hbCAoaW48YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpdHMgeWFuZyBsaWJyYXJ5KSB3aGljaCBwYXJ0cyBhcmUg ZXBoZW1lcmFsLjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2h5IHRo ZSBzZWNvbmQgcmVxdWlyZW1lbnQ/Jm5ic3A7IElmIHRoZSBkYXRhIG1vZGVsIGlzIHN1cHBvcnRl ZCwgYW5kIHRoZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRhdGEgbW9kZWwgc3Rh dGVzIHRoYXQgY2VydGFpbiBpdGVtcyBhcmUgZXBoZW1lcmFsLCB3aGF0IHdvdWxkIGl0PGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWVhbiBpZiB0aGUgc2lnbmFsaW5nIGRpZCBub3Qg YWxzbyBzYXkgdGhhdC4mbmJzcDsgQ29udmVyc2VseSwgd2hhdCB3b3VsZDxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0IG1lYW4gaWYgdGhlIHNpZ25hbGluZyBzYWlkIHNvbWV0aGlu ZyB3YXMgZXBoZW1lcmFsIHRoYXQgdGhlIG1vZGVsPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZG9lcyBub3QgZGVmaW5lIGFzIGVwaGVtZXJhbD88YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IG1heSBiZSB0aGF0IEkgYW0gbWlzcmVhZGluZyBidWxsZXQg Ni4mbmJzcDsgUGxlYXNlIGV4cGxhaW4uPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsg SSB0aGluayB5b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgWUFORyBsaWJyYXJ5IGRvZXMgbm90IG5l ZWQgYW55IDxicj4mZ3Q7IGNoYW5nZXMgdG8gaWRlbnRpZnkgZXBoZW1lcmFsIGRhdGEuJm5ic3A7 IE9ubHkgdGhlIHZhcmlhYmxlIGNvbXBvbmVudHMgb2YgPGJyPiZndDsgWUFORyBjb25mb3JtYW5j ZSBhcmUgY29udGFpbmVkIGluIHRoZSBsaWJyYXJ5Ljxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFuayB5b3UsPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSm9lbDxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IEFuZHk8YnI+Jmd0 Ozxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpMnJzIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGkycnNAaWV0Zi5vcmcgJmx0O21haWx0bzppMnJzQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aTJyczxicj4mZ3Q7PGJyPiZndDs8YnI+PGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_934795023916920-- From nobody Tue May 10 07:54:47 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A87012D1B7; Tue, 10 May 2016 07:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay661oZVxXEU; Tue, 10 May 2016 07:54:41 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 A58EB12D0E3; Tue, 10 May 2016 07:54:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.91.193.41; From: "Susan Hares" To: "'jmh.direct'" , "'Joel M. Halpern'" , "'Andy Bierman'" References: <7eqdbrhnm368w3aqvlarweoi.1462882301561@email.android.com> In-Reply-To: <7eqdbrhnm368w3aqvlarweoi.1462882301561@email.android.com> Date: Tue, 10 May 2016 10:54:28 -0400 Message-ID: <010901d1aacb$ddabec90$9903c5b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010A_01D1AAAA.569BD330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJK5cF+B3c7cj/h/Gl6Cpq2sTtrkJ6/y26w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Netconf' Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 14:54:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010A_01D1AAAA.569BD330 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Joel:=20 =20 See below. Just trying to wrap up the discussion. =20 From: jmh.direct [mailto:jmh.direct@joelhalpern.com]=20 Sent: Tuesday, May 10, 2016 8:12 AM To: Susan Hares; 'Joel M. Halpern'; 'Andy Bierman' Cc: i2rs@ietf.org; 'Netconf' Subject: RE: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 =20 If the I2RS aren't is off then the system does not currently support = this models. This is just like any other optional YANG module. If you = are not currently prepared to use it, you don't claim to support it. =20 Sue: I assume you desired to say=E2=80=A6 if the I2RS is not on, then = the system does not support this model. =20 =20 Caveat: The NetMod folks may have come up with a more nuanced mechanism. = =20 =20 Sue: Do we need them to come up with mechanism that indicates I2RS is = there but off?=20 =20 Yours, Joel =20 =20 =20 Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone -------- Original message -------- From: Susan Hares =20 Date: 5/10/2016 1:25 PM (GMT+01:00)=20 To: "'Joel M. Halpern'" , 'Andy Bierman' = =20 Cc: i2rs@ietf.org, 'Netconf' =20 Subject: RE: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1=20 =20 Joel:=20 What happens if the code supports the I2RS agent, but the I2RS agent is = configured to be "off"? Is this covered by the deviations or is this = variable configuration?=20 Sue=20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, May 10, 2016 1:34 AM To: Susan Hares; Andy Bierman Cc: i2rs@ietf.org; Netconf Subject: Re: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 As I understand it, if a model requires ephemeral elements, and the = agent does not support ephemeral, then the agent can not claim to = support the model. Yes, deviations allow you to specify this, as Andy says. But this is = specifying a failure to conform. I would go far as to say that such an agent is not an I2RS agent, but = that is a step beyond the NetConf compliance definitions. Yours, Joel On 5/9/16 6:09 PM, Susan Hares wrote: > Andy and Joel: > > These are good points. > > What happens if the data model has some ephemeral sections and the=20 > I2RS agent is not supported by the routing system. The data model=20 > would specify the ephemeral section, but there would be no support by = i2rs. > Is the support of the ephemeral not a variable condition to be=20 > indicated in Yang module library? > > Sue > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/7/2016 12:53 PM (GMT-05:00) > To: "Joel M. Halpern" > Cc: i2rs@ietf.org, Netconf , Susan Hares=20 > > Subject: Re: [i2rs] FW: New Version Notification for=20 > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern =20 > > wrote: > > Reading the latest revision, in section 3.1.1, the text in bullet = 5 > says that the data model indicates which portions are ephemeral. > That makes sense to me. > > Then bullet 6 says that the management protocol needs to signal = (in > its yang library) which parts are ephemeral. > > Why the second requirement? If the data model is supported, and = the > data model states that certain items are ephemeral, what would it > mean if the signaling did not also say that. Conversely, what = would > it mean if the signaling said something was ephemeral that the = model > does not define as ephemeral? > > It may be that I am misreading bullet 6. Please explain. > > > > I think you are correct that the YANG library does not need any=20 > changes to identify ephemeral data. Only the variable components of=20 > YANG conformance are contained in the library. > > > Thank you, > Joel > > > > Andy > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > ------=_NextPart_000_010A_01D1AAAA.569BD330 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Joel:

 

See below.=C2=A0=C2=A0 Just trying to wrap up the = discussion.

 

From:= = jmh.direct [mailto:jmh.direct@joelhalpern.com]
Sent: Tuesday, = May 10, 2016 8:12 AM
To: Susan Hares; 'Joel M. Halpern'; 'Andy = Bierman'
Cc: i2rs@ietf.org; 'Netconf'
Subject: RE: = [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - = 3.1.1

 

If the = I2RS aren't is off then the system does not currently support this = models.  This is just like any other optional YANG module.  If = you are not currently prepared to use it, you don't claim to support = it.

 

Sue: I assume you desired to say=E2=80=A6 =C2=A0if the I2RS is not = on, then the system does not support this model.=C2=A0 =

 

Caveat: = The NetMod folks may have come up with a more nuanced mechanism. =  

 

Sue: Do we need them to come up with mechanism that indicates I2RS is = there but off?

 

Yours,

Joel

 

 

 

Sent via the Samsung Galaxy = S=C2=AE 6, an AT&T 4G LTE = smartphone

-------- Original message = --------

From: Susan Hares <shares@ndzh.com> =

Date: 5/10/2016 1:25 PM (GMT+01:00) =

To: "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Andy = Bierman' <andy@yumaworks.com> =

Cc: i2rs@ietf.org, 'Netconf' <netconf@ietf.org> =

Subject: RE: [i2rs] FW: New Version Notification = for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 =

 

Joel:

What = happens if the code supports the I2RS agent, but the I2RS agent is = configured to be "off"?  Is this covered by the = deviations or is this variable configuration?

Sue =

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com] =
Sent: Tuesday, May 10, 2016 1:34 AM
To: Susan Hares; Andy = Bierman
Cc: i2rs@ietf.org; = Netconf
Subject: Re: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1

As I understand = it, if a model requires ephemeral elements, and the agent does not = support ephemeral, then the agent can not claim to support the = model.

Yes, deviations allow you to specify this, as Andy = says.  But this is specifying a failure to conform.

I would = go far as to say that such an agent is not an I2RS agent, but that is a = step beyond the NetConf compliance = definitions.

Yours,
Joel

On 5/9/16 6:09 PM, Susan Hares = wrote:
> Andy and Joel:
>
> These are good = points.
>
> What happens if the data model has some = ephemeral sections and the
> I2RS agent is not supported by the = routing system.  The data model
> would specify the = ephemeral section, but there would be no support by i2rs.
>  = Is the support of the ephemeral not a variable  condition to be =
> indicated in Yang module library?
>
> Sue
> = Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
> = -------- Original message --------
> From: Andy Bierman <andy@yumaworks.com>
> = Date: 5/7/2016 12:53 PM (GMT-05:00)
> To: "Joel M. = Halpern" <jmh@joelhalpern.com>
> = Cc: i2rs@ietf.org, Netconf <netconf@ietf.org>, Susan Hares =
> <shares@ndzh.com>
> Subject: = Re: [i2rs] FW: New Version Notification for
> = draft-hares-i2rs-protocol-strawman-02.txt - = 3.1.1
>
>
>
> On Fri, May 6, 2016 at 8:51 AM, = Joel M. Halpern <jmh@joelhalpern.com =
> <mailto:jmh@joelhalpern.com>>= ; wrote:
>
>     Reading the latest = revision, in section 3.1.1, the text in bullet = 5
>     says that the data model indicates = which portions are ephemeral.
>     That makes = sense to me.
>
>     Then bullet 6 says = that the management protocol needs to signal = (in
>     its yang library) which parts are = ephemeral.
>
>     Why the second = requirement?  If the data model is supported, and = the
>     data model states that certain items = are ephemeral, what would it
>     mean if the = signaling did not also say that.  Conversely, what = would
>     it mean if the signaling said = something was ephemeral that the model
>     = does not define as ephemeral?
>
>     It = may be that I am misreading bullet 6.  Please = explain.
>
>
>
> I think you are correct that = the YANG library does not need any
> changes to identify = ephemeral data.  Only the variable components of
> YANG = conformance are contained in the = library.
>
>
>     Thank = you,
>     = Joel
>
>
>
> = Andy
>
>
>     = _______________________________________________
>   =   i2rs mailing list
>     i2rs@ietf.org <mailto:i2rs@ietf.org>
> &= nbsp;   https://www.ietf.org/= mailman/listinfo/i2rs
>
>

------=_NextPart_000_010A_01D1AAAA.569BD330-- From nobody Tue May 10 08:11:05 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0375412D1C2; Tue, 10 May 2016 08:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm6JuMf0IKpz; Tue, 10 May 2016 08:10:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 A6D4312D1B7; Tue, 10 May 2016 08:10:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 893A31C0ADE; Tue, 10 May 2016 08:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462893059; bh=ezCJLbyAj5IWw44TMffc8bjdpV+TWSPrRNn+KKGWeoE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ZQfmeHnBtECYICBDGbFIG9vCiCsvreePVufZlDLCDgXF74+Sy4YDz/Igp7sERJpWL 4+uDOOUv/qSVYapcRPpbi6gVk1RybOLAEe0vV6ah6dvzsl2uvhL/VDWsTb3V3bJDCl 77HVB8RgKUXxyb6bcBSRLHDVPOswUWhFHUTUZ5Hw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (sessfw99-sesbfw99-81.ericsson.net [192.176.1.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3C3C31C069E; Tue, 10 May 2016 08:10:58 -0700 (PDT) To: Susan Hares , 'Andy Bierman' References: <7eqdbrhnm368w3aqvlarweoi.1462882301561@email.android.com> <010901d1aacb$ddabec90$9903c5b0$@ndzh.com> From: "Joel M. Halpern" Message-ID: <5b422567-7120-16c8-7a7d-2ee5227165c1@joelhalpern.com> Date: Tue, 10 May 2016 11:10:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <010901d1aacb$ddabec90$9903c5b0$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: i2rs@ietf.org, 'Netconf' Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 15:11:02 -0000 Yes, you interpreted my awful typing correctly. I don't see any need for anything more, but was allowing that I am not fully current on the groups thinking. Yours, Joel On 5/10/16 10:54 AM, Susan Hares wrote: > Joel: > > > > See below. Just trying to wrap up the discussion. > > > > *From:*jmh.direct [mailto:jmh.direct@joelhalpern.com] > *Sent:* Tuesday, May 10, 2016 8:12 AM > *To:* Susan Hares; 'Joel M. Halpern'; 'Andy Bierman' > *Cc:* i2rs@ietf.org; 'Netconf' > *Subject:* RE: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > If the I2RS aren't is off then the system does not currently support > this models. This is just like any other optional YANG module. If you > are not currently prepared to use it, you don't claim to support it. > > > > Sue: I assume you desired to say… if the I2RS is not on, then the > system does not support this model. > > > > Caveat: The NetMod folks may have come up with a more nuanced mechanism. > > > > Sue: Do we need them to come up with mechanism that indicates I2RS is > there but off? > > > > Yours, > > Joel > > > > > > > > Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone > > -------- Original message -------- > > From: Susan Hares > > > Date: 5/10/2016 1:25 PM (GMT+01:00) > > To: "'Joel M. Halpern'" >, 'Andy Bierman' > > > Cc: i2rs@ietf.org , 'Netconf' > > > Subject: RE: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > Joel: > > What happens if the code supports the I2RS agent, but the I2RS agent is > configured to be "off"? Is this covered by the deviations or is this > variable configuration? > > Sue > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, May 10, 2016 1:34 AM > To: Susan Hares; Andy Bierman > Cc: i2rs@ietf.org ; Netconf > Subject: Re: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > As I understand it, if a model requires ephemeral elements, and the > agent does not support ephemeral, then the agent can not claim to > support the model. > > Yes, deviations allow you to specify this, as Andy says. But this is > specifying a failure to conform. > > I would go far as to say that such an agent is not an I2RS agent, but > that is a step beyond the NetConf compliance definitions. > > Yours, > Joel > > On 5/9/16 6:09 PM, Susan Hares wrote: >> Andy and Joel: >> >> These are good points. >> >> What happens if the data model has some ephemeral sections and the >> I2RS agent is not supported by the routing system. The data model >> would specify the ephemeral section, but there would be no support by > i2rs. >> Is the support of the ephemeral not a variable condition to be >> indicated in Yang module library? >> >> Sue >> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone >> -------- Original message -------- >> From: Andy Bierman > >> Date: 5/7/2016 12:53 PM (GMT-05:00) >> To: "Joel M. Halpern" > >> Cc: i2rs@ietf.org , Netconf >, Susan Hares >> > >> Subject: Re: [i2rs] FW: New Version Notification for >> draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 >> >> >> >> On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern > > wrote: >> >> Reading the latest revision, in section 3.1.1, the text in bullet 5 >> says that the data model indicates which portions are ephemeral. >> That makes sense to me. >> >> Then bullet 6 says that the management protocol needs to signal (in >> its yang library) which parts are ephemeral. >> >> Why the second requirement? If the data model is supported, and the >> data model states that certain items are ephemeral, what would it >> mean if the signaling did not also say that. Conversely, what would >> it mean if the signaling said something was ephemeral that the model >> does not define as ephemeral? >> >> It may be that I am misreading bullet 6. Please explain. >> >> >> >> I think you are correct that the YANG library does not need any >> changes to identify ephemeral data. Only the variable components of >> YANG conformance are contained in the library. >> >> >> Thank you, >> Joel >> >> >> >> Andy >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > From nobody Tue May 10 15:04:38 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC2E12D1D7; Tue, 10 May 2016 15:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqpTBjoFqIsS; Tue, 10 May 2016 15:04:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62DE512D16F; Tue, 10 May 2016 15:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4665; q=dns/txt; s=iport; t=1462917871; x=1464127471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NI4Te88tlbBtJOFcM1ZkKUphPLjKy83TsHpI3TEMsWc=; b=cz04QGHLE/38khsHFsn0vpGsAmQNy8Rshf4Qhcc//S57eHpErPA41tw3 dvtPB5yNYNDYn+6Ebdr5d5uPGclOQVfLcXzIobchIRG3A5vJGWlshkpoT rtEmEB0I3X0iXZqvoukeXGGXw73P6A/5CCDOWX/aRDxkHg9axVHqXCsvE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgCvWTJX/4oNJK1UCYM4gVIGuS8BD?= =?us-ascii?q?YF2hhACgTo4FAEBAQEBAQFlJ4RBAQEBAwE6PwwEAgEIEQEDAQEBHhAyFwYIAQE?= =?us-ascii?q?EAQ0FCIgbBwG5RQEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIIRMhBEHCgGFdQWYJ?= =?us-ascii?q?wGOFoFwhE+IYY8/AR4BAUKDa26HVTYBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,606,1454976000"; d="scan'208";a="105770875" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2016 22:04:30 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4AM4UOp006968 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 May 2016 22:04:30 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 10 May 2016 17:04:29 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Tue, 10 May 2016 17:04:29 -0500 From: "Les Ginsberg (ginsberg)" To: "Joe Clarke (jclarke)" , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQBnClYAAieCg0A= Date: Tue, 10 May 2016 22:04:29 +0000 Message-ID: References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.69.34.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 22:04:34 -0000 Joe - Apologies for the delayed response. I am a victim of my own email infilters= . :-( Inline. > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Friday, April 29, 2016 10:44 AM > To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.or= g > Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >=20 > On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: > > Summary: This document is a well written document - easy to understand= . > > My compliments to the authors. I believe there is one minor issue > > which I would like to see addressed before publication. >=20 > Thanks for your comments and feedback, Les. Please see below for some > replies and questions. >=20 > > In Section 5.2 there is a definition of the information which is > > required to be kept by an I2RS Agent for each I2RS interaction. I > > would like to see the addition of "Request State" into this list. > > Operationally each request could be in one of the following states: > > > > > > > > * Enqueued (or pending if you prefer) > > > > * In process > > > > * Completed > > > > > > > > The lack of such a state seems to imply that both the queue time and > > the processing time are insignificant. While I think this may be the > > case for many requests, it will not always be the case. In queue time > > may be lengthy due to other load on the Agent. Also, some requests - > > particularly destructive requests which involve cleanup of resources - > > may take a significant amount of time to complete. >=20 > Good observation. Traceability was aimed mainly at the termination of th= e > request, but I like the idea of tracing the state machine. >=20 > > > > > > > > Along with this an additional timestamp - Processing Initiated - would > > be useful to indicate when processing of the request actually began. >=20 > I don't know we need a new timestamp. Perhaps we just need to rename > "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and > "End Timestamp" to denote the time within the current state. What do you > think? [Les:] My intent was to log the time at which the request began processing = so that you can see whether a long delay in completion was due to enqueue = delay or actual lengthy processing time. I am not adamant about this so if = you want to stay with the two timestamps that is OK. >=20 > > s/Some notable elements on the architecture/ Some notable elements of > > the architecture >=20 > Fixed. Thanks! >=20 > > > > > > > > Figure 1 > > > > > > > > Not clear to me why Application IDs start at 0 but Client IDs start at = 1. >=20 > Ah. The numbers there are not IDs. They are the number of actual things= in > the boxes above. For Applications, there may be 0 to N for a given clien= t. For > Clients, you need at least 1. Does that make sense? >=20 [Les:] Maybe you want to use "shadows" on the boxes to indicate there can b= e multiple Application boxes and multiple Client boxes? What you say makes sense but I do not intuit that when I look at the ASSCII= art. > > > > > > > > Figure 1 > > > > > > > > Is the text "Op Data V" between I2RS Agent box and Routing System box > > intentional? >=20 > Yes. The 'V' is meant to be an arrow head pointed down. The request > and data go from Client to Agent whereas the Response goes from Agent to > Client. >=20 > We are open to suggestions on how to make this clearer. [Les:] I think it would be clearer if you had two lines - one flowing down = associated with the Op Data and one flowing up with the result. >=20 > > > > > > > > Section 5.2 > > > > > > > > Secondary Identity > > > > > > > > This is defined to be "opaque" yet if not provided the agent is suppose= d > > to insert "an UNAVAILABLE value". This seems to be a contradiction > > unless we have a publicly defined value that clients are prohibited fro= m > > using. Absent that you would need a "Secondary Identity Valid" indicato= r. >=20 > Good observation. I think it's fine to say that this field must be > logged. If there is no application, then the field will be logged as > empty. If there is an application, then whatever value is provided will > be logged. >=20 > Do you feel strongly that we need a field to indicate Application Present= ? > [Les:] I am fine w your changes. Les =20 > > > > > > > > Section 7.4 > > > > > > > > s/establish an vendor-agnostic/establish a vendor-agnostic >=20 > Fixed. Thanks! >=20 > Joe From nobody Wed May 11 03:59:40 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1309412D9A0; Wed, 11 May 2016 03:59:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511105936.15223.60001.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 03:59:36 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-problem-statement-11.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 10:59:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : Interface to the Routing System Problem Statement Authors : Alia Atlas Thomas D. Nadeau Dave Ward Filename : draft-ietf-i2rs-problem-statement-11.txt Pages : 11 Date : 2016-05-10 Abstract: Traditionally, routing systems have implemented routing and signaling (e.g. MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. With the advent of highly dynamic data center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision- making from the router itself, requirements have emerged to more dynamically manage and program routing systems. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems. This document proposes meeting this need via an Interface to the Routing System (I2RS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-problem-statement-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-problem-statement-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 11 08:18:44 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B3612DB40; Wed, 11 May 2016 08:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nob-BXPH1ZOq; Wed, 11 May 2016 08:18:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F3B12D0E3; Wed, 11 May 2016 08:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4867; q=dns/txt; s=iport; t=1462979920; x=1464189520; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=VJyxM9sO7tRQ5370S0UBH8hQY9ed7Hq13jpT9DZnUAA=; b=fkMvTfMfegonn/Lzw+k67XMnlDjK4XarY/qjD910njMhPOrrYmNhNLJt ND+Kfka1y/YeMG2B2ObGroIzzSDJjp69OjsVAM5L3ulGqemVvJ0Dzdwwj HHoVjMnLkRINPwPUbZavHqiyFBc0VtV/7/cJkVIresE2hr5ENUw4HmjbV Y=; X-IronPort-AV: E=Sophos;i="5.24,608,1454976000"; d="scan'208";a="101084280" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2016 15:18:39 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4BFIcxv025288; Wed, 11 May 2016 15:18:39 GMT To: "Les Ginsberg (ginsberg)" , "rtg-ads@ietf.org" References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <978721df-6b95-dff7-af53-31d42a731946@cisco.com> Date: Wed, 11 May 2016 11:18:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 15:18:43 -0000 On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: > Joe - > > Apologies for the delayed response. I am a victim of my own email infilters. :-( > Inline. Thanks, Les. Have a look at https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html . I added a new line to show the flow in both directions. Joe > >> -----Original Message----- >> From: Joe Clarke (jclarke) >> Sent: Friday, April 29, 2016 10:44 AM >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.org >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >> >> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: >>> Summary: This document is a well written document - easy to understand. >>> My compliments to the authors. I believe there is one minor issue >>> which I would like to see addressed before publication. >> >> Thanks for your comments and feedback, Les. Please see below for some >> replies and questions. >> >>> In Section 5.2 there is a definition of the information which is >>> required to be kept by an I2RS Agent for each I2RS interaction. I >>> would like to see the addition of "Request State" into this list. >>> Operationally each request could be in one of the following states: >>> >>> >>> >>> * Enqueued (or pending if you prefer) >>> >>> * In process >>> >>> * Completed >>> >>> >>> >>> The lack of such a state seems to imply that both the queue time and >>> the processing time are insignificant. While I think this may be the >>> case for many requests, it will not always be the case. In queue time >>> may be lengthy due to other load on the Agent. Also, some requests - >>> particularly destructive requests which involve cleanup of resources - >>> may take a significant amount of time to complete. >> >> Good observation. Traceability was aimed mainly at the termination of the >> request, but I like the idea of tracing the state machine. >> >>> >>> >>> >>> Along with this an additional timestamp - Processing Initiated - would >>> be useful to indicate when processing of the request actually began. >> >> I don't know we need a new timestamp. Perhaps we just need to rename >> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and >> "End Timestamp" to denote the time within the current state. What do you >> think? > > [Les:] My intent was to log the time at which the request began processing so that you can see whether a long delay in completion was due to enqueue delay or actual lengthy processing time. I am not adamant about this so if you want to stay with the two timestamps that is OK. > >> >>> s/Some notable elements on the architecture/ Some notable elements of >>> the architecture >> >> Fixed. Thanks! >> >>> >>> >>> >>> Figure 1 >>> >>> >>> >>> Not clear to me why Application IDs start at 0 but Client IDs start at 1. >> >> Ah. The numbers there are not IDs. They are the number of actual things in >> the boxes above. For Applications, there may be 0 to N for a given client. For >> Clients, you need at least 1. Does that make sense? >> > [Les:] Maybe you want to use "shadows" on the boxes to indicate there can be multiple Application boxes and multiple Client boxes? > What you say makes sense but I do not intuit that when I look at the ASSCII art. > >>> >>> >>> >>> Figure 1 >>> >>> >>> >>> Is the text "Op Data V" between I2RS Agent box and Routing System box >>> intentional? >> >> Yes. The 'V' is meant to be an arrow head pointed down. The request >> and data go from Client to Agent whereas the Response goes from Agent to >> Client. >> >> We are open to suggestions on how to make this clearer. > > [Les:] I think it would be clearer if you had two lines - one flowing down associated with the Op Data and one flowing up with the result. > >> >>> >>> >>> >>> Section 5.2 >>> >>> >>> >>> Secondary Identity >>> >>> >>> >>> This is defined to be "opaque" yet if not provided the agent is supposed >>> to insert "an UNAVAILABLE value". This seems to be a contradiction >>> unless we have a publicly defined value that clients are prohibited from >>> using. Absent that you would need a "Secondary Identity Valid" indicator. >> >> Good observation. I think it's fine to say that this field must be >> logged. If there is no application, then the field will be logged as >> empty. If there is an application, then whatever value is provided will >> be logged. >> >> Do you feel strongly that we need a field to indicate Application Present? >> > [Les:] I am fine w your changes. > > Les > >>> >>> >>> >>> Section 7.4 >>> >>> >>> >>> s/establish an vendor-agnostic/establish a vendor-agnostic >> >> Fixed. Thanks! >> >> Joe From nobody Wed May 11 12:28:05 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E741D12D79D; Wed, 11 May 2016 12:28:04 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511192804.15288.74083.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 12:28:04 -0700 Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, db3546@att.com, draft-ietf-i2rs-architecture@ietf.org, i2rs-chairs@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [i2rs] Document Action: 'An Architecture for the Interface to the Routing System' to Informational RFC (draft-ietf-i2rs-architecture-15.txt) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:28:05 -0000 The IESG has approved the following document: - 'An Architecture for the Interface to the Routing System' (draft-ietf-i2rs-architecture-15.txt) as Informational RFC This document is the product of the Interface to the Routing System Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ Technical Summary This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of the Interface to Routing System (I2RS). Working Group Summary There has been significant debate and discussion relating to template, multi-head control, security and consensus was made on these topics. Document Quality There was active discussion in the WG and the document passed through a number of iterations reflecting that. This document has been well reviewed and updated to reflect comments received in WG last call. Personnel Who is the Document Shepherd for this document? Mach Chen Who is the Responsible Area Director? Deborah Brungard From nobody Wed May 11 12:34:37 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0CB12D7CA; Wed, 11 May 2016 12:34:30 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511193430.15223.94102.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 12:34:30 -0700 Archived-At: Cc: i2rs@ietf.org, db3546@att.com, i2rs-chairs@ietf.org, The IESG , rfc-editor@rfc-editor.org, bill.wu@huawei.com, draft-ietf-i2rs-problem-statement@ietf.org Subject: [i2rs] Document Action: 'Interface to the Routing System Problem Statement' to Informational RFC (draft-ietf-i2rs-problem-statement-11.txt) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:34:31 -0000 The IESG has approved the following document: - 'Interface to the Routing System Problem Statement' (draft-ietf-i2rs-problem-statement-11.txt) as Informational RFC This document is the product of the Interface to the Routing System Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ Technical Summary As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable network applications to have access to and control over information in the Internet's routing system, we need a publicly documented interface specification. The interface needs to support real-time, asynchronous interactions using data models and encodings that are efficient and potentially different from those available today. Furthermore, the interface must be tailored to support a variety of use cases. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Routing System (I2RS). Working Group Summary Consensus was complete in the working group after 2 year of review. Document Quality [Shepherd] Document is ready to ship, but there is one unused reference RFC4292 which might link to Appendix A, suggest to add reference to where it was referenced in this document. Personnel Who is the Document Shepherd for this document? Qin Wu Who is the Responsible Area Director? Deborah Brungard From nobody Wed May 11 14:41:52 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7612D1B3; Wed, 11 May 2016 14:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqvluXrWeELB; Wed, 11 May 2016 14:41:48 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F52112D141; Wed, 11 May 2016 14:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5644; q=dns/txt; s=iport; t=1463002908; x=1464212508; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VvzmrQzucvj18jvcaGPTLwXg93B16bkrB2lBxVPQUzo=; b=AnTNnSSz5b1zsIY0NW3tIzuZH5+WUN8G+qAQij20cmQZZ8tsfIZ6+bEZ l8GC1/kgzpmjUPP+dEXSSlbhjuIWThQimPgknRqCgwfz2ZhlyN/VJjPxM 19tKq+wQpZPf/UzjdR5pWs4+Qwo5PZJ61ZM5E8ImWTwPu9gKkSBctO7Wr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAgDOpTNX/5ldJa1VCYQNgQO5Mw2Bd?= =?us-ascii?q?oYUAoE+OBQBAQEBAQEBZSeEQgEBBTo/DAQCAQgRAQMBAQEeEDIXBggBAQQBDQ2?= =?us-ascii?q?IJw66XgSGIIRMhBEHCgGFdQWYJwGOFoFwhE+IYY9AAR4CQoNriEM2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="271628577" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2016 21:39:30 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4BLdUDS032706 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 May 2016 21:39:30 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 16:39:29 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Wed, 11 May 2016 16:39:29 -0500 From: "Les Ginsberg (ginsberg)" To: "Joe Clarke (jclarke)" , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQBnClYAAieCg0AALuo+AAACzD3Q Date: Wed, 11 May 2016 21:39:29 +0000 Message-ID: <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> In-Reply-To: <978721df-6b95-dff7-af53-31d42a731946@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.120.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 21:41:51 -0000 Joe - Yes - this looks better to me. What about the "shadow boxes" for Applications/Clients? Les > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Wednesday, May 11, 2016 8:19 AM > To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.or= g > Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >=20 > On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: > > Joe - > > > > Apologies for the delayed response. I am a victim of my own email > > infilters. :-( Inline. >=20 > Thanks, Les. Have a look at > https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- > 10.diff.html > . I added a new line to show the flow in both directions. >=20 > Joe >=20 > > > >> -----Original Message----- > >> From: Joe Clarke (jclarke) > >> Sent: Friday, April 29, 2016 10:44 AM > >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >> i2rs@ietf.org > >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >> > >> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: > >>> Summary: This document is a well written document - easy to > understand. > >>> My compliments to the authors. I believe there is one minor issue > >>> which I would like to see addressed before publication. > >> > >> Thanks for your comments and feedback, Les. Please see below for > >> some replies and questions. > >> > >>> In Section 5.2 there is a definition of the information which is > >>> required to be kept by an I2RS Agent for each I2RS interaction. I > >>> would like to see the addition of "Request State" into this list. > >>> Operationally each request could be in one of the following states: > >>> > >>> > >>> > >>> * Enqueued (or pending if you prefer) > >>> > >>> * In process > >>> > >>> * Completed > >>> > >>> > >>> > >>> The lack of such a state seems to imply that both the queue time and > >>> the processing time are insignificant. While I think this may be the > >>> case for many requests, it will not always be the case. In queue > >>> time may be lengthy due to other load on the Agent. Also, some > >>> requests - particularly destructive requests which involve cleanup > >>> of resources - may take a significant amount of time to complete. > >> > >> Good observation. Traceability was aimed mainly at the termination > >> of the request, but I like the idea of tracing the state machine. > >> > >>> > >>> > >>> > >>> Along with this an additional timestamp - Processing Initiated - > >>> would be useful to indicate when processing of the request actually > began. > >> > >> I don't know we need a new timestamp. Perhaps we just need to > rename > >> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and > >> "End Timestamp" to denote the time within the current state. What do > >> you think? > > > > [Les:] My intent was to log the time at which the request began process= ing > so that you can see whether a long delay in completion was due to enqueue > delay or actual lengthy processing time. I am not adamant about this so i= f you > want to stay with the two timestamps that is OK. > > > >> > >>> s/Some notable elements on the architecture/ Some notable elements > >>> of the architecture > >> > >> Fixed. Thanks! > >> > >>> > >>> > >>> > >>> Figure 1 > >>> > >>> > >>> > >>> Not clear to me why Application IDs start at 0 but Client IDs start a= t 1. > >> > >> Ah. The numbers there are not IDs. They are the number of actual > >> things in the boxes above. For Applications, there may be 0 to N for > >> a given client. For Clients, you need at least 1. Does that make sen= se? > >> > > [Les:] Maybe you want to use "shadows" on the boxes to indicate there > can be multiple Application boxes and multiple Client boxes? > > What you say makes sense but I do not intuit that when I look at the AS= SCII > art. > > > >>> > >>> > >>> > >>> Figure 1 > >>> > >>> > >>> > >>> Is the text "Op Data V" between I2RS Agent box and Routing System > >>> box intentional? > >> > >> Yes. The 'V' is meant to be an arrow head pointed down. The request > >> and data go from Client to Agent whereas the Response goes from Agent > >> to Client. > >> > >> We are open to suggestions on how to make this clearer. > > > > [Les:] I think it would be clearer if you had two lines - one flowing d= own > associated with the Op Data and one flowing up with the result. > > > >> > >>> > >>> > >>> > >>> Section 5.2 > >>> > >>> > >>> > >>> Secondary Identity > >>> > >>> > >>> > >>> This is defined to be "opaque" yet if not provided the agent is > >>> supposed to insert "an UNAVAILABLE value". This seems to be a > >>> contradiction unless we have a publicly defined value that clients > >>> are prohibited from using. Absent that you would need a "Secondary > Identity Valid" indicator. > >> > >> Good observation. I think it's fine to say that this field must be > >> logged. If there is no application, then the field will be logged as > >> empty. If there is an application, then whatever value is provided > >> will be logged. > >> > >> Do you feel strongly that we need a field to indicate Application Pres= ent? > >> > > [Les:] I am fine w your changes. > > > > Les > > > >>> > >>> > >>> > >>> Section 7.4 > >>> > >>> > >>> > >>> s/establish an vendor-agnostic/establish a vendor-agnostic > >> > >> Fixed. Thanks! > >> > >> Joe From nobody Wed May 11 15:21:27 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B75B12D593; Wed, 11 May 2016 15:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyI9TxUTJFxJ; Wed, 11 May 2016 15:21:22 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD42012D521; Wed, 11 May 2016 15:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5767; q=dns/txt; s=iport; t=1463005281; x=1464214881; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=d2y/tUeJvte8NefVuXPFq0hD1EI5W1TMsyNghZz9tuI=; b=dqWh5EqN5lJ+0Vqz/M3XreL7kQsfazptNHwAr63R/PYcY9/JVzLaoiif qgl4YafvOH5ugicC3o3pSbkUgdp6JlBJO+4QDBZLIUYEoqChSb1AqUk/D 7bX12hkz0i9HFNd5yNKPZAu/jEk6Lf4EnaPWPkP715T3P1eYgpXhkbuFA 8=; X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="272403085" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2016 22:21:00 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4BML0YX008578; Wed, 11 May 2016 22:21:00 GMT To: "Les Ginsberg (ginsberg)" , "rtg-ads@ietf.org" References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> Date: Wed, 11 May 2016 18:20:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 22:21:24 -0000 On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: > Joe - > > Yes - this looks better to me. > > What about the "shadow boxes" for Applications/Clients? Do you have an example draft I could look at for that? Joe > > Les > > >> -----Original Message----- >> From: Joe Clarke (jclarke) >> Sent: Wednesday, May 11, 2016 8:19 AM >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.org >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >> >> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: >>> Joe - >>> >>> Apologies for the delayed response. I am a victim of my own email >>> infilters. :-( Inline. >> >> Thanks, Les. Have a look at >> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- >> 10.diff.html >> . I added a new line to show the flow in both directions. >> >> Joe >> >>> >>>> -----Original Message----- >>>> From: Joe Clarke (jclarke) >>>> Sent: Friday, April 29, 2016 10:44 AM >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; >>>> i2rs@ietf.org >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >>>> >>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: >>>>> Summary: This document is a well written document - easy to >> understand. >>>>> My compliments to the authors. I believe there is one minor issue >>>>> which I would like to see addressed before publication. >>>> >>>> Thanks for your comments and feedback, Les. Please see below for >>>> some replies and questions. >>>> >>>>> In Section 5.2 there is a definition of the information which is >>>>> required to be kept by an I2RS Agent for each I2RS interaction. I >>>>> would like to see the addition of "Request State" into this list. >>>>> Operationally each request could be in one of the following states: >>>>> >>>>> >>>>> >>>>> * Enqueued (or pending if you prefer) >>>>> >>>>> * In process >>>>> >>>>> * Completed >>>>> >>>>> >>>>> >>>>> The lack of such a state seems to imply that both the queue time and >>>>> the processing time are insignificant. While I think this may be the >>>>> case for many requests, it will not always be the case. In queue >>>>> time may be lengthy due to other load on the Agent. Also, some >>>>> requests - particularly destructive requests which involve cleanup >>>>> of resources - may take a significant amount of time to complete. >>>> >>>> Good observation. Traceability was aimed mainly at the termination >>>> of the request, but I like the idea of tracing the state machine. >>>> >>>>> >>>>> >>>>> >>>>> Along with this an additional timestamp - Processing Initiated - >>>>> would be useful to indicate when processing of the request actually >> began. >>>> >>>> I don't know we need a new timestamp. Perhaps we just need to >> rename >>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and >>>> "End Timestamp" to denote the time within the current state. What do >>>> you think? >>> >>> [Les:] My intent was to log the time at which the request began processing >> so that you can see whether a long delay in completion was due to enqueue >> delay or actual lengthy processing time. I am not adamant about this so if you >> want to stay with the two timestamps that is OK. >>> >>>> >>>>> s/Some notable elements on the architecture/ Some notable elements >>>>> of the architecture >>>> >>>> Fixed. Thanks! >>>> >>>>> >>>>> >>>>> >>>>> Figure 1 >>>>> >>>>> >>>>> >>>>> Not clear to me why Application IDs start at 0 but Client IDs start at 1. >>>> >>>> Ah. The numbers there are not IDs. They are the number of actual >>>> things in the boxes above. For Applications, there may be 0 to N for >>>> a given client. For Clients, you need at least 1. Does that make sense? >>>> >>> [Les:] Maybe you want to use "shadows" on the boxes to indicate there >> can be multiple Application boxes and multiple Client boxes? >>> What you say makes sense but I do not intuit that when I look at the ASSCII >> art. >>> >>>>> >>>>> >>>>> >>>>> Figure 1 >>>>> >>>>> >>>>> >>>>> Is the text "Op Data V" between I2RS Agent box and Routing System >>>>> box intentional? >>>> >>>> Yes. The 'V' is meant to be an arrow head pointed down. The request >>>> and data go from Client to Agent whereas the Response goes from Agent >>>> to Client. >>>> >>>> We are open to suggestions on how to make this clearer. >>> >>> [Les:] I think it would be clearer if you had two lines - one flowing down >> associated with the Op Data and one flowing up with the result. >>> >>>> >>>>> >>>>> >>>>> >>>>> Section 5.2 >>>>> >>>>> >>>>> >>>>> Secondary Identity >>>>> >>>>> >>>>> >>>>> This is defined to be "opaque" yet if not provided the agent is >>>>> supposed to insert "an UNAVAILABLE value". This seems to be a >>>>> contradiction unless we have a publicly defined value that clients >>>>> are prohibited from using. Absent that you would need a "Secondary >> Identity Valid" indicator. >>>> >>>> Good observation. I think it's fine to say that this field must be >>>> logged. If there is no application, then the field will be logged as >>>> empty. If there is an application, then whatever value is provided >>>> will be logged. >>>> >>>> Do you feel strongly that we need a field to indicate Application Present? >>>> >>> [Les:] I am fine w your changes. >>> >>> Les >>> >>>>> >>>>> >>>>> >>>>> Section 7.4 >>>>> >>>>> >>>>> >>>>> s/establish an vendor-agnostic/establish a vendor-agnostic >>>> >>>> Fixed. Thanks! >>>> >>>> Joe > From nobody Fri May 13 05:17:53 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4C812D185; Fri, 13 May 2016 05:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRb9OSKC4l-h; Fri, 13 May 2016 05:17:50 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BB112D18F; Fri, 13 May 2016 05:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10242; q=dns/txt; s=iport; t=1463141869; x=1464351469; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=On3CJIF6VoY7nRclT4NZ3E3ygT2jTMQgcPPkMD304g8=; b=eZSFZjFzN4VXwoQjEMu+3preUDZ0dVfzj7B/RT6aNcSqy68LYLah1tTp 1cEZ+c8zMz62YQc/lRmsoQ2yT+5W2yqI6gAUUvhj5T4glE+GOp4WubBTW xosX+bIPPe0mTR+hLVVy12E79SXNUw2Iguwl4RgSdkkb2UN8Zcjo/mYpa E=; X-Files: shadow.txt : 2271 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AgDgxDVX/5xdJa1VCYM3VX4GuVEOg?= =?us-ascii?q?XYihXICgS84FAEBAQEBAQFlJ4RCAQEBBCdSDAQCAQgRAQMBAQEuAjAXBggCBAE?= =?us-ascii?q?NBQgGiCEOv24BAQEBAQEBAQEBAQEBAQEBAQEBAQEOCQWGJYRNhBEHCgEzhUIBB?= =?us-ascii?q?Id+kCkBgyiBaIkGgXCET4hhj0ABHgFDg2xuAYckNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="txt'?scan'208";a="273254413" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 12:17:48 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4DCHmMK027746 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 12:17:48 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 07:17:48 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Fri, 13 May 2016 07:17:47 -0500 From: "Les Ginsberg (ginsberg)" To: "Joe Clarke (jclarke)" , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQBnClYAAieCg0AALuo+AAACzD3QAAvztwAARQFW8A== Date: Fri, 13 May 2016 12:17:47 +0000 Message-ID: <30733d2a0880449dbd5cf930c48ad6be@XCH-ALN-001.cisco.com> References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> In-Reply-To: <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.134] Content-Type: multipart/mixed; boundary="_002_30733d2a0880449dbd5cf930c48ad6beXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 12:17:52 -0000 --_002_30733d2a0880449dbd5cf930c48ad6beXCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe - Something like the attached file perhaps? Les > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Wednesday, May 11, 2016 3:21 PM > To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.or= g > Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >=20 > On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: > > Joe - > > > > Yes - this looks better to me. > > > > What about the "shadow boxes" for Applications/Clients? >=20 > Do you have an example draft I could look at for that? >=20 > Joe >=20 > > > > Les > > > > > >> -----Original Message----- > >> From: Joe Clarke (jclarke) > >> Sent: Wednesday, May 11, 2016 8:19 AM > >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >> i2rs@ietf.org > >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >> > >> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: > >>> Joe - > >>> > >>> Apologies for the delayed response. I am a victim of my own email > >>> infilters. :-( Inline. > >> > >> Thanks, Les. Have a look at > >> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- > >> 10.diff.html > >> . I added a new line to show the flow in both directions. > >> > >> Joe > >> > >>> > >>>> -----Original Message----- > >>>> From: Joe Clarke (jclarke) > >>>> Sent: Friday, April 29, 2016 10:44 AM > >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >>>> i2rs@ietf.org > >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >>>> > >>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: > >>>>> Summary: This document is a well written document - easy to > >> understand. > >>>>> My compliments to the authors. I believe there is one minor issue > >>>>> which I would like to see addressed before publication. > >>>> > >>>> Thanks for your comments and feedback, Les. Please see below for > >>>> some replies and questions. > >>>> > >>>>> In Section 5.2 there is a definition of the information which is > >>>>> required to be kept by an I2RS Agent for each I2RS interaction. I > >>>>> would like to see the addition of "Request State" into this list. > >>>>> Operationally each request could be in one of the following states: > >>>>> > >>>>> > >>>>> > >>>>> * Enqueued (or pending if you prefer) > >>>>> > >>>>> * In process > >>>>> > >>>>> * Completed > >>>>> > >>>>> > >>>>> > >>>>> The lack of such a state seems to imply that both the queue time > >>>>> and the processing time are insignificant. While I think this may > >>>>> be the case for many requests, it will not always be the case. In > >>>>> queue time may be lengthy due to other load on the Agent. Also, > >>>>> some requests - particularly destructive requests which involve > >>>>> cleanup of resources - may take a significant amount of time to > complete. > >>>> > >>>> Good observation. Traceability was aimed mainly at the termination > >>>> of the request, but I like the idea of tracing the state machine. > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Along with this an additional timestamp - Processing Initiated - > >>>>> would be useful to indicate when processing of the request > >>>>> actually > >> began. > >>>> > >>>> I don't know we need a new timestamp. Perhaps we just need to > >> rename > >>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" > and > >>>> "End Timestamp" to denote the time within the current state. What > >>>> do you think? > >>> > >>> [Les:] My intent was to log the time at which the request began > >>> processing > >> so that you can see whether a long delay in completion was due to > >> enqueue delay or actual lengthy processing time. I am not adamant > >> about this so if you want to stay with the two timestamps that is OK. > >>> > >>>> > >>>>> s/Some notable elements on the architecture/ Some notable > elements > >>>>> of the architecture > >>>> > >>>> Fixed. Thanks! > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Figure 1 > >>>>> > >>>>> > >>>>> > >>>>> Not clear to me why Application IDs start at 0 but Client IDs start= at 1. > >>>> > >>>> Ah. The numbers there are not IDs. They are the number of actual > >>>> things in the boxes above. For Applications, there may be 0 to N > >>>> for a given client. For Clients, you need at least 1. Does that ma= ke > sense? > >>>> > >>> [Les:] Maybe you want to use "shadows" on the boxes to indicate > >>> there > >> can be multiple Application boxes and multiple Client boxes? > >>> What you say makes sense but I do not intuit that when I look at the > >>> ASSCII > >> art. > >>> > >>>>> > >>>>> > >>>>> > >>>>> Figure 1 > >>>>> > >>>>> > >>>>> > >>>>> Is the text "Op Data V" between I2RS Agent box and Routing System > >>>>> box intentional? > >>>> > >>>> Yes. The 'V' is meant to be an arrow head pointed down. The > >>>> request and data go from Client to Agent whereas the Response goes > >>>> from Agent to Client. > >>>> > >>>> We are open to suggestions on how to make this clearer. > >>> > >>> [Les:] I think it would be clearer if you had two lines - one > >>> flowing down > >> associated with the Op Data and one flowing up with the result. > >>> > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Section 5.2 > >>>>> > >>>>> > >>>>> > >>>>> Secondary Identity > >>>>> > >>>>> > >>>>> > >>>>> This is defined to be "opaque" yet if not provided the agent is > >>>>> supposed to insert "an UNAVAILABLE value". This seems to be a > >>>>> contradiction unless we have a publicly defined value that clients > >>>>> are prohibited from using. Absent that you would need a "Secondary > >> Identity Valid" indicator. > >>>> > >>>> Good observation. I think it's fine to say that this field must be > >>>> logged. If there is no application, then the field will be logged > >>>> as empty. If there is an application, then whatever value is > >>>> provided will be logged. > >>>> > >>>> Do you feel strongly that we need a field to indicate Application > Present? > >>>> > >>> [Les:] I am fine w your changes. > >>> > >>> Les > >>> > >>>>> > >>>>> > >>>>> > >>>>> Section 7.4 > >>>>> > >>>>> > >>>>> > >>>>> s/establish an vendor-agnostic/establish a vendor-agnostic > >>>> > >>>> Fixed. Thanks! > >>>> > >>>> Joe > > --_002_30733d2a0880449dbd5cf930c48ad6beXCHALN001ciscocom_ Content-Type: text/plain; name="shadow.txt" Content-Description: shadow.txt Content-Disposition: attachment; filename="shadow.txt"; size=2271; creation-date="Fri, 13 May 2016 12:06:05 GMT"; modification-date="Fri, 13 May 2016 12:16:43 GMT" Content-Transfer-Encoding: base64 DQoNCiAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0rICB8DQogICAgICAgICB8QXBwbGljYXRpb24gICAgIHwgIHwNCiAgICAgICAgIHwuLi4u Li4uLi4uLi4uLiAgfCAgfCAgMCBvciBtb3JlIEFwcGxpY2F0aW9ucw0KICAgICAgICAgfCBBcHBs aWNhdGlvbiBJRCB8ICArDQogICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAg ICAgICBeDQogICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg ICAgICB2DQogICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQogICAgICAgICArLS0tLS0tLS0t LS0tLSsgICB8DQogICAgICAgICB8STJSUyBDbGllbnQgIHwgICB8ICAgMSBvciBtb3JlIENsaWVu dHMNCiAgICAgICAgIHwuLi4uLi4uLi4uLi4ufCAgIHwNCiAgICAgICAgIHwgIENsaWVudCBJRCAg fCAgICsNCiAgICAgICAgICstLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgIF4NCiAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHYNCiAgICAg ICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KICAgICAgICAgfEkyUlMgQWdlbnQgICB8LS0tLS0tLS0tLS0tLS0tLT58VHJh Y2UgTG9nICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICB8ICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgIHwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLnwNCiAgICAgICAgICst LS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgfExvZyBFbnRyeSAgWzEgLi4gTl0gICAgICAg ICAgfA0KICAgICAgICAgICAgICAgIF4gICAgICAgICAgICAgICAgICAgICAgICB8Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi58DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIHxTdGFydGluZyBUaW1lc3RhbXAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgfFJlcXVlc3QgU3RhdGUgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8Q2xpZW50IElEICAgICAg ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg IHxDbGllbnQgUHJpb3JpdHkgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAg XiAgICAgICAgICAgICAgICAgfFNlY29uZGFyeSBJRCAgICAgICAgICAgICAgICAgfA0KICAgIE9w ZXJhdGlvbiArIHwgUmVzdWx0IENvZGUgICAgICAgICAgICB8Q2xpZW50IEFkZHJlc3MgICAgICAg ICAgICAgICB8DQogICAgIE9wIERhdGEgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHxSZXF1 ZXN0ZWQgT3BlcmF0aW9uICAgICAgICAgIHwNCiAgICAgICB2ICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgfEFwcGxpZWQgT3BlcmF0aW9uICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8T3BlcmF0aW9uIERhdGEgUHJlc2VudCAgICAg ICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHxSZXF1ZXN0ZWQg T3BlcmF0aW9uIERhdGEgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgfEFwcGxpZWQgT3BlcmF0aW9uIERhdGEgICAgICAgfA0KICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICB8VHJhbnNhY3Rpb24gSUQgICAgICAgICAgICAgICB8DQog ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHxSZXN1bHQgQ29kZSAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fEVuZGluZyBUaW1lc3RhbXAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICB8VGltZW91dCBPY2N1cnJlZCAgICAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgdiAgICAgICAgICAgICAgICAgICAgICAgIHxFbmQgT2YgTWVzc2FnZSAgICAgICAg ICAgICAgIHwNCiAgICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgfFJvdXRpbmcgICAgICB8DQogICAg ICAgICB8U3lzdGVtICAgICAgIHwNCiAgICAgICAgICstLS0tLS0tLS0tLS0tKw0K --_002_30733d2a0880449dbd5cf930c48ad6beXCHALN001ciscocom_-- From nobody Fri May 13 08:20:18 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA14612D57F; Fri, 13 May 2016 08:20:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513152013.10628.98871.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 08:20:13 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-pub-sub-requirements-08.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:20:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : Requirements for Subscription to YANG Datastores Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Filename : draft-ietf-i2rs-pub-sub-requirements-08.txt Pages : 17 Date : 2016-05-13 Abstract: This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Netconf and Restconf). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-pub-sub-requirements-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 13 08:26:41 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A945512D565; Fri, 13 May 2016 08:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VSm9B3lGst2; Fri, 13 May 2016 08:26:30 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8870912B00A; Fri, 13 May 2016 08:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59074; q=dns/txt; s=iport; t=1463153189; x=1464362789; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Gp/nVIK6kVzhZNYDQ35c1eDyNq8nJxoUZom+EFJVNFg=; b=Wx5M/S+fha9y8BaCA+u9NJ0cJvJzVUiU8j+dpXleW0FGfCWm5T82Rtc6 ovLF15udH/MmmnghAAodtbtudyuWzGQBYIX5z+P9lUx/kYzEBOKQCsTfp HbESArGDX8j9i52qxl2dMfGrX7aXX4g0n4sWmJB9aGmXt6uEVU+b0BUMe I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAgAt8TVX/5pdJa1egmxLVX4GuVABD?= =?us-ascii?q?YFyBBcBCoI9gzICHIEQOBQBAQEBAQEBZSeEQgEBAQMBAQEBFwkKQQsFBwQCAQg?= =?us-ascii?q?OAwMBAQEBDAETAQIEAwICAiULFAkIAgQBDQUIE4gMCA6vfJENAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWGJYRNhBERAQY2FoJKglkFhjsJgTqLMoR3AYV9gniFIYF?= =?us-ascii?q?whE+IYYYtiRMBHgEBQoIGGxaBNW6HHAUEFx9/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208,217";a="273092399" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 15:26:27 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4DFQQPx029587 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 15:26:27 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 11:26:25 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Fri, 13 May 2016 11:26:25 -0400 From: "Eric Voit (evoit)" To: Susan Hares , Ben Campbell , "Alia Atlas (akatlas@gmail.com)" Thread-Topic: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRp+xNYDspbfuo4UOD+L2iwgAMip+3BC7g Date: Fri, 13 May 2016 15:26:25 +0000 Message-ID: <9e9692bd22a041ba91e39a9f7dce8c9e@XCH-RTP-013.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_9e9692bd22a041ba91e39a9f7dce8c9eXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , The IESG , "i2rs-chairs@ietf.org" Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:26:34 -0000 --_000_9e9692bd22a041ba91e39a9f7dce8c9eXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVuLA0KDQpJIGhhdmUgYWRkZWQgdGhlIHRleHQgYmVsb3cgYXMgdGhlIGxlYWQtaW4gdG8g c2VjdGlvbiA0LjIuNS4gIEkgYmVsaWV2ZSB0aGlzIG1lZXRzIHRoZSBpbnRlbnRzIG9mIHlvdXIg c3VnZ2VzdGlvbnMgYmVsb3cuDQoNCkhpIFN1c2FuICYgQWxpYSwNCg0KSSBoYXZlIHVwbG9hZGVk IHYwOCBvZg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJz LXB1Yi1zdWItcmVxdWlyZW1lbnRzLw0KSWYgQmVuIGNvbmN1cnMgd2l0aCB0aGUgdGV4dCBiZWxv dywgSSBhbSBub3QgYXdhcmUgb2YgYW55IHJlbWFpbmluZyBkaXNjdXNzIGl0ZW1zLg0KDQpUaGFu a3MgZXZlcnlvbmUgZm9yIHlvdXIgcmV2aWV3cywNCkVyaWMsIEFsZXgsICYgQWxiZXJ0bw0KDQo0 LjIuNS4gIFNlY3VyaXR5IFJlcXVpcmVtZW50cw0KDQoNCg0KICAgU29tZSB1c2VzIG9mIHRoaXMg U3Vic2NyaXB0aW9uIFNlcnZpY2Ugd2lsbCBwdXNoIHByaXZhY3ktc2Vuc2l0aXZlDQoNCiAgIHVw ZGF0ZXMgYW5kIG1ldGFkYXRhLiAgR29vZCBkZXBsb3ltZW50IHByYWN0aWNlcyB3aWxsIGJpbmQg dGhpcw0KDQogICBnZW5lcmF0ZWQgaW5mb3JtYXRpb24gd2l0aGluIHNlY3VyZSwgZW5jcnlwdGVk IHRyYW5zcG9ydCBsYXllcg0KDQogICBtZWNoYW5pc21zLiAgRm9yIGV4YW1wbGUgaWYgTkVUQ09O RiBpcyB1c2VkIGFzIHRyYW5zcG9ydCwgdGhlbg0KDQogICBbUkZDNTUzOV0gd291bGQgYmUgYSB2 YWxpZCBvcHRpb24gdG8gc2VjdXJlIHRoZSB0cmFuc3BvcnRlZA0KDQogICBpbmZvcm1hdGlvbi4g IFRoZSBTdWJzY3JpcHRpb24gU2VydmljZSBjYW4gYWxzbyBiZSB1c2VkIHdpdGggZW1lcmdpbmcN Cg0KICAgZGVwbG95bWVudCBjb250ZXh0cyBhcyB3ZWxsLiAgQXMgYW4gZXhhbXBsZSwgZGVwbG95 bWVudHMgYmFzZWQgb24NCg0KICAgW2kycnMtdXNlY2FzZV0gY2FuIGFwcGx5IHRoZXNlIHJlcXVp cmVtZW50cyBpbiBjb25qdW5jdGlvbiB3aXRoIHRob3NlDQoNCiAgIGRvY3VtZW50ZWQgd2l0aGlu IFtpMnJzLXByb3RvY29sLXNlY3VyaXR5XSB0byBzZWN1cmUgZXBoZW1lcmFsIHN0YXRlDQoNCiAg IGluZm9ybWF0aW9uIGJlaW5nIHB1c2hlZCBmcm9tIGEgTmV0d29yayBFbGVtZW50Lg0KDQoNCg0K RnJvbTogU3VzYW4gSGFyZXMgW21haWx0bzpzaGFyZXNAbmR6aC5jb21dDQpTZW50OiBGcmlkYXks IE1heSAwNiwgMjAxNiA3OjA5IFBNDQpUbzogQmVuIENhbXBiZWxsDQpDYzogRXJpYyBWb2l0IChl dm9pdCk7IFRoZSBJRVNHOyBpMnJzQGlldGYub3JnOyBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1y ZXF1aXJlbWVudHNAaWV0Zi5vcmc7IGkycnMtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWIt cmVxdWlyZW1lbnRzLTA2OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpCZW46DQoNClRo aXMgaXMgd2lzZSBpZGVhLiAgSSB3aWxsIHN1Z2dlc3Qgc29tZSB0ZXh0IHRvIEVyaWMgYW5kIHlv dSBpbiB0aGUgbW9ybmluZy4NCg0KU3VlDQoNCg0KDQpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxh eHkgTm90ZTUsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUNCi0tLS0tLS0tIE9yaWdpbmFsIG1l c3NhZ2UgLS0tLS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0 bzpiZW5Abm9zdHJ1bS5jb20+Pg0KRGF0ZTogNS82LzIwMTYgMjozOCBQTSAoR01ULTA2OjAwKQ0K VG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+ DQpDYzogRXJpYyBWb2l0IDxldm9pdEBjaXNjby5jb208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+ LCBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+LCBpMnJzQGll dGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPiwgZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVx dWlyZW1lbnRzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJl bWVudHNAaWV0Zi5vcmc+LCBpMnJzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aTJycy1jaGFpcnNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24g ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2OiAod2l0aCBESVNDVVNTIGFu ZCBDT01NRU5UKQ0KDQpIaSBTdXNhbiwNCg0KVG8gYmUgY2xlYXIsIEkgZG8gbm90IG9iamVjdCB0 byB0aGUgd2lkZXIgY29udGV4dCBwZXIgc2UuIE15IGNvbmNlcm4gaXMNCnRoYXQgdGhlIHNlY3Vy aXR5IGFuZCBwcml2YWN5IHJlcXVpcmVtZW50cyBhcmUgbGVmdCBhcyBpbXBsaWNpdCwgYmFzZWQN Cm9uIHRoZSBtb3JlIG5hcnJvdyBpMnJzL25ldGNvbmYgY29udGV4dC4gSSBvbmx5IG1lbnRpb25l ZCB0aGUgcG90ZW50aWFsDQpvZiByZXN0cmljdGluZyB0aGUgY29udGV4dGFzIG9uZSBwb3NzaWJs ZSB3YXkgZm9yd2FyZDsgSSBhbSBjZXJ0YWlubHkNCm5vdCB3ZWRkZWQgdG8gaXQuDQoNCk15IHN1 Z2dlc3Rpb24gZm9yIGEgd2F5IGZvcndhcmQgd291bGQgYmUgdG8gZG9jdW1lbnQgdGhlIGhpZ2gg bGV2ZWwNCnNlY3VyaXR5IGFuZCBwcml2YWN5IHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50 LiBJSVVDLCB0aGUgbGFyZ2VyDQpjb250ZXh0IGluY2x1ZGVzIHBvdGVudGlhbGx5IHVua25vd24g Y29udGV4dHMsIHNvIHNvbWUgb2YgdGhpcyBtYXkgbmVlZA0KdG8gYmUgY29uZGl0aW9uYWwuIEZv ciBleGFtcGxlLCBsYW5ndWFnZSBsaWtlIHRoZSBmb2xsb3dpbmcgbWlnaHQgYmUNCmhlbHBmdWwg KHRoaXMgaXMganVzdCBhbiBleGFtcGxlLS1JIGRvbid0IG1lYW4gdG8gc2F5IHRoYXQgaXQgaXMg dHJ1ZSBvcg0KYXBwbGljYWJsZSk6DQoNCiAgIlNvbWUgdXNlcyBvZiB0aGlzIG1lY2hhbmlzbSBt YXkgY2FycnkgcHJpdmFjeS1zZW5zaXRpdmUgaW5mb3JtYXRpb24sDQpvciBnZW5lcmF0ZSAgICBw cml2YWN5LXNlbnNpdGl2ZSBtZXRhZGF0YSB0aHJvdWdoIHRoZSBzdWJzY3JpcHRpb24NCm1lY2hh bmlzbS4gSW4gY29udGV4dHMgd2hlcmUgdGhpcyBpcyB0cnVlLCB0aGUgZm9sbG93aW5nIHJlcXVp cmVtZW50cw0KYXBwbHkuLi4iDQoNCkl0IG1pZ2h0IGFsc28gYmUgcmVhc29uYWJsZSB0byBzYXkg dGhhdCwgZm9yIHRoZSBjb250ZXh0IG9mIGkycnMsIHRoZXNlDQpyZXF1aXJlbWVudHMgYXJlIGRv Y3VtZW50ZWQgaW4gW3JlZmVyZW5jZXNdIGFuZCBhcmUgZXhwZWN0ZWQgdG8gYmUNCmZ1bGZpbGxl ZCBieSB0aGUgW3RyYW5zcG9ydCBhbmQgb3IgcHJvdG9jb2xdDQoNCkVyaWMncyBlbWFpbCBhbHNv IHN1Z2dlc3RlZCB0aGF0IHRoZSBhY3R1YWwgdHJhbnNwb3J0IG9mIGRhdGEgZnJvbSB0aGUNCllh bmcgZGF0YXN0b3JlIG1heSBiZSBvdXQgb2Ygc2NvcGUgZm9yIHRoZXNlIHJlcXVpcmVtZW50cy4g SSBkb24ndA0Kb2JqZWN0IHRvIHRoYXQsIGVpdGhlciwgYXMgbG9uZyBhcyBpdCBpcyBjbGVhciBh bmQgZXhwbGljaXQsIGFsdGhvdWdoIGl0DQp3b3VsZCBiZSBnb29kIHRvIHBvaW50IHRvIHdoZXJl IGl0IGlzIF9pbl8gc2NvcGUuDQoNClRoYW5rcyENCg0KQmVuLg0KDQpPbiA2IE1heSAyMDE2LCBh dCAxOjA2LCBTdXNhbiBIYXJlcyB3cm90ZToNCg0KPiBCZW46DQo+DQo+IFRoaXMgaXMgdGhlIGZp cnN0IG9mIHRoZSAicmUtdXNlIiBtYW5hZ2VtZW50IHByb3RvY29scy4gIFRoZQ0KPiByZXF1aXJl bWVudHMNCj4gYXJlIHNldC11cCBzbyB0aGF0IHdlIGNhbiBzdWdnZXN0IGFkZGl0aW9ucyB0byB0 aGUgTkVUQ09ORiBhbmQNCj4gUkVTVENPTkYgZm9yDQo+IHRoaXMgZmlyc3Qgb2YgSTJSUy4NCj4N Cj4gVGhlIEkyUlMgZXBoZW1lcmFsIHdvcmssIHB1Yi9zdWIsIHRyYWNlYWJpbGl0eSwgYW5kIHNl Y3VyaXR5IGFyZQ0KPiB0YXJnZXQgYXQNCj4gdGhlIEkyUlMgcHJvdG9jb2wgZGVmaW5pdGlvbiB3 aXRoIHRoZSBJMlJTIHVzZSBjYXNlLiAgSG93ZXZlciwgc2luY2UNCj4gdGhlc2UNCj4gYXJlIGdl bmVyYWwgYWRkaXRpb25zIHRvIE5FVENPTkYvUkVTVENPTkYsIHRoaXMgd29yayBjYW4gYmUgdXNl ZA0KPiBlbHNld2hlcmUuDQo+DQo+IEkgdGhpbmsgdGhlIHRleHQgeW91IGFyZSBoaWdobGlnaHRp bmcgaGFzIHRoaXMgbGFyZ2VyIGNvbnRleHQuICAgTm93LA0KPiBvbmUgb2YNCj4gdGhlIHJlYWxs eSBpbXBvcnRhbnQgdGhpbmdzIHRvIGNoYXQgd2l0aCBBbGlhIGFuZCBCZW5vaXQgaXMgaG93IGRv IHdlDQo+IGhhbmRsZQ0KPiB0aGUgd2lkZXIgdXNlIGNhc2UuICAgRG8gd2UgbWVudGlvbiB0aGUg d2lkZXIgY29udGV4dD8NCj4NCj4gVGhlIFdHIHRob3VnaHQgbWVudGlvbmluZyBpdCB3YXMgaW1w b3J0YW50Lg0KPg0KPiBTdWUNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXQ0KPiBTZW50OiBUaHVyc2Rh eSwgTWF5IDA1LCAyMDE2IDU6MzEgUE0NCj4gVG86IFN1c2FuIEhhcmVzDQo+IENjOiBFcmljIFZv aXQ7IFRoZSBJRVNHOyBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsNCj4gZHJh ZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc+OyBpMnJzLWNoYWlyc0BpZXRm Lm9yZzxtYWlsdG86aTJycy1jaGFpcnNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbaTJyc10g QmVuIENhbXBiZWxsJ3MgRGlzY3VzcyBvbg0KPiBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1 aXJlbWVudHMtMDY6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+DQo+IE9uIDUgTWF5IDIw MTYsIGF0IDU6MTUsIFN1c2FuIEhhcmVzIHdyb3RlOg0KPg0KPj4gRXJpYywgQmVuIGFuZCBJRVNH IG1lbWJlcnM6DQo+Pg0KPj4NCj4+DQo+PiBUaGUgcHViL3N1YiByZXF1aXJlbWVudHMgYXJlIHBh cnQgb2YgYSA1IHBhcnQgcmVxdWlyZW1lbnRzLiAgIE1heSBJDQo+PiBxdW90ZQ0KPj4gZnJvbSB0 aGUgc2hlcGhlcmQncyByZXBvcnQ6DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0K Pj4gVGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIGZpcnN0IHZlcnNpb24gb2YgSTJSUyBhcmU6DQo+ Pg0KPj4gMSkgbW9kZWwgZHJpdmVuIGVwaGVtZXJhbCBzdGF0ZSAtIHRoYXQgaXMgZGF0YSBtb2Rl bHMgdGhhdCBkbyBub3QNCj4+IHN1cnZpdmUNCj4+DQo+PiAgICAgYSBzb2Z0d2FyZSBvciBoYXJk d2FyZSByZWJvb3QuDQo+Pg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS8NCj4+DQo+Pg0KPj4NCj4+IDIpIGEgc2VjdXJl IHByb3RvY29sIC0NCj4+DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxDQo+PiB1aXJlbWUNCj4+IG50cy8NCj4+ DQo+Pg0KPj4NCj4+IDMpIHRyYWNlYWJpbGl0eSAtIGFiaWxpdHkgdG8gcmVjb3JkIGludGVyYWN0 aW9ucyBiZXR3ZWVuIEkyUlMNCj4+IGVsZW1lbnRzDQo+Pg0KPj4gKENsaWVudCwgQWdlbnQsIFJv dXRpbmcgc3lzdGVtKQ0KPj4NCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaTJycy10cmFjZWFiaWxpdHkvDQo+Pg0KPj4NCj4+DQo+PiA0KSBub3RpZmljYXRp b24gcHVibGljYXRpb24gdmlhIHN1YnNjcmlwdGlvbg0KPj4NCj4+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy8NCj4+ DQo+Pg0KPj4NCj4+IDUpIFByb3RvY29sIHRvIHBhc3MgRGF0YSBmb3IgQW5hbHl0aWNzDQo+Pg0K Pj4gVGhlIGZpcnN0IHZlcnNpb24gb2YgdGhlc2UgcmVxdWlyZW1lbnRzIGRvZXMgbm90IGluY2x1 ZGUgYQ0KPj4NCj4+IHNlcGFyYXRlIGFuYWx5dGljYWwgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGFz IHRoZSBzaW1wbGUgdXNlIGNhc2VzIG1heQ0KPj4NCj4+IHBhc3MgaW5mb3JtYXRpb24gdmlhIHF1 ZXJ5L3BvbGwgb3IgdGhlIG5vdGlmaWNhdGlvbnMuDQo+Pg0KPj4NCj4+DQo+PiBUaGUgSTJSUyBw cm90b2NvbCBleGlzdHMgaW4gYW4gc2VjdXJlIGVudmlyb25tZW50IGRlc2NyaWJlZCBieToNCj4+ DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtc2Vj dXJpdHktZW52aXJvbm1lbnQtDQo+PiByZXFzLw0KPj4NCj4+DQo+Pg0KPj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4NCj4+DQo+Pg0KPj4gRXJpYyAtIFBlcmhhcHMgaXQgd291bGQgYmUg Z29vZCB0byBwb2ludCB0bzoNCj4+DQo+PiAuICAgICAgICAgZHJhZnQtaWV0Zi1pMnJzLXByb3Rv Y29sLXNlY3VyaXR5LXJlcXVpcmVtZW50cyBhbmQNCj4+DQo+PiAuICAgICAgICAgZHJhZnQtaWV0 Zi1pMnJzLXNlY3VyaXR5LWVudmlyb25tZW50LXJlcXMvDQo+Pg0KPj4NCj4+DQo+PiBCZW4gLSBD YW4geW91IHRlbGwgbWUgaG93IHRoZSBzaGVwaGVyZCByZXBvcnQgY291bGQgaGF2ZSBiZWVuDQo+ PiBjbGVhcmVyPw0KPj4gIFRoZQ0KPj4gSTJycyBwcm90b2NvbCBzZWN1cml0eSByZXF1aXJlbWVu dHMgcmVxdWlyZTogIGNvbmZpZGVudGlhbGl0eSwNCj4+IGVuY3J5cHRpb24sIHNlY3VyZSB0cmFu c3BvcnQsIHByb3RlY3Rpb24gYWdhaW5zdCByZXBsYXkgYXR0YWNrLA0KPj4gcHJvdGVjdGlvbiBh Z2FpbnN0IEREb1MgYXR0YWNrIChpZiBwb3NzaWJsZSkuDQo+DQo+IEkgdGhpbmsgbXkgY29uZnVz aW9uIGxpZXMgaW4gdGhlIGZhY3QgdGhhdCwgd2hpbGUgdGhlIHNoZXBoZXJkJ3MNCj4gd3JpdGV1 cA0KPiBzdHlsZXMgdGhpcyBkcmFmdCBhcyBwYXJ0IG9mIHRoZSBJMlJTIHByb3RvY29sIHJlcXVp cmVtZW50cywgdGhlIGRyYWZ0DQo+IGl0c2VsZiBjbGFpbXMgdG8gZGVzY3JpYmUgcmVxdWlyZW1l bnRzIGZvciBhIGdlbmVyYWxseSB1c2VmdWwgcHViLXN1Yg0KPiBpbnRlcmZhY2UgdG8gYSB5YW5n IGRhdGFzdG9yZS4gSXQncyBub3QgY2xlYXIgdG8gbWUgaG93IGFuZCB3aGVuIHRoZQ0KPiBJMlJT DQo+IHByb3RvY29sIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBhcHBseSB0byBpdC4gSWYgdGhlIGRl c2NyaWJlZCBpbnRlcmZhY2UNCj4gaXMNCj4gaW50ZW5kZWQgdG8gYmUgdXNlZnVsIGluIGNvbnRl eHRzIG90aGVyIHRoYW4gSTJSUyAoYW5kIHRoZSBkcmFmdA0KPiBleHBsaWNpdGx5DQo+IHNldHMg dGhhdCBleHBlY3RhdGlvbiBpbiAyLjIpLCBpdCBuZWVkcyB0byB0YWxrIG1vcmUgZ2VuZXJhbGx5 IGFib3V0DQo+IHNlY3VyaXR5IGFuZCBwcml2YWN5Lg0KPg0KPiBGb3IgZXhhbXBsZSwgaXQgbWln aHQgbWFrZSBzZW5zZSB0byBzYXkgdGhhdCBjZXJ0YWluIHNlY3VyaXR5DQo+IHJlcXVpcmVtZW50 cw0KPiBhcHBseSBpbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlIG1lY2hhbmlzbSBtaWdodCBjYXJy eSBwcml2YWN5DQo+IHNlbnNpdGl2ZQ0KPiBkYXRhLCBhbmQgdGhlbiBwb2ludCB0byB0aGUgaTJy cyByZXF1aXJlbWVudHMgZm9yIHdoZW4gdGhlIG1lY2hhbmlzbQ0KPiBpcyB1c2VkDQo+IGluIGFu IEkyUlMgY29udGV4dC4NCj4NCj4gQSBkaWZmZXJlbnQgYXBwcm9hY2ggbWlnaHQgYmUgdG8gbW9y ZSB0aWdodGx5IGNvbnN0cmFpbiB0aGlzIHRvIGkycnMNCj4NCj4+DQo+Pg0KPj4NCj4+IEJlbiAt IE9uIG9wdGluZyBpbiwgb25jZSB0aGUgcmVjZWl2ZSBhY2NlcHRzIGEgdHJhbnNwb3J0IGNvbm5l Y3Rpb24NCj4+IGZyb20gdGhlIEkyUlMgc2VydmVyIC0gaG93IGlzIHRoaXMgbm90IGFuIG9wdC1p biB0byByZWNlaXZlIGRhdGE/DQo+PiBXaGF0DQo+PiBhcmUgeW91IGxvb2tpbmcgZm9yPw0KPg0K PiBJIGd1ZXNzIHRoYXQgZGVwZW5kcyBvbiB0aGUgdHJhbnNwb3J0LiBUaGUgdHJhbnNwb3J0IHJl cXVpcmVtZW50cyBzYXkNCj4gdGhlDQo+IG1lY2hhbmlzbSBoYXMgdG8gd29yayBvdmVyIG11bHRp cGxlIHRyYW5zcG9ydHMuIFRoZSBsYXN0IHBhcmFncmFwaCBpbg0KPiA0LjIuNA0KPiBzYXlzICJJ biB0aGUgY2FzZSBvZiBjb25uZWN0aW9uLW9yaWVudGVkIHRyYW5zcG9ydHMuLi4iIHdoaWNoIHN1 Z2dlc3RzDQo+IHRoYXQNCj4gbm9uLWNvbm5lY3Rpb24tb3JpZW50ZWQgdHJhbnNwb3J0cyBhcmUg cG9zc2libGUuDQo+DQo+IEV2ZW4gd2l0aCBhIGNvbm5lY3Rpb24tb3JpZW50ZWQgdHJhbnNwb3J0 LCB0aGlzIG1heSBkZXBlbmQgb24gaG93DQo+IGNvbm5lY3Rpb24tbWFuYWdlbWVudCBpcyBoYW5k bGVkLCBhbmQgd2hldGhlciB0aGUgcmVjZWl2ZXIgbWlnaHQgYmUNCj4gcmVjZWl2aW5nIHRoaW5n cyBpdCBfd2FudHNfIHRvIHJlY2VpdmUgb24gdGhlIHNhbWUgdHJhbnNwb3J0Lg0KPg0KPj4NCj4+ DQo+Pg0KPj4gU3VlIEhhcmVzDQo+Pg0KPj4gKHNoZXBoZXJkKQ0KPj4NCj4+DQo+Pg0KPj4NCj4+ DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogaTJycyBbbWFpbHRvOmky cnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgVm9pdA0KPj4gKGV2b2l0KQ0K Pj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMDQsIDIwMTYgNzoyNSBQTQ0KPj4gVG86IEJlbiBDYW1w YmVsbDsgVGhlIElFU0cNCj4+IENjOiBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3Jn PjsgZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc+Ow0KPj4gaTJycy1j aGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmkycnMtY2hhaXJzQGlldGYub3JnPjsgc2hhcmVzQG5kemgu Y29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+DQo+PiBTdWJqZWN0OiBSZTogW2kycnNdIEJlbiBD YW1wYmVsbCdzIERpc2N1c3Mgb24NCj4+IGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVt ZW50cy0wNjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4+DQo+Pg0KPj4NCj4+IEhpIEJl biwNCj4+DQo+Pg0KPj4NCj4+IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuICAgSW4tbGluZS4uLi4N Cj4+DQo+Pg0KPj4NCj4+PiBGcm9tOiBCZW4gQ2FtcGJlbGwsIE1heSAwNCwgMjAxNiAyOjQ5IFBN DQo+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+Pj4gRElTQ1VTUzoNCj4+DQo+Pj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4NCj4+Pg0KPj4NCj4+PiBJIGhhdmUgYSBjb3VwbGUgb2YgcG9pbnRzIEkgd291 bGQgbGlrZSB0byBkaXNjdXNzLiBIb3BlZnVsbHkgdGhleQ0KPj4+IGNhbg0KPj4NCj4+PiBiZSBy ZXNvbHZlZA0KPj4NCj4+PiBlYXNpbHk6DQo+Pg0KPj4+DQo+Pg0KPj4+IEFyZSB0aGVyZSByZWFs bHkgbm8gcmVxdWlyZW1lbnRzIGZvciBwcml2YWN5IG9yIGludGVncml0eQ0KPj4+IHByb3RlY3Rp b24/DQo+Pg0KPj4+IElzIHRoZXJlIGFuIGV4cGVjdGF0aW9uIHRoYXQgdGhpcyBtZWNoYW5pc20g d291bGQgZXZlciBjYXJyeSBwcml2YWN5DQo+Pg0KPj4+IHNlbnNpdGl2ZSBvciBvdGhlcndpc2Ug c2Vuc2l0aXZlIGluZm9ybWF0aW9uPw0KPj4NCj4+DQo+Pg0KPj4gW2VyaWMncyBjb21tZW50Og0K Pj4NCj4+IFdoZW4gdGhlIHN1YnNjcmlwdGlvbiBpcyBlc3RhYmxpc2hlZCBkeW5hbWljYWxseSB2 aWEgYW4gZXhpc3RpbmcNCj4+IHRyYW5zcG9ydA0KPj4gc2Vzc2lvbiAod2hpY2ggaXMgZXhwZWN0 ZWQgdG8gYmUgdGhlIGRvbWluYW50IGNhc2UpIHdlIGhhdmUgdGhlIHNhbWUNCj4+IGV4cGVjdGF0 aW9ucyBmb3IgUHJpdmFjeSBhbmQgaW50ZWdyaXR5IGFzIHdvdWxkIGJlIHByb3ZpZGVkIHZpYSBh DQo+PiAiR0VUIg0KPj4gaW5zdGVhZCBvZiBhICJQVVNIIiBvdmVyIHRoZSBzYW1lIHRyYW5zcG9y dC4gICBXZSBjb3VsZCBoYXZlDQo+PiByZXBsaWNhdGVkIGFsbA0KPj4gdGhlc2UgcmVxdWlyZW1l bnRzLCBidXQgdGhhdCB3YXMgc2VlbiBhcyB1bm5lY2Vzc2FyeSBhbmQgbGlrZWx5IGxlc3MNCj4+ IHNlY3VyZQ0KPj4gdGhhbiBhZG9wdGluZyBleGlzdGluZyBtZWNoYW5pc21zLg0KPj4NCj4+DQo+ Pg0KPj4gV2hlbiB0aGUgU3Vic2NyaWJlciBhbmQgUmVjZWl2ZXIgYXJlIGRpZmZlcmVudCwgdGhl biB0aGUgdHJhbnNwb3J0DQo+PiBjb25uZWN0aW9uIHdpbGwgaGF2ZSBjcmVkZW50aWFscyBwYXNz ZWQgYXMgcGFydCBvZiB0aGUgZXN0YWJsaXNobWVudC4NCj4+IFRoZXNlDQo+PiBjcmVkZW50aWFs cyB3aWxsIGJlIHVzZWQgYXMgYSBTZWN1cml0eSBHcm9vbWluZyBGaWx0ZXIganVzdCBsaWtlIHRo ZQ0KPj4gYWJvdmUNCj4+IGNhc2Ugc28gdGhhdCBwdXNoZWQgb2JqZWN0cyB3aWxsIGJlIGV4Y2x1 ZGVkIGZyb20gYW4gVXBkYXRlDQo+PiBOb3RpZmljYXRpb24gYXMNCj4+IHBlciB0aGUgcGVybWlz c2lvbnMgb2YgdGhlIFJlY2VpdmVyLiAgIChJLmUuLCB0aGlzIGlzIGlkZW50aWNhbA0KPj4gYmVo YXZpb3IgdG8NCj4+IHRoZSBhYm92ZS4pICAgIEFzIHNldmVyYWwgcGVvcGxlIGhhdmUgaGFkIHF1 ZXN0aW9ucyBhYm91dCB0aGlzLCB0aGUNCj4+IG5ldyB2MDcNCj4+IHdpbGwgbWFrZSB0aGlzIGV4 cGxpY2l0IGluIHRoZSBTZWN1cml0eSBzZWN0aW9uLg0KPj4NCj4+IEVuZCBvZiBlcmljJ3MgY29t bWVudF0NCj4+DQo+Pg0KPj4NCj4+IFN1ZTogVGhlIHRyYW5zcG9ydCBwcm92aWRlcyBmb3IgcHJp dmFjeSwgaW50ZWdyaXR5IHByb3RlY3Rpb24uICAgTW9zdA0KPj4gY29uZmlndXJhdGlvbiBpbiBu ZXR3b3JrIGJveGVzIHdvdWxkIG5lZWQgcHJpdmFjeS4NCj4+DQo+Pg0KPj4NCj4+PiAtIDQuMi41 LCAybmQgdG8gbGFzdCBwYXJhZ3JhcGg6DQo+Pg0KPj4+IEkgYW0gc3VycHJpc2VkIHRvIGZpbmQg dGhhdCwgd2hlbiB0aGUgcmVjZWl2ZXIgaXMgbm90IHRoZQ0KPj4+IHN1YnNjcmliZXIsDQo+Pg0K Pj4+IHRoYXQgdGhlIHJlY2VpdmVyIGlzIGV4cGVjdGVkIHRvIG9wdC1vdXQuIEl0IHNlZW1zIGxp a2Ugc29tZSBmb3JtIG9mDQo+Pg0KPj4+IG9wdC1pbiBvciBhZmZpcm1hdGl2ZSBjb25zZW50IHdv dWxkIGJlIG5lZWRlZCBoZXJlLg0KPj4NCj4+DQo+Pg0KPj4gVGhlIHF1ZXN0aW9uIHJlYWxseSB3 YXMgaG93IGhlYXZ5LXdlaWdodCBzaG91bGQgdGhlIG1lY2hhbmlzbSBiZS4NCj4+IFRyYW5zcG9y dHMgYmVlbiBjb25zaWRlcmluZyBhcmUgYWxsIGVuY3J5cHRlZC4gIFNvIHRoZXJlIGlzIGFscmVh ZHkgYQ0KPj4gbGV2ZWwNCj4+IG9mIHRydXN0IGJldHdlZW4gdGhlIHBlZXJzLiAgQW5kIGEgdGFy Z2V0IGNhbiBhbHdheXMgcHVsbCBkb3duIHRoZQ0KPj4gY29ubmVjdGlvbiBpZiB0aGVyZSBhcmUg aXNzdWVzLg0KPj4NCj4+DQo+Pg0KPj4gSW4gYWRkaXRpb24sIG11bHRpY2FzdCB0cmFuc3BvcnRz IGFyZSB2aWFibGUgZm9yIHNvbWUgZnV0dXJlIGNhc2VzLg0KPj4gV2UNCj4+IGRpZG4ndCB3YW50 IG1lY2hhbmlzbXMgd2hpY2ggY29tcGxpY2F0ZWQgdGhpcyB0eXBlIG9mIGludGVyYWN0aW9uLA0K Pj4gZXNwZWNpYWxseSBpbiBhIHdvcmxkIHdoZXJlIGR1bWIgSW9UIGRldmljZXMgbWF5IGJlIGlu dm9sdmVkLg0KPj4NCj4+DQo+Pg0KPj4gU3VlOiBJZiB0aGUgcmVjZWl2ZXIgYWNjZXB0cyBhIHNl Y3VyZSB0cmFuc3BvcnQgc2V0LXVwIGZyb20gdGhlDQo+PiBzZXJ2ZXIsIGNhbg0KPj4geW91IHBy b3ZpZGUgdGhlIHJlYXNvbiB3aHkgdGhpcyBpcyBub3QgYW4gIm9wdC1pbiIgb25jZSBpdCByZWNl aXZlcw0KPj4gdGhlDQo+PiBjb25uZWN0aW9uIGZyb20gdGhlIEkyUlMgYWdlbnQ/DQo+Pg0KPj4N Cj4+DQo+Pg0KPj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj4+IENPTU1FTlQ6DQo+Pg0KPj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+DQo+Pj4NCj4+DQo+Pj4gLSBHZW5lcmFsOiBJIHN1cHBvcnQgU3Rl cGhlbidzIERJU0NVU1MNCj4+DQo+Pj4NCj4+DQo+Pj4gLTIuMjogV2hhdCBpcyB0aGUgcmVhbCBz Y29wZSBvZiB0aGlzIHdvcms/IElzIGl0IGV4cGVjdGVkIHRvDQo+Pj4gc3VwcGxhbnQNCj4+DQo+ Pj4gdGhlIG1lbnRpb25lZCBtZWNoYW5pc21zPw0KPj4NCj4+DQo+Pg0KPj4gTm8uICAgSXQgaXMg anVzdCBzaG93aW5nIHRoYXQgbWFueSBzcGVjaWFsaXplZCBQdXNoIG1lY2hhbmlzbSBleGlzdC4N Cj4+IFRoaXMNCj4+IGlzIG5vdCBpbnRlbmRlZCB0byBzdXBwbGFudCBleGlzdGluZyBtZWNoYW5p c21zLCBhbHRob3VnaCBwZXJoYXBzIGl0DQo+PiBjYW4NCj4+IGhlbHAgYXZvaWQgZnV0dXJlIGRl ZGljYXRlZCBzb2x1dGlvbnMuDQo+Pg0KPj4+IC0gMi4zOiAiV2UgbmVlZCBhIG5ldyBwdWItc3Vi DQo+Pg0KPj4+ICAgIHRlY2hub2xvZ3kiDQo+Pg0KPj4+IFRoZSBzaGVwaGVyZCB3cml0ZSB1cCBt ZW50aW9uZWQgYSBnb2FsIHRvIHVzZSBleGlzdGluZyB0ZWNobm9sb2dpZXMuDQo+Pg0KPj4+IElz IHRoZSBwb2ludCBvZiB0aGlzIHNlbnRlbmNlIHRvIHN1Z2dlc3QgdGhhdCBpcyBub3QgZmVhc2li bGU/DQo+Pg0KPj4NCj4+DQo+PiBFeGlzdGluZyB0ZWNobm9sb2dpZXMgY2Fubm90IG1lZXQgYWxs IHRoZSByZXF1aXJlbWVudHMgc3BlY2lmaWVkLg0KPj4gVGhlcmUgYXJlDQo+PiB0ZWNobm9sb2d5 IGRyYWZ0cyBwcm9ncmVzc2luZyBpbiBORVRDT05GIHdoaWNoIGNhbi4NCj4+DQo+Pg0KPj4NCj4+ PiAtIDQuMSwgNHRoIHBhcmFncmFwaDoNCj4+DQo+Pj4gVGhlIE1BWSBkb2Vzbid0IHNlZW0gcmln aHQtLWlzIHRoaXMgYSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0IHRoZQ0KPj4NCj4+PiBzdWJzY3Jp YmVyIG1heSBoYXZlIHRvIHJlc3Vic2NyaWJlLCBvciBhIHJlcXVpcmVtZW50IG9mIHRoZSBmb3Jt DQo+Pj4gdGhhdA0KPj4NCj4+PiB0aGUgc2VydmljZSBNQVkgZm9yY2UgdGhlIHN1YnNjcmliZXIg dG8gcmVzdWJzY3JpYmU/IChCZSBjYXJlZnVsDQo+Pj4gd2l0aA0KPj4NCj4+PiBNQVlzIGluIHJl cXVpcmVtZW50cyBsYW5ndWFnZS0tdGhleSBpbXBseSB1bmV4cGVjdGVkIHRoaW5ncy4gRm9yDQo+ Pg0KPj4+IGV4YW1wbGUsIHNldmVyYWwgcmVxdWlyZW1lbnRzIHNheSBhIFNVQlNDUklCRSBNQVkg ZG8gc29tZXRoaW5nLS1kbw0KPj4NCj4+PiB0aG9zZSBpbXBseSB0aGF0IHRoZSBzZXJ2aWNlIE1V U1QgYWxsb3cgdGhlIHN1YnNjcmliZXIgdG8gZG8gaXQgPykNCj4+DQo+Pg0KPj4NCj4+IEdvb2Qg cG9pbnQuICAgUmV3b3JkZWQgaW4gdjA3Lg0KPj4NCj4+DQo+Pg0KPj4+IC0tIDQuMi4yLCB0aGly ZCBidWxsZXQ6IFRoZSBwcmV2aW91cyBzZWN0aW9uIHNhaWQgZGFtcGVuaW5nIHBlcmlvZHMNCj4+ DQo+Pj4gTVVTVCBiZSBzdXBwb3J0ZWQuDQo+Pg0KPj4NCj4+DQo+PiBZZXMsIGJ1dCBkYW1wZW5p bmcgaXMgbmV2ZXIgZm9yIHBlcmlvZGljIHN1YnNjcmlwdGlvbnMuDQo+Pg0KPj4+IC0gNC4yLjEs IHRoaXJkIHBhcmFncmFwaDogVGhpcyBpcyBhIGJpdCBhbWJpZ3VvdXMuIEkgdGhpbmsgaXQgbWVh bnMNCj4+PiB0bw0KPj4NCj4+PiBjaGFuZ2UgdGhlIHdoYXQgc3VidHJlZXMgdGhlIHN1YnNjcmlw dGlvbiBhcHBsaWVzIHRvLCBidXQgY291bGQgYmUNCj4+DQo+Pj4gaW50ZXJwcmV0ZWQgdG8gY2hh bmdlIHRoZSBzdWJ0cmVlcyB0aGVtc2VsdmVzLg0KPj4NCj4+DQo+Pg0KPj4gRml4ZWQNCj4+DQo+ Pj4gLSA0LjIuNi40OiBXb3VsZCBhIG1lY2hhbmlzbSB0aGF0IGFsbG93ZWQgb3V0LW9mLW9yZGVy IGRlbGl2ZXJ5IGJ1dA0KPj4NCj4+PiBnYXZlIHRoZSBzdWJzY3JpYmVyIGEgd2F5IHRvIHJlY29u c3RydWN0IHRoZSBvcmRlciBmdWxmaWxsIHRoaXMNCj4+IHJlcXVpcmVtZW50Pw0KPj4NCj4+DQo+ Pg0KPj4gWWVzLCB0aGUgdGltZXN0YW1wIHdpdGhpbiBhbiB1cGRhdGUuICBCdXQgdGhpcyByZXF1 aXJlbWVudCB0YXJnZXRzIGENCj4+IHNwZWNpZmljIG9iamVjdCBpbiBhIHNwZWNpZmljIHN1YnNj cmlwdGlvbi4gIFNvIHRoZXJlIHNob3VsZCBiZSBubw0KPj4gaXNzdWVzLg0KPj4NCj4+PiBOaXRz Og0KPj4NCj4+PiAtIFRoZSBzaGVwaGVyZCB3cml0ZSB1cCBzdWdnZXN0cyB0aGlzIGlzIHN0YW5k YXJkcyB0cmFjay4gVGhlIGRyYWZ0DQo+Pg0KPj4+IGFuZCB0cmFja2VyIGJvdGggc2F5IGluZm9y bWF0aW9uYWwuIFBsZWFzZSB1cGRhdGUgdGhlIHNoZXBoZXJkIHdyaXQNCj4+PiB1cC4NCj4+DQo+ Pg0KPj4NCj4+IEZpeGVkDQo+Pg0KPj4+IC0zLCBsYXN0IHBhcmFncmFwaDogV2hhdCdzIHRoZSBk aWZmZXJlbmNlIGJldHdlZW4gYSAiUHVzaCIgYW5kIGFuDQo+PiAiVXBkYXRlIj8NCj4+DQo+Pg0K Pj4NCj4+IFJld29yZGVkDQo+Pg0KPj4+IC00LjE6IEEgZm9yd2FyZCByZWZlcmVuY2UgdG8gdGhl IHN1YnNjcmlwdGlvbiBRb1Mgc2VjdGlvbiB3b3VsZCBiZQ0KPj4gaGVscGZ1bC4NCj4+DQo+Pg0K Pj4NCj4+IE1vdmVkIHRoZSByZXF1aXJlbWVudCBpbiBxdWVzdGlvbiB0byA0LjIuNi4NCj4+DQo+ Pj4gLS0gTGFzdCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2U6IFNlbnRlbmNlIGRvZXNuJ3QgcGFy c2UuDQo+Pg0KPj4NCj4+DQo+PiBGaXhlZA0KPj4NCj4+Pg0KPj4NCj4+PiAtIDQuMi44LCB0aGly ZCBwYXJhZ3JhcGg6IEkgZG9uJ3QgdGhpbmsgdGhhdCBzaG91bGQgYmUgYSAyMTE5IE1BWQ0KPj4N Cj4+DQo+Pg0KPj4gRml4ZWQNCj4+DQo+PiBUaGFua3MgYWdhaW4gZm9yIHRoZSByZXZpZXchDQo+ Pg0KPj4gRXJpYw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pg0KPj4gaTJycyBtYWlsaW5nIGxpc3QNCj4+DQo+PiAgPG1haWx0bzppMnJz QGlldGYub3JnPiBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KPj4NCj4+ICA8 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPg0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo= --_000_9e9692bd22a041ba91e39a9f7dce8c9eXCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQmVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIGFkZGVkIHRoZSB0 ZXh0IGJlbG93IGFzIHRoZSBsZWFkLWluIHRvIHNlY3Rpb24gNC4yLjUuJm5ic3A7IEkgYmVsaWV2 ZSB0aGlzIG1lZXRzIHRoZSBpbnRlbnRzIG9mIHlvdXIgc3VnZ2VzdGlvbnMgYmVsb3cuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBTdXNhbiAmYW1wOyBBbGlhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIHVwbG9hZGVkIHYwOCBv ZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMvPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIEJlbiBjb25jdXJzIHdpdGggdGhlIHRleHQgYmVsb3csIEkg YW0gbm90IGF3YXJlIG9mIGFueSByZW1haW5pbmcgZGlzY3VzcyBpdGVtcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyBldmVyeW9uZSBmb3IgeW91ciByZXZpZXdzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5FcmljLCBBbGV4LCAmYW1wOyBBbGJlcnRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj40LjIuNS4mbmJzcDsgU2VjdXJpdHkgUmVx dWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFNvbWUgdXNlcyBvZiB0aGlzIFN1YnNjcmlwdGlv biBTZXJ2aWNlIHdpbGwgcHVzaCBwcml2YWN5LXNlbnNpdGl2ZTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB1cGRhdGVz IGFuZCBtZXRhZGF0YS4mbmJzcDsgR29vZCBkZXBsb3ltZW50IHByYWN0aWNlcyB3aWxsIGJpbmQg dGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBnZW5lcmF0ZWQgaW5mb3JtYXRpb24gd2l0aGluIHNlY3VyZSwgZW5j cnlwdGVkIHRyYW5zcG9ydCBsYXllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBtZWNoYW5pc21zLiZuYnNwOyBGb3Ig ZXhhbXBsZSBpZiBORVRDT05GIGlzIHVzZWQgYXMgdHJhbnNwb3J0LCB0aGVuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IFtSRkM1NTM5XSB3b3VsZCBiZSBhIHZhbGlkIG9wdGlvbiB0byBzZWN1cmUgdGhlIHRyYW5zcG9y dGVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uLiZuYnNwOyBUaGUgU3Vic2NyaXB0aW9uIFNlcnZp Y2UgY2FuIGFsc28gYmUgdXNlZCB3aXRoIGVtZXJnaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRlcGxveW1lbnQg Y29udGV4dHMgYXMgd2VsbC4mbmJzcDsgQXMgYW4gZXhhbXBsZSwgZGVwbG95bWVudHMgYmFzZWQg b248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgW2kycnMtdXNlY2FzZV0gY2FuIGFwcGx5IHRoZXNlIHJlcXVpcmVtZW50 cyBpbiBjb25qdW5jdGlvbiB3aXRoIHRob3NlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50ZWQgd2l0aGlu IFtpMnJzLXByb3RvY29sLXNlY3VyaXR5XSB0byBzZWN1cmUgZXBoZW1lcmFsIHN0YXRlPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IGluZm9ybWF0aW9uIGJlaW5nIHB1c2hlZCBmcm9tIGEgTmV0d29yayBFbGVtZW50Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gU3VzYW4gSGFyZXMgW21haWx0bzpzaGFyZXNAbmR6aC5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMDYsIDIwMTYgNzowOSBQTTxicj4NCjxiPlRvOjwvYj4g QmVuIENhbXBiZWxsPGJyPg0KPGI+Q2M6PC9iPiBFcmljIFZvaXQgKGV2b2l0KTsgVGhlIElFU0c7 IGkycnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRm Lm9yZzsgaTJycy1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtpMnJz XSBCZW4gQ2FtcGJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVp cmVtZW50cy0wNjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVuOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHdpc2UgaWRlYS4g Jm5ic3A7SSB3aWxsIHN1Z2dlc3Qgc29tZSB0ZXh0IHRvIEVyaWMgYW5kIHlvdSBpbiB0aGUgbW9y bmluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U3VlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImNvbXBvc2VyX3Np Z25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6IzU3NTc1NyI+U2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5v dGU1LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogQmVuIENhbXBiZWxsICZsdDs8YSBocmVm PSJtYWlsdG86YmVuQG5vc3RydW0uY29tIj5iZW5Abm9zdHJ1bS5jb208L2E+Jmd0Ow0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EYXRlOiA1LzYvMjAxNiAyOjM4IFBNIChHTVQtMDY6MDAp DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRvOiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDsNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q2M6IEVyaWMgVm9pdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmV2b2l0QGNpc2NvLmNvbSI+ZXZvaXRAY2lzY28uY29tPC9hPiZndDssIFRoZSBJRVNHICZsdDs8 YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7LA0KPGEg aHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+LCA8YSBocmVmPSJt YWlsdG86ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnIj4NCmRy YWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZzwvYT4sIDxhIGhyZWY9 Im1haWx0bzppMnJzLWNoYWlyc0BpZXRmLm9yZyI+DQppMnJzLWNoYWlyc0BpZXRmLm9yZzwvYT4g PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TdWJqZWN0OiBSZTogW2kycnNdIEJlbiBDYW1w YmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2 OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgU3VzYW4sPGJyPg0KPGJyPg0KVG8gYmUgY2xlYXIsIEkgZG8gbm90IG9i amVjdCB0byB0aGUgd2lkZXIgY29udGV4dCBwZXIgc2UuIE15IGNvbmNlcm4gaXMgPGJyPg0KdGhh dCB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgcmVxdWlyZW1lbnRzIGFyZSBsZWZ0IGFzIGltcGxp Y2l0LCBiYXNlZCA8YnI+DQpvbiB0aGUgbW9yZSBuYXJyb3cgaTJycy9uZXRjb25mIGNvbnRleHQu IEkgb25seSBtZW50aW9uZWQgdGhlIHBvdGVudGlhbCA8YnI+DQpvZiByZXN0cmljdGluZyB0aGUg Y29udGV4dGFzIG9uZSBwb3NzaWJsZSB3YXkgZm9yd2FyZDsgSSBhbSBjZXJ0YWlubHkgPGJyPg0K bm90IHdlZGRlZCB0byBpdC48YnI+DQo8YnI+DQpNeSBzdWdnZXN0aW9uIGZvciBhIHdheSBmb3J3 YXJkIHdvdWxkIGJlIHRvIGRvY3VtZW50IHRoZSBoaWdoIGxldmVsIDxicj4NCnNlY3VyaXR5IGFu ZCBwcml2YWN5IHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50LiBJSVVDLCB0aGUgbGFyZ2Vy IDxicj4NCmNvbnRleHQgaW5jbHVkZXMgcG90ZW50aWFsbHkgdW5rbm93biBjb250ZXh0cywgc28g c29tZSBvZiB0aGlzIG1heSBuZWVkIDxicj4NCnRvIGJlIGNvbmRpdGlvbmFsLiBGb3IgZXhhbXBs ZSwgbGFuZ3VhZ2UgbGlrZSB0aGUgZm9sbG93aW5nIG1pZ2h0IGJlIDxicj4NCmhlbHBmdWwgKHRo aXMgaXMganVzdCBhbiBleGFtcGxlLS1JIGRvbid0IG1lYW4gdG8gc2F5IHRoYXQgaXQgaXMgdHJ1 ZSBvciA8YnI+DQphcHBsaWNhYmxlKTo8YnI+DQo8YnI+DQombmJzcDsgJnF1b3Q7U29tZSB1c2Vz IG9mIHRoaXMgbWVjaGFuaXNtIG1heSBjYXJyeSBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlv biwgPGJyPg0Kb3IgZ2VuZXJhdGUmbmJzcDsmbmJzcDsmbmJzcDsgcHJpdmFjeS1zZW5zaXRpdmUg bWV0YWRhdGEgdGhyb3VnaCB0aGUgc3Vic2NyaXB0aW9uIDxicj4NCm1lY2hhbmlzbS4gSW4gY29u dGV4dHMgd2hlcmUgdGhpcyBpcyB0cnVlLCB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50cyA8YnI+ DQphcHBseS4uLiZxdW90Ozxicj4NCjxicj4NCkl0IG1pZ2h0IGFsc28gYmUgcmVhc29uYWJsZSB0 byBzYXkgdGhhdCwgZm9yIHRoZSBjb250ZXh0IG9mIGkycnMsIHRoZXNlIDxicj4NCnJlcXVpcmVt ZW50cyBhcmUgZG9jdW1lbnRlZCBpbiBbcmVmZXJlbmNlc10gYW5kIGFyZSBleHBlY3RlZCB0byBi ZSA8YnI+DQpmdWxmaWxsZWQgYnkgdGhlIFt0cmFuc3BvcnQgYW5kIG9yIHByb3RvY29sXTxicj4N Cjxicj4NCkVyaWMncyBlbWFpbCBhbHNvIHN1Z2dlc3RlZCB0aGF0IHRoZSBhY3R1YWwgdHJhbnNw b3J0IG9mIGRhdGEgZnJvbSB0aGUgPGJyPg0KWWFuZyBkYXRhc3RvcmUgbWF5IGJlIG91dCBvZiBz Y29wZSBmb3IgdGhlc2UgcmVxdWlyZW1lbnRzLiBJIGRvbid0IDxicj4NCm9iamVjdCB0byB0aGF0 LCBlaXRoZXIsIGFzIGxvbmcgYXMgaXQgaXMgY2xlYXIgYW5kIGV4cGxpY2l0LCBhbHRob3VnaCBp dCA8YnI+DQp3b3VsZCBiZSBnb29kIHRvIHBvaW50IHRvIHdoZXJlIGl0IGlzIF9pbl8gc2NvcGUu PGJyPg0KPGJyPg0KVGhhbmtzITxicj4NCjxicj4NCkJlbi48YnI+DQo8YnI+DQpPbiA2IE1heSAy MDE2LCBhdCAxOjA2LCBTdXNhbiBIYXJlcyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEJlbjo8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGlzIHRoZSBmaXJzdCBvZiB0aGUgJnF1b3Q7cmUtdXNlJnF1 b3Q7IG1hbmFnZW1lbnQgcHJvdG9jb2xzLiZuYnNwOyBUaGUgPGJyPg0KJmd0OyByZXF1aXJlbWVu dHM8YnI+DQomZ3Q7IGFyZSBzZXQtdXAgc28gdGhhdCB3ZSBjYW4gc3VnZ2VzdCBhZGRpdGlvbnMg dG8gdGhlIE5FVENPTkYgYW5kIDxicj4NCiZndDsgUkVTVENPTkYgZm9yPGJyPg0KJmd0OyB0aGlz IGZpcnN0IG9mIEkyUlMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIEkyUlMgZXBoZW1lcmFsIHdv cmssIHB1Yi9zdWIsIHRyYWNlYWJpbGl0eSwgYW5kIHNlY3VyaXR5IGFyZSA8YnI+DQomZ3Q7IHRh cmdldCBhdDxicj4NCiZndDsgdGhlIEkyUlMgcHJvdG9jb2wgZGVmaW5pdGlvbiB3aXRoIHRoZSBJ MlJTIHVzZSBjYXNlLiZuYnNwOyBIb3dldmVyLCBzaW5jZSA8YnI+DQomZ3Q7IHRoZXNlPGJyPg0K Jmd0OyBhcmUgZ2VuZXJhbCBhZGRpdGlvbnMgdG8gTkVUQ09ORi9SRVNUQ09ORiwgdGhpcyB3b3Jr IGNhbiBiZSB1c2VkIDxicj4NCiZndDsgZWxzZXdoZXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkg dGhpbmsgdGhlIHRleHQgeW91IGFyZSBoaWdobGlnaHRpbmcgaGFzIHRoaXMgbGFyZ2VyIGNvbnRl eHQuJm5ic3A7Jm5ic3A7IE5vdywgPGJyPg0KJmd0OyBvbmUgb2Y8YnI+DQomZ3Q7IHRoZSByZWFs bHkgaW1wb3J0YW50IHRoaW5ncyB0byBjaGF0IHdpdGggQWxpYSBhbmQgQmVub2l0IGlzIGhvdyBk byB3ZSA8YnI+DQomZ3Q7IGhhbmRsZTxicj4NCiZndDsgdGhlIHdpZGVyIHVzZSBjYXNlLiZuYnNw OyZuYnNwOyBEbyB3ZSBtZW50aW9uIHRoZSB3aWRlciBjb250ZXh0Pzxicj4NCiZndDs8YnI+DQom Z3Q7IFRoZSBXRyB0aG91Z2h0IG1lbnRpb25pbmcgaXQgd2FzIGltcG9ydGFudC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBTdWU8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsgRnJvbTogQmVuIENhbXBiZWxsIFs8YSBocmVmPSJtYWlsdG86YmVuQG5v c3RydW0uY29tIj5tYWlsdG86YmVuQG5vc3RydW0uY29tPC9hPl08YnI+DQomZ3Q7IFNlbnQ6IFRo dXJzZGF5LCBNYXkgMDUsIDIwMTYgNTozMSBQTTxicj4NCiZndDsgVG86IFN1c2FuIEhhcmVzPGJy Pg0KJmd0OyBDYzogRXJpYyBWb2l0OyBUaGUgSUVTRzsgPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0 Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0 LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pMnJz LXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzppMnJz LWNoYWlyc0BpZXRmLm9yZyI+aTJycy1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJq ZWN0OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb248YnI+DQomZ3Q7IGRyYWZ0 LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0wNjogKHdpdGggRElTQ1VTUyBhbmQgQ09N TUVOVCk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiA1IE1heSAyMDE2LCBhdCA1OjE1LCBTdXNhbiBI YXJlcyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgRXJpYywgQmVuIGFuZCBJRVNHIG1l bWJlcnM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgVGhlIHB1Yi9zdWIgcmVxdWlyZW1lbnRzIGFyZSBwYXJ0IG9mIGEgNSBwYXJ0IHJlcXVp cmVtZW50cy4mbmJzcDsmbmJzcDsgTWF5IEk8YnI+DQomZ3Q7Jmd0OyBxdW90ZTxicj4NCiZndDsm Z3Q7IGZyb20gdGhlIHNoZXBoZXJkJ3MgcmVwb3J0Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUg cmVxdWlyZW1lbnRzIGZvciB0aGUgZmlyc3QgdmVyc2lvbiBvZiBJMlJTIGFyZTo8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IDEpIG1vZGVsIGRyaXZlbiBlcGhlbWVyYWwgc3RhdGUgLSB0aGF0 IGlzIGRhdGEgbW9kZWxzIHRoYXQgZG8gbm90PGJyPg0KJmd0OyZndDsgc3Vydml2ZTxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBzb2Z0d2FyZSBv ciBoYXJkd2FyZSByZWJvb3QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtZXBoZW1lcmFs LXN0YXRlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJz LWVwaGVtZXJhbC1zdGF0ZS88L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgMikgYSBzZWN1cmUgcHJvdG9jb2wgLTxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcSI+DQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxPC9h Pjxicj4NCiZndDsmZ3Q7IHVpcmVtZTxicj4NCiZndDsmZ3Q7IG50cy88YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAzKSB0cmFjZWFiaWxpdHkg LSBhYmlsaXR5IHRvIHJlY29yZCBpbnRlcmFjdGlvbnMgYmV0d2VlbiBJMlJTIDxicj4NCiZndDsm Z3Q7IGVsZW1lbnRzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAoQ2xpZW50LCBBZ2VudCwg Um91dGluZyBzeXN0ZW0pPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtdHJhY2VhYmlsaXR5 LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXRyYWNl YWJpbGl0eS88L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgNCkgbm90aWZpY2F0aW9uIHB1YmxpY2F0aW9uIHZpYSBzdWJzY3JpcHRpb248 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy8iPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVx dWlyZW1lbnRzLzwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyA1KSBQcm90b2NvbCB0byBwYXNzIERhdGEgZm9yIEFuYWx5dGljczxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGZpcnN0IHZlcnNpb24gb2YgdGhlc2UgcmVxdWly ZW1lbnRzIGRvZXMgbm90IGluY2x1ZGUgYTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgc2Vw YXJhdGUgYW5hbHl0aWNhbCBwcm90b2NvbCByZXF1aXJlbWVudHMgYXMgdGhlIHNpbXBsZSB1c2Ug Y2FzZXMgbWF5PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBwYXNzIGluZm9ybWF0aW9uIHZp YSBxdWVyeS9wb2xsIG9yIHRoZSBub3RpZmljYXRpb25zLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBJMlJTIHByb3RvY29sIGV4aXN0 cyBpbiBhbiBzZWN1cmUgZW52aXJvbm1lbnQgZGVzY3JpYmVkIGJ5Ojxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pMnJzLXNlY3VyaXR5LWVudmlyb25tZW50LSI+DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtc2VjdXJpdHktZW52aXJvbm1lbnQtPC9hPjxi cj4NCiZndDsmZ3Q7IHJlcXMvPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEVyaWMgLSBQZXJoYXBz IGl0IHdvdWxkIGJlIGdvb2QgdG8gcG9pbnQgdG86PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0 LWlldGYtaTJycy1wcm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVudHMgYW5kPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRyYWZ0LWlldGYtaTJycy1zZWN1cml0eS1lbnZpcm9ubWVudC1yZXFzLzxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEJlbiAt IENhbiB5b3UgdGVsbCBtZSBob3cgdGhlIHNoZXBoZXJkIHJlcG9ydCBjb3VsZCBoYXZlIGJlZW4g PGJyPg0KJmd0OyZndDsgY2xlYXJlcj88YnI+DQomZ3Q7Jmd0OyZuYnNwOyBUaGU8YnI+DQomZ3Q7 Jmd0OyBJMnJzIHByb3RvY29sIHNlY3VyaXR5IHJlcXVpcmVtZW50cyByZXF1aXJlOiZuYnNwOyBj b25maWRlbnRpYWxpdHksPGJyPg0KJmd0OyZndDsgZW5jcnlwdGlvbiwgc2VjdXJlIHRyYW5zcG9y dCwgcHJvdGVjdGlvbiBhZ2FpbnN0IHJlcGxheSBhdHRhY2ssPGJyPg0KJmd0OyZndDsgcHJvdGVj dGlvbiBhZ2FpbnN0IEREb1MgYXR0YWNrIChpZiBwb3NzaWJsZSkuPGJyPg0KJmd0Ozxicj4NCiZn dDsgSSB0aGluayBteSBjb25mdXNpb24gbGllcyBpbiB0aGUgZmFjdCB0aGF0LCB3aGlsZSB0aGUg c2hlcGhlcmQncyA8YnI+DQomZ3Q7IHdyaXRldXA8YnI+DQomZ3Q7IHN0eWxlcyB0aGlzIGRyYWZ0 IGFzIHBhcnQgb2YgdGhlIEkyUlMgcHJvdG9jb2wgcmVxdWlyZW1lbnRzLCB0aGUgZHJhZnQ8YnI+ DQomZ3Q7IGl0c2VsZiBjbGFpbXMgdG8gZGVzY3JpYmUgcmVxdWlyZW1lbnRzIGZvciBhIGdlbmVy YWxseSB1c2VmdWwgcHViLXN1Yjxicj4NCiZndDsgaW50ZXJmYWNlIHRvIGEgeWFuZyBkYXRhc3Rv cmUuIEl0J3Mgbm90IGNsZWFyIHRvIG1lIGhvdyBhbmQgd2hlbiB0aGUgPGJyPg0KJmd0OyBJMlJT PGJyPg0KJmd0OyBwcm90b2NvbCBzZWN1cml0eSByZXF1aXJlbWVudHMgYXBwbHkgdG8gaXQuIElm IHRoZSBkZXNjcmliZWQgaW50ZXJmYWNlIDxicj4NCiZndDsgaXM8YnI+DQomZ3Q7IGludGVuZGVk IHRvIGJlIHVzZWZ1bCBpbiBjb250ZXh0cyBvdGhlciB0aGFuIEkyUlMgKGFuZCB0aGUgZHJhZnQg PGJyPg0KJmd0OyBleHBsaWNpdGx5PGJyPg0KJmd0OyBzZXRzIHRoYXQgZXhwZWN0YXRpb24gaW4g Mi4yKSwgaXQgbmVlZHMgdG8gdGFsayBtb3JlIGdlbmVyYWxseSBhYm91dDxicj4NCiZndDsgc2Vj dXJpdHkgYW5kIHByaXZhY3kuPGJyPg0KJmd0Ozxicj4NCiZndDsgRm9yIGV4YW1wbGUsIGl0IG1p Z2h0IG1ha2Ugc2Vuc2UgdG8gc2F5IHRoYXQgY2VydGFpbiBzZWN1cml0eSA8YnI+DQomZ3Q7IHJl cXVpcmVtZW50czxicj4NCiZndDsgYXBwbHkgaW4gZW52aXJvbm1lbnRzIHdoZXJlIHRoZSBtZWNo YW5pc20gbWlnaHQgY2FycnkgcHJpdmFjeSA8YnI+DQomZ3Q7IHNlbnNpdGl2ZTxicj4NCiZndDsg ZGF0YSwgYW5kIHRoZW4gcG9pbnQgdG8gdGhlIGkycnMgcmVxdWlyZW1lbnRzIGZvciB3aGVuIHRo ZSBtZWNoYW5pc20gPGJyPg0KJmd0OyBpcyB1c2VkPGJyPg0KJmd0OyBpbiBhbiBJMlJTIGNvbnRl eHQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQSBkaWZmZXJlbnQgYXBwcm9hY2ggbWlnaHQgYmUgdG8g bW9yZSB0aWdodGx5IGNvbnN0cmFpbiB0aGlzIHRvIGkycnM8YnI+DQomZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQmVuIC0gT24gb3B0 aW5nIGluLCBvbmNlIHRoZSByZWNlaXZlIGFjY2VwdHMgYSB0cmFuc3BvcnQgY29ubmVjdGlvbjxi cj4NCiZndDsmZ3Q7IGZyb20gdGhlIEkyUlMgc2VydmVyIC0gaG93IGlzIHRoaXMgbm90IGFuIG9w dC1pbiB0byByZWNlaXZlIGRhdGE/IDxicj4NCiZndDsmZ3Q7IFdoYXQ8YnI+DQomZ3Q7Jmd0OyBh cmUgeW91IGxvb2tpbmcgZm9yPzxicj4NCiZndDs8YnI+DQomZ3Q7IEkgZ3Vlc3MgdGhhdCBkZXBl bmRzIG9uIHRoZSB0cmFuc3BvcnQuIFRoZSB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIHNheSA8YnI+ DQomZ3Q7IHRoZTxicj4NCiZndDsgbWVjaGFuaXNtIGhhcyB0byB3b3JrIG92ZXIgbXVsdGlwbGUg dHJhbnNwb3J0cy4gVGhlIGxhc3QgcGFyYWdyYXBoIGluIDxicj4NCiZndDsgNC4yLjQ8YnI+DQom Z3Q7IHNheXMgJnF1b3Q7SW4gdGhlIGNhc2Ugb2YgY29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3Bv cnRzLi4uJnF1b3Q7IHdoaWNoIHN1Z2dlc3RzIDxicj4NCiZndDsgdGhhdDxicj4NCiZndDsgbm9u LWNvbm5lY3Rpb24tb3JpZW50ZWQgdHJhbnNwb3J0cyBhcmUgcG9zc2libGUuPGJyPg0KJmd0Ozxi cj4NCiZndDsgRXZlbiB3aXRoIGEgY29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3BvcnQsIHRoaXMg bWF5IGRlcGVuZCBvbiBob3c8YnI+DQomZ3Q7IGNvbm5lY3Rpb24tbWFuYWdlbWVudCBpcyBoYW5k bGVkLCBhbmQgd2hldGhlciB0aGUgcmVjZWl2ZXIgbWlnaHQgYmU8YnI+DQomZ3Q7IHJlY2Vpdmlu ZyB0aGluZ3MgaXQgX3dhbnRzXyB0byByZWNlaXZlIG9uIHRoZSBzYW1lIHRyYW5zcG9ydC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgU3VlIEhhcmVzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAoc2hlcGhlcmQpPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K Jmd0OyZndDsgRnJvbTogaTJycyBbPGEgaHJlZj0ibWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBFcmljIFZv aXQ8YnI+DQomZ3Q7Jmd0OyAoZXZvaXQpPGJyPg0KJmd0OyZndDsgU2VudDogV2VkbmVzZGF5LCBN YXkgMDQsIDIwMTYgNzoyNSBQTTxicj4NCiZndDsmZ3Q7IFRvOiBCZW4gQ2FtcGJlbGw7IFRoZSBJ RVNHPGJyPg0KJmd0OyZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJz QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJl cXVpcmVtZW50c0BpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVu dHNAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzppMnJzLWNoYWly c0BpZXRmLm9yZyI+aTJycy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86c2hh cmVzQG5kemguY29tIj4NCnNoYXJlc0BuZHpoLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0 OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb248YnI+DQomZ3Q7Jmd0OyBkcmFm dC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDY6ICh3aXRoIERJU0NVU1MgYW5kIENP TU1FTlQpPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgSGkgQmVuLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuJm5ic3A7Jm5ic3A7IEluLWxpbmUu Li4uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IEZyb206IEJlbiBDYW1wYmVsbCwgTWF5IDA0LCAyMDE2IDI6NDkgUE08YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgRElTQ1VTUzo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyBJIGhhdmUgYSBjb3VwbGUgb2YgcG9pbnRzIEkgd291bGQgbGlrZSB0 byBkaXNjdXNzLiBIb3BlZnVsbHkgdGhleSA8YnI+DQomZ3Q7Jmd0OyZndDsgY2FuPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgYmUgcmVzb2x2ZWQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyBlYXNpbHk6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBcmUgdGhlcmUgcmVhbGx5IG5vIHJlcXVpcmVtZW50 cyBmb3IgcHJpdmFjeSBvciBpbnRlZ3JpdHkgPGJyPg0KJmd0OyZndDsmZ3Q7IHByb3RlY3Rpb24/ PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSXMgdGhlcmUgYW4gZXhwZWN0YXRpb24g dGhhdCB0aGlzIG1lY2hhbmlzbSB3b3VsZCBldmVyIGNhcnJ5IHByaXZhY3k8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBzZW5zaXRpdmUgb3Igb3RoZXJ3aXNlIHNlbnNpdGl2ZSBpbmZv cm1hdGlvbj88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBbZXJpYydzIGNvbW1lbnQ6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXaGVu IHRoZSBzdWJzY3JpcHRpb24gaXMgZXN0YWJsaXNoZWQgZHluYW1pY2FsbHkgdmlhIGFuIGV4aXN0 aW5nPGJyPg0KJmd0OyZndDsgdHJhbnNwb3J0PGJyPg0KJmd0OyZndDsgc2Vzc2lvbiAod2hpY2gg aXMgZXhwZWN0ZWQgdG8gYmUgdGhlIGRvbWluYW50IGNhc2UpIHdlIGhhdmUgdGhlIHNhbWU8YnI+ DQomZ3Q7Jmd0OyBleHBlY3RhdGlvbnMgZm9yIFByaXZhY3kgYW5kIGludGVncml0eSBhcyB3b3Vs ZCBiZSBwcm92aWRlZCB2aWEgYTxicj4NCiZndDsmZ3Q7ICZxdW90O0dFVCZxdW90Ozxicj4NCiZn dDsmZ3Q7IGluc3RlYWQgb2YgYSAmcXVvdDtQVVNIJnF1b3Q7IG92ZXIgdGhlIHNhbWUgdHJhbnNw b3J0LiZuYnNwOyZuYnNwOyBXZSBjb3VsZCBoYXZlPGJyPg0KJmd0OyZndDsgcmVwbGljYXRlZCBh bGw8YnI+DQomZ3Q7Jmd0OyB0aGVzZSByZXF1aXJlbWVudHMsIGJ1dCB0aGF0IHdhcyBzZWVuIGFz IHVubmVjZXNzYXJ5IGFuZCBsaWtlbHkgbGVzczxicj4NCiZndDsmZ3Q7IHNlY3VyZTxicj4NCiZn dDsmZ3Q7IHRoYW4gYWRvcHRpbmcgZXhpc3RpbmcgbWVjaGFuaXNtcy48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXaGVuIHRoZSBTdWJzY3Jp YmVyIGFuZCBSZWNlaXZlciBhcmUgZGlmZmVyZW50LCB0aGVuIHRoZSB0cmFuc3BvcnQ8YnI+DQom Z3Q7Jmd0OyBjb25uZWN0aW9uIHdpbGwgaGF2ZSBjcmVkZW50aWFscyBwYXNzZWQgYXMgcGFydCBv ZiB0aGUgZXN0YWJsaXNobWVudC48YnI+DQomZ3Q7Jmd0OyBUaGVzZTxicj4NCiZndDsmZ3Q7IGNy ZWRlbnRpYWxzIHdpbGwgYmUgdXNlZCBhcyBhIFNlY3VyaXR5IEdyb29taW5nIEZpbHRlciBqdXN0 IGxpa2UgdGhlPGJyPg0KJmd0OyZndDsgYWJvdmU8YnI+DQomZ3Q7Jmd0OyBjYXNlIHNvIHRoYXQg cHVzaGVkIG9iamVjdHMgd2lsbCBiZSBleGNsdWRlZCBmcm9tIGFuIFVwZGF0ZTxicj4NCiZndDsm Z3Q7IE5vdGlmaWNhdGlvbiBhczxicj4NCiZndDsmZ3Q7IHBlciB0aGUgcGVybWlzc2lvbnMgb2Yg dGhlIFJlY2VpdmVyLiZuYnNwOyZuYnNwOyAoSS5lLiwgdGhpcyBpcyBpZGVudGljYWw8YnI+DQom Z3Q7Jmd0OyBiZWhhdmlvciB0bzxicj4NCiZndDsmZ3Q7IHRoZSBhYm92ZS4pJm5ic3A7Jm5ic3A7 Jm5ic3A7IEFzIHNldmVyYWwgcGVvcGxlIGhhdmUgaGFkIHF1ZXN0aW9ucyBhYm91dCB0aGlzLCB0 aGU8YnI+DQomZ3Q7Jmd0OyBuZXcgdjA3PGJyPg0KJmd0OyZndDsgd2lsbCBtYWtlIHRoaXMgZXhw bGljaXQgaW4gdGhlIFNlY3VyaXR5IHNlY3Rpb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBFbmQgb2YgZXJpYydzIGNvbW1lbnRdPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgU3VlOiBUaGUgdHJhbnNwb3J0IHByb3ZpZGVzIGZvciBw cml2YWN5LCBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4mbmJzcDsmbmJzcDsgTW9zdDxicj4NCiZndDsm Z3Q7IGNvbmZpZ3VyYXRpb24gaW4gbmV0d29yayBib3hlcyB3b3VsZCBuZWVkIHByaXZhY3kuPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 IC0gNC4yLjUsIDJuZCB0byBsYXN0IHBhcmFncmFwaDo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyBJIGFtIHN1cnByaXNlZCB0byBmaW5kIHRoYXQsIHdoZW4gdGhlIHJlY2VpdmVyIGlz IG5vdCB0aGUgPGJyPg0KJmd0OyZndDsmZ3Q7IHN1YnNjcmliZXIsPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgdGhhdCB0aGUgcmVjZWl2ZXIgaXMgZXhwZWN0ZWQgdG8gb3B0LW91dC4g SXQgc2VlbXMgbGlrZSBzb21lIGZvcm0gb2Y8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyBvcHQtaW4gb3IgYWZmaXJtYXRpdmUgY29uc2VudCB3b3VsZCBiZSBuZWVkZWQgaGVyZS48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUg cXVlc3Rpb24gcmVhbGx5IHdhcyBob3cgaGVhdnktd2VpZ2h0IHNob3VsZCB0aGUgbWVjaGFuaXNt IGJlLjxicj4NCiZndDsmZ3Q7IFRyYW5zcG9ydHMgYmVlbiBjb25zaWRlcmluZyBhcmUgYWxsIGVu Y3J5cHRlZC4mbmJzcDsgU28gdGhlcmUgaXMgYWxyZWFkeSBhPGJyPg0KJmd0OyZndDsgbGV2ZWw8 YnI+DQomZ3Q7Jmd0OyBvZiB0cnVzdCBiZXR3ZWVuIHRoZSBwZWVycy4mbmJzcDsgQW5kIGEgdGFy Z2V0IGNhbiBhbHdheXMgcHVsbCBkb3duIHRoZTxicj4NCiZndDsmZ3Q7IGNvbm5lY3Rpb24gaWYg dGhlcmUgYXJlIGlzc3Vlcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBJbiBhZGRpdGlvbiwgbXVsdGljYXN0IHRyYW5zcG9ydHMgYXJlIHZp YWJsZSBmb3Igc29tZSBmdXR1cmUgY2FzZXMuPGJyPg0KJmd0OyZndDsgV2U8YnI+DQomZ3Q7Jmd0 OyBkaWRuJ3Qgd2FudCBtZWNoYW5pc21zIHdoaWNoIGNvbXBsaWNhdGVkIHRoaXMgdHlwZSBvZiBp bnRlcmFjdGlvbiw8YnI+DQomZ3Q7Jmd0OyBlc3BlY2lhbGx5IGluIGEgd29ybGQgd2hlcmUgZHVt YiBJb1QgZGV2aWNlcyBtYXkgYmUgaW52b2x2ZWQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgU3VlOiBJZiB0aGUgcmVjZWl2ZXIgYWNjZXB0 cyBhIHNlY3VyZSB0cmFuc3BvcnQgc2V0LXVwIGZyb20gdGhlPGJyPg0KJmd0OyZndDsgc2VydmVy LCBjYW48YnI+DQomZ3Q7Jmd0OyB5b3UgcHJvdmlkZSB0aGUgcmVhc29uIHdoeSB0aGlzIGlzIG5v dCBhbiAmcXVvdDtvcHQtaW4mcXVvdDsgb25jZSBpdCByZWNlaXZlczxicj4NCiZndDsmZ3Q7IHRo ZTxicj4NCiZndDsmZ3Q7IGNvbm5lY3Rpb24gZnJvbSB0aGUgSTJSUyBhZ2VudD88YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyBDT01NRU5UOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IC0gR2VuZXJhbDogSSBzdXBwb3J0IFN0ZXBoZW4ncyBESVNDVVNTPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyAtMi4yOiBXaGF0IGlzIHRoZSByZWFsIHNjb3BlIG9mIHRoaXMgd29yaz8gSXMgaXQgZXhw ZWN0ZWQgdG8gPGJyPg0KJmd0OyZndDsmZ3Q7IHN1cHBsYW50PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgdGhlIG1lbnRpb25lZCBtZWNoYW5pc21zPzxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE5vLiZuYnNwOyZuYnNwOyBJdCBp cyBqdXN0IHNob3dpbmcgdGhhdCBtYW55IHNwZWNpYWxpemVkIFB1c2ggbWVjaGFuaXNtIGV4aXN0 Ljxicj4NCiZndDsmZ3Q7IFRoaXM8YnI+DQomZ3Q7Jmd0OyBpcyBub3QgaW50ZW5kZWQgdG8gc3Vw cGxhbnQgZXhpc3RpbmcgbWVjaGFuaXNtcywgYWx0aG91Z2ggcGVyaGFwcyBpdDxicj4NCiZndDsm Z3Q7IGNhbjxicj4NCiZndDsmZ3Q7IGhlbHAgYXZvaWQgZnV0dXJlIGRlZGljYXRlZCBzb2x1dGlv bnMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLSAyLjM6ICZxdW90O1dlIG5lZWQg YSBuZXcgcHViLXN1Yjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRlY2hub2xvZ3kmcXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBU aGUgc2hlcGhlcmQgd3JpdGUgdXAgbWVudGlvbmVkIGEgZ29hbCB0byB1c2UgZXhpc3RpbmcgdGVj aG5vbG9naWVzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IElzIHRoZSBwb2ludCBv ZiB0aGlzIHNlbnRlbmNlIHRvIHN1Z2dlc3QgdGhhdCBpcyBub3QgZmVhc2libGU/PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRXhpc3Rpbmcg dGVjaG5vbG9naWVzIGNhbm5vdCBtZWV0IGFsbCB0aGUgcmVxdWlyZW1lbnRzIHNwZWNpZmllZC48 YnI+DQomZ3Q7Jmd0OyBUaGVyZSBhcmU8YnI+DQomZ3Q7Jmd0OyB0ZWNobm9sb2d5IGRyYWZ0cyBw cm9ncmVzc2luZyBpbiBORVRDT05GIHdoaWNoIGNhbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLSA0LjEsIDR0aCBwYXJhZ3JhcGg6 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhlIE1BWSBkb2Vzbid0IHNlZW0gcmln aHQtLWlzIHRoaXMgYSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0IHRoZTxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IHN1YnNjcmliZXIgbWF5IGhhdmUgdG8gcmVzdWJzY3JpYmUsIG9yIGEg cmVxdWlyZW1lbnQgb2YgdGhlIGZvcm0gPGJyPg0KJmd0OyZndDsmZ3Q7IHRoYXQ8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgc2VydmljZSBNQVkgZm9yY2UgdGhlIHN1YnNjcmli ZXIgdG8gcmVzdWJzY3JpYmU/IChCZSBjYXJlZnVsIDxicj4NCiZndDsmZ3Q7Jmd0OyB3aXRoPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgTUFZcyBpbiByZXF1aXJlbWVudHMgbGFuZ3Vh Z2UtLXRoZXkgaW1wbHkgdW5leHBlY3RlZCB0aGluZ3MuIEZvcjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7IGV4YW1wbGUsIHNldmVyYWwgcmVxdWlyZW1lbnRzIHNheSBhIFNVQlNDUklC RSBNQVkgZG8gc29tZXRoaW5nLS1kbzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IHRo b3NlIGltcGx5IHRoYXQgdGhlIHNlcnZpY2UgTVVTVCBhbGxvdyB0aGUgc3Vic2NyaWJlciB0byBk byBpdCA/KTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IEdvb2QgcG9pbnQuJm5ic3A7Jm5ic3A7IFJld29yZGVkIGluIHYwNy48YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS0gNC4y LjIsIHRoaXJkIGJ1bGxldDogVGhlIHByZXZpb3VzIHNlY3Rpb24gc2FpZCBkYW1wZW5pbmcgcGVy aW9kczxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE1VU1QgYmUgc3VwcG9ydGVkLjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFll cywgYnV0IGRhbXBlbmluZyBpcyBuZXZlciBmb3IgcGVyaW9kaWMgc3Vic2NyaXB0aW9ucy48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtIDQuMi4xLCB0aGlyZCBwYXJhZ3JhcGg6IFRo aXMgaXMgYSBiaXQgYW1iaWd1b3VzLiBJIHRoaW5rIGl0IG1lYW5zPGJyPg0KJmd0OyZndDsmZ3Q7 IHRvPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgY2hhbmdlIHRoZSB3aGF0IHN1YnRy ZWVzIHRoZSBzdWJzY3JpcHRpb24gYXBwbGllcyB0bywgYnV0IGNvdWxkIGJlPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsgaW50ZXJwcmV0ZWQgdG8gY2hhbmdlIHRoZSBzdWJ0cmVlcyB0 aGVtc2VsdmVzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IEZpeGVkPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLSA0LjIuNi40 OiBXb3VsZCBhIG1lY2hhbmlzbSB0aGF0IGFsbG93ZWQgb3V0LW9mLW9yZGVyIGRlbGl2ZXJ5IGJ1 dDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IGdhdmUgdGhlIHN1YnNjcmliZXIgYSB3 YXkgdG8gcmVjb25zdHJ1Y3QgdGhlIG9yZGVyIGZ1bGZpbGwgdGhpczxicj4NCiZndDsmZ3Q7IHJl cXVpcmVtZW50Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFllcywgdGhlIHRpbWVzdGFtcCB3aXRoaW4gYW4gdXBkYXRlLiZuYnNwOyBCdXQg dGhpcyByZXF1aXJlbWVudCB0YXJnZXRzIGE8YnI+DQomZ3Q7Jmd0OyBzcGVjaWZpYyBvYmplY3Qg aW4gYSBzcGVjaWZpYyBzdWJzY3JpcHRpb24uJm5ic3A7IFNvIHRoZXJlIHNob3VsZCBiZSBubzxi cj4NCiZndDsmZ3Q7IGlzc3Vlcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBOaXRz Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0gVGhlIHNoZXBoZXJkIHdyaXRlIHVw IHN1Z2dlc3RzIHRoaXMgaXMgc3RhbmRhcmRzIHRyYWNrLiBUaGUgZHJhZnQ8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBhbmQgdHJhY2tlciBib3RoIHNheSBpbmZvcm1hdGlvbmFsLiBQ bGVhc2UgdXBkYXRlIHRoZSBzaGVwaGVyZCB3cml0PGJyPg0KJmd0OyZndDsmZ3Q7IHVwLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZpeGVk PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLTMsIGxhc3QgcGFyYWdyYXBoOiBXaGF0 J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhICZxdW90O1B1c2gmcXVvdDsgYW5kIGFuPGJyPg0K Jmd0OyZndDsgJnF1b3Q7VXBkYXRlJnF1b3Q7Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFJld29yZGVkPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgLTQuMTogQSBmb3J3YXJkIHJlZmVyZW5jZSB0byB0aGUgc3Vic2NyaXB0aW9u IFFvUyBzZWN0aW9uIHdvdWxkIGJlPGJyPg0KJmd0OyZndDsgaGVscGZ1bC48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBNb3ZlZCB0aGUgcmVx dWlyZW1lbnQgaW4gcXVlc3Rpb24gdG8gNC4yLjYuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgLS0gTGFzdCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2U6IFNlbnRlbmNlIGRvZXNuJ3Qg cGFyc2UuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgRml4ZWQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IC0gNC4yLjgsIHRoaXJkIHBhcmFncmFwaDogSSBkb24ndCB0aGlu ayB0aGF0IHNob3VsZCBiZSBhIDIxMTkgTUFZPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRml4ZWQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldyE8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IEVyaWM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBp MnJzIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJmx0Ozxh IGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5tYWlsdG86aTJyc0BpZXRmLm9yZzwvYT4mZ3Q7 IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj4NCmkycnNAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2kycnM8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pMnJzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_9e9692bd22a041ba91e39a9f7dce8c9eXCHRTP013ciscocom_-- From nobody Fri May 13 08:28:56 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CA212D589; Fri, 13 May 2016 08:28:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513152853.10600.96529.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 08:28:53 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-traceability-10.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:28:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : Interface to the Routing System (I2RS) Traceability: Framework and Information Model Authors : Joe Clarke Gonzalo Salgueiro Carlos Pignataro Filename : draft-ietf-i2rs-traceability-10.txt Pages : 15 Date : 2016-05-13 Abstract: This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-traceability-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 13 08:35:08 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9F812D592 for ; Fri, 13 May 2016 08:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.496 X-Spam-Level: X-Spam-Status: No, score=-14.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ghKGims0jrc for ; Fri, 13 May 2016 08:35:05 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01A412D588 for ; Fri, 13 May 2016 08:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2537; q=dns/txt; s=iport; t=1463153704; x=1464363304; h=subject:references:cc:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=/ewy/rTtCwAuG/6iWliTN0WyMIxBkRpxhMAQOC/dEIo=; b=gdr4TPj4/j+XVOwyueVAY9nlRw3Bj3FyH7IGg9e94ECkj8FvBpDPFxHZ 1skVypQmDn0xGtvD9AzTnGj/G7i9sVI4HxuWkjww1dY2Qt4Qu6ZVvL81D sCnibmabEEkiKL/ErrDm44KtZTMbeL7nP9R/IKawJqLzK/AlXOPvdEqzr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeCAAk8zVX/4UNJK1egzdVK0cMpiGJe?= =?us-ascii?q?Ik9AQ2BdhcNhW0CKIEEOBQBAQEBAQEBZSeEOgkBAQQBAQE1NgsQCxIGLiciDhM?= =?us-ascii?q?GAgEBhW6CPQ7BAwEBAQEBAQEDAQEBAQEBIYYlgXYIgk+HT4JJAQSYJ4V+iCCBa?= =?us-ascii?q?U6EAYMHhVqPQR4BAUKECCAyAQEBiFcBAQU?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208";a="272546880" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2016 15:35:04 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4DFZ3Eh017232 for ; Fri, 13 May 2016 15:35:04 GMT References: <20160513152853.10600.96529.idtracker@ietfa.amsl.com> Cc: i2rs@ietf.org From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: Date: Fri, 13 May 2016 11:35:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160513152853.10600.96529.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-traceability-10.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:35:07 -0000 WG, This draft contains numerous changes from the IESG and area directorate reviews. In particular: * I2RS pub-sub is now MTI * Security wording has been improved * Logging is now done at the beginning of a state change, thus meaning only one timestamp may be present in a log entry * Text was added to address Client authn and disconnect The full set of SxS changes can be found at https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html . Joe On 5/13/16 11:28, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System of the IETF. > > Title : Interface to the Routing System (I2RS) Traceability: Framework and Information Model > Authors : Joe Clarke > Gonzalo Salgueiro > Carlos Pignataro > Filename : draft-ietf-i2rs-traceability-10.txt > Pages : 15 > Date : 2016-05-13 > > Abstract: > This document describes a framework for traceability in the Interface > to the Routing System (I2RS) and information model for that > framework. It specifies the motivation, requirements, use cases, and > defines an information model for recording interactions between > elements implementing the I2RS protocol. This framework provides a > consistent tracing interface for components implementing the I2RS > architecture to record what was done, by which component, and when. > It aims to improve the management of I2RS implementations, and can be > used for troubleshooting, auditing, forensics, and accounting > purposes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-traceability-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Fri May 13 08:35:45 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274A812D588; Fri, 13 May 2016 08:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6DDLLZOH5Yt; Fri, 13 May 2016 08:35:41 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E0D12D594; Fri, 13 May 2016 08:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6734; q=dns/txt; s=iport; t=1463153739; x=1464363339; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=or1u/pEM7cstaQ84KGrAQeTAliYj8b4P78S4DuA7f4M=; b=UPj+I9vIDsX19zU43xqJCk4WzkBdb1pexOseveM1ynYbpMqjC4SyLRMp L64kPZXos/IMLHkY9is7C43MkraET0upiPjO/GD/uXDyrtnSUx99kijnh kIAT/hJhhjIzjTxDSHqVG9JX0UP+H2dtDJWctHxkjXjE+YmknopqPfE46 I=; X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208";a="104055048" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2016 15:35:38 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4DFZbV3000687; Fri, 13 May 2016 15:35:38 GMT To: "Les Ginsberg (ginsberg)" , "rtg-ads@ietf.org" References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> <30733d2a0880449dbd5cf930c48ad6be@XCH-ALN-001.cisco.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: Date: Fri, 13 May 2016 11:35:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <30733d2a0880449dbd5cf930c48ad6be@XCH-ALN-001.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:35:44 -0000 On 5/13/16 08:17, Les Ginsberg (ginsberg) wrote: > Joe - > > Something like the attached file perhaps? Thanks. We have posted rev -10 of this draft that should address all of your comments. Joe > > Les > > >> -----Original Message----- >> From: Joe Clarke (jclarke) >> Sent: Wednesday, May 11, 2016 3:21 PM >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.org >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >> >> On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: >>> Joe - >>> >>> Yes - this looks better to me. >>> >>> What about the "shadow boxes" for Applications/Clients? >> >> Do you have an example draft I could look at for that? >> >> Joe >> >>> >>> Les >>> >>> >>>> -----Original Message----- >>>> From: Joe Clarke (jclarke) >>>> Sent: Wednesday, May 11, 2016 8:19 AM >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; >>>> i2rs@ietf.org >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >>>> >>>> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: >>>>> Joe - >>>>> >>>>> Apologies for the delayed response. I am a victim of my own email >>>>> infilters. :-( Inline. >>>> >>>> Thanks, Les. Have a look at >>>> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- >>>> 10.diff.html >>>> . I added a new line to show the flow in both directions. >>>> >>>> Joe >>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Joe Clarke (jclarke) >>>>>> Sent: Friday, April 29, 2016 10:44 AM >>>>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >>>>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; >>>>>> i2rs@ietf.org >>>>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >>>>>> >>>>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: >>>>>>> Summary: This document is a well written document - easy to >>>> understand. >>>>>>> My compliments to the authors. I believe there is one minor issue >>>>>>> which I would like to see addressed before publication. >>>>>> >>>>>> Thanks for your comments and feedback, Les. Please see below for >>>>>> some replies and questions. >>>>>> >>>>>>> In Section 5.2 there is a definition of the information which is >>>>>>> required to be kept by an I2RS Agent for each I2RS interaction. I >>>>>>> would like to see the addition of "Request State" into this list. >>>>>>> Operationally each request could be in one of the following states: >>>>>>> >>>>>>> >>>>>>> >>>>>>> * Enqueued (or pending if you prefer) >>>>>>> >>>>>>> * In process >>>>>>> >>>>>>> * Completed >>>>>>> >>>>>>> >>>>>>> >>>>>>> The lack of such a state seems to imply that both the queue time >>>>>>> and the processing time are insignificant. While I think this may >>>>>>> be the case for many requests, it will not always be the case. In >>>>>>> queue time may be lengthy due to other load on the Agent. Also, >>>>>>> some requests - particularly destructive requests which involve >>>>>>> cleanup of resources - may take a significant amount of time to >> complete. >>>>>> >>>>>> Good observation. Traceability was aimed mainly at the termination >>>>>> of the request, but I like the idea of tracing the state machine. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Along with this an additional timestamp - Processing Initiated - >>>>>>> would be useful to indicate when processing of the request >>>>>>> actually >>>> began. >>>>>> >>>>>> I don't know we need a new timestamp. Perhaps we just need to >>>> rename >>>>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" >> and >>>>>> "End Timestamp" to denote the time within the current state. What >>>>>> do you think? >>>>> >>>>> [Les:] My intent was to log the time at which the request began >>>>> processing >>>> so that you can see whether a long delay in completion was due to >>>> enqueue delay or actual lengthy processing time. I am not adamant >>>> about this so if you want to stay with the two timestamps that is OK. >>>>> >>>>>> >>>>>>> s/Some notable elements on the architecture/ Some notable >> elements >>>>>>> of the architecture >>>>>> >>>>>> Fixed. Thanks! >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Figure 1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Not clear to me why Application IDs start at 0 but Client IDs start at 1. >>>>>> >>>>>> Ah. The numbers there are not IDs. They are the number of actual >>>>>> things in the boxes above. For Applications, there may be 0 to N >>>>>> for a given client. For Clients, you need at least 1. Does that make >> sense? >>>>>> >>>>> [Les:] Maybe you want to use "shadows" on the boxes to indicate >>>>> there >>>> can be multiple Application boxes and multiple Client boxes? >>>>> What you say makes sense but I do not intuit that when I look at the >>>>> ASSCII >>>> art. >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Figure 1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is the text "Op Data V" between I2RS Agent box and Routing System >>>>>>> box intentional? >>>>>> >>>>>> Yes. The 'V' is meant to be an arrow head pointed down. The >>>>>> request and data go from Client to Agent whereas the Response goes >>>>>> from Agent to Client. >>>>>> >>>>>> We are open to suggestions on how to make this clearer. >>>>> >>>>> [Les:] I think it would be clearer if you had two lines - one >>>>> flowing down >>>> associated with the Op Data and one flowing up with the result. >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Section 5.2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Secondary Identity >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is defined to be "opaque" yet if not provided the agent is >>>>>>> supposed to insert "an UNAVAILABLE value". This seems to be a >>>>>>> contradiction unless we have a publicly defined value that clients >>>>>>> are prohibited from using. Absent that you would need a "Secondary >>>> Identity Valid" indicator. >>>>>> >>>>>> Good observation. I think it's fine to say that this field must be >>>>>> logged. If there is no application, then the field will be logged >>>>>> as empty. If there is an application, then whatever value is >>>>>> provided will be logged. >>>>>> >>>>>> Do you feel strongly that we need a field to indicate Application >> Present? >>>>>> >>>>> [Les:] I am fine w your changes. >>>>> >>>>> Les >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Section 7.4 >>>>>>> >>>>>>> >>>>>>> >>>>>>> s/establish an vendor-agnostic/establish a vendor-agnostic >>>>>> >>>>>> Fixed. Thanks! >>>>>> >>>>>> Joe >>> > From nobody Fri May 13 08:36:49 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0CC12D59D; Fri, 13 May 2016 08:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcmR0_xcVVUt; Fri, 13 May 2016 08:36:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6EB12D59B; Fri, 13 May 2016 08:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=579; q=dns/txt; s=iport; t=1463153797; x=1464363397; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yjGeVJpMgQfl5/yL5ns2+oGsLEJJvEe8SooC6KYS+Ms=; b=m/GuD263y8jtsa6Jsr98l+6lFZwj3EV1/P6LRwFxNhHtyMu4zLVE5XpE OZoA+59mZczwSxbW67f6dPSlFHhqPY+VsZAqSPggtp2d9nBsD0Ce/LATV 8QyMiApO1bYTwGDFPGzWuveaOa+SbL7jEsYuSHlgGYbRtUHj+GmksgU11 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSBgBl8zVX/5pdJa1egzdVK1O3R4Idg?= =?us-ascii?q?XYkhW0CgSw6EgEBAQEBAQFlJ4RDAQEEIxVBEAsYAgImAgJXBgEMCAEBiCsOsAa?= =?us-ascii?q?QfwEBAQEBAQEBAQEBAQEBAQEBAR+BAYUkgXaCV4c/glkBBJgnjh6BUxaET4MHh?= =?us-ascii?q?VqPQScKMYI3gVEgMgEBAYhXAQEB?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208";a="104042728" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 15:36:37 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4DFaalQ006507; Fri, 13 May 2016 15:36:36 GMT To: Stephen Farrell , The IESG References: <20160504164332.8280.38602.idtracker@ietfa.amsl.com> <5c9b1a61-ade4-8f4c-f754-1b500d2b3b4b@cisco.com> <572A73A0.6080609@cs.tcd.ie> <925b83b8-fa61-3153-911d-8111a690ac03@cisco.com> <572CFF20.10708@cs.tcd.ie> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: Date: Fri, 13 May 2016 11:36:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <572CFF20.10708@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:36:43 -0000 On 5/6/16 16:31, Stephen Farrell wrote: > > On 06/05/16 21:28, Joe Clarke wrote: >> On 5/4/16 18:11, Stephen Farrell wrote: >>> Hi Joe, >>> >>> Those are all fine changes. Couple of tweaks suggested below. >> >> Thank you for your suggestions, Stephen. Please find a new proposed set >> of text changes at >> http://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html >> . We believe they satisfy your discuss items. > > Yep, post that and I'll clear, We just posted rev -10 of the draft. Thanks for the review and text, Stephen. Joe From nobody Fri May 13 08:37:15 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AABF12D589; Fri, 13 May 2016 08:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR7qsRHpweQR; Fri, 13 May 2016 08:37:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DCB12D59B; Fri, 13 May 2016 08:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=296; q=dns/txt; s=iport; t=1463153830; x=1464363430; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ud4Dl6pecuNAzhwWYlydyvkW3SHjSN3Di8+dBGns/Mw=; b=mgIG5Tv7PNqBsleUWWqUGhGdumYGZ3Guh8hfzgwTdMMrVpfFOdOExUuU bhETvD2oBBTk7v3gHtcploQJbGB16XJaJ0XGjm/lDq4+kGmTYkqmp3pF4 RSElXFGQKdNeohScXf3H7zSh9ktEcSMybNTN4Xkcjy5+2vICzAsUWGWiD Y=; X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208";a="272547921" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 15:37:10 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4DFb9fd019446; Fri, 13 May 2016 15:37:09 GMT To: Benoit Claise , The IESG References: <20160503132225.7451.45289.idtracker@ietfa.amsl.com> <86fc3f80-17ac-8449-67ac-3b9729942557@cisco.com> <5728BAC5.4000704@cisco.com> <096a7e2d-2e5f-6ec7-88ad-4a1b95644239@cisco.com> <5729CAE5.7030403@cisco.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <545c6cc5-4d4c-d192-d994-95352654b491@cisco.com> Date: Fri, 13 May 2016 11:37:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <5729CAE5.7030403@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, menachemdodge1@gmail.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:37:14 -0000 On 5/4/16 06:11, Benoit Claise wrote: > Agreed that this is the best we can do. That would solve my DISCUSS. > Please add "typically local configuration", as this is mentioned in > different I2RS documents. We just posted rev -10 of the draft, Benoit. Thanks again for the review. Joe From nobody Fri May 13 08:49:13 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BF112D5B7; Fri, 13 May 2016 08:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6OZQO0SwOz3; Fri, 13 May 2016 08:49:08 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 CD0E812D5B5; Fri, 13 May 2016 08:49:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , "'Ben Campbell'" , "'Alia Atlas'" References: <9e9692bd22a041ba91e39a9f7dce8c9e@XCH-RTP-013.cisco.com> In-Reply-To: <9e9692bd22a041ba91e39a9f7dce8c9e@XCH-RTP-013.cisco.com> Date: Fri, 13 May 2016 11:49:01 -0400 Message-ID: <00a901d1ad2e$f8a21e10$e9e65a30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AA_01D1AD0D.71981F30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIU8vzK+Q9YGgizFl1gE64LnYjY+QJjnbK/nx1as8A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:49:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AA_01D1AD0D.71981F30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Eric:=20 =20 Thanks for jumping in and putting out text that resolves Ben=E2=80=99s = comments. This text works for me with one addition. Add reference to = the security environment draft.=20 =20 Sue=20 =20 From: Eric Voit (evoit) [mailto:evoit@cisco.com]=20 Sent: Friday, May 13, 2016 11:26 AM To: Susan Hares; Ben Campbell; Alia Atlas (akatlas@gmail.com) Cc: The IESG; i2rs@ietf.org; = draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org Subject: RE: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) =20 Hi Ben, =20 I have added the text below as the lead-in to section 4.2.5. I believe = this meets the intents of your suggestions below. =20 Hi Susan & Alia, =20 I have uploaded v08 of https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ If Ben concurs with the text below, I am not aware of any remaining = discuss items. =20 Thanks everyone for your reviews, Eric, Alex, & Alberto 4.2.5. Security Requirements =20 Some uses of this Subscription Service will push privacy-sensitive updates and metadata. Good deployment practices will bind this generated information within secure, encrypted transport layer mechanisms. For example if NETCONF is used as transport, then [RFC5539] would be a valid option to secure the transported information. The Subscription Service can also be used with emerging deployment contexts as well. As an example, deployments based on [i2rs-usecase] can apply these requirements in conjunction with those documented within [i2rs-protocol-security] to secure ephemeral state information being pushed from a Network Element. =20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Friday, May 06, 2016 7:09 PM To: Ben Campbell Cc: Eric Voit (evoit); The IESG; i2rs@ietf.org; = draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) =20 Ben: =20 This is wise idea. I will suggest some text to Eric and you in the = morning. =20 Sue =20 =20 =20 Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone -------- Original message -------- From: Ben Campbell =20 Date: 5/6/2016 2:38 PM (GMT-06:00)=20 To: Susan Hares =20 Cc: Eric Voit , The IESG , = i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, = i2rs-chairs@ietf.org=20 Subject: Re: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)=20 =20 Hi Susan, To be clear, I do not object to the wider context per se. My concern is=20 that the security and privacy requirements are left as implicit, based=20 on the more narrow i2rs/netconf context. I only mentioned the potential=20 of restricting the contextas one possible way forward; I am certainly=20 not wedded to it. My suggestion for a way forward would be to document the high level=20 security and privacy requirements in this document. IIUC, the larger=20 context includes potentially unknown contexts, so some of this may need=20 to be conditional. For example, language like the following might be=20 helpful (this is just an example--I don't mean to say that it is true or = applicable): "Some uses of this mechanism may carry privacy-sensitive information,=20 or generate privacy-sensitive metadata through the subscription=20 mechanism. In contexts where this is true, the following requirements=20 apply..." It might also be reasonable to say that, for the context of i2rs, these=20 requirements are documented in [references] and are expected to be=20 fulfilled by the [transport and or protocol] Eric's email also suggested that the actual transport of data from the=20 Yang datastore may be out of scope for these requirements. I don't=20 object to that, either, as long as it is clear and explicit, although it = would be good to point to where it is _in_ scope. Thanks! Ben. On 6 May 2016, at 1:06, Susan Hares wrote: > Ben: > > This is the first of the "re-use" management protocols. The=20 > requirements > are set-up so that we can suggest additions to the NETCONF and=20 > RESTCONF for > this first of I2RS. > > The I2RS ephemeral work, pub/sub, traceability, and security are=20 > target at > the I2RS protocol definition with the I2RS use case. However, since=20 > these > are general additions to NETCONF/RESTCONF, this work can be used=20 > elsewhere. > > I think the text you are highlighting has this larger context. Now,=20 > one of > the really important things to chat with Alia and Benoit is how do we=20 > handle > the wider use case. Do we mention the wider context? > > The WG thought mentioning it was important. > > Sue > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Thursday, May 05, 2016 5:31 PM > To: Susan Hares > Cc: Eric Voit; The IESG; i2rs@ietf.org; > draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ben Campbell's Discuss on > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > On 5 May 2016, at 5:15, Susan Hares wrote: > >> Eric, Ben and IESG members: >> >> >> >> The pub/sub requirements are part of a 5 part requirements. May I >> quote >> from the shepherd's report: >> >> --------------------- >> >> The requirements for the first version of I2RS are: >> >> 1) model driven ephemeral state - that is data models that do not >> survive >> >> a software or hardware reboot. >> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >> >> >> >> 2) a secure protocol - >> >> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req >> uireme >> nts/ >> >> >> >> 3) traceability - ability to record interactions between I2RS=20 >> elements >> >> (Client, Agent, Routing system) >> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ >> >> >> >> 4) notification publication via subscription >> >> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ >> >> >> >> 5) Protocol to pass Data for Analytics >> >> The first version of these requirements does not include a >> >> separate analytical protocol requirements as the simple use cases may >> >> pass information via query/poll or the notifications. >> >> >> >> The I2RS protocol exists in an secure environment described by: >> >> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment- >> reqs/ >> >> >> >> ------------------------- >> >> >> >> Eric - Perhaps it would be good to point to: >> >> . draft-ietf-i2rs-protocol-security-requirements and >> >> . draft-ietf-i2rs-security-environment-reqs/ >> >> >> >> Ben - Can you tell me how the shepherd report could have been=20 >> clearer? >> The >> I2rs protocol security requirements require: confidentiality, >> encryption, secure transport, protection against replay attack, >> protection against DDoS attack (if possible). > > I think my confusion lies in the fact that, while the shepherd's=20 > writeup > styles this draft as part of the I2RS protocol requirements, the draft > itself claims to describe requirements for a generally useful pub-sub > interface to a yang datastore. It's not clear to me how and when the=20 > I2RS > protocol security requirements apply to it. If the described interface = > is > intended to be useful in contexts other than I2RS (and the draft=20 > explicitly > sets that expectation in 2.2), it needs to talk more generally about > security and privacy. > > For example, it might make sense to say that certain security=20 > requirements > apply in environments where the mechanism might carry privacy=20 > sensitive > data, and then point to the i2rs requirements for when the mechanism=20 > is used > in an I2RS context. > > A different approach might be to more tightly constrain this to i2rs > >> >> >> >> Ben - On opting in, once the receive accepts a transport connection >> from the I2RS server - how is this not an opt-in to receive data?=20 >> What >> are you looking for? > > I guess that depends on the transport. The transport requirements say=20 > the > mechanism has to work over multiple transports. The last paragraph in=20 > 4.2.4 > says "In the case of connection-oriented transports..." which suggests = > that > non-connection-oriented transports are possible. > > Even with a connection-oriented transport, this may depend on how > connection-management is handled, and whether the receiver might be > receiving things it _wants_ to receive on the same transport. > >> >> >> >> Sue Hares >> >> (shepherd) >> >> >> >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit >> (evoit) >> Sent: Wednesday, May 04, 2016 7:25 PM >> To: Ben Campbell; The IESG >> Cc: i2rs@ietf.org; draft-ietf-i2rs-pub-sub-requirements@ietf.org; >> i2rs-chairs@ietf.org; shares@ndzh.com >> Subject: Re: [i2rs] Ben Campbell's Discuss on >> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) >> >> >> >> Hi Ben, >> >> >> >> Thanks for the comment. In-line.... >> >> >> >>> From: Ben Campbell, May 04, 2016 2:49 PM >> >>> = ---------------------------------------------------------------------- >> >>> DISCUSS: >> >>> = ---------------------------------------------------------------------- >> >>> >> >>> I have a couple of points I would like to discuss. Hopefully they=20 >>> can >> >>> be resolved >> >>> easily: >> >>> >> >>> Are there really no requirements for privacy or integrity=20 >>> protection? >> >>> Is there an expectation that this mechanism would ever carry privacy >> >>> sensitive or otherwise sensitive information? >> >> >> >> [eric's comment: >> >> When the subscription is established dynamically via an existing >> transport >> session (which is expected to be the dominant case) we have the same >> expectations for Privacy and integrity as would be provided via a >> "GET" >> instead of a "PUSH" over the same transport. We could have >> replicated all >> these requirements, but that was seen as unnecessary and likely less >> secure >> than adopting existing mechanisms. >> >> >> >> When the Subscriber and Receiver are different, then the transport >> connection will have credentials passed as part of the establishment. >> These >> credentials will be used as a Security Grooming Filter just like the >> above >> case so that pushed objects will be excluded from an Update >> Notification as >> per the permissions of the Receiver. (I.e., this is identical >> behavior to >> the above.) As several people have had questions about this, the >> new v07 >> will make this explicit in the Security section. >> >> End of eric's comment] >> >> >> >> Sue: The transport provides for privacy, integrity protection. Most >> configuration in network boxes would need privacy. >> >> >> >>> - 4.2.5, 2nd to last paragraph: >> >>> I am surprised to find that, when the receiver is not the=20 >>> subscriber, >> >>> that the receiver is expected to opt-out. It seems like some form of >> >>> opt-in or affirmative consent would be needed here. >> >> >> >> The question really was how heavy-weight should the mechanism be. >> Transports been considering are all encrypted. So there is already a >> level >> of trust between the peers. And a target can always pull down the >> connection if there are issues. >> >> >> >> In addition, multicast transports are viable for some future cases. >> We >> didn't want mechanisms which complicated this type of interaction, >> especially in a world where dumb IoT devices may be involved. >> >> >> >> Sue: If the receiver accepts a secure transport set-up from the >> server, can >> you provide the reason why this is not an "opt-in" once it receives >> the >> connection from the I2RS agent? >> >> >> >> >> >>> = ---------------------------------------------------------------------- >> >>> COMMENT: >> >>> = ---------------------------------------------------------------------- >> >>> >> >>> - General: I support Stephen's DISCUSS >> >>> >> >>> -2.2: What is the real scope of this work? Is it expected to=20 >>> supplant >> >>> the mentioned mechanisms? >> >> >> >> No. It is just showing that many specialized Push mechanism exist. >> This >> is not intended to supplant existing mechanisms, although perhaps it >> can >> help avoid future dedicated solutions. >> >>> - 2.3: "We need a new pub-sub >> >>> technology" >> >>> The shepherd write up mentioned a goal to use existing technologies. >> >>> Is the point of this sentence to suggest that is not feasible? >> >> >> >> Existing technologies cannot meet all the requirements specified. >> There are >> technology drafts progressing in NETCONF which can. >> >> >> >>> - 4.1, 4th paragraph: >> >>> The MAY doesn't seem right--is this a statement of fact that the >> >>> subscriber may have to resubscribe, or a requirement of the form=20 >>> that >> >>> the service MAY force the subscriber to resubscribe? (Be careful=20 >>> with >> >>> MAYs in requirements language--they imply unexpected things. For >> >>> example, several requirements say a SUBSCRIBE MAY do something--do >> >>> those imply that the service MUST allow the subscriber to do it ?) >> >> >> >> Good point. Reworded in v07. >> >> >> >>> -- 4.2.2, third bullet: The previous section said dampening periods >> >>> MUST be supported. >> >> >> >> Yes, but dampening is never for periodic subscriptions. >> >>> - 4.2.1, third paragraph: This is a bit ambiguous. I think it means >>> to >> >>> change the what subtrees the subscription applies to, but could be >> >>> interpreted to change the subtrees themselves. >> >> >> >> Fixed >> >>> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but >> >>> gave the subscriber a way to reconstruct the order fulfill this >> requirement? >> >> >> >> Yes, the timestamp within an update. But this requirement targets a >> specific object in a specific subscription. So there should be no >> issues. >> >>> Nits: >> >>> - The shepherd write up suggests this is standards track. The draft >> >>> and tracker both say informational. Please update the shepherd writ >>> up. >> >> >> >> Fixed >> >>> -3, last paragraph: What's the difference between a "Push" and an >> "Update"? >> >> >> >> Reworded >> >>> -4.1: A forward reference to the subscription QoS section would be >> helpful. >> >> >> >> Moved the requirement in question to 4.2.6. >> >>> -- Last paragraph, last sentence: Sentence doesn't parse. >> >> >> >> Fixed >> >>> >> >>> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY >> >> >> >> Fixed >> >> Thanks again for the review! >> >> Eric >> >> _______________________________________________ >> >> i2rs mailing list >> >> i2rs@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_00AA_01D1AD0D.71981F30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Eric:

 

Thanks for jumping in and putting out text that resolves = Ben=E2=80=99s comments.=C2=A0 This text works for me with one = addition.=C2=A0 Add reference to the security environment draft. =

 

Sue

 

From:= = Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Friday, May = 13, 2016 11:26 AM
To: Susan Hares; Ben Campbell; Alia Atlas = (akatlas@gmail.com)
Cc: The IESG; i2rs@ietf.org; = draft-ietf-i2rs-pub-sub-requirements@ietf.org; = i2rs-chairs@ietf.org
Subject: RE: [i2rs] Ben Campbell's = Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = COMMENT)

 

Hi Ben,

 

I have added the text below as the lead-in to section 4.2.5.  I = believe this meets the intents of your suggestions = below.

 

Hi Susan & Alia,

 

I have uploaded v08 of

https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requireme= nts/

If Ben concurs with the text below, I am not aware of any remaining = discuss items.

 

Thanks everyone for your reviews,

Eric, Alex, & Alberto


4.2.5.  Security =
Requirements
 
   Some uses of this Subscription =
Service will push privacy-sensitive
   updates and metadata.  Good =
deployment practices will bind this
   generated information within secure, =
encrypted transport layer
   mechanisms.  For example if =
NETCONF is used as transport, then
   [RFC5539] would be a valid option to =
secure the transported
   information.  The Subscription =
Service can also be used with emerging
   deployment contexts as well.  As =
an example, deployments based on
   [i2rs-usecase] can apply these =
requirements in conjunction with those
   documented within =
[i2rs-protocol-security] to secure ephemeral =
state
   information being pushed from a =
Network Element.
 

 

From:= = Susan Hares [mailto:shares@ndzh.com] =
Sent: Friday, May 06, 2016 7:09 PM
To: Ben = Campbell
Cc: Eric Voit (evoit); The IESG; i2rs@ietf.org; draft-ietf-= i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org
Subje= ct: Re: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = COMMENT)

 

Ben:

 

This is wise idea.  I will suggest some text to = Eric and you in the morning.

 

Sue

 

 

 

Sent via the Samsung Galaxy = Note5, an AT&T 4G LTE = smartphone

-------- Original message = --------

From: Ben Campbell <ben@nostrum.com> =

Date: 5/6/2016 2:38 PM (GMT-06:00) =

To: Susan Hares <shares@ndzh.com> =

Subject: Re: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) =

 

Hi Susan,

To be clear, I do not object to the = wider context per se. My concern is
that the security and privacy = requirements are left as implicit, based
on the more narrow = i2rs/netconf context. I only mentioned the potential
of restricting = the contextas one possible way forward; I am certainly
not wedded to = it.

My suggestion for a way forward would be to document the high = level
security and privacy requirements in this document. IIUC, the = larger
context includes potentially unknown contexts, so some of = this may need
to be conditional. For example, language like the = following might be
helpful (this is just an example--I don't mean to = say that it is true or
applicable):

  "Some uses of = this mechanism may carry privacy-sensitive information,
or = generate    privacy-sensitive metadata through the = subscription
mechanism. In contexts where this is true, the = following requirements
apply..."

It might also be = reasonable to say that, for the context of i2rs, these
requirements = are documented in [references] and are expected to be
fulfilled by = the [transport and or protocol]

Eric's email also suggested that = the actual transport of data from the
Yang datastore may be out of = scope for these requirements. I don't
object to that, either, as = long as it is clear and explicit, although it
would be good to point = to where it is _in_ scope.

Thanks!

Ben.

On 6 May = 2016, at 1:06, Susan Hares wrote:

> Ben:
>
> This = is the first of the "re-use" management protocols.  The =
> requirements
> are set-up so that we can suggest = additions to the NETCONF and
> RESTCONF for
> this first of = I2RS.
>
> The I2RS ephemeral work, pub/sub, traceability, = and security are
> target at
> the I2RS protocol definition = with the I2RS use case.  However, since
> these
> are = general additions to NETCONF/RESTCONF, this work can be used
> = elsewhere.
>
> I think the text you are highlighting has = this larger context.   Now,
> one of
> the really = important things to chat with Alia and Benoit is how do we
> = handle
> the wider use case.   Do we mention the wider = context?
>
> The WG thought mentioning it was = important.
>
> Sue
>
> -----Original = Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> = Sent: Thursday, May 05, 2016 5:31 PM
> To: Susan Hares
> Cc: = Eric Voit; The IESG; i2rs@ietf.org;
> draft-ietf-= i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org
> = Subject: Re: [i2rs] Ben Campbell's Discuss on
> = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = COMMENT)
>
> On 5 May 2016, at 5:15, Susan Hares = wrote:
>
>> Eric, Ben and IESG = members:
>>
>>
>>
>> The pub/sub = requirements are part of a 5 part requirements.   May = I
>> quote
>> from the shepherd's = report:
>>
>> = ---------------------
>>
>> The requirements for the = first version of I2RS are:
>>
>> 1) model driven = ephemeral state - that is data models that do not
>> = survive
>>
>>     a software or = hardware reboot.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/>>
>>
>>
>> 2) a secure protocol = -
>>
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security= -req
>> uireme
>> = nts/
>>
>>
>>
>> 3) traceability - = ability to record interactions between I2RS
>> = elements
>>
>> (Client, Agent, Routing = system)
>>
>> h= ttps://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/
>= >
>>
>>
>> 4) notification publication via = subscription
>>
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requireme= nts/
>>
>>
>>
>> 5) Protocol to = pass Data for Analytics
>>
>> The first version of = these requirements does not include a
>>
>> separate = analytical protocol requirements as the simple use cases = may
>>
>> pass information via query/poll or the = notifications.
>>
>>
>>
>> The I2RS = protocol exists in an secure environment described = by:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environm= ent-
>> = reqs/
>>
>>
>>
>> = -------------------------
>>
>>
>>
>>= Eric - Perhaps it would be good to point to:
>>
>> = .         = draft-ietf-i2rs-protocol-security-requirements = and
>>
>> = .         = draft-ietf-i2rs-security-environment-reqs/
>>
>>
>= ;>
>> Ben - Can you tell me how the shepherd report could = have been
>> clearer?
>>  The
>> I2rs = protocol security requirements require:  = confidentiality,
>> encryption, secure transport, protection = against replay attack,
>> protection against DDoS attack (if = possible).
>
> I think my confusion lies in the fact that, = while the shepherd's
> writeup
> styles this draft as part = of the I2RS protocol requirements, the draft
> itself claims to = describe requirements for a generally useful pub-sub
> interface = to a yang datastore. It's not clear to me how and when the
> = I2RS
> protocol security requirements apply to it. If the = described interface
> is
> intended to be useful in = contexts other than I2RS (and the draft
> explicitly
> sets = that expectation in 2.2), it needs to talk more generally about
> = security and privacy.
>
> For example, it might make sense = to say that certain security
> requirements
> apply in = environments where the mechanism might carry privacy
> = sensitive
> data, and then point to the i2rs requirements for when = the mechanism
> is used
> in an I2RS = context.
>
> A different approach might be to more tightly = constrain this to = i2rs
>
>>
>>
>>
>> Ben - On = opting in, once the receive accepts a transport connection
>> = from the I2RS server - how is this not an opt-in to receive data? =
>> What
>> are you looking for?
>
> I = guess that depends on the transport. The transport requirements say =
> the
> mechanism has to work over multiple transports. The = last paragraph in
> 4.2.4
> says "In the case of = connection-oriented transports..." which suggests
> = that
> non-connection-oriented transports are = possible.
>
> Even with a connection-oriented transport, = this may depend on how
> connection-management is handled, and = whether the receiver might be
> receiving things it _wants_ to = receive on the same = transport.
>
>>
>>
>>
>> Sue = Hares
>>
>> = (shepherd)
>>
>>
>>
>>
>>>> -----Original Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Eric Voit
>> (evoit)
>> Sent: Wednesday, = May 04, 2016 7:25 PM
>> To: Ben Campbell; The IESG
>> = Cc: i2rs@ietf.org; draft-ietf-= i2rs-pub-sub-requirements@ietf.org;
>> i2rs-chairs@ietf.org; shares@ndzh.com
>> Subject: = Re: [i2rs] Ben Campbell's Discuss on
>> = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = COMMENT)
>>
>>
>>
>> Hi = Ben,
>>
>>
>>
>> Thanks for the = comment.   = In-line....
>>
>>
>>
>>> From: = Ben Campbell, May 04, 2016 2:49 PM
>>
>>> = ---------------------------------------------------------------------->>
>>> DISCUSS:
>>
>>> = ---------------------------------------------------------------------->>
>>>
>>
>>> I have a couple of = points I would like to discuss. Hopefully they
>>> = can
>>
>>> be resolved
>>
>>> = easily:
>>
>>>
>>
>>> Are = there really no requirements for privacy or integrity
>>> = protection?
>>
>>> Is there an expectation that = this mechanism would ever carry privacy
>>
>>> = sensitive or otherwise sensitive = information?
>>
>>
>>
>> [eric's = comment:
>>
>> When the subscription is established = dynamically via an existing
>> transport
>> session = (which is expected to be the dominant case) we have the same
>> = expectations for Privacy and integrity as would be provided via = a
>> "GET"
>> instead of a "PUSH" = over the same transport.   We could have
>> = replicated all
>> these requirements, but that was seen as = unnecessary and likely less
>> secure
>> than adopting = existing mechanisms.
>>
>>
>>
>> = When the Subscriber and Receiver are different, then the = transport
>> connection will have credentials passed as part of = the establishment.
>> These
>> credentials will be = used as a Security Grooming Filter just like the
>> = above
>> case so that pushed objects will be excluded from an = Update
>> Notification as
>> per the permissions of = the Receiver.   (I.e., this is identical
>> behavior = to
>> the above.)    As several people have had = questions about this, the
>> new v07
>> will make this = explicit in the Security section.
>>
>> End of eric's = comment]
>>
>>
>>
>> Sue: The = transport provides for privacy, integrity protection.   = Most
>> configuration in network boxes would need = privacy.
>>
>>
>>
>>> - 4.2.5, = 2nd to last paragraph:
>>
>>> I am surprised to = find that, when the receiver is not the
>>> = subscriber,
>>
>>> that the receiver is expected to = opt-out. It seems like some form of
>>
>>> opt-in = or affirmative consent would be needed = here.
>>
>>
>>
>> The question = really was how heavy-weight should the mechanism be.
>> = Transports been considering are all encrypted.  So there is already = a
>> level
>> of trust between the peers.  And a = target can always pull down the
>> connection if there are = issues.
>>
>>
>>
>> In addition, = multicast transports are viable for some future cases.
>> = We
>> didn't want mechanisms which complicated this type of = interaction,
>> especially in a world where dumb IoT devices = may be involved.
>>
>>
>>
>> Sue: If = the receiver accepts a secure transport set-up from the
>> = server, can
>> you provide the reason why this is not an = "opt-in" once it receives
>> the
>> = connection from the I2RS = agent?
>>
>>
>>
>>
>>
>= ;>> = ---------------------------------------------------------------------->>
>>> COMMENT:
>>
>>> = ---------------------------------------------------------------------->>
>>>
>>
>>> - General: I = support Stephen's = DISCUSS
>>
>>>
>>
>>> -2.2: = What is the real scope of this work? Is it expected to
>>> = supplant
>>
>>> the mentioned = mechanisms?
>>
>>
>>
>> = No.   It is just showing that many specialized Push mechanism = exist.
>> This
>> is not intended to supplant existing = mechanisms, although perhaps it
>> can
>> help avoid = future dedicated solutions.
>>
>>> - 2.3: "We = need a new pub-sub
>>
>>>    = technology"
>>
>>> The shepherd write up = mentioned a goal to use existing = technologies.
>>
>>> Is the point of this sentence = to suggest that is not = feasible?
>>
>>
>>
>> Existing = technologies cannot meet all the requirements specified.
>> = There are
>> technology drafts progressing in NETCONF which = can.
>>
>>
>>
>>> - 4.1, 4th = paragraph:
>>
>>> The MAY doesn't seem right--is = this a statement of fact that the
>>
>>> subscriber = may have to resubscribe, or a requirement of the form
>>> = that
>>
>>> the service MAY force the subscriber to = resubscribe? (Be careful
>>> = with
>>
>>> MAYs in requirements language--they = imply unexpected things. For
>>
>>> example, = several requirements say a SUBSCRIBE MAY do = something--do
>>
>>> those imply that the service = MUST allow the subscriber to do it = ?)
>>
>>
>>
>> Good = point.   Reworded in = v07.
>>
>>
>>
>>> -- 4.2.2, third = bullet: The previous section said dampening = periods
>>
>>> MUST be = supported.
>>
>>
>>
>> Yes, but = dampening is never for periodic = subscriptions.
>>
>>> - 4.2.1, third paragraph: = This is a bit ambiguous. I think it means
>>> = to
>>
>>> change the what subtrees the subscription = applies to, but could be
>>
>>> interpreted to = change the subtrees = themselves.
>>
>>
>>
>> = Fixed
>>
>>> - 4.2.6.4: Would a mechanism that = allowed out-of-order delivery but
>>
>>> gave the = subscriber a way to reconstruct the order fulfill this
>> = requirement?
>>
>>
>>
>> Yes, the = timestamp within an update.  But this requirement targets = a
>> specific object in a specific subscription.  So there = should be no
>> issues.
>>
>>> = Nits:
>>
>>> - The shepherd write up suggests this = is standards track. The draft
>>
>>> and tracker = both say informational. Please update the shepherd writ
>>> = up.
>>
>>
>>
>> = Fixed
>>
>>> -3, last paragraph: What's the = difference between a "Push" and an
>> = "Update"?
>>
>>
>>
>> = Reworded
>>
>>> -4.1: A forward reference to the = subscription QoS section would be
>> = helpful.
>>
>>
>>
>> Moved the = requirement in question to 4.2.6.
>>
>>> -- Last = paragraph, last sentence: Sentence doesn't = parse.
>>
>>
>>
>> = Fixed
>>
>>>
>>
>>> - 4.2.8, = third paragraph: I don't think that should be a 2119 = MAY
>>
>>
>>
>> = Fixed
>>
>> Thanks again for the = review!
>>
>> Eric
>>
>> = _______________________________________________
>>
>> = i2rs mailing list
>>
>>  <mailto:i2rs@ietf.org> i2rs@ietf.org
>>
>>&n= bsp; <https://www.ietf.org/= mailman/listinfo/i2rs>
>> https://www.ietf.org/= mailman/listinfo/i2rs

------=_NextPart_000_00AA_01D1AD0D.71981F30-- From nobody Fri May 13 10:16:43 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FE812D1A9; Fri, 13 May 2016 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQnXIuSLjL0L; Fri, 13 May 2016 10:16:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604F812B05B; Fri, 13 May 2016 10:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71064; q=dns/txt; s=iport; t=1463159792; x=1464369392; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zKhhV4FZvoL+Z5LFML5JbOHvoLATeJ7fU8CskI5pvNM=; b=QCAomqNS++hSkIoJ0qPU2ribIebOJC03W1pvYxu7vPEeuktDYO0s7A8b ncyhRXQ59yKFi1x2kQ6ukF7IQPSLwfsHI2URH/AhDM7dypEbrkt3QIzmo OeiGOEb/HNawpHsEMkcEi05iGXvs7bT/fvep4gsIKMuZbbm42gB1QIU+Z w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AgBuCzZX/4cNJK1egmxLVX4GrWuLZ?= =?us-ascii?q?QENgXIEFwEKgj2DMgIcgRA4FAEBAQEBAQFlJ4RCAQEBAwEBAQEXAQgKQQsFBwQ?= =?us-ascii?q?CAQgOAwMBAQEBDAETAQIEAwICAh8GCxQJCAIEAQ0FCBOHegMPCA6xAIxdDYQjA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJYRNgkOBThEBBi0JFoJKglkFhjsJgTq?= =?us-ascii?q?LMoRGMQGFfYJ4gy+BcoFwhE+IYYYtgS+HZAEeAQFCggYbFoE1boccBQQXH38BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208,217";a="104088996" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2016 17:16:30 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4DHGTBl013182 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 17:16:29 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 13:16:28 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Fri, 13 May 2016 13:16:28 -0400 From: "Eric Voit (evoit)" To: Susan Hares , "'Ben Campbell'" , "'Alia Atlas'" Thread-Topic: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRp+xNYDspbfuo4UOD+L2iwgAMip+3BC7ggABM94D//9TXoA== Date: Fri, 13 May 2016 17:16:28 +0000 Message-ID: References: <9e9692bd22a041ba91e39a9f7dce8c9e@XCH-RTP-013.cisco.com> <00a901d1ad2e$f8a21e10$e9e65a30$@ndzh.com> In-Reply-To: <00a901d1ad2e$f8a21e10$e9e65a30$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_d12fea6bf3d9431d8994524fd1e6e576XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , 'The IESG' , "i2rs-chairs@ietf.org" Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 17:16:38 -0000 --_000_d12fea6bf3d9431d8994524fd1e6e576XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VlLA0KDQpNYWRlIHlvdXIgY2hhbmdlICAoc2VlIGdyZWVuIGJlbG93KS4gICBJIHdpbGwgYXdh aXQgZXZlcnlvbmUgZWxzZeKAmXMgb2sgdG8gc2VlIGlmIHRoZXJlIGFyZSBhbnkgZmluYWwgY2hh bmdlcyBiZWZvcmUgcG9zdGluZy4NCg0KRXJpYw0KDQo0LjIuNS4gIFNlY3VyaXR5IFJlcXVpcmVt ZW50cw0KDQogICBTb21lIHVzZXMgb2YgdGhpcyBTdWJzY3JpcHRpb24gU2VydmljZSB3aWxsIHB1 c2ggcHJpdmFjeS1zZW5zaXRpdmUNCiAgIHVwZGF0ZXMgYW5kIG1ldGFkYXRhLiAgR29vZCBkZXBs b3ltZW50IHByYWN0aWNlcyB3aWxsIGJpbmQgdGhpcw0KICAgZ2VuZXJhdGVkIGluZm9ybWF0aW9u IHdpdGhpbiBzZWN1cmUsIGVuY3J5cHRlZCB0cmFuc3BvcnQgbGF5ZXINCiAgIG1lY2hhbmlzbXMu ICBGb3IgZXhhbXBsZSBpZiBORVRDT05GIGlzIHVzZWQgYXMgdHJhbnNwb3J0LCB0aGVuDQogICBb UkZDNTUzOV0gd291bGQgYmUgYSB2YWxpZCBvcHRpb24gdG8gc2VjdXJlIHRoZSB0cmFuc3BvcnRl ZA0KICAgaW5mb3JtYXRpb24uICBUaGUgU3Vic2NyaXB0aW9uIFNlcnZpY2UgY2FuIGFsc28gYmUg dXNlZCB3aXRoIGVtZXJnaW5nDQogICBkZXBsb3ltZW50IGNvbnRleHRzIGFzIHdlbGwuICBBcyBh biBleGFtcGxlLCBkZXBsb3ltZW50cyBiYXNlZCBvbg0KICAgW2kycnMtdXNlY2FzZV0gY2FuIGFw cGx5IHRoZXNlIHJlcXVpcmVtZW50cyBpbiBjb25qdW5jdGlvbiB3aXRoIHRob3NlDQogICBkb2N1 bWVudGVkIHdpdGhpbiBbaTJycy1lbnZpcm9ubWVudC1zZWN1cml0eV1hbmQNCiAgIFtpMnJzLXBy b3RvY29sLXNlY3VyaXR5XSB0byBzZWN1cmUgZXBoZW1lcmFsIHN0YXRlIGluZm9ybWF0aW9uIGJl aW5nDQogICBwdXNoZWQgZnJvbSBhIE5ldHdvcmsgRWxlbWVudC4NCg0KDQpGcm9tOiBTdXNhbiBI YXJlcywgTWF5IDEzLCAyMDE2IDExOjQ5IEFNDQoNCkVyaWM6DQoNClRoYW5rcyBmb3IganVtcGlu ZyBpbiBhbmQgcHV0dGluZyBvdXQgdGV4dCB0aGF0IHJlc29sdmVzIEJlbuKAmXMgY29tbWVudHMu ICBUaGlzIHRleHQgd29ya3MgZm9yIG1lIHdpdGggb25lIGFkZGl0aW9uLiAgQWRkIHJlZmVyZW5j ZSB0byB0aGUgc2VjdXJpdHkgZW52aXJvbm1lbnQgZHJhZnQuDQoNClN1ZQ0KDQpGcm9tOiBFcmlj IFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0NClNlbnQ6IEZyaWRheSwgTWF5 IDEzLCAyMDE2IDExOjI2IEFNDQpUbzogU3VzYW4gSGFyZXM7IEJlbiBDYW1wYmVsbDsgQWxpYSBB dGxhcyAoYWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPikNCkNjOiBU aGUgSUVTRzsgaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYt aTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pMnJz LXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnPjsgaTJycy1jaGFpcnNAaWV0Zi5vcmc8bWFp bHRvOmkycnMtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtpMnJzXSBCZW4gQ2FtcGJl bGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0wNjog KHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KSGkgQmVuLA0KDQpJIGhhdmUgYWRkZWQgdGhl IHRleHQgYmVsb3cgYXMgdGhlIGxlYWQtaW4gdG8gc2VjdGlvbiA0LjIuNS4gIEkgYmVsaWV2ZSB0 aGlzIG1lZXRzIHRoZSBpbnRlbnRzIG9mIHlvdXIgc3VnZ2VzdGlvbnMgYmVsb3cuDQoNCkhpIFN1 c2FuICYgQWxpYSwNCg0KSSBoYXZlIHVwbG9hZGVkIHYwOCBvZg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLw0KSWYg QmVuIGNvbmN1cnMgd2l0aCB0aGUgdGV4dCBiZWxvdywgSSBhbSBub3QgYXdhcmUgb2YgYW55IHJl bWFpbmluZyBkaXNjdXNzIGl0ZW1zLg0KDQpUaGFua3MgZXZlcnlvbmUgZm9yIHlvdXIgcmV2aWV3 cywNCkVyaWMsIEFsZXgsICYgQWxiZXJ0bw0KDQo0LjIuNS4gIFNlY3VyaXR5IFJlcXVpcmVtZW50 cw0KDQoNCg0KICAgU29tZSB1c2VzIG9mIHRoaXMgU3Vic2NyaXB0aW9uIFNlcnZpY2Ugd2lsbCBw dXNoIHByaXZhY3ktc2Vuc2l0aXZlDQoNCiAgIHVwZGF0ZXMgYW5kIG1ldGFkYXRhLiAgR29vZCBk ZXBsb3ltZW50IHByYWN0aWNlcyB3aWxsIGJpbmQgdGhpcw0KDQogICBnZW5lcmF0ZWQgaW5mb3Jt YXRpb24gd2l0aGluIHNlY3VyZSwgZW5jcnlwdGVkIHRyYW5zcG9ydCBsYXllcg0KDQogICBtZWNo YW5pc21zLiAgRm9yIGV4YW1wbGUgaWYgTkVUQ09ORiBpcyB1c2VkIGFzIHRyYW5zcG9ydCwgdGhl bg0KDQogICBbUkZDNTUzOV0gd291bGQgYmUgYSB2YWxpZCBvcHRpb24gdG8gc2VjdXJlIHRoZSB0 cmFuc3BvcnRlZA0KDQogICBpbmZvcm1hdGlvbi4gIFRoZSBTdWJzY3JpcHRpb24gU2VydmljZSBj YW4gYWxzbyBiZSB1c2VkIHdpdGggZW1lcmdpbmcNCg0KICAgZGVwbG95bWVudCBjb250ZXh0cyBh cyB3ZWxsLiAgQXMgYW4gZXhhbXBsZSwgZGVwbG95bWVudHMgYmFzZWQgb24NCg0KICAgW2kycnMt dXNlY2FzZV0gY2FuIGFwcGx5IHRoZXNlIHJlcXVpcmVtZW50cyBpbiBjb25qdW5jdGlvbiB3aXRo IHRob3NlDQoNCiAgIGRvY3VtZW50ZWQgd2l0aGluIFtpMnJzLXByb3RvY29sLXNlY3VyaXR5XSB0 byBzZWN1cmUgZXBoZW1lcmFsIHN0YXRlDQoNCiAgIGluZm9ybWF0aW9uIGJlaW5nIHB1c2hlZCBm cm9tIGEgTmV0d29yayBFbGVtZW50Lg0KDQoNCg0KRnJvbTogU3VzYW4gSGFyZXMgW21haWx0bzpz aGFyZXNAbmR6aC5jb21dDQpTZW50OiBGcmlkYXksIE1heSAwNiwgMjAxNiA3OjA5IFBNDQpUbzog QmVuIENhbXBiZWxsDQpDYzogRXJpYyBWb2l0IChldm9pdCk7IFRoZSBJRVNHOyBpMnJzQGlldGYu b3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWly ZW1lbnRzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVu dHNAaWV0Zi5vcmc+OyBpMnJzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aTJycy1jaGFpcnNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2OiAod2l0aCBESVNDVVNTIGFuZCBD T01NRU5UKQ0KDQpCZW46DQoNClRoaXMgaXMgd2lzZSBpZGVhLiAgSSB3aWxsIHN1Z2dlc3Qgc29t ZSB0ZXh0IHRvIEVyaWMgYW5kIHlvdSBpbiB0aGUgbW9ybmluZy4NCg0KU3VlDQoNCg0KDQpTZW50 IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUN Ci0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCA8 YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+Pg0KRGF0ZTogNS82LzIwMTYg MjozOCBQTSAoR01ULTA2OjAwKQ0KVG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFp bHRvOnNoYXJlc0BuZHpoLmNvbT4+DQpDYzogRXJpYyBWb2l0IDxldm9pdEBjaXNjby5jb208bWFp bHRvOmV2b2l0QGNpc2NvLmNvbT4+LCBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVz Z0BpZXRmLm9yZz4+LCBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPiwgZHJhZnQt aWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc+LCBpMnJzLWNoYWlyc0BpZXRmLm9y ZzxtYWlsdG86aTJycy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2kycnNdIEJlbiBD YW1wYmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRz LTA2OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpIaSBTdXNhbiwNCg0KVG8gYmUgY2xl YXIsIEkgZG8gbm90IG9iamVjdCB0byB0aGUgd2lkZXIgY29udGV4dCBwZXIgc2UuIE15IGNvbmNl cm4gaXMNCnRoYXQgdGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IHJlcXVpcmVtZW50cyBhcmUgbGVm dCBhcyBpbXBsaWNpdCwgYmFzZWQNCm9uIHRoZSBtb3JlIG5hcnJvdyBpMnJzL25ldGNvbmYgY29u dGV4dC4gSSBvbmx5IG1lbnRpb25lZCB0aGUgcG90ZW50aWFsDQpvZiByZXN0cmljdGluZyB0aGUg Y29udGV4dGFzIG9uZSBwb3NzaWJsZSB3YXkgZm9yd2FyZDsgSSBhbSBjZXJ0YWlubHkNCm5vdCB3 ZWRkZWQgdG8gaXQuDQoNCk15IHN1Z2dlc3Rpb24gZm9yIGEgd2F5IGZvcndhcmQgd291bGQgYmUg dG8gZG9jdW1lbnQgdGhlIGhpZ2ggbGV2ZWwNCnNlY3VyaXR5IGFuZCBwcml2YWN5IHJlcXVpcmVt ZW50cyBpbiB0aGlzIGRvY3VtZW50LiBJSVVDLCB0aGUgbGFyZ2VyDQpjb250ZXh0IGluY2x1ZGVz IHBvdGVudGlhbGx5IHVua25vd24gY29udGV4dHMsIHNvIHNvbWUgb2YgdGhpcyBtYXkgbmVlZA0K dG8gYmUgY29uZGl0aW9uYWwuIEZvciBleGFtcGxlLCBsYW5ndWFnZSBsaWtlIHRoZSBmb2xsb3dp bmcgbWlnaHQgYmUNCmhlbHBmdWwgKHRoaXMgaXMganVzdCBhbiBleGFtcGxlLS1JIGRvbid0IG1l YW4gdG8gc2F5IHRoYXQgaXQgaXMgdHJ1ZSBvcg0KYXBwbGljYWJsZSk6DQoNCiAgIlNvbWUgdXNl cyBvZiB0aGlzIG1lY2hhbmlzbSBtYXkgY2FycnkgcHJpdmFjeS1zZW5zaXRpdmUgaW5mb3JtYXRp b24sDQpvciBnZW5lcmF0ZSAgICBwcml2YWN5LXNlbnNpdGl2ZSBtZXRhZGF0YSB0aHJvdWdoIHRo ZSBzdWJzY3JpcHRpb24NCm1lY2hhbmlzbS4gSW4gY29udGV4dHMgd2hlcmUgdGhpcyBpcyB0cnVl LCB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50cw0KYXBwbHkuLi4iDQoNCkl0IG1pZ2h0IGFsc28g YmUgcmVhc29uYWJsZSB0byBzYXkgdGhhdCwgZm9yIHRoZSBjb250ZXh0IG9mIGkycnMsIHRoZXNl DQpyZXF1aXJlbWVudHMgYXJlIGRvY3VtZW50ZWQgaW4gW3JlZmVyZW5jZXNdIGFuZCBhcmUgZXhw ZWN0ZWQgdG8gYmUNCmZ1bGZpbGxlZCBieSB0aGUgW3RyYW5zcG9ydCBhbmQgb3IgcHJvdG9jb2xd DQoNCkVyaWMncyBlbWFpbCBhbHNvIHN1Z2dlc3RlZCB0aGF0IHRoZSBhY3R1YWwgdHJhbnNwb3J0 IG9mIGRhdGEgZnJvbSB0aGUNCllhbmcgZGF0YXN0b3JlIG1heSBiZSBvdXQgb2Ygc2NvcGUgZm9y IHRoZXNlIHJlcXVpcmVtZW50cy4gSSBkb24ndA0Kb2JqZWN0IHRvIHRoYXQsIGVpdGhlciwgYXMg bG9uZyBhcyBpdCBpcyBjbGVhciBhbmQgZXhwbGljaXQsIGFsdGhvdWdoIGl0DQp3b3VsZCBiZSBn b29kIHRvIHBvaW50IHRvIHdoZXJlIGl0IGlzIF9pbl8gc2NvcGUuDQoNClRoYW5rcyENCg0KQmVu Lg0KDQpPbiA2IE1heSAyMDE2LCBhdCAxOjA2LCBTdXNhbiBIYXJlcyB3cm90ZToNCg0KPiBCZW46 DQo+DQo+IFRoaXMgaXMgdGhlIGZpcnN0IG9mIHRoZSAicmUtdXNlIiBtYW5hZ2VtZW50IHByb3Rv Y29scy4gIFRoZQ0KPiByZXF1aXJlbWVudHMNCj4gYXJlIHNldC11cCBzbyB0aGF0IHdlIGNhbiBz dWdnZXN0IGFkZGl0aW9ucyB0byB0aGUgTkVUQ09ORiBhbmQNCj4gUkVTVENPTkYgZm9yDQo+IHRo aXMgZmlyc3Qgb2YgSTJSUy4NCj4NCj4gVGhlIEkyUlMgZXBoZW1lcmFsIHdvcmssIHB1Yi9zdWIs IHRyYWNlYWJpbGl0eSwgYW5kIHNlY3VyaXR5IGFyZQ0KPiB0YXJnZXQgYXQNCj4gdGhlIEkyUlMg cHJvdG9jb2wgZGVmaW5pdGlvbiB3aXRoIHRoZSBJMlJTIHVzZSBjYXNlLiAgSG93ZXZlciwgc2lu Y2UNCj4gdGhlc2UNCj4gYXJlIGdlbmVyYWwgYWRkaXRpb25zIHRvIE5FVENPTkYvUkVTVENPTkYs IHRoaXMgd29yayBjYW4gYmUgdXNlZA0KPiBlbHNld2hlcmUuDQo+DQo+IEkgdGhpbmsgdGhlIHRl eHQgeW91IGFyZSBoaWdobGlnaHRpbmcgaGFzIHRoaXMgbGFyZ2VyIGNvbnRleHQuICAgTm93LA0K PiBvbmUgb2YNCj4gdGhlIHJlYWxseSBpbXBvcnRhbnQgdGhpbmdzIHRvIGNoYXQgd2l0aCBBbGlh IGFuZCBCZW5vaXQgaXMgaG93IGRvIHdlDQo+IGhhbmRsZQ0KPiB0aGUgd2lkZXIgdXNlIGNhc2Uu ICAgRG8gd2UgbWVudGlvbiB0aGUgd2lkZXIgY29udGV4dD8NCj4NCj4gVGhlIFdHIHRob3VnaHQg bWVudGlvbmluZyBpdCB3YXMgaW1wb3J0YW50Lg0KPg0KPiBTdWUNCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0u Y29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDA1LCAyMDE2IDU6MzEgUE0NCj4gVG86IFN1c2Fu IEhhcmVzDQo+IENjOiBFcmljIFZvaXQ7IFRoZSBJRVNHOyBpMnJzQGlldGYub3JnPG1haWx0bzpp MnJzQGlldGYub3JnPjsNCj4gZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGll dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5v cmc+OyBpMnJzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aTJycy1jaGFpcnNAaWV0Zi5vcmc+DQo+ IFN1YmplY3Q6IFJlOiBbaTJyc10gQmVuIENhbXBiZWxsJ3MgRGlzY3VzcyBvbg0KPiBkcmFmdC1p ZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDY6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1F TlQpDQo+DQo+IE9uIDUgTWF5IDIwMTYsIGF0IDU6MTUsIFN1c2FuIEhhcmVzIHdyb3RlOg0KPg0K Pj4gRXJpYywgQmVuIGFuZCBJRVNHIG1lbWJlcnM6DQo+Pg0KPj4NCj4+DQo+PiBUaGUgcHViL3N1 YiByZXF1aXJlbWVudHMgYXJlIHBhcnQgb2YgYSA1IHBhcnQgcmVxdWlyZW1lbnRzLiAgIE1heSBJ DQo+PiBxdW90ZQ0KPj4gZnJvbSB0aGUgc2hlcGhlcmQncyByZXBvcnQ6DQo+Pg0KPj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj4gVGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIGZpcnN0IHZl cnNpb24gb2YgSTJSUyBhcmU6DQo+Pg0KPj4gMSkgbW9kZWwgZHJpdmVuIGVwaGVtZXJhbCBzdGF0 ZSAtIHRoYXQgaXMgZGF0YSBtb2RlbHMgdGhhdCBkbyBub3QNCj4+IHN1cnZpdmUNCj4+DQo+PiAg ICAgYSBzb2Z0d2FyZSBvciBoYXJkd2FyZSByZWJvb3QuDQo+Pg0KPj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS8NCj4+DQo+ Pg0KPj4NCj4+IDIpIGEgc2VjdXJlIHByb3RvY29sIC0NCj4+DQo+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxDQo+ PiB1aXJlbWUNCj4+IG50cy8NCj4+DQo+Pg0KPj4NCj4+IDMpIHRyYWNlYWJpbGl0eSAtIGFiaWxp dHkgdG8gcmVjb3JkIGludGVyYWN0aW9ucyBiZXR3ZWVuIEkyUlMNCj4+IGVsZW1lbnRzDQo+Pg0K Pj4gKENsaWVudCwgQWdlbnQsIFJvdXRpbmcgc3lzdGVtKQ0KPj4NCj4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy10cmFjZWFiaWxpdHkvDQo+Pg0KPj4N Cj4+DQo+PiA0KSBub3RpZmljYXRpb24gcHVibGljYXRpb24gdmlhIHN1YnNjcmlwdGlvbg0KPj4N Cj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wdWIt c3ViLXJlcXVpcmVtZW50cy8NCj4+DQo+Pg0KPj4NCj4+IDUpIFByb3RvY29sIHRvIHBhc3MgRGF0 YSBmb3IgQW5hbHl0aWNzDQo+Pg0KPj4gVGhlIGZpcnN0IHZlcnNpb24gb2YgdGhlc2UgcmVxdWly ZW1lbnRzIGRvZXMgbm90IGluY2x1ZGUgYQ0KPj4NCj4+IHNlcGFyYXRlIGFuYWx5dGljYWwgcHJv dG9jb2wgcmVxdWlyZW1lbnRzIGFzIHRoZSBzaW1wbGUgdXNlIGNhc2VzIG1heQ0KPj4NCj4+IHBh c3MgaW5mb3JtYXRpb24gdmlhIHF1ZXJ5L3BvbGwgb3IgdGhlIG5vdGlmaWNhdGlvbnMuDQo+Pg0K Pj4NCj4+DQo+PiBUaGUgSTJSUyBwcm90b2NvbCBleGlzdHMgaW4gYW4gc2VjdXJlIGVudmlyb25t ZW50IGRlc2NyaWJlZCBieToNCj4+DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWkycnMtc2VjdXJpdHktZW52aXJvbm1lbnQtDQo+PiByZXFzLw0KPj4NCj4+ DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+DQo+Pg0KPj4gRXJpYyAt IFBlcmhhcHMgaXQgd291bGQgYmUgZ29vZCB0byBwb2ludCB0bzoNCj4+DQo+PiAuICAgICAgICAg ZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50cyBhbmQNCj4+DQo+ PiAuICAgICAgICAgZHJhZnQtaWV0Zi1pMnJzLXNlY3VyaXR5LWVudmlyb25tZW50LXJlcXMvDQo+ Pg0KPj4NCj4+DQo+PiBCZW4gLSBDYW4geW91IHRlbGwgbWUgaG93IHRoZSBzaGVwaGVyZCByZXBv cnQgY291bGQgaGF2ZSBiZWVuDQo+PiBjbGVhcmVyPw0KPj4gIFRoZQ0KPj4gSTJycyBwcm90b2Nv bCBzZWN1cml0eSByZXF1aXJlbWVudHMgcmVxdWlyZTogIGNvbmZpZGVudGlhbGl0eSwNCj4+IGVu Y3J5cHRpb24sIHNlY3VyZSB0cmFuc3BvcnQsIHByb3RlY3Rpb24gYWdhaW5zdCByZXBsYXkgYXR0 YWNrLA0KPj4gcHJvdGVjdGlvbiBhZ2FpbnN0IEREb1MgYXR0YWNrIChpZiBwb3NzaWJsZSkuDQo+ DQo+IEkgdGhpbmsgbXkgY29uZnVzaW9uIGxpZXMgaW4gdGhlIGZhY3QgdGhhdCwgd2hpbGUgdGhl IHNoZXBoZXJkJ3MNCj4gd3JpdGV1cA0KPiBzdHlsZXMgdGhpcyBkcmFmdCBhcyBwYXJ0IG9mIHRo ZSBJMlJTIHByb3RvY29sIHJlcXVpcmVtZW50cywgdGhlIGRyYWZ0DQo+IGl0c2VsZiBjbGFpbXMg dG8gZGVzY3JpYmUgcmVxdWlyZW1lbnRzIGZvciBhIGdlbmVyYWxseSB1c2VmdWwgcHViLXN1Yg0K PiBpbnRlcmZhY2UgdG8gYSB5YW5nIGRhdGFzdG9yZS4gSXQncyBub3QgY2xlYXIgdG8gbWUgaG93 IGFuZCB3aGVuIHRoZQ0KPiBJMlJTDQo+IHByb3RvY29sIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBh cHBseSB0byBpdC4gSWYgdGhlIGRlc2NyaWJlZCBpbnRlcmZhY2UNCj4gaXMNCj4gaW50ZW5kZWQg dG8gYmUgdXNlZnVsIGluIGNvbnRleHRzIG90aGVyIHRoYW4gSTJSUyAoYW5kIHRoZSBkcmFmdA0K PiBleHBsaWNpdGx5DQo+IHNldHMgdGhhdCBleHBlY3RhdGlvbiBpbiAyLjIpLCBpdCBuZWVkcyB0 byB0YWxrIG1vcmUgZ2VuZXJhbGx5IGFib3V0DQo+IHNlY3VyaXR5IGFuZCBwcml2YWN5Lg0KPg0K PiBGb3IgZXhhbXBsZSwgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byBzYXkgdGhhdCBjZXJ0YWluIHNl Y3VyaXR5DQo+IHJlcXVpcmVtZW50cw0KPiBhcHBseSBpbiBlbnZpcm9ubWVudHMgd2hlcmUgdGhl IG1lY2hhbmlzbSBtaWdodCBjYXJyeSBwcml2YWN5DQo+IHNlbnNpdGl2ZQ0KPiBkYXRhLCBhbmQg dGhlbiBwb2ludCB0byB0aGUgaTJycyByZXF1aXJlbWVudHMgZm9yIHdoZW4gdGhlIG1lY2hhbmlz bQ0KPiBpcyB1c2VkDQo+IGluIGFuIEkyUlMgY29udGV4dC4NCj4NCj4gQSBkaWZmZXJlbnQgYXBw cm9hY2ggbWlnaHQgYmUgdG8gbW9yZSB0aWdodGx5IGNvbnN0cmFpbiB0aGlzIHRvIGkycnMNCj4N Cj4+DQo+Pg0KPj4NCj4+IEJlbiAtIE9uIG9wdGluZyBpbiwgb25jZSB0aGUgcmVjZWl2ZSBhY2Nl cHRzIGEgdHJhbnNwb3J0IGNvbm5lY3Rpb24NCj4+IGZyb20gdGhlIEkyUlMgc2VydmVyIC0gaG93 IGlzIHRoaXMgbm90IGFuIG9wdC1pbiB0byByZWNlaXZlIGRhdGE/DQo+PiBXaGF0DQo+PiBhcmUg eW91IGxvb2tpbmcgZm9yPw0KPg0KPiBJIGd1ZXNzIHRoYXQgZGVwZW5kcyBvbiB0aGUgdHJhbnNw b3J0LiBUaGUgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBzYXkNCj4gdGhlDQo+IG1lY2hhbmlzbSBo YXMgdG8gd29yayBvdmVyIG11bHRpcGxlIHRyYW5zcG9ydHMuIFRoZSBsYXN0IHBhcmFncmFwaCBp bg0KPiA0LjIuNA0KPiBzYXlzICJJbiB0aGUgY2FzZSBvZiBjb25uZWN0aW9uLW9yaWVudGVkIHRy YW5zcG9ydHMuLi4iIHdoaWNoIHN1Z2dlc3RzDQo+IHRoYXQNCj4gbm9uLWNvbm5lY3Rpb24tb3Jp ZW50ZWQgdHJhbnNwb3J0cyBhcmUgcG9zc2libGUuDQo+DQo+IEV2ZW4gd2l0aCBhIGNvbm5lY3Rp b24tb3JpZW50ZWQgdHJhbnNwb3J0LCB0aGlzIG1heSBkZXBlbmQgb24gaG93DQo+IGNvbm5lY3Rp b24tbWFuYWdlbWVudCBpcyBoYW5kbGVkLCBhbmQgd2hldGhlciB0aGUgcmVjZWl2ZXIgbWlnaHQg YmUNCj4gcmVjZWl2aW5nIHRoaW5ncyBpdCBfd2FudHNfIHRvIHJlY2VpdmUgb24gdGhlIHNhbWUg dHJhbnNwb3J0Lg0KPg0KPj4NCj4+DQo+Pg0KPj4gU3VlIEhhcmVzDQo+Pg0KPj4gKHNoZXBoZXJk KQ0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogaTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVy aWMgVm9pdA0KPj4gKGV2b2l0KQ0KPj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMDQsIDIwMTYgNzoy NSBQTQ0KPj4gVG86IEJlbiBDYW1wYmVsbDsgVGhlIElFU0cNCj4+IENjOiBpMnJzQGlldGYub3Jn PG1haWx0bzppMnJzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1l bnRzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNA aWV0Zi5vcmc+Ow0KPj4gaTJycy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmkycnMtY2hhaXJzQGll dGYub3JnPjsgc2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+DQo+PiBTdWJq ZWN0OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24NCj4+IGRyYWZ0LWlldGYt aTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0wNjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkN Cj4+DQo+Pg0KPj4NCj4+IEhpIEJlbiwNCj4+DQo+Pg0KPj4NCj4+IFRoYW5rcyBmb3IgdGhlIGNv bW1lbnQuICAgSW4tbGluZS4uLi4NCj4+DQo+Pg0KPj4NCj4+PiBGcm9tOiBCZW4gQ2FtcGJlbGws IE1heSAwNCwgMjAxNiAyOjQ5IFBNDQo+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+Pj4gRElT Q1VTUzoNCj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+Pg0KPj4NCj4+PiBJIGhhdmUgYSBj b3VwbGUgb2YgcG9pbnRzIEkgd291bGQgbGlrZSB0byBkaXNjdXNzLiBIb3BlZnVsbHkgdGhleQ0K Pj4+IGNhbg0KPj4NCj4+PiBiZSByZXNvbHZlZA0KPj4NCj4+PiBlYXNpbHk6DQo+Pg0KPj4+DQo+ Pg0KPj4+IEFyZSB0aGVyZSByZWFsbHkgbm8gcmVxdWlyZW1lbnRzIGZvciBwcml2YWN5IG9yIGlu dGVncml0eQ0KPj4+IHByb3RlY3Rpb24/DQo+Pg0KPj4+IElzIHRoZXJlIGFuIGV4cGVjdGF0aW9u IHRoYXQgdGhpcyBtZWNoYW5pc20gd291bGQgZXZlciBjYXJyeSBwcml2YWN5DQo+Pg0KPj4+IHNl bnNpdGl2ZSBvciBvdGhlcndpc2Ugc2Vuc2l0aXZlIGluZm9ybWF0aW9uPw0KPj4NCj4+DQo+Pg0K Pj4gW2VyaWMncyBjb21tZW50Og0KPj4NCj4+IFdoZW4gdGhlIHN1YnNjcmlwdGlvbiBpcyBlc3Rh Ymxpc2hlZCBkeW5hbWljYWxseSB2aWEgYW4gZXhpc3RpbmcNCj4+IHRyYW5zcG9ydA0KPj4gc2Vz c2lvbiAod2hpY2ggaXMgZXhwZWN0ZWQgdG8gYmUgdGhlIGRvbWluYW50IGNhc2UpIHdlIGhhdmUg dGhlIHNhbWUNCj4+IGV4cGVjdGF0aW9ucyBmb3IgUHJpdmFjeSBhbmQgaW50ZWdyaXR5IGFzIHdv dWxkIGJlIHByb3ZpZGVkIHZpYSBhDQo+PiAiR0VUIg0KPj4gaW5zdGVhZCBvZiBhICJQVVNIIiBv dmVyIHRoZSBzYW1lIHRyYW5zcG9ydC4gICBXZSBjb3VsZCBoYXZlDQo+PiByZXBsaWNhdGVkIGFs bA0KPj4gdGhlc2UgcmVxdWlyZW1lbnRzLCBidXQgdGhhdCB3YXMgc2VlbiBhcyB1bm5lY2Vzc2Fy eSBhbmQgbGlrZWx5IGxlc3MNCj4+IHNlY3VyZQ0KPj4gdGhhbiBhZG9wdGluZyBleGlzdGluZyBt ZWNoYW5pc21zLg0KPj4NCj4+DQo+Pg0KPj4gV2hlbiB0aGUgU3Vic2NyaWJlciBhbmQgUmVjZWl2 ZXIgYXJlIGRpZmZlcmVudCwgdGhlbiB0aGUgdHJhbnNwb3J0DQo+PiBjb25uZWN0aW9uIHdpbGwg aGF2ZSBjcmVkZW50aWFscyBwYXNzZWQgYXMgcGFydCBvZiB0aGUgZXN0YWJsaXNobWVudC4NCj4+ IFRoZXNlDQo+PiBjcmVkZW50aWFscyB3aWxsIGJlIHVzZWQgYXMgYSBTZWN1cml0eSBHcm9vbWlu ZyBGaWx0ZXIganVzdCBsaWtlIHRoZQ0KPj4gYWJvdmUNCj4+IGNhc2Ugc28gdGhhdCBwdXNoZWQg b2JqZWN0cyB3aWxsIGJlIGV4Y2x1ZGVkIGZyb20gYW4gVXBkYXRlDQo+PiBOb3RpZmljYXRpb24g YXMNCj4+IHBlciB0aGUgcGVybWlzc2lvbnMgb2YgdGhlIFJlY2VpdmVyLiAgIChJLmUuLCB0aGlz IGlzIGlkZW50aWNhbA0KPj4gYmVoYXZpb3IgdG8NCj4+IHRoZSBhYm92ZS4pICAgIEFzIHNldmVy YWwgcGVvcGxlIGhhdmUgaGFkIHF1ZXN0aW9ucyBhYm91dCB0aGlzLCB0aGUNCj4+IG5ldyB2MDcN Cj4+IHdpbGwgbWFrZSB0aGlzIGV4cGxpY2l0IGluIHRoZSBTZWN1cml0eSBzZWN0aW9uLg0KPj4N Cj4+IEVuZCBvZiBlcmljJ3MgY29tbWVudF0NCj4+DQo+Pg0KPj4NCj4+IFN1ZTogVGhlIHRyYW5z cG9ydCBwcm92aWRlcyBmb3IgcHJpdmFjeSwgaW50ZWdyaXR5IHByb3RlY3Rpb24uICAgTW9zdA0K Pj4gY29uZmlndXJhdGlvbiBpbiBuZXR3b3JrIGJveGVzIHdvdWxkIG5lZWQgcHJpdmFjeS4NCj4+ DQo+Pg0KPj4NCj4+PiAtIDQuMi41LCAybmQgdG8gbGFzdCBwYXJhZ3JhcGg6DQo+Pg0KPj4+IEkg YW0gc3VycHJpc2VkIHRvIGZpbmQgdGhhdCwgd2hlbiB0aGUgcmVjZWl2ZXIgaXMgbm90IHRoZQ0K Pj4+IHN1YnNjcmliZXIsDQo+Pg0KPj4+IHRoYXQgdGhlIHJlY2VpdmVyIGlzIGV4cGVjdGVkIHRv IG9wdC1vdXQuIEl0IHNlZW1zIGxpa2Ugc29tZSBmb3JtIG9mDQo+Pg0KPj4+IG9wdC1pbiBvciBh ZmZpcm1hdGl2ZSBjb25zZW50IHdvdWxkIGJlIG5lZWRlZCBoZXJlLg0KPj4NCj4+DQo+Pg0KPj4g VGhlIHF1ZXN0aW9uIHJlYWxseSB3YXMgaG93IGhlYXZ5LXdlaWdodCBzaG91bGQgdGhlIG1lY2hh bmlzbSBiZS4NCj4+IFRyYW5zcG9ydHMgYmVlbiBjb25zaWRlcmluZyBhcmUgYWxsIGVuY3J5cHRl ZC4gIFNvIHRoZXJlIGlzIGFscmVhZHkgYQ0KPj4gbGV2ZWwNCj4+IG9mIHRydXN0IGJldHdlZW4g dGhlIHBlZXJzLiAgQW5kIGEgdGFyZ2V0IGNhbiBhbHdheXMgcHVsbCBkb3duIHRoZQ0KPj4gY29u bmVjdGlvbiBpZiB0aGVyZSBhcmUgaXNzdWVzLg0KPj4NCj4+DQo+Pg0KPj4gSW4gYWRkaXRpb24s IG11bHRpY2FzdCB0cmFuc3BvcnRzIGFyZSB2aWFibGUgZm9yIHNvbWUgZnV0dXJlIGNhc2VzLg0K Pj4gV2UNCj4+IGRpZG4ndCB3YW50IG1lY2hhbmlzbXMgd2hpY2ggY29tcGxpY2F0ZWQgdGhpcyB0 eXBlIG9mIGludGVyYWN0aW9uLA0KPj4gZXNwZWNpYWxseSBpbiBhIHdvcmxkIHdoZXJlIGR1bWIg SW9UIGRldmljZXMgbWF5IGJlIGludm9sdmVkLg0KPj4NCj4+DQo+Pg0KPj4gU3VlOiBJZiB0aGUg cmVjZWl2ZXIgYWNjZXB0cyBhIHNlY3VyZSB0cmFuc3BvcnQgc2V0LXVwIGZyb20gdGhlDQo+PiBz ZXJ2ZXIsIGNhbg0KPj4geW91IHByb3ZpZGUgdGhlIHJlYXNvbiB3aHkgdGhpcyBpcyBub3QgYW4g Im9wdC1pbiIgb25jZSBpdCByZWNlaXZlcw0KPj4gdGhlDQo+PiBjb25uZWN0aW9uIGZyb20gdGhl IEkyUlMgYWdlbnQ/DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0K Pj4+IENPTU1FTlQ6DQo+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+Pj4NCj4+DQo+Pj4gLSBH ZW5lcmFsOiBJIHN1cHBvcnQgU3RlcGhlbidzIERJU0NVU1MNCj4+DQo+Pj4NCj4+DQo+Pj4gLTIu MjogV2hhdCBpcyB0aGUgcmVhbCBzY29wZSBvZiB0aGlzIHdvcms/IElzIGl0IGV4cGVjdGVkIHRv DQo+Pj4gc3VwcGxhbnQNCj4+DQo+Pj4gdGhlIG1lbnRpb25lZCBtZWNoYW5pc21zPw0KPj4NCj4+ DQo+Pg0KPj4gTm8uICAgSXQgaXMganVzdCBzaG93aW5nIHRoYXQgbWFueSBzcGVjaWFsaXplZCBQ dXNoIG1lY2hhbmlzbSBleGlzdC4NCj4+IFRoaXMNCj4+IGlzIG5vdCBpbnRlbmRlZCB0byBzdXBw bGFudCBleGlzdGluZyBtZWNoYW5pc21zLCBhbHRob3VnaCBwZXJoYXBzIGl0DQo+PiBjYW4NCj4+ IGhlbHAgYXZvaWQgZnV0dXJlIGRlZGljYXRlZCBzb2x1dGlvbnMuDQo+Pg0KPj4+IC0gMi4zOiAi V2UgbmVlZCBhIG5ldyBwdWItc3ViDQo+Pg0KPj4+ICAgIHRlY2hub2xvZ3kiDQo+Pg0KPj4+IFRo ZSBzaGVwaGVyZCB3cml0ZSB1cCBtZW50aW9uZWQgYSBnb2FsIHRvIHVzZSBleGlzdGluZyB0ZWNo bm9sb2dpZXMuDQo+Pg0KPj4+IElzIHRoZSBwb2ludCBvZiB0aGlzIHNlbnRlbmNlIHRvIHN1Z2dl c3QgdGhhdCBpcyBub3QgZmVhc2libGU/DQo+Pg0KPj4NCj4+DQo+PiBFeGlzdGluZyB0ZWNobm9s b2dpZXMgY2Fubm90IG1lZXQgYWxsIHRoZSByZXF1aXJlbWVudHMgc3BlY2lmaWVkLg0KPj4gVGhl cmUgYXJlDQo+PiB0ZWNobm9sb2d5IGRyYWZ0cyBwcm9ncmVzc2luZyBpbiBORVRDT05GIHdoaWNo IGNhbi4NCj4+DQo+Pg0KPj4NCj4+PiAtIDQuMSwgNHRoIHBhcmFncmFwaDoNCj4+DQo+Pj4gVGhl IE1BWSBkb2Vzbid0IHNlZW0gcmlnaHQtLWlzIHRoaXMgYSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0 IHRoZQ0KPj4NCj4+PiBzdWJzY3JpYmVyIG1heSBoYXZlIHRvIHJlc3Vic2NyaWJlLCBvciBhIHJl cXVpcmVtZW50IG9mIHRoZSBmb3JtDQo+Pj4gdGhhdA0KPj4NCj4+PiB0aGUgc2VydmljZSBNQVkg Zm9yY2UgdGhlIHN1YnNjcmliZXIgdG8gcmVzdWJzY3JpYmU/IChCZSBjYXJlZnVsDQo+Pj4gd2l0 aA0KPj4NCj4+PiBNQVlzIGluIHJlcXVpcmVtZW50cyBsYW5ndWFnZS0tdGhleSBpbXBseSB1bmV4 cGVjdGVkIHRoaW5ncy4gRm9yDQo+Pg0KPj4+IGV4YW1wbGUsIHNldmVyYWwgcmVxdWlyZW1lbnRz IHNheSBhIFNVQlNDUklCRSBNQVkgZG8gc29tZXRoaW5nLS1kbw0KPj4NCj4+PiB0aG9zZSBpbXBs eSB0aGF0IHRoZSBzZXJ2aWNlIE1VU1QgYWxsb3cgdGhlIHN1YnNjcmliZXIgdG8gZG8gaXQgPykN Cj4+DQo+Pg0KPj4NCj4+IEdvb2QgcG9pbnQuICAgUmV3b3JkZWQgaW4gdjA3Lg0KPj4NCj4+DQo+ Pg0KPj4+IC0tIDQuMi4yLCB0aGlyZCBidWxsZXQ6IFRoZSBwcmV2aW91cyBzZWN0aW9uIHNhaWQg ZGFtcGVuaW5nIHBlcmlvZHMNCj4+DQo+Pj4gTVVTVCBiZSBzdXBwb3J0ZWQuDQo+Pg0KPj4NCj4+ DQo+PiBZZXMsIGJ1dCBkYW1wZW5pbmcgaXMgbmV2ZXIgZm9yIHBlcmlvZGljIHN1YnNjcmlwdGlv bnMuDQo+Pg0KPj4+IC0gNC4yLjEsIHRoaXJkIHBhcmFncmFwaDogVGhpcyBpcyBhIGJpdCBhbWJp Z3VvdXMuIEkgdGhpbmsgaXQgbWVhbnMNCj4+PiB0bw0KPj4NCj4+PiBjaGFuZ2UgdGhlIHdoYXQg c3VidHJlZXMgdGhlIHN1YnNjcmlwdGlvbiBhcHBsaWVzIHRvLCBidXQgY291bGQgYmUNCj4+DQo+ Pj4gaW50ZXJwcmV0ZWQgdG8gY2hhbmdlIHRoZSBzdWJ0cmVlcyB0aGVtc2VsdmVzLg0KPj4NCj4+ DQo+Pg0KPj4gRml4ZWQNCj4+DQo+Pj4gLSA0LjIuNi40OiBXb3VsZCBhIG1lY2hhbmlzbSB0aGF0 IGFsbG93ZWQgb3V0LW9mLW9yZGVyIGRlbGl2ZXJ5IGJ1dA0KPj4NCj4+PiBnYXZlIHRoZSBzdWJz Y3JpYmVyIGEgd2F5IHRvIHJlY29uc3RydWN0IHRoZSBvcmRlciBmdWxmaWxsIHRoaXMNCj4+IHJl cXVpcmVtZW50Pw0KPj4NCj4+DQo+Pg0KPj4gWWVzLCB0aGUgdGltZXN0YW1wIHdpdGhpbiBhbiB1 cGRhdGUuICBCdXQgdGhpcyByZXF1aXJlbWVudCB0YXJnZXRzIGENCj4+IHNwZWNpZmljIG9iamVj dCBpbiBhIHNwZWNpZmljIHN1YnNjcmlwdGlvbi4gIFNvIHRoZXJlIHNob3VsZCBiZSBubw0KPj4g aXNzdWVzLg0KPj4NCj4+PiBOaXRzOg0KPj4NCj4+PiAtIFRoZSBzaGVwaGVyZCB3cml0ZSB1cCBz dWdnZXN0cyB0aGlzIGlzIHN0YW5kYXJkcyB0cmFjay4gVGhlIGRyYWZ0DQo+Pg0KPj4+IGFuZCB0 cmFja2VyIGJvdGggc2F5IGluZm9ybWF0aW9uYWwuIFBsZWFzZSB1cGRhdGUgdGhlIHNoZXBoZXJk IHdyaXQNCj4+PiB1cC4NCj4+DQo+Pg0KPj4NCj4+IEZpeGVkDQo+Pg0KPj4+IC0zLCBsYXN0IHBh cmFncmFwaDogV2hhdCdzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSAiUHVzaCIgYW5kIGFuDQo+ PiAiVXBkYXRlIj8NCj4+DQo+Pg0KPj4NCj4+IFJld29yZGVkDQo+Pg0KPj4+IC00LjE6IEEgZm9y d2FyZCByZWZlcmVuY2UgdG8gdGhlIHN1YnNjcmlwdGlvbiBRb1Mgc2VjdGlvbiB3b3VsZCBiZQ0K Pj4gaGVscGZ1bC4NCj4+DQo+Pg0KPj4NCj4+IE1vdmVkIHRoZSByZXF1aXJlbWVudCBpbiBxdWVz dGlvbiB0byA0LjIuNi4NCj4+DQo+Pj4gLS0gTGFzdCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2U6 IFNlbnRlbmNlIGRvZXNuJ3QgcGFyc2UuDQo+Pg0KPj4NCj4+DQo+PiBGaXhlZA0KPj4NCj4+Pg0K Pj4NCj4+PiAtIDQuMi44LCB0aGlyZCBwYXJhZ3JhcGg6IEkgZG9uJ3QgdGhpbmsgdGhhdCBzaG91 bGQgYmUgYSAyMTE5IE1BWQ0KPj4NCj4+DQo+Pg0KPj4gRml4ZWQNCj4+DQo+PiBUaGFua3MgYWdh aW4gZm9yIHRoZSByZXZpZXchDQo+Pg0KPj4gRXJpYw0KPj4NCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pg0KPj4gaTJycyBtYWlsaW5nIGxpc3QN Cj4+DQo+PiAgPG1haWx0bzppMnJzQGlldGYub3JnPiBpMnJzQGlldGYub3JnPG1haWx0bzppMnJz QGlldGYub3JnPg0KPj4NCj4+ICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pMnJzPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo= --_000_d12fea6bf3d9431d8994524fd1e6e576XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5T dWUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDBCMDUwIj5NYWRlIHlvdXIgY2hhbmdlJm5ic3A7IChzZWUgZ3JlZW4gYmVsb3cpLiZu YnNwOyZuYnNwOyBJIHdpbGwgYXdhaXQgZXZlcnlvbmUgZWxzZeKAmXMgb2sgdG8gc2VlIGlmIHRo ZXJlIGFyZSBhbnkgZmluYWwgY2hhbmdlcyBiZWZvcmUgcG9zdGluZy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkVyaWM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjQuMi41LiZuYnNw OyBTZWN1cml0eSBSZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBTb21lIHVzZXMgb2YgdGhpcyBTdWJzY3JpcHRpb24gU2VydmljZSB3aWxsIHB1c2ggcHJp dmFjeS1zZW5zaXRpdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHVwZGF0ZXMgYW5kIG1ldGFkYXRh LiZuYnNwOyBHb29kIGRlcGxveW1lbnQgcHJhY3RpY2VzIHdpbGwgYmluZCB0aGlzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBnZW5lcmF0ZWQgaW5mb3JtYXRpb24gd2l0aGluIHNlY3VyZSwgZW5jcnlw dGVkIHRyYW5zcG9ydCBsYXllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtcy4mbmJz cDsgRm9yIGV4YW1wbGUgaWYgTkVUQ09ORiBpcyB1c2VkIGFzIHRyYW5zcG9ydCwgdGhlbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgW1JGQzU1MzldIHdvdWxkIGJlIGEgdmFsaWQgb3B0aW9uIHRvIHNl Y3VyZSB0aGUgdHJhbnNwb3J0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uLiZu YnNwOyBUaGUgU3Vic2NyaXB0aW9uIFNlcnZpY2UgY2FuIGFsc28gYmUgdXNlZCB3aXRoIGVtZXJn aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBkZXBsb3ltZW50IGNvbnRleHRzIGFzIHdlbGwuJm5i c3A7IEFzIGFuIGV4YW1wbGUsIGRlcGxveW1lbnRzIGJhc2VkIG9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBbaTJycy11c2VjYXNlXSBjYW4gYXBwbHkgdGhlc2UgcmVxdWlyZW1lbnRzIGluIGNvbmp1 bmN0aW9uIHdpdGggdGhvc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50ZWQgd2l0aGlu DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwQjA1MCI+W2kycnMtZW52aXJvbm1lbnQtc2VjdXJp dHldYW5kPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IFtpMnJzLXByb3RvY29sLXNlY3VyaXR5XSB0byBzZWN1cmUgZXBoZW1lcmFsIHN0YXRlIGluZm9y bWF0aW9uIGJlaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwdXNoZWQgZnJvbSBhIE5ldHdvcmsg RWxlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFN1c2FuIEhhcmVzLCBNYXkgMTMsIDIw MTYgMTE6NDkgQU08YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkVyaWM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IganVtcGluZyBpbiBhbmQg cHV0dGluZyBvdXQgdGV4dCB0aGF0IHJlc29sdmVzIEJlbuKAmXMgY29tbWVudHMuJm5ic3A7IFRo aXMgdGV4dCB3b3JrcyBmb3IgbWUgd2l0aCBvbmUgYWRkaXRpb24uJm5ic3A7IEFkZCByZWZlcmVu Y2UgdG8gdGhlIHNlY3VyaXR5IGVudmlyb25tZW50DQogZHJhZnQuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3VlDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBFcmljIFZvaXQgKGV2b2l0KSBbPGEgaHJlZj0ibWFpbHRvOmV2 b2l0QGNpc2NvLmNvbSI+bWFpbHRvOmV2b2l0QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBNYXkgMTMsIDIwMTYgMTE6MjYgQU08YnI+DQo8Yj5Ubzo8L2I+IFN1c2Fu IEhhcmVzOyBCZW4gQ2FtcGJlbGw7IEFsaWEgQXRsYXMgKDxhIGhyZWY9Im1haWx0bzpha2F0bGFz QGdtYWlsLmNvbSI+YWthdGxhc0BnbWFpbC5jb208L2E+KTxicj4NCjxiPkNjOjwvYj4gVGhlIElF U0c7IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPjsgPGEg aHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9y ZyI+DQpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc8L2E+OyA8 YSBocmVmPSJtYWlsdG86aTJycy1jaGFpcnNAaWV0Zi5vcmciPg0KaTJycy1jaGFpcnNAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbaTJyc10gQmVuIENhbXBiZWxsJ3MgRGlz Y3VzcyBvbiBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDY6ICh3aXRoIERJ U0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEJl biw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgaGF2ZSBhZGRlZCB0aGUgdGV4dCBiZWxvdyBhcyB0aGUgbGVhZC1pbiB0 byBzZWN0aW9uIDQuMi41LiZuYnNwOyBJIGJlbGlldmUgdGhpcyBtZWV0cyB0aGUgaW50ZW50cyBv ZiB5b3VyIHN1Z2dlc3Rpb25zIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgU3VzYW4gJmFtcDsgQWxpYSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgaGF2ZSB1cGxvYWRlZCB2MDggb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLzwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgQmVuIGNvbmN1cnMgd2l0aCB0aGUgdGV4dCBiZWxvdywg SSBhbSBub3QgYXdhcmUgb2YgYW55IHJlbWFpbmluZyBkaXNjdXNzIGl0ZW1zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIGV2ZXJ5b25lIGZvciB5b3VyIHJldmlld3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkVyaWMsIEFsZXgsICZhbXA7IEFsYmVydG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPjQuMi41LiZuYnNwOyBTZWN1cml0eSBS ZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgU29tZSB1c2VzIG9mIHRoaXMgU3Vic2NyaXB0 aW9uIFNlcnZpY2Ugd2lsbCBwdXNoIHByaXZhY3ktc2Vuc2l0aXZlPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHVwZGF0 ZXMgYW5kIG1ldGFkYXRhLiZuYnNwOyBHb29kIGRlcGxveW1lbnQgcHJhY3RpY2VzIHdpbGwgYmlu ZCB0aGlzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IGdlbmVyYXRlZCBpbmZvcm1hdGlvbiB3aXRoaW4gc2VjdXJlLCBl bmNyeXB0ZWQgdHJhbnNwb3J0IGxheWVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG1lY2hhbmlzbXMuJm5ic3A7IEZv ciBleGFtcGxlIGlmIE5FVENPTkYgaXMgdXNlZCBhcyB0cmFuc3BvcnQsIHRoZW48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgW1JGQzU1MzldIHdvdWxkIGJlIGEgdmFsaWQgb3B0aW9uIHRvIHNlY3VyZSB0aGUgdHJhbnNw b3J0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgaW5mb3JtYXRpb24uJm5ic3A7IFRoZSBTdWJzY3JpcHRpb24gU2Vy dmljZSBjYW4gYWxzbyBiZSB1c2VkIHdpdGggZW1lcmdpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZGVwbG95bWVu dCBjb250ZXh0cyBhcyB3ZWxsLiZuYnNwOyBBcyBhbiBleGFtcGxlLCBkZXBsb3ltZW50cyBiYXNl ZCBvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBbaTJycy11c2VjYXNlXSBjYW4gYXBwbHkgdGhlc2UgcmVxdWlyZW1l bnRzIGluIGNvbmp1bmN0aW9uIHdpdGggdGhvc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZG9jdW1lbnRlZCB3aXRo aW4gW2kycnMtcHJvdG9jb2wtc2VjdXJpdHldIHRvIHNlY3VyZSBlcGhlbWVyYWwgc3RhdGU8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgaW5mb3JtYXRpb24gYmVpbmcgcHVzaGVkIGZyb20gYSBOZXR3b3JrIEVsZW1lbnQu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBTdXNhbiBIYXJlcyBbPGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNv bSI+bWFpbHRvOnNoYXJlc0BuZHpoLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBNYXkgMDYsIDIwMTYgNzowOSBQTTxicj4NCjxiPlRvOjwvYj4gQmVuIENhbXBiZWxsPGJyPg0K PGI+Q2M6PC9iPiBFcmljIFZvaXQgKGV2b2l0KTsgVGhlIElFU0c7IDxhIGhyZWY9Im1haWx0bzpp MnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1p ZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmciPmRyYWZ0LWlldGYtaTJycy1w dWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86aTJycy1j aGFpcnNAaWV0Zi5vcmciPmkycnMtY2hhaXJzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1pMnJz LXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZW46PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg aXMgd2lzZSBpZGVhLiAmbmJzcDtJIHdpbGwgc3VnZ2VzdCBzb21lIHRleHQgdG8gRXJpYyBhbmQg eW91IGluIHRoZSBtb3JuaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TdWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0iY29tcG9zZXJfc2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojNTc1NzU3Ij5TZW50IHZpYSB0aGUgU2Ft c3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJmFtcDtUIDRHIExURSBzbWFydHBob25lPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNz YWdlIC0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiBCZW4gQ2FtcGJl bGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5jb20iPmJlbkBub3N0cnVtLmNvbTwv YT4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRhdGU6IDUvNi8yMDE2IDI6Mzgg UE0gKEdNVC0wNjowMCkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VG86IFN1c2FuIEhh cmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208 L2E+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DYzogRXJpYyBWb2l0ICZsdDs8 YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0Oywg VGhlIElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3Jn PC9hPiZndDssDQo8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwv YT4sIDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNA aWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3Jn PC9hPiwgPGEgaHJlZj0ibWFpbHRvOmkycnMtY2hhaXJzQGlldGYub3JnIj4NCmkycnMtY2hhaXJz QGlldGYub3JnPC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlN1YmplY3Q6IFJlOiBb aTJyc10gQmVuIENhbXBiZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1y ZXF1aXJlbWVudHMtMDY6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBTdXNhbiw8YnI+DQo8YnI+DQpUbyBiZSBjbGVh ciwgSSBkbyBub3Qgb2JqZWN0IHRvIHRoZSB3aWRlciBjb250ZXh0IHBlciBzZS4gTXkgY29uY2Vy biBpcyA8YnI+DQp0aGF0IHRoZSBzZWN1cml0eSBhbmQgcHJpdmFjeSByZXF1aXJlbWVudHMgYXJl IGxlZnQgYXMgaW1wbGljaXQsIGJhc2VkIDxicj4NCm9uIHRoZSBtb3JlIG5hcnJvdyBpMnJzL25l dGNvbmYgY29udGV4dC4gSSBvbmx5IG1lbnRpb25lZCB0aGUgcG90ZW50aWFsIDxicj4NCm9mIHJl c3RyaWN0aW5nIHRoZSBjb250ZXh0YXMgb25lIHBvc3NpYmxlIHdheSBmb3J3YXJkOyBJIGFtIGNl cnRhaW5seSA8YnI+DQpub3Qgd2VkZGVkIHRvIGl0Ljxicj4NCjxicj4NCk15IHN1Z2dlc3Rpb24g Zm9yIGEgd2F5IGZvcndhcmQgd291bGQgYmUgdG8gZG9jdW1lbnQgdGhlIGhpZ2ggbGV2ZWwgPGJy Pg0Kc2VjdXJpdHkgYW5kIHByaXZhY3kgcmVxdWlyZW1lbnRzIGluIHRoaXMgZG9jdW1lbnQuIElJ VUMsIHRoZSBsYXJnZXIgPGJyPg0KY29udGV4dCBpbmNsdWRlcyBwb3RlbnRpYWxseSB1bmtub3du IGNvbnRleHRzLCBzbyBzb21lIG9mIHRoaXMgbWF5IG5lZWQgPGJyPg0KdG8gYmUgY29uZGl0aW9u YWwuIEZvciBleGFtcGxlLCBsYW5ndWFnZSBsaWtlIHRoZSBmb2xsb3dpbmcgbWlnaHQgYmUgPGJy Pg0KaGVscGZ1bCAodGhpcyBpcyBqdXN0IGFuIGV4YW1wbGUtLUkgZG9uJ3QgbWVhbiB0byBzYXkg dGhhdCBpdCBpcyB0cnVlIG9yIDxicj4NCmFwcGxpY2FibGUpOjxicj4NCjxicj4NCiZuYnNwOyAm cXVvdDtTb21lIHVzZXMgb2YgdGhpcyBtZWNoYW5pc20gbWF5IGNhcnJ5IHByaXZhY3ktc2Vuc2l0 aXZlIGluZm9ybWF0aW9uLCA8YnI+DQpvciBnZW5lcmF0ZSZuYnNwOyZuYnNwOyZuYnNwOyBwcml2 YWN5LXNlbnNpdGl2ZSBtZXRhZGF0YSB0aHJvdWdoIHRoZSBzdWJzY3JpcHRpb24gPGJyPg0KbWVj aGFuaXNtLiBJbiBjb250ZXh0cyB3aGVyZSB0aGlzIGlzIHRydWUsIHRoZSBmb2xsb3dpbmcgcmVx dWlyZW1lbnRzIDxicj4NCmFwcGx5Li4uJnF1b3Q7PGJyPg0KPGJyPg0KSXQgbWlnaHQgYWxzbyBi ZSByZWFzb25hYmxlIHRvIHNheSB0aGF0LCBmb3IgdGhlIGNvbnRleHQgb2YgaTJycywgdGhlc2Ug PGJyPg0KcmVxdWlyZW1lbnRzIGFyZSBkb2N1bWVudGVkIGluIFtyZWZlcmVuY2VzXSBhbmQgYXJl IGV4cGVjdGVkIHRvIGJlIDxicj4NCmZ1bGZpbGxlZCBieSB0aGUgW3RyYW5zcG9ydCBhbmQgb3Ig cHJvdG9jb2xdPGJyPg0KPGJyPg0KRXJpYydzIGVtYWlsIGFsc28gc3VnZ2VzdGVkIHRoYXQgdGhl IGFjdHVhbCB0cmFuc3BvcnQgb2YgZGF0YSBmcm9tIHRoZSA8YnI+DQpZYW5nIGRhdGFzdG9yZSBt YXkgYmUgb3V0IG9mIHNjb3BlIGZvciB0aGVzZSByZXF1aXJlbWVudHMuIEkgZG9uJ3QgPGJyPg0K b2JqZWN0IHRvIHRoYXQsIGVpdGhlciwgYXMgbG9uZyBhcyBpdCBpcyBjbGVhciBhbmQgZXhwbGlj aXQsIGFsdGhvdWdoIGl0IDxicj4NCndvdWxkIGJlIGdvb2QgdG8gcG9pbnQgdG8gd2hlcmUgaXQg aXMgX2luXyBzY29wZS48YnI+DQo8YnI+DQpUaGFua3MhPGJyPg0KPGJyPg0KQmVuLjxicj4NCjxi cj4NCk9uIDYgTWF5IDIwMTYsIGF0IDE6MDYsIFN1c2FuIEhhcmVzIHdyb3RlOjxicj4NCjxicj4N CiZndDsgQmVuOjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgaXMgdGhlIGZpcnN0IG9mIHRoZSAm cXVvdDtyZS11c2UmcXVvdDsgbWFuYWdlbWVudCBwcm90b2NvbHMuJm5ic3A7IFRoZSA8YnI+DQom Z3Q7IHJlcXVpcmVtZW50czxicj4NCiZndDsgYXJlIHNldC11cCBzbyB0aGF0IHdlIGNhbiBzdWdn ZXN0IGFkZGl0aW9ucyB0byB0aGUgTkVUQ09ORiBhbmQgPGJyPg0KJmd0OyBSRVNUQ09ORiBmb3I8 YnI+DQomZ3Q7IHRoaXMgZmlyc3Qgb2YgSTJSUy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgSTJS UyBlcGhlbWVyYWwgd29yaywgcHViL3N1YiwgdHJhY2VhYmlsaXR5LCBhbmQgc2VjdXJpdHkgYXJl IDxicj4NCiZndDsgdGFyZ2V0IGF0PGJyPg0KJmd0OyB0aGUgSTJSUyBwcm90b2NvbCBkZWZpbml0 aW9uIHdpdGggdGhlIEkyUlMgdXNlIGNhc2UuJm5ic3A7IEhvd2V2ZXIsIHNpbmNlIDxicj4NCiZn dDsgdGhlc2U8YnI+DQomZ3Q7IGFyZSBnZW5lcmFsIGFkZGl0aW9ucyB0byBORVRDT05GL1JFU1RD T05GLCB0aGlzIHdvcmsgY2FuIGJlIHVzZWQgPGJyPg0KJmd0OyBlbHNld2hlcmUuPGJyPg0KJmd0 Ozxicj4NCiZndDsgSSB0aGluayB0aGUgdGV4dCB5b3UgYXJlIGhpZ2hsaWdodGluZyBoYXMgdGhp cyBsYXJnZXIgY29udGV4dC4mbmJzcDsmbmJzcDsgTm93LCA8YnI+DQomZ3Q7IG9uZSBvZjxicj4N CiZndDsgdGhlIHJlYWxseSBpbXBvcnRhbnQgdGhpbmdzIHRvIGNoYXQgd2l0aCBBbGlhIGFuZCBC ZW5vaXQgaXMgaG93IGRvIHdlIDxicj4NCiZndDsgaGFuZGxlPGJyPg0KJmd0OyB0aGUgd2lkZXIg dXNlIGNhc2UuJm5ic3A7Jm5ic3A7IERvIHdlIG1lbnRpb24gdGhlIHdpZGVyIGNvbnRleHQ/PGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhlIFdHIHRob3VnaHQgbWVudGlvbmluZyBpdCB3YXMgaW1wb3J0 YW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFN1ZTxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBCZW4gQ2FtcGJlbGwgWzxhIGhyZWY9 Im1haWx0bzpiZW5Abm9zdHJ1bS5jb20iPm1haWx0bzpiZW5Abm9zdHJ1bS5jb208L2E+XTxicj4N CiZndDsgU2VudDogVGh1cnNkYXksIE1heSAwNSwgMjAxNiA1OjMxIFBNPGJyPg0KJmd0OyBUbzog U3VzYW4gSGFyZXM8YnI+DQomZ3Q7IENjOiBFcmljIFZvaXQ7IFRoZSBJRVNHOyA8YSBocmVmPSJt YWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT47PGJyPg0KJmd0OyA8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnIj5k cmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJl Zj0ibWFpbHRvOmkycnMtY2hhaXJzQGlldGYub3JnIj5pMnJzLWNoYWlyc0BpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbaTJyc10gQmVuIENhbXBiZWxsJ3MgRGlzY3VzcyBvbjxi cj4NCiZndDsgZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2OiAod2l0aCBE SVNDVVNTIGFuZCBDT01NRU5UKTxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDUgTWF5IDIwMTYsIGF0 IDU6MTUsIFN1c2FuIEhhcmVzIHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBFcmljLCBC ZW4gYW5kIElFU0cgbWVtYmVyczo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgcHViL3N1YiByZXF1aXJlbWVudHMgYXJlIHBhcnQgb2Yg YSA1IHBhcnQgcmVxdWlyZW1lbnRzLiZuYnNwOyZuYnNwOyBNYXkgSTxicj4NCiZndDsmZ3Q7IHF1 b3RlPGJyPg0KJmd0OyZndDsgZnJvbSB0aGUgc2hlcGhlcmQncyByZXBvcnQ6PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBmaXJzdCB2ZXJzaW9uIG9mIEkyUlMg YXJlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgMSkgbW9kZWwgZHJpdmVuIGVwaGVtZXJh bCBzdGF0ZSAtIHRoYXQgaXMgZGF0YSBtb2RlbHMgdGhhdCBkbyBub3Q8YnI+DQomZ3Q7Jmd0OyBz dXJ2aXZlPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBhIHNvZnR3YXJlIG9yIGhhcmR3YXJlIHJlYm9vdC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aTJycy1lcGhlbWVyYWwtc3RhdGUvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLzwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAyKSBhIHNlY3VyZSBwcm90b2NvbCAt PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxIj4NCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wcm90b2NvbC1z ZWN1cml0eS1yZXE8L2E+PGJyPg0KJmd0OyZndDsgdWlyZW1lPGJyPg0KJmd0OyZndDsgbnRzLzxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDMp IHRyYWNlYWJpbGl0eSAtIGFiaWxpdHkgdG8gcmVjb3JkIGludGVyYWN0aW9ucyBiZXR3ZWVuIEky UlMgPGJyPg0KJmd0OyZndDsgZWxlbWVudHM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IChD bGllbnQsIEFnZW50LCBSb3V0aW5nIHN5c3RlbSk8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJy cy10cmFjZWFiaWxpdHkvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWkycnMtdHJhY2VhYmlsaXR5LzwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA0KSBub3RpZmljYXRpb24gcHVibGljYXRpb24gdmlh IHN1YnNjcmlwdGlvbjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWly ZW1lbnRzLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWky cnMtcHViLXN1Yi1yZXF1aXJlbWVudHMvPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDUpIFByb3RvY29sIHRvIHBhc3MgRGF0YSBmb3Ig QW5hbHl0aWNzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgZmlyc3QgdmVyc2lvbiBv ZiB0aGVzZSByZXF1aXJlbWVudHMgZG9lcyBub3QgaW5jbHVkZSBhPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBzZXBhcmF0ZSBhbmFseXRpY2FsIHByb3RvY29sIHJlcXVpcmVtZW50cyBhcyB0 aGUgc2ltcGxlIHVzZSBjYXNlcyBtYXk8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHBhc3Mg aW5mb3JtYXRpb24gdmlhIHF1ZXJ5L3BvbGwgb3IgdGhlIG5vdGlmaWNhdGlvbnMuPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIEkyUlMg cHJvdG9jb2wgZXhpc3RzIGluIGFuIHNlY3VyZSBlbnZpcm9ubWVudCBkZXNjcmliZWQgYnk6PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtc2VjdXJpdHktZW52aXJvbm1lbnQtIj4NCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1zZWN1cml0eS1lbnZp cm9ubWVudC08L2E+PGJyPg0KJmd0OyZndDsgcmVxcy88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg RXJpYyAtIFBlcmhhcHMgaXQgd291bGQgYmUgZ29vZCB0byBwb2ludCB0bzo8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50cyBh bmQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1pMnJzLXNlY3VyaXR5LWVudmlyb25t ZW50LXJlcXMvPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgQmVuIC0gQ2FuIHlvdSB0ZWxsIG1lIGhvdyB0aGUgc2hlcGhlcmQgcmVwb3J0IGNv dWxkIGhhdmUgYmVlbiA8YnI+DQomZ3Q7Jmd0OyBjbGVhcmVyPzxicj4NCiZndDsmZ3Q7Jm5ic3A7 IFRoZTxicj4NCiZndDsmZ3Q7IEkycnMgcHJvdG9jb2wgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIHJl cXVpcmU6Jm5ic3A7IGNvbmZpZGVudGlhbGl0eSw8YnI+DQomZ3Q7Jmd0OyBlbmNyeXB0aW9uLCBz ZWN1cmUgdHJhbnNwb3J0LCBwcm90ZWN0aW9uIGFnYWluc3QgcmVwbGF5IGF0dGFjayw8YnI+DQom Z3Q7Jmd0OyBwcm90ZWN0aW9uIGFnYWluc3QgRERvUyBhdHRhY2sgKGlmIHBvc3NpYmxlKS48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBJIHRoaW5rIG15IGNvbmZ1c2lvbiBsaWVzIGluIHRoZSBmYWN0IHRo YXQsIHdoaWxlIHRoZSBzaGVwaGVyZCdzIDxicj4NCiZndDsgd3JpdGV1cDxicj4NCiZndDsgc3R5 bGVzIHRoaXMgZHJhZnQgYXMgcGFydCBvZiB0aGUgSTJSUyBwcm90b2NvbCByZXF1aXJlbWVudHMs IHRoZSBkcmFmdDxicj4NCiZndDsgaXRzZWxmIGNsYWltcyB0byBkZXNjcmliZSByZXF1aXJlbWVu dHMgZm9yIGEgZ2VuZXJhbGx5IHVzZWZ1bCBwdWItc3ViPGJyPg0KJmd0OyBpbnRlcmZhY2UgdG8g YSB5YW5nIGRhdGFzdG9yZS4gSXQncyBub3QgY2xlYXIgdG8gbWUgaG93IGFuZCB3aGVuIHRoZSA8 YnI+DQomZ3Q7IEkyUlM8YnI+DQomZ3Q7IHByb3RvY29sIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBh cHBseSB0byBpdC4gSWYgdGhlIGRlc2NyaWJlZCBpbnRlcmZhY2UgPGJyPg0KJmd0OyBpczxicj4N CiZndDsgaW50ZW5kZWQgdG8gYmUgdXNlZnVsIGluIGNvbnRleHRzIG90aGVyIHRoYW4gSTJSUyAo YW5kIHRoZSBkcmFmdCA8YnI+DQomZ3Q7IGV4cGxpY2l0bHk8YnI+DQomZ3Q7IHNldHMgdGhhdCBl eHBlY3RhdGlvbiBpbiAyLjIpLCBpdCBuZWVkcyB0byB0YWxrIG1vcmUgZ2VuZXJhbGx5IGFib3V0 PGJyPg0KJmd0OyBzZWN1cml0eSBhbmQgcHJpdmFjeS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb3Ig ZXhhbXBsZSwgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byBzYXkgdGhhdCBjZXJ0YWluIHNlY3VyaXR5 IDxicj4NCiZndDsgcmVxdWlyZW1lbnRzPGJyPg0KJmd0OyBhcHBseSBpbiBlbnZpcm9ubWVudHMg d2hlcmUgdGhlIG1lY2hhbmlzbSBtaWdodCBjYXJyeSBwcml2YWN5IDxicj4NCiZndDsgc2Vuc2l0 aXZlPGJyPg0KJmd0OyBkYXRhLCBhbmQgdGhlbiBwb2ludCB0byB0aGUgaTJycyByZXF1aXJlbWVu dHMgZm9yIHdoZW4gdGhlIG1lY2hhbmlzbSA8YnI+DQomZ3Q7IGlzIHVzZWQ8YnI+DQomZ3Q7IGlu IGFuIEkyUlMgY29udGV4dC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIGRpZmZlcmVudCBhcHByb2Fj aCBtaWdodCBiZSB0byBtb3JlIHRpZ2h0bHkgY29uc3RyYWluIHRoaXMgdG8gaTJyczxicj4NCiZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBCZW4gLSBPbiBvcHRpbmcgaW4sIG9uY2UgdGhlIHJlY2VpdmUgYWNjZXB0cyBhIHRyYW5zcG9y dCBjb25uZWN0aW9uPGJyPg0KJmd0OyZndDsgZnJvbSB0aGUgSTJSUyBzZXJ2ZXIgLSBob3cgaXMg dGhpcyBub3QgYW4gb3B0LWluIHRvIHJlY2VpdmUgZGF0YT8gPGJyPg0KJmd0OyZndDsgV2hhdDxi cj4NCiZndDsmZ3Q7IGFyZSB5b3UgbG9va2luZyBmb3I/PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBn dWVzcyB0aGF0IGRlcGVuZHMgb24gdGhlIHRyYW5zcG9ydC4gVGhlIHRyYW5zcG9ydCByZXF1aXJl bWVudHMgc2F5IDxicj4NCiZndDsgdGhlPGJyPg0KJmd0OyBtZWNoYW5pc20gaGFzIHRvIHdvcmsg b3ZlciBtdWx0aXBsZSB0cmFuc3BvcnRzLiBUaGUgbGFzdCBwYXJhZ3JhcGggaW4gPGJyPg0KJmd0 OyA0LjIuNDxicj4NCiZndDsgc2F5cyAmcXVvdDtJbiB0aGUgY2FzZSBvZiBjb25uZWN0aW9uLW9y aWVudGVkIHRyYW5zcG9ydHMuLi4mcXVvdDsgd2hpY2ggc3VnZ2VzdHMgPGJyPg0KJmd0OyB0aGF0 PGJyPg0KJmd0OyBub24tY29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3BvcnRzIGFyZSBwb3NzaWJs ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBFdmVuIHdpdGggYSBjb25uZWN0aW9uLW9yaWVudGVkIHRy YW5zcG9ydCwgdGhpcyBtYXkgZGVwZW5kIG9uIGhvdzxicj4NCiZndDsgY29ubmVjdGlvbi1tYW5h Z2VtZW50IGlzIGhhbmRsZWQsIGFuZCB3aGV0aGVyIHRoZSByZWNlaXZlciBtaWdodCBiZTxicj4N CiZndDsgcmVjZWl2aW5nIHRoaW5ncyBpdCBfd2FudHNfIHRvIHJlY2VpdmUgb24gdGhlIHNhbWUg dHJhbnNwb3J0Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBTdWUgSGFyZXM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IChzaGVwaGVyZCk8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBpMnJzIFs8YSBocmVmPSJtYWlsdG86aTJycy1i b3VuY2VzQGlldGYub3JnIj5tYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo YWxmIE9mIEVyaWMgVm9pdDxicj4NCiZndDsmZ3Q7IChldm9pdCk8YnI+DQomZ3Q7Jmd0OyBTZW50 OiBXZWRuZXNkYXksIE1heSAwNCwgMjAxNiA3OjI1IFBNPGJyPg0KJmd0OyZndDsgVG86IEJlbiBD YW1wYmVsbDsgVGhlIElFU0c8YnI+DQomZ3Q7Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOmkycnNA aWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1p MnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnIj4NCmRyYWZ0LWlldGYtaTJycy1wdWIt c3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZzwvYT47PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOmkycnMtY2hhaXJzQGlldGYub3JnIj5pMnJzLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhy ZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPg0Kc2hhcmVzQG5kemguY29tPC9hPjxicj4NCiZn dDsmZ3Q7IFN1YmplY3Q6IFJlOiBbaTJyc10gQmVuIENhbXBiZWxsJ3MgRGlzY3VzcyBvbjxicj4N CiZndDsmZ3Q7IGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0wNjogKHdpdGgg RElTQ1VTUyBhbmQgQ09NTUVOVCk8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBIaSBCZW4sPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzIGZvciB0aGUgY29tbWVudC4mbmJzcDsm bmJzcDsgSW4tbGluZS4uLi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsgRnJvbTogQmVuIENhbXBiZWxsLCBNYXkgMDQsIDIwMTYgMjo0 OSBQTTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBESVNDVVNTOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgaGF2ZSBhIGNvdXBsZSBvZiBwb2ludHMg SSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MuIEhvcGVmdWxseSB0aGV5IDxicj4NCiZndDsmZ3Q7Jmd0 OyBjYW48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBiZSByZXNvbHZlZDxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IGVhc2lseTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFyZSB0aGVyZSByZWFsbHkg bm8gcmVxdWlyZW1lbnRzIGZvciBwcml2YWN5IG9yIGludGVncml0eSA8YnI+DQomZ3Q7Jmd0OyZn dDsgcHJvdGVjdGlvbj88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJcyB0aGVyZSBh biBleHBlY3RhdGlvbiB0aGF0IHRoaXMgbWVjaGFuaXNtIHdvdWxkIGV2ZXIgY2FycnkgcHJpdmFj eTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IHNlbnNpdGl2ZSBvciBvdGhlcndpc2Ug c2Vuc2l0aXZlIGluZm9ybWF0aW9uPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFtlcmljJ3MgY29tbWVudDo8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFdoZW4gdGhlIHN1YnNjcmlwdGlvbiBpcyBlc3RhYmxpc2hlZCBkeW5hbWljYWxs eSB2aWEgYW4gZXhpc3Rpbmc8YnI+DQomZ3Q7Jmd0OyB0cmFuc3BvcnQ8YnI+DQomZ3Q7Jmd0OyBz ZXNzaW9uICh3aGljaCBpcyBleHBlY3RlZCB0byBiZSB0aGUgZG9taW5hbnQgY2FzZSkgd2UgaGF2 ZSB0aGUgc2FtZTxicj4NCiZndDsmZ3Q7IGV4cGVjdGF0aW9ucyBmb3IgUHJpdmFjeSBhbmQgaW50 ZWdyaXR5IGFzIHdvdWxkIGJlIHByb3ZpZGVkIHZpYSBhPGJyPg0KJmd0OyZndDsgJnF1b3Q7R0VU JnF1b3Q7PGJyPg0KJmd0OyZndDsgaW5zdGVhZCBvZiBhICZxdW90O1BVU0gmcXVvdDsgb3ZlciB0 aGUgc2FtZSB0cmFuc3BvcnQuJm5ic3A7Jm5ic3A7IFdlIGNvdWxkIGhhdmU8YnI+DQomZ3Q7Jmd0 OyByZXBsaWNhdGVkIGFsbDxicj4NCiZndDsmZ3Q7IHRoZXNlIHJlcXVpcmVtZW50cywgYnV0IHRo YXQgd2FzIHNlZW4gYXMgdW5uZWNlc3NhcnkgYW5kIGxpa2VseSBsZXNzPGJyPg0KJmd0OyZndDsg c2VjdXJlPGJyPg0KJmd0OyZndDsgdGhhbiBhZG9wdGluZyBleGlzdGluZyBtZWNoYW5pc21zLjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdo ZW4gdGhlIFN1YnNjcmliZXIgYW5kIFJlY2VpdmVyIGFyZSBkaWZmZXJlbnQsIHRoZW4gdGhlIHRy YW5zcG9ydDxicj4NCiZndDsmZ3Q7IGNvbm5lY3Rpb24gd2lsbCBoYXZlIGNyZWRlbnRpYWxzIHBh c3NlZCBhcyBwYXJ0IG9mIHRoZSBlc3RhYmxpc2htZW50Ljxicj4NCiZndDsmZ3Q7IFRoZXNlPGJy Pg0KJmd0OyZndDsgY3JlZGVudGlhbHMgd2lsbCBiZSB1c2VkIGFzIGEgU2VjdXJpdHkgR3Jvb21p bmcgRmlsdGVyIGp1c3QgbGlrZSB0aGU8YnI+DQomZ3Q7Jmd0OyBhYm92ZTxicj4NCiZndDsmZ3Q7 IGNhc2Ugc28gdGhhdCBwdXNoZWQgb2JqZWN0cyB3aWxsIGJlIGV4Y2x1ZGVkIGZyb20gYW4gVXBk YXRlPGJyPg0KJmd0OyZndDsgTm90aWZpY2F0aW9uIGFzPGJyPg0KJmd0OyZndDsgcGVyIHRoZSBw ZXJtaXNzaW9ucyBvZiB0aGUgUmVjZWl2ZXIuJm5ic3A7Jm5ic3A7IChJLmUuLCB0aGlzIGlzIGlk ZW50aWNhbDxicj4NCiZndDsmZ3Q7IGJlaGF2aW9yIHRvPGJyPg0KJmd0OyZndDsgdGhlIGFib3Zl LikmbmJzcDsmbmJzcDsmbmJzcDsgQXMgc2V2ZXJhbCBwZW9wbGUgaGF2ZSBoYWQgcXVlc3Rpb25z IGFib3V0IHRoaXMsIHRoZTxicj4NCiZndDsmZ3Q7IG5ldyB2MDc8YnI+DQomZ3Q7Jmd0OyB3aWxs IG1ha2UgdGhpcyBleHBsaWNpdCBpbiB0aGUgU2VjdXJpdHkgc2VjdGlvbi48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IEVuZCBvZiBlcmljJ3MgY29tbWVudF08YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTdWU6IFRoZSB0cmFuc3BvcnQg cHJvdmlkZXMgZm9yIHByaXZhY3ksIGludGVncml0eSBwcm90ZWN0aW9uLiZuYnNwOyZuYnNwOyBN b3N0PGJyPg0KJmd0OyZndDsgY29uZmlndXJhdGlvbiBpbiBuZXR3b3JrIGJveGVzIHdvdWxkIG5l ZWQgcHJpdmFjeS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgLSA0LjIuNSwgMm5kIHRvIGxhc3QgcGFyYWdyYXBoOjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgYW0gc3VycHJpc2VkIHRvIGZpbmQgdGhhdCwgd2hlbiB0 aGUgcmVjZWl2ZXIgaXMgbm90IHRoZSA8YnI+DQomZ3Q7Jmd0OyZndDsgc3Vic2NyaWJlciw8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyB0aGF0IHRoZSByZWNlaXZlciBpcyBleHBlY3Rl ZCB0byBvcHQtb3V0LiBJdCBzZWVtcyBsaWtlIHNvbWUgZm9ybSBvZjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IG9wdC1pbiBvciBhZmZpcm1hdGl2ZSBjb25zZW50IHdvdWxkIGJlIG5l ZWRlZCBoZXJlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFRoZSBxdWVzdGlvbiByZWFsbHkgd2FzIGhvdyBoZWF2eS13ZWlnaHQgc2hvdWxk IHRoZSBtZWNoYW5pc20gYmUuPGJyPg0KJmd0OyZndDsgVHJhbnNwb3J0cyBiZWVuIGNvbnNpZGVy aW5nIGFyZSBhbGwgZW5jcnlwdGVkLiZuYnNwOyBTbyB0aGVyZSBpcyBhbHJlYWR5IGE8YnI+DQom Z3Q7Jmd0OyBsZXZlbDxicj4NCiZndDsmZ3Q7IG9mIHRydXN0IGJldHdlZW4gdGhlIHBlZXJzLiZu YnNwOyBBbmQgYSB0YXJnZXQgY2FuIGFsd2F5cyBwdWxsIGRvd24gdGhlPGJyPg0KJmd0OyZndDsg Y29ubmVjdGlvbiBpZiB0aGVyZSBhcmUgaXNzdWVzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEluIGFkZGl0aW9uLCBtdWx0aWNhc3QgdHJh bnNwb3J0cyBhcmUgdmlhYmxlIGZvciBzb21lIGZ1dHVyZSBjYXNlcy48YnI+DQomZ3Q7Jmd0OyBX ZTxicj4NCiZndDsmZ3Q7IGRpZG4ndCB3YW50IG1lY2hhbmlzbXMgd2hpY2ggY29tcGxpY2F0ZWQg dGhpcyB0eXBlIG9mIGludGVyYWN0aW9uLDxicj4NCiZndDsmZ3Q7IGVzcGVjaWFsbHkgaW4gYSB3 b3JsZCB3aGVyZSBkdW1iIElvVCBkZXZpY2VzIG1heSBiZSBpbnZvbHZlZC48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTdWU6IElmIHRoZSBy ZWNlaXZlciBhY2NlcHRzIGEgc2VjdXJlIHRyYW5zcG9ydCBzZXQtdXAgZnJvbSB0aGU8YnI+DQom Z3Q7Jmd0OyBzZXJ2ZXIsIGNhbjxicj4NCiZndDsmZ3Q7IHlvdSBwcm92aWRlIHRoZSByZWFzb24g d2h5IHRoaXMgaXMgbm90IGFuICZxdW90O29wdC1pbiZxdW90OyBvbmNlIGl0IHJlY2VpdmVzPGJy Pg0KJmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsgY29ubmVjdGlvbiBmcm9tIHRoZSBJMlJTIGFn ZW50Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IENPTU1FTlQ6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLSBHZW5lcmFsOiBJIHN1cHBvcnQgU3RlcGhl bidzIERJU0NVU1M8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IC0yLjI6IFdoYXQgaXMgdGhlIHJlYWwgc2NvcGUgb2YgdGhpcyB3 b3JrPyBJcyBpdCBleHBlY3RlZCB0byA8YnI+DQomZ3Q7Jmd0OyZndDsgc3VwcGxhbnQ8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgbWVudGlvbmVkIG1lY2hhbmlzbXM/PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTm8uJm5i c3A7Jm5ic3A7IEl0IGlzIGp1c3Qgc2hvd2luZyB0aGF0IG1hbnkgc3BlY2lhbGl6ZWQgUHVzaCBt ZWNoYW5pc20gZXhpc3QuPGJyPg0KJmd0OyZndDsgVGhpczxicj4NCiZndDsmZ3Q7IGlzIG5vdCBp bnRlbmRlZCB0byBzdXBwbGFudCBleGlzdGluZyBtZWNoYW5pc21zLCBhbHRob3VnaCBwZXJoYXBz IGl0PGJyPg0KJmd0OyZndDsgY2FuPGJyPg0KJmd0OyZndDsgaGVscCBhdm9pZCBmdXR1cmUgZGVk aWNhdGVkIHNvbHV0aW9ucy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtIDIuMzog JnF1b3Q7V2UgbmVlZCBhIG5ldyBwdWItc3ViPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgdGVjaG5vbG9neSZxdW90Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7IFRoZSBzaGVwaGVyZCB3cml0ZSB1cCBtZW50aW9uZWQgYSBnb2FsIHRvIHVz ZSBleGlzdGluZyB0ZWNobm9sb2dpZXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg SXMgdGhlIHBvaW50IG9mIHRoaXMgc2VudGVuY2UgdG8gc3VnZ2VzdCB0aGF0IGlzIG5vdCBmZWFz aWJsZT88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBFeGlzdGluZyB0ZWNobm9sb2dpZXMgY2Fubm90IG1lZXQgYWxsIHRoZSByZXF1aXJlbWVu dHMgc3BlY2lmaWVkLjxicj4NCiZndDsmZ3Q7IFRoZXJlIGFyZTxicj4NCiZndDsmZ3Q7IHRlY2hu b2xvZ3kgZHJhZnRzIHByb2dyZXNzaW5nIGluIE5FVENPTkYgd2hpY2ggY2FuLjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtIDQuMSwg NHRoIHBhcmFncmFwaDo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgTUFZIGRv ZXNuJ3Qgc2VlbSByaWdodC0taXMgdGhpcyBhIHN0YXRlbWVudCBvZiBmYWN0IHRoYXQgdGhlPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgc3Vic2NyaWJlciBtYXkgaGF2ZSB0byByZXN1 YnNjcmliZSwgb3IgYSByZXF1aXJlbWVudCBvZiB0aGUgZm9ybSA8YnI+DQomZ3Q7Jmd0OyZndDsg dGhhdDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IHRoZSBzZXJ2aWNlIE1BWSBmb3Jj ZSB0aGUgc3Vic2NyaWJlciB0byByZXN1YnNjcmliZT8gKEJlIGNhcmVmdWwgPGJyPg0KJmd0OyZn dDsmZ3Q7IHdpdGg8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBNQVlzIGluIHJlcXVp cmVtZW50cyBsYW5ndWFnZS0tdGhleSBpbXBseSB1bmV4cGVjdGVkIHRoaW5ncy4gRm9yPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgZXhhbXBsZSwgc2V2ZXJhbCByZXF1aXJlbWVudHMg c2F5IGEgU1VCU0NSSUJFIE1BWSBkbyBzb21ldGhpbmctLWRvPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgdGhvc2UgaW1wbHkgdGhhdCB0aGUgc2VydmljZSBNVVNUIGFsbG93IHRoZSBz dWJzY3JpYmVyIHRvIGRvIGl0ID8pPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgR29vZCBwb2ludC4mbmJzcDsmbmJzcDsgUmV3b3JkZWQgaW4g djA3Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyAtLSA0LjIuMiwgdGhpcmQgYnVsbGV0OiBUaGUgcHJldmlvdXMgc2VjdGlvbiBzYWlk IGRhbXBlbmluZyBwZXJpb2RzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgTVVTVCBi ZSBzdXBwb3J0ZWQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgWWVzLCBidXQgZGFtcGVuaW5nIGlzIG5ldmVyIGZvciBwZXJpb2RpYyBzdWJz Y3JpcHRpb25zLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0gNC4yLjEsIHRoaXJk IHBhcmFncmFwaDogVGhpcyBpcyBhIGJpdCBhbWJpZ3VvdXMuIEkgdGhpbmsgaXQgbWVhbnM8YnI+ DQomZ3Q7Jmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBjaGFuZ2Ug dGhlIHdoYXQgc3VidHJlZXMgdGhlIHN1YnNjcmlwdGlvbiBhcHBsaWVzIHRvLCBidXQgY291bGQg YmU8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBpbnRlcnByZXRlZCB0byBjaGFuZ2Ug dGhlIHN1YnRyZWVzIHRoZW1zZWx2ZXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRml4ZWQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyAtIDQuMi42LjQ6IFdvdWxkIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dlZCBvdXQtb2Ytb3Jk ZXIgZGVsaXZlcnkgYnV0PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgZ2F2ZSB0aGUg c3Vic2NyaWJlciBhIHdheSB0byByZWNvbnN0cnVjdCB0aGUgb3JkZXIgZnVsZmlsbCB0aGlzPGJy Pg0KJmd0OyZndDsgcmVxdWlyZW1lbnQ/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgWWVzLCB0aGUgdGltZXN0YW1wIHdpdGhpbiBhbiB1cGRh dGUuJm5ic3A7IEJ1dCB0aGlzIHJlcXVpcmVtZW50IHRhcmdldHMgYTxicj4NCiZndDsmZ3Q7IHNw ZWNpZmljIG9iamVjdCBpbiBhIHNwZWNpZmljIHN1YnNjcmlwdGlvbi4mbmJzcDsgU28gdGhlcmUg c2hvdWxkIGJlIG5vPGJyPg0KJmd0OyZndDsgaXNzdWVzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IE5pdHM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLSBUaGUgc2hl cGhlcmQgd3JpdGUgdXAgc3VnZ2VzdHMgdGhpcyBpcyBzdGFuZGFyZHMgdHJhY2suIFRoZSBkcmFm dDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IGFuZCB0cmFja2VyIGJvdGggc2F5IGlu Zm9ybWF0aW9uYWwuIFBsZWFzZSB1cGRhdGUgdGhlIHNoZXBoZXJkIHdyaXQ8YnI+DQomZ3Q7Jmd0 OyZndDsgdXAuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgRml4ZWQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtMywgbGFzdCBw YXJhZ3JhcGg6IFdoYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgJnF1b3Q7UHVzaCZxdW90 OyBhbmQgYW48YnI+DQomZ3Q7Jmd0OyAmcXVvdDtVcGRhdGUmcXVvdDs/PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUmV3b3JkZWQ8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtNC4xOiBBIGZvcndhcmQgcmVmZXJlbmNlIHRvIHRo ZSBzdWJzY3JpcHRpb24gUW9TIHNlY3Rpb24gd291bGQgYmU8YnI+DQomZ3Q7Jmd0OyBoZWxwZnVs Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IE1vdmVkIHRoZSByZXF1aXJlbWVudCBpbiBxdWVzdGlvbiB0byA0LjIuNi48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLSBMYXN0IHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZTogU2Vu dGVuY2UgZG9lc24ndCBwYXJzZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBGaXhlZDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLSA0LjIuOCwgdGhpcmQgcGFyYWdyYXBo OiBJIGRvbid0IHRoaW5rIHRoYXQgc2hvdWxkIGJlIGEgMjExOSBNQVk8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBGaXhlZDxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzIGFnYWluIGZvciB0aGUgcmV2aWV3ITxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgRXJpYzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IGkycnMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPm1haWx0bzppMnJzQGll dGYub3JnPC9hPiZndDsgPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPg0KaTJyc0BpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZsdDs8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_d12fea6bf3d9431d8994524fd1e6e576XCHRTP013ciscocom_-- From nobody Fri May 13 13:48:35 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A314912D548; Fri, 13 May 2016 13:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.778 X-Spam-Level: X-Spam-Status: No, score=-4.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_IMAGE_RATIO_02=0.437, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynM5M2QCXUsY; Fri, 13 May 2016 13:48:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6938012D17E; Fri, 13 May 2016 13:48:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COP96180; Fri, 13 May 2016 20:48:26 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 13 May 2016 21:48:25 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 13 May 2016 13:48:18 -0700 From: Linda Dunbar To: "i2rs@ietf.org" , "draft-ietf-i2rs-yang-network-topo@ietf.org" Thread-Topic: draft-ietf-i2rs-yang-network-topo should add a section to show the XML formated Topology exchanged over the wire Thread-Index: AdGtWMYcvTozCjVmS/2fDSj0Cwq1aQ== Date: Fri, 13 May 2016 20:48:18 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E85BEF@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/related; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F657E85BEFdfweml501mbb_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57363D9B.00F1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b9e08e64aa5e828a25bd6416f6ae6f3e Archived-At: Subject: [i2rs] draft-ietf-i2rs-yang-network-topo should add a section to show the XML formated Topology exchanged over the wire X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 20:48:33 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F657E85BEFdfweml501mbb_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E85BEFdfweml501mbb_" --_000_4A95BA014132FF49AE685FAB4B9F17F657E85BEFdfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Draft-i2rs-yang-network-topo authors, As I2RS is to define the interface between Client and Agent, it will be ver= y beneficial in the draft to provide an instance of the data model you have= specified. You should have a section on Examples over the wire between Agent and Clien= t based on the YANG modules specified in the document. For example, the "draft-ietf-netmod-acl-model-07" has a section on the ACL = configuration XML: [cid:image001.png@01D1AD2E.DD44CEB0] Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657E85BEFdfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear  Draft-i2rs-yang-network-topo authors,

 

 

As I2RS is to define the interface between Client an= d Agent, it will be very beneficial in the draft to provide an instance of = the data model you have specified.

 

You should have a section on Examples over the wire = between Agent and Client based on the YANG modules specified in the documen= t.

 

For example, the “draft-ietf-netmod-acl-model-= 07” has a section on the ACL configuration XML:

 

 

 

Thanks, Linda Du= nbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657E85BEFdfweml501mbb_-- --_004_4A95BA014132FF49AE685FAB4B9F17F657E85BEFdfweml501mbb_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=55044; creation-date="Fri, 13 May 2016 20:48:18 GMT"; modification-date="Fri, 13 May 2016 20:48:18 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAqYAAAFKCAYAAADPFZ37AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAANaESURBVHja 7J0HWBXH+v9Juem93ZteTK92o2mWaCyxF+yK2LBiF1RAuvSOImIXFRRBRJEiXVTEgqIovffe2+e/ 5xzKwZLo7+afa5L5PA8PZ3d2Z2femZ357juzOyoIBAKBQCAQCAQPACrCBAKBQCAQCASCBwEhTAUC gUAgEAgEDwRCmAoEAoFAIBAIHgiEMBUIBAKBQCAQPBAIYSoQCAQCgUAgeCAQwlQgEAgEAoFA8EAg hKlAIBAIBAKB4IFACNMO1JJxKZZz5y+SkFZAffNfI9WNNaXkZZbSKArwwaK5juyb8cScO09SUV3H MqsWZSYQCAQCwa38ZYVpTeENjrvZYWhohN32AFLLm/6AWDPYPHkk3/fsTNfRy4gp/GvYIv2oMeM+ 3UTan3jN0htRHD4SRmGt8t4mKosyiYsM4ODRY1wpbLi/SBvyiTq0BSMjBwKuFNwWXJt9nm0Hg8lp 4K9BfTa7dZcy7KvneGp+cIegtCPGjP/SnPQ/MTkl16Uy8w6nsE0j13EzwBMHawtMzS05cq2Igosn cLSwwM7Wln1hpzm62w4TYxPMLKxxsLFgk6kxRiY7iS9tIu/CcezMzLC0NMPU1FT6M8bYdDfRyeX3 lp6kMLZZm6BruZPYwvrb6/XZADx946jq8IBYQ9bFk9hL1zLcZI1HVBJ1f9VGTCAQCAS38RcVpnWc NtFm5qSlWNs7YGW0kfWO+0iv/oOir7iEldVGzuT9VexRTMLp9D+xg27gqPZkeo2yIauDSMzGx9EW MwM9Rk0dhXF02f0YnaDNFqxaa4CdJJSWr13HvvgqpfAmLpjP4MNfdMn8q7kZy3bx4Rz/28ss+s8s s3qOrJ3Et2NsyW5qL8fMc7tRffpzJhlKDwNJJRRfj2DrvJ48MlyL/e52zFUdjY61K8YaA/jPT0tw 3mmL+jfdMD1fTd0NLyZ+0Zfxc3Wwd3TAcfMmZnUfz8Zdl+/BJucxHrEIk82bsTJbyeShjlLtUaYa q2md+XFtAB2efcrPM2PiLBbrm+PkaMWG5frsCbjx12zGBAKBQHAbfzFh2tDSSTWScymOhLzWLiuD NesN2XdFUqZ53vykooKKyreYBxdD4nbekW13mYSL82Je/XdvJo3qx1ufT+JQ4B6GvPQIH0/eQa7S VeozIjDepHfPwjRupwbPy6/5BcZhJVAUwdxvX5K2VfhQT+EpK4rzYOY3/5Hv66RqQVyrZkvfxyvS vid/mkVUbhHRjuo8pfIU462iUOjscrapf8ezsvhf/pKRg7sxwiNLcW55FKPfeE6K80WGLzxGyS3p qrh+FI3eb8iv+XrXORy+pjji2OrOqHzaH+sd9kz86Fkp/GlGbQqj5l6LofYm2lP7sc4v+7byqSit oKGqgK32yzE5XXrvRZsbzVojQ0Jasha3zw5D7RO0SdO6FLRVp7J8T9x91pkaAi1n85bMfi98xvzt 5+V7S+N2MuDJfzNRZxsuy4bIbfTv3gsJzlSyQm0y2xb24xEp7LnXujNw2DK2HU9RhDWlSWG/8Mq/ ZOX+CWv3XVIalq/loNav/Ft2zbd/ZavjYr5cckoRVBbJqNdlNn+JEYv9lMqsCp/1I/jXM0Nw8d3J uE+eko55hREbfSXJrqAxL4rV/TrxsBTv89/NlwTdfL54vDtmYbn3YIYE1k4dwPrjt5ZZObt7L+KE 8jPAGV0+33ITrhzEyNAJWSnWn7NgkLFCcJ5eNgL9aFmqKtm/zA6vcxVtp0av0cPCLeZ3k1MZZUyP pRFt2+5jf2aHsvu4MowZb/dj/60u5bo8ws4k0OpfrYl2Zq7lbkplD0jNTfwR4yYCgUAg+N/xwAvT hspCbl4MZY/pXD75UZebt3jLitLiOLJZn2UGziRXtu6tZr+VCU6BCSQft2Shpm+baDg2sye6sdKP syZ0mWiAbNDRx3IyujJB2cL9ClM5NzxZ6eTVIu6aid7qhOsRhSen7NoR1izZyNXWY68eYt0yC65W tafX1mQK3w9ZyM6zsvkDDSScuyRPW+6OUXxjmdh2maxdavy4I7XjtfNCsBhj22EoPy/MlemztQlt nY5QFsH8KUvZf0WhiJ1WjaDHwj0twqgQc+3pOF1QGLCmMJkz0WeJiYmR/507G8OVhBxqW4ZUa7JC sFS3Iuluc3Cby3C1XyYJ05J7Nl/xJR9sLJ1Ib1EchRcOY7bRlpQWl2KdVCabbG2ILbyfib+VnNSb g+b+do9a4OoFrA/MlP8uDTfnp/7j2BevuMiNbQZoWfooHn6qk7DQ1MDYO6W1puEybyWWB2VlUYzV hIGsP5HVFq+v8XRmmYQqriGJ2TE7Wsssm029HueJlVEdk5Z7Cotx9rdMv6hk74hR9J3h2PJQksVa 1XV4XJMqSnE02tPV2J3Q4qKuCEP1w69RNTinsE9h0m+WWXVGMJZzrEm+TbkV4NpjLl5KMyeaQ9bS yVJ2kzRSUqqoE4UhRvTTPa24VnEhJXUKm+xduAHjzSc4E7KZ2Z+tI+Vei6YkEq3hK/A8H8+VU7YM /0yPZKXg6lgnxmud4q6zNhrKuH7GD5OFa3A6chVFNkvw2LiEMZPXcTA4hqziKtHCCwQCwV+MB1eY NhcTuW8fTnYmrFq+FtcTV7l9FtpZRj/xIar2J8i5dRi/OYF1M77j455aSvP4ajk49VcOFEn92hkn Fmz2ke/1dFrI6uCitqP+T8JUkhiGalp4J0vStPwKpgb6+KUoUhzmpE7nX5dhZWOOickmLPVX02/K TLbGtrhNq1LQWauBQVDObbHWXHBAdYEOluYmGBmb4eDgSkRmR0uUxHtjPNZeKZ/lHLAwxsIjqcNx 6Xu0mL8zGpmwsnNYx9YWQUZ9PvZ2a7A5p0hPVpgzquMmMn3GDGbMmM6UydNZY3KU3HsdQm8swdXu /oRpQawnZoa2pLY4wQsveGFhaE/qfzPWXRDCkCFTWG1khrmpCSbm1lgv7sdT84/Ig5MOWWG2u33u Z4q3NYYuR+XD60UXvTBdYktmW2gD6ZcvEZ8uJTBtG9/96tnBO9dUcA7rDTokpIUw8HsrKpTTEbac 5zSCOiSt6MoRjCc43jLHNB2biRacSGmtzFk4qJpwNKGWnBALZqwM7XD0BUcrNq47IU9vdpjjLWU2 g7WmUpn97nzcArZ2nccR5fnUoVq8b37+FlO2C9N2SvHUmEqfLj/xy8+9+P6bTR3EZdZ5X8x0NmJk ZIS+oTH7YpUuUhnHyjE/0aP/IAb06kL/BS5SrbyPovWZw6OdJrD3TNptXtKytGic1yxGy9QOux0+ XMz5o+b4CAQCgeD/Nw+uMK2PY8FH79J1nhOpdx2fKycuNP/OIRcOob10DrPmzsM1rlXIyYTpUPZK p9SddmCuw2H5Xk/HBaw91d4t1mcqhOnZ/PtLcpHHOga7Xqby0n7WaR9sG6Y9YaPKN2pGuG11lgSg Pfb2jrgeDialvNX7lYShrR77rt0+mJ4Z6oVPQDAHtjlga+/EFvMVqK8O6TA3sSTeRxKmDmQo2eWg uSRMDyZ2iCt992pmu8nERRG2Nmuwj215SaUuDzubVdjFKLYzgqwYMmgYo8eMYcyY0Yz4dTSLN3iS fa8vHTWVtnhM730ovzYxgPUW7VMcMoMOYLFqLwX/TR3KOMa3qnMwluzm5GCPnb0Djo6bOXBGITeT DlliuPVY2xzGZC8rSZj6yh+Aii95YbTY6s4vJ6Vs5fshBzsIouaCs1hor+NacjAD+ljSIeehy3hW o+PLT8VXFcI0o2MJYTPBmMNXW+tiJraqxhy9UUt+uA3qmic7HB1taYj2On95ejODLG8pszEs1jl0 D2VWwp6BMzmkVNcbgzX50vpCh6MK7yhMC9i5yBqv8zLhV0a4W2CH8sq9HICjuSW2trZY29jhdbn9 HotzmYjatvYHp1CDcagevfcbrrk4nrO/845VpON8Puz0A2Yh2aKlFwgEgr8ID/BQfjO15TlEezsz 5Zcf+XWhM1dLOnoKK6+6oz5Zi9DcW4Z3C85grm9IUJok30pjMFqyBL8W19fByUM4KKmGhig75m05 qtjntJB1kZXt55dfxNrOlPj79tZdY023aZKIU8fpTHt8WVFuLJtnreR9qyDSP5Ar6a09awHmm43w vE0FNXBCvSezDij5oWL1+XyER8cXQjKCsJ64DeVXjQqitjNjzloCW/vkrBPMnLoMz2uya1axZYsO rtdbVUsVW7esx+Wqwr71pVlcvRrP9evX5X/Xrl0jOa3wDh7ru7PXdS3WV+4UkskWjYlo77vSMb7G dKyWSmI5UDZfsomdOmqsOZD0X9ahXNxmz8Y0QMkTnR/D7kMX5D+z/Rwx3xPSfrS/E+a7WzybtSlY r5jHhgPxLaGFeOqbsdNflqZS7KcMZO3RlJawetwNpjHbPFKWEY7N/onZrfOAG6+i/ZUKT2pd6JCy pvRArKe40fH1sAKcJ1vjn9Za8YpxmWrFybRGqYgusmbSCFZ6XJeH5IQ50fuZNxm5Pkw+3N1QdmuZ XSc5veiePnl2w2403TeeatkqxWX4EPRu8XbXx1jys8mt83srOKBpx6EzZfddMqkeGgy1vNxWz/fP GYjW6Xud5VxFiPkC5m4K5LZHn6YSYg4b0OfDH1ju4M3F5HzqxMRTgUAg+Mvwl3n5qTjuANMG6XNJ yQNUHGTIu68PYvfNdomT6a0pf5Hl0XfGsvtqNZQFM/qph6R9H7Bk32l8V/Wnx6JgirO86Pvuj9jG FHNq00S+GGtGXmYoP7/wFA8/8Qwvv/wKzzyuwsPPabTPDb0Hcrzm02nIHm7tqrOiXBj50b/5l5S2 lz4chYlHJIWyofHMA/IXc1546RVefOYJKZ0PM/Voq9+pkWijqUxavIjvP5C95PQMn40zbxvyrIi2 4b3XnuRfTz3Hy/95iadkL9uMcGi7ZsWVI8z58R3pvH/x1tezOHJdIYRP6HzPw48+xiOvT8C3sJS9 0zrxyKOP8+R3GoTl1v4XpZSBQ9/PeOjhf/HiS6/yyjMPS9f+lYASpUOa41nU7X2GGobe/rJVdTwm 47+Szn+Hxa4X/qAXWYo4uH6C4kWkx97g+4nr8U8spzLhAKPffIrHH36MblZnqY625dvHH+FfD7/B jL3XFKc2pLNr2WCeelSFZ1/ri47nOdoeNyQhvXXBQP797MPyurVqX7zSNevYvbCv/IW4l7rPxu/E Fj55/DUmWF+g6JIj77/6JI8pl9koZ/lZx/Qn8foz/5Li64VvTjW7VgzgqWcelbYncEF2gCSWD2iP 5dlH3mWigSsejltwNjnecdrA/4kmTppO5b2HVXjo9a4s3XVBKSwTxwGf868nnuPfzzzOy0NWcbFY oXajHOfy5hNP8rRknzeWHr/vq0bZzuDDZ6X8v9QZLZ+0+yrTnVN78Nkkt45v8jfks8dah1V2QeIT UgKBQPAXRXxgXyD4i3CrUL/gYomxaRBiBqVAIBAI/i4IYSoQ/BVoKOXUttUMHfwz333/PT/2HcQk TWtOXSsTthEIBALB3wYhTAWCvwRNVJXkkpx4k4SEBBJuJJFXVivMIhAIBIK/FUKYCgQCgUAgEAge CIQwFQgEAoFAIBA8EAhhKhAIBAKBQCB4IPgHC9MqAhb9JP+01Jf9Xcn6K2YhyYMvXntC/hmpgTO9 KPon1+Sy62gZGbP3cskfG29+KHN6/lteT1Se7Y3ZqUzRatwLzams//FZhd366yE+cf9/ozY9mMW9 3lbY8an30Y387VUFskIs6f7wv5mz/bIwnkAg+EsiPKaksKm7NvH3cmjePl4cuevBy0JeCBZjbEn7 ky5X4LeWt58awfEAW6nD7M+x0gfBCDkY29lx4Np9JKYimv5qVsTfdXWkRnxV5+MS/yDk76/KFQbP cyKp/q+diyTLH5kW0PynX9fLwRCj4/f35YX0/cboHzjzAFmvnEsn3DFdqsZXPb5AM+h+Fp+t5ZKv GQPfeYVHnviKlVvDOny398qWWXT6YC6Rx3WltmgY58UNJxD85fkHCdNmWruVoquBOJttRFtvMycv +GDQRw/FejoVXA33wUZvHevXG7PF82x7I9hcRoTtXJ79ZCQbzY3RW78B08PR1LR8XLK2OI3wQ67o 6+mw0dgOv9gM7mVp+YxTbqxZZ4CLZySl0hnJPlvZsMGEfSeucCPsENabPTlywBnbvSGk3DiNnYEB 7ucKO8RREu+N8Vj79uUzG0oJ2W+DmUcgqfEROOppscHMhfDEdtHWUJLI0S3WUj7WY+y8h4P+AcQX 3duaoxUXXJn4xXKu3/Dh3fc1udxiu+hDW9Gz8FMsAFBfgP9eezbsjlB87LwiAy83M7TWbyW+EmpS Ithstgl7n8s0NOVwZJMJe/zOEX/aFxPdDZjYH+RK4b2pmbyz7qzR1sVq70nSK2//LH/G2WNY60g2 2OTEiauty142cOOIKZ98/TMa6/Qw0NXBcNsRUspbC7SA4EMmjOr0LaM11mKop4/tniDyfudF+OLL xzA1diLq5g2CdtqzUUsfu4On21a5aq7KIcZ/L3ra69hgaIV7xM22sMaSm7hvMUFrw3bSpGSUJQRj b7IJx+MKZVyeHYf3Vhv0ddejb7KD6FRF7ay5fgwji10c3uuGtesJsnKu4Kqvj5v/jbYPzZfeCMbZ VFeq12a47t+Hx/44fm+dpbqCeNwlYaSjZ0tYVj1NBXHst9Rjre5BriVE4mTlgOd+N0xtPEkuSMbL 1gxnr3NUKBdBcRj9ZjuQfI/L2Tbkx7HVxgS309dICHbHfIMWOk5HyVZKbHliJJsNNrLewJTN23ez IzSO2t/TjMUX2bTeHK/wOM6d3COV93osXYPJVUpXY+Fl9jubs0HbAAeP0222a8w7h9bID/lm6nrM jPTQXmvDyYQS5VSTGnUIHa11GNtuwX3vIaKSW8PrSDl9BFNDPfQM7PGNSWsp7yoCLA3YvD+c+Nhg HEw2omfiSnRmawWrIdxWm1+H9OOnKcsxNJTuCetT9zQqEu+mh9EuH8I8nNFaZ8TWw+cob7VPQyVJ 545hv8mIDTp62HlEoLymRlNFOv5udmyU2gUD+114HvfjQl77fZgd44u9mb5UR204dulel5At4cKp U5y5dB03qzmsDr73sZ3a9FB0NLUIK1PY2WXxeIxPt3uN049uYuoAUzLid/L0f9aQq9TeN4oVvwSC vyR/f2GaHyOJkvXYHrkh36xLPMg01ZXYuLjgsmUz2rP68uVXm0iVB17H1dIWBwcnXLa6YDxvOjon U1siquLSjuW82Hk6zru24Wxvz7bAy9TJG/xmci4GSR2qDY5bXNhqv4l5q43xuQfvXUGsL9rqv9Jv uB550rbH4E50mW9L4Nl0Ci640FPlOzZ67GHDdDXmLJI6mW2GzBymRZxSh3qbMG2uJtZdize/7sP0 9XbsdtuMxfoFTDJwQ97vNRdzZMs6Vhk44OqylS2ORgwaNxzz31t8vNUSSV4s67OR7LxgvvzZqMVT W8fNICs6PzNf4bVoruSi+yoe76ePfEHQmjzCTrgyr2dP5ks2NjFyZoerBUs3eFAodVzHdKfQrctP LLfYitvWzegvXcw6c58OS05WJ59CV8uKiKyO6rDoqj9O5uv5cdx8tp7vKNoLT1iioW0hXWszzpIQ X6m2jsA0hcrJCLDnm2/HsM7aERcn6e9wMJmVLT14XQnngl2Y+WV/pmub47p5M3t8oylSXlKoNgPP TYbYnLjRbpv0aKksPuGpL2Zg4biNrZu34Ki/iNmG0fKlQxuTQnG0s8feeQsuLtYsnqCF5yVFmpvK Mwg45oL6l9+wwMEFM9PN7NhiyoL1h+ViJjHSA5tNNlI+tkj5NWb1elNiZQYqDmLEB28zy2wHlpqT GbrEiJ0Oxsxashq/DFnMF1k+dgW2213ZsmUHu62n0+l5o47D640FeEvnOHhfblvutr4klSB3A356 4WMMpSe3ppitjPz2R5abB5CddpqZv3Rj0EpbXA006DlyPTvdLJk6eQM+V5Q8Yr8lTJtKOLXNkk17 o9rEeVN5Gl4bh6Hy8Shstu5gu6sjOrNHM21/y2pcWWHSA+VGbG0347LNDad1E3lphinZylWi9BJW S9fhlaikZmuSMZ38M1+9NwrjrW5sc3VmzZy5rN/Z6g5PxEh1PiZb3KR2wQVHo2Ustb7UeoOxafIX 9F5ky07pPDvr3USltN4rDVzdZcEKbRMcpbLettOZ5T//iMZexfKtUZ52rFhlhK1Uf1ykP/3VOrge UVwzynEp3332FWr6zmzbtg1LHemamq5kNivupwt7rJmq+itDNQyluiLdq7vPdVxRTiqzI/bGOPrE dVjpKlm67z7vPIR1ti5slto4K+0lLDtwusU2qRyTHpgs7J2lNs4J/VXaWGyOaFmkoYaA7Vos0XVg m6x93GrNmNF9WR1SIg8tv+zC9AVSWtykeuTsjP4yDbbe6LjG1g1/VwwtPcm4y6oPXs7zWRlYeM/N d2bEfsyWHqCkZfuqjxmLDCLbHvqzw9xYPdqJ0uzD/Od7S5QWlibvhCETdPaTWI5AIPgL8bcVplUZ UWya+hNdx63EPeAiOVWy1r6eI/N+xSKm3QNQE21B79f1Sb5TJBdM+dAkrH278DAfT/e4p+sfN7Rm 84Hr95paghw2sVJ1KKONjyrtv8zcdzcg0xY3XGwxNT0l3+s6dhhHlZwVtwlTGQWRTN5oQXhGS8dR EMpkQxsuypwVtVInvXICJmElbYcnXo7kWoFCPcTvmC6f0/bY44/z+OOP8bDK43w9aBM3Wjr/urIr eLsEUFl9A9ttgUqdwU1Wd91IbKt3pjKcH2Y5dxBAlwwG8d3KAxS0CpUGRRdTHu+DyYZNcm+q/NQ4 L0x1bEhR6vcyfbV5VOV1NoTfqWMrZNMmSYDGFLTvqr7I4qV2XFbuJGNs+cE6usXssYxduoUbd3Vt 1+E7URv3+Lv0snkhjH7lSf4zx7PD7sytg3hz3WmlPels/GU43rm3R5FgtwKdIx3nCpxZ3oMfNwZS 0uLxaa67k6qrxtl2NQ6xVbIj2DN5KN5SB9wQos8YmwB52rdIcVvFSueW7ufzz7Wl0mkln5OeFzt6 TCVbTXvnaT6avuN2r1xZBJr9prNw7WJ2x7ZKo1r2Oi9D/5yUyOJ9vDXeHdnUh/1LzdnR9jDHbwvT quus6fUmT/1sSony/lhz3tbyVTKIAe8ahCju11hXBs7X5XJr4puzCYi5Rp2ydyx+C69K9Vf1YMf5 wFmBW1k561Dbw07GCUdWzj8hF8UZu2ez6KjyY1AFLnPUCW7ZleY8koVhd8hDdiiztM2IzG7PYMI+ KxxDpbu2+AybFi3jVE774U0JPszUt+eqzIxVl7FZtIiw1ipbcR6rBZqcaxNSzRx2M8PoZN5dmo3z TJXK7OMZOylW8hjf3LmYHzS30paiurPM/mk9MXdwkTde88bMwJEM2T3QXIjT6uGsOdF+vYy4MC7m NMnrzJahiwhUHsTIOozmJA/adV8Tngu7ofK6KsHZdxrtkMId592XML3h44z2koC2upp0bDNaGsep aq2aGec4uv80dRWXMN4ScsvtW0CYlyNzhkvt6hxLonIaEAgEDz5/S2EaYTmTD94ejtvFWx+VMzB5 fzqRyrsqglnypS6Jst9Z0VgtH8ubjzzGMy+8zIuPqPCajlJjl7Wf96fsvcMVa7kZuYeFv3zD8888 wwsvPoPKE70xOpp6z2nOP+tCj09/YfWhJKW9Mai9q4ese72y2QFbS1la6nBRHf77wjQjCFUTR660 9lhZwUw2tudigWy7mZxYH9ZP6MOrzz3JM8+/zcA51pxOUTT3jRV53LyZSEpKivwvOSmJ9OzSe5ia cIWlX2/kYutmWSjfqTkpCdMmQldOwjbu9pXM8897Ym7kSHpLf1Z44RDm+nYdhOlvUp+OgdGmjsI0 3Y9uX7/DM889x3NSuTzzzLPy/5+tbBH/pdEMX2hPXMXdclaKx9iVbD9fcF/1L8F2KHOCOibce+0v OF1roOySH/pTv+ehfz3BCy8/z2Mqb6HhcVPpyEb8Zw9lS/otkTZVcN7DmBFfd+K5J5/mhWef5onO A9lxrV5e/9wm/IqPJHaqAg2YKu+gy3CwW4V1jEzp1xPjYcKwru/y2GOP8eg73Vls5ttRDP4m5Wxf 3J/3+llwrVURNJezw34phmekfObu4YMZh6WdlexdZMauexWmdyPSgPdNItq3TxvxnlFoix1Kuezj iGqPt3n0sSf59/s9mKp/lOJ7GLZN9JVEzuKTbR7hZD9ntOb7y5d6Ddb4CpXHX+Dl55+V6skzPP30 M3z07VxOtrwVed1mKPMDbn9Aqby4l8WWW8m7Q/5KrvlgOMam44uVtfGor7bgZKZUbkXnsNVcxYWW h7G6wrPYLF1OTFuzVck+ZwN0vVPuq/7Fb9uA7oFzyilha8/5HJHajOaCOLatnsh7/3mRp6X74unH XmbAvG20NicFV06gP60vr7/4JE8982/6zjDh1E1ZHbvIeJVHefLVl3j+2WcUNnruNQbO9CDvnlN2 /8I0LWgHBhoebXX1up8Ny5U8pvdK8SV3hr+gwjDPQgQCwYPN31KY5scdx2KjHpvMzDHfepSEvLbe lFMbRqNxMKPt2Cuus/nkPTv5XNJTCyaw+mS7vyjOfhIfWChNp8/35LMfrNs6tsaCRGJTpV6l5DLa azU53KrA6q+ycepynPxz7im91Tf90DN0JuJKFDYrNuAa0+qVikXtfRO5ByvO2ZnNjjJPXwOuk8cQ qDxmlR2C3dQdHYaxZN6amXY7SG/tMMvOoS5tp8n6mNILOGqt57ySU8NTfwXr3RSzRTMCrRn2yzDG jBkj/Y1m5PAxLNbxJOt3p3zeZP03Cwhs0WTlIWa8Psa2g2fuku5MnG/efmbVTX+crbe3dUC1yQE4 W21DWRLWF9/kuHcQSaV3UjkVWNk6cihRSaFUXUBT04SoDjMqmshMbxlqrjjH+HEbOd1quOpsLt/M ol4pipNTdfFMuovqaSjlUuBxgq917JqTN//Mo0NcaOsCs7yZNWYDKTVp6E5cxd62kf98dsyYhI5/ R89e9JJRuN2ihavSA1g/aRltPvj0YDQWz2aP3NVfz/aJIzkpVczqAANm7pa9+FKOo6M2WxKkn+dN +dHsrFJsWaz64leOKY8LN1cSF36SsEuZt3T65QRsNWDtrnNcCdnBWmNP0uXPOrXsdFrOpovSRt4e Os05ITMgexfb4Bmh7Bq+xJAlO7nj6y7N1SRGB3EyJokOFr5syce2l9q3r1jzsY3icSftuDP6W44p HRzH1CHahBYoPQjUZBN62Ft6COtYT/LD92C4uv2xtDhC2l6hEMAZuzRYsKfj/VpdmElRixZNdhzK UPfi9jp06SJZsugrpHt/2Wq2RrbnOS82mNAkybiV8dL9vJDtp9vFUIb/FtR1tyoeuOqv46qtw81W b2dTAq7SfXldqQB891hjFnKXKUFSmV0OO0n45awOZZZ3ZBWfDl1NYsv92nzDnfFjreXzLyNc9Fhu HtN27Dk3PVZo71R4PRuS2LJ8KWFKDUmQ9XKWWsXKrMWW4Qs4UtExCYXZeR3u7/zrUfgHx1J8l7bi 5K7l6MTcKaSK6yG+nIrL71AXqlNOYbBcl7MtTfjedVNZF3zv4rIy+SwH3eyxsDKTysmAgAzhNRUI HnT+xnNM68m6Es5et83ordLF5dA1eYPXVBiNnsZUhvzQky4DJrJsvRofqbzANIuT3Ajey7xRA+jS +ycmaBrjvGoYKs+9z5LDrR6gAvavUOe7bp3p/tMQpi7QwjVKpkbLCNquxeAfv6NHj+GsNLdkQb+u vPz8RHzTf+ttmUxcJ/zMy088RlfV7XJhmWrzIyoqz9NnjjHXCs6hpvIfFl0sJ3XbEj59ZyrRzaUY fvMcQzZESp3AIUYN/pHOn73DCyqv8k33LnRZcQiZmNih+R0qjz3BG4McpC4lC7vJX6Dyryd4f/Fh 6qvPsfynjxk9fSYDfvyW3n2GMkdvO+eyav5LmzeSuMeQQd/14rtBqmhpzuClZ1/i2wW+VNTdxGTx EN7+lwovfdqNXl37s9jMXzFnruE663u+yuP/eo4fTQJpLj3NnPee57FHX2fGlvYh8azjOjyl8g4b I5QHm8vxnPMLXbt+xfMvvMjrn3xNr28n4JGs6O1LT3uyYbEag7p1o3vvgajOXoGtz9WWcyuIdNZn WO/udP+uLyNnLsPySIxivl5lCg5rhvKKyuO8/mlXevfozVhNZxKVO+b8cFTfeI63FxzuYIUkl1F8 MUqTeRMG06NLf8ZOX8GBKzKFU0v0Pism/NSLXt8NZZGeOevGfsvTL/Vin6yK5Z9hzZyBvKmiwitf 9aZnl0Gsdo5QPAjVpHNAawb9Jdt2HjQZY2srRvX+D48PNSBVyod5n1cYZnedoihdXvr3EE5llWA1 uzffLDtMacBKVLpPQnPGSL7t3pWeQydi4BBCh/GEmsvM+ugFvlBrF5GpAc6M//g5qT524ZBMe+cc Z8jHT/Pka5+j6R2Hm+ZAvl3uLz0Y7ZfK7gsc4jPxmj6Yd361obg5EZPB3enV5UOp3r3Kl917MmSy LtHKgrvqBut/eJcXhpi1Da/XpQYxp++/UXniPebanic74Qgze70g314pCfjUozr8Onw4s6eMpHv3 bxkwZDLLnYMpVVYz17fxjmTDKYeVJpHk+vPDC4/zkJSX9Z7XqIvfw0cvPcHDKj9geVL2oJrD5rUL GTNsAD26d6PPyJkYO3tyvaS18vkyfmBfKawXA0ZMk9qNzdxs0cIl530xWjyNHl278+PA0cxZZsqJ m4oT02K80Z03me+/702vPn1RXWxBcJzMwlU4Dv6AJ1QepeuyXVQ0pLCuy1vS9jMM1z8q1cFKto/r zosvPcdz735N7287M2DUVjKUy6z6AjM/epEvZ+1ue6Arurwf1bde5u3vVZk7cThde/zAkHGL2XZW MRM854IXS0ZK5dbtW8bO1WXTenW+eOkDZrjGyoWx1g/vMGz6bAb3ldLbaxBqUj7DUxXqvDLRi1Vz pjGk/7d07/YT4+euwc07tsNQvpfmtzz+7iRCcpSVaRE+K6fzXY/uvPXqYzz1wVd06baIkxnKbeNV NN5S4d8zvOiofSs57WXGxH4/0KPXUDTNPMm9x48jZPvpM3OtOVv3HCYsLvO+vawCgeB/wz/irfzK kmJKlNYVb64qIiMlicTUHCobG6nISSe7QPFIXp6XQWJyCtlFkkxsric3I5XsMqVGtqmCzOREklLT yS2qaPeuNVaTJx2blJROcXUDTTWl0nHZUofzW61oAyXpqSSnZpIvXU92ZEN5AelpqaRmFVDX3ERl TgZ5NVJIfRlZGfly70RVYTY5hdU01ZeTnppCSlo6mdkZpErpSsyVdRPNlOZnkSHFk5ReLHs/lWIp j7Lt5DxZs99EVWkRxYV5pKUmk5ySSWnNH/UKawMFGSkkp2VTXl1Leb4kJrJl16ynIDud1IwsMmV5 TkqV8lDZ4h2po1Dal5aWRnqRVA7NNeSmpEjbGeSWtA+fNtdVkJudT2UHmzZTnpUqlVkqmZmZUh5l Uw8yKFcqstqyfNKSkkhKSZPKuZS6JuXza8mX0psknZ+VX0pNQ+vEznqKciWbyuKUpTc5mfScYuo7 XLqekrxc8m9Zsz7JcRSLQ6R8VOVLZZJGTrGy4JfymimVS3I6BeW1NDdUkJWaRoksvU1SvrPSpGtm yfORJNkot7i67WsSTXXl0rHJUr3NplI6vq6igGSpnshOrSrKkWxVJ/dCZku2r5KyUVOST7ZkYxqq yCsuledHNi0jWapHt8+QaKQsP5eCspq269VXFkv3iawccqmS9epNtRTnSuUp2SKnsoG68iLyZOUl pSA/I4PiOqmmSfU3LadUiqOewtQk+X2SnSXZMSWZNOm61Y0dr1lRlC/lsap9V32ldHwmWVJdzSqq ldfxLClu2XaObMpFQzVlZSUUSnlJSpLizCyg9taqK7sXs3IoVX5Vv7GSdOm+Tk/PlPIo5b6uVKr3 qaRnZFNc0VJZpLLIyUiV2yglM4/K2o5SpqYoSwpLlsonl9KqjhZsqCgkOVE6Ly2LosqOXrk6ySay /CenpFNY2fZ9Bkqkepeank56nsxeDeRLx6RK6csuVEizkgzFdmZ6GinJSdLvEhpuuddKbymzxpoy qfyzKK+R7r28TBKlOpRdVN3hfqksyiZFymNmfjmNzQ1S25BBdkmNPKyqpFBqF/KldkVKr1RHi6s6 2qCuTBEmq5vye+kWtVdbXkiOdB91uE+ku7xCqjfJMvtL939WegqJiVIdbril/uVlk1d6hwd52b0o 3RdJyVlU3kcz1VCeT155HQKB4K+F+I6pQPAH0liRwb4FnRlsfpKLV29QKPpFgUAgEAjuGSFMBYI/ kNywbajPnMm0CaMYobGRgORKYRSBQCAQCO4RIUwFAoFAIBAIBA8EQpgKBAKBQCAQCB4IhDAVCAQC gUAgEDwQCGH6T6S5hhhfF1avXo3WhoNk3eXDASXxofhfSvtLZ7Uw5jC62mvQMnUiMOmfvTZhTW48 4afPU1b/x8ZblxaBzTpt1q5Zi+F2P7Krm/+aBvqzb8PabHyd9aT7cC0b9p1BWO037uNYf/zjC/7w eBMDt6Mv2X/tqrVY+F//C1rmn0PxJV+MdNaiZWjDsetl935iUzVnfDazRurv1m7w4M5fF6/iqm8E l9LE+rUPAkKY/iOp4/rpY2zfbcLwR4fjW3Xnoy5ZTeQnHY/7ijk/yAb7M0UPTE7LEsLY7ebCIvWx THOL/9OuG+q0mpV2IVw8ZMLojT4PhC1yTlkxcc4q4u+jTZd9QF7L4cTdV4lquMa6OWvZ5LQVt61b 2X38DEW1QmLdE/VFnD66l92ms3l0gBlVwiJ3JVq7Hz9ZRtzfSVm+LNx86e7hpScY/ssKNu/awbbN Luw/ly4M/UfQWIz3ES/8E0r/0GjLE6Nwl8pqzbxfGW53+d5PbK4jPtKX7XtM+PWhXzlxxy+lZGLe eRp6+xPuJ0UErnLmXMXd7u8kLGdo4BKTjr+9DnrbL/AH+wT+tghh+o+mErfOs/G9241FE/WN9ycy 0rdNZLp33gOX07MehszbdvVPu56X9jC6LT5B7OYxPDN3zwNjh8bG+/zMeGkQPWY4c1dfVUU4P85y ufPKToJ7oyqYzlM2UyEs8Rs0dFiR7Z64YcN7c4PvHp7iyAfzwoRp/2iacjHbZMqWM/9/WoWbxzYy 0fbi/+HMCly/VMPvbmveNDRyf1WsmK3fSP3nXZ2s11n8dHfMzuWwZeEYhhtEi1GRe0QI09+gMu8m keHXWjqMeumGcGLidx/zxFPP8p9OPZhmG9i+DGhjHiG7dOj79ks8+eo79OzZmaenG5Eu/7Z6DVcD nJjU/UNefOZZ3u/en0/HTGLHVcWHrzPDNjP75+68+exjPPfVUBx8E9pvkLJolgzvwztPPcXTnXox pPNTvGmXpAirSWC77kzee+wJnn7rU37s+iYqarvuI4f5OH856zZhWl8Qwuz3n0JFRYUvtI7dck45 nuum0/ndF3jq6ff5YdA3UroN5cMjDVf28O17j6Py2PO8+vJzPP7IZ2jujms1EKmhe5jT7zOeffYF On3ShQ9eG4ntyd/zUjRxfMW38rT85+eNFEm2tHxfRdr+kEXam1nw7b9R6fYLwz//gF5T1qE/fxgv PfYhSw91WCOH0L26zFUSpqXX9zP4Xw/z2fClbNQYzguPPclrH49m++nW5UGriPEyYfDH7/H8M8/x ftfevDdMlV3x1fdk2VNWMxmoHUnKEQ0+1PZW2DU1gHGfSWmfuFPRrF3cTb8XVfhoQ5B8uy41kCkD 3pby9gKWZ27gY7WYLm/9m/emu5N12ojnVJ7mpymrWKbamycef4b3+mhyMqnjx9Or8tOIT8q7ZZWb Qky7vijF+zDvjjEg5VbXXF4keurD+fT5x3jm/W5M3uChqPPNebjNHyCd9xAvvPwyLzz1NG+NXsfl YkXzmndmGyPf/JcU/jgvvizVh6c+Rs0orIPnr6m6iBvXUyipa2+Sb+6cx5Mqj9Fv/lpm9PmcFx97 lZ7j1nA8QZGX+ht+aI7/juefkOr86x/xw3QHUqoV+UvYv4GeL8nKfxFnMkIxUR/Ia499hIaXbG3W Io5azuWr917n2Wee5s0+amwLUKzalnZghnTOy3z/fR/e+3o05lv06CYd00XdieRahY3clozmy7dl 9fpD+g7+hk/fc2xbQ16el9piUm4mU9j20fkGLmxdyVcPydIzEFkKfJYPkNfVZ2bvxMfoJx57qhN9 vv6at/vMxt56ER8/9Sq/bDxCB6d1gR9fTnK+ozBtri8nVbpmbtuH4hu4tHkeL6v8izEbLJg96Cue /ddzvPWDFoktH6yvSw6T7PIzzzz7HG98+BVd3v2caQ6ht3TCZSReuUFBTdvyDRxd0kWe9l7zD7as yHaBac9IeXtyCLuuVVAU4cjQXp/I68ETb3VhxsbjKFZWPcSAd6TjBq/AZvFwPnj2UR5+8yfszreM nDTmELRjPT+8+QJPvPg2301VZ+S7T6Ly7Lz2JXZlC3MkXyMpr+P9VZbgwYR3FG3RdzbnbrFOPaGO qxjQ9UOeefxVvh68AN+EFtVReZapnV6SznuSV159iWelNvIz3ZMt59VxZtNMOj0rpfmhp3n1lWd5 9PFBbDn/+0KqsTwex3nD+OitV3j6yefpJtVbn5vtC2iUJfqyYlQf3n7mCZ76ZCBDB37McI/stjbF V7qne3/0Kk88+QGDRn7L+y+ZtAwtlxKxbxNDu73L40//hy6DFnPgassDfnMxobulvuXdN3jmhVf4 tEtXXh2tQWCmosATQxwZ1/VTXnn6aV77+kc6D/gerdCSe2qn8kK3ofqD1CY/8QIfDRjMT69/wY4M RXkkhOxj0fAu/OuJ53nviwEssvST93c33BfyqMorjFikzfyhX/PYYy/wyS+6ROcq6uiN/ct5SSqv f0nt/EvPP8uLn/TF8UJLT5l6gA+lMJWvBrDleCjuBjN447GXGW0UIF88pjLWiwWjv+ONx5/g+U++ ZbKW221D75cPb0D1/yRM83D8dMZtwjT3pD7vPyq7hz9hw7Fbpq5VxbJ2Qn/eefJJnv6gG4O/kfJj ovDWXnZZIF9h7vEXX+bl55/i4bfG4R6v7CVOx/CDgbjEl3BIfwFq1rHt2qIgiYvnr5JfjeAOCGF6 B1LPncDV3gwTnZXMNjipWBJSariL07OU1qPPYuk4I8ILG+RhcXusWKC7t91zlHCQsfrbyJOCy+O8 WDnbgDOtT1bVV9A10sHrpmwlm7Noqutzrb3pY8eyhey4qej8Ml1/5RvL9sXlG8MtWOCruFUrA9ZL T/w7lRLuxWy3yPvI6Z2FaRtnrZnpEthxX8Fevv7MQGloNwadeYfa8l2yX50Fp+7wSNqYiqH6cqyC 22/cAIfdnIy7x3ljuWdx1LPjxFFX1q4w5XKrco+34vWlvjKjsnHxYoxlC32XH2Js/10oNxG3ClMZ xaG2TJq1mtal3VPdzdCx9VGUd8F5Vi2fx/62ZewL2blnG+EZ9fJGO9xtI8tXr0VbWxttrbWs0jJk b0hGmyBMCLRH1yuFsigH1ngqDTslutFJr13s14QYMHFrxyHKOO3+9NO05ki0ImFpVxUiO87ZgBkT bbnZkvdAG0MMnC4oPeWXcmhBd1ReVyPlTjYsCEXf3o6bHZ7w07FdsoKDqe17btiuYElAS6dYF03f hXt/YwjqEoMW7+Zu7WvOCR2ekB4iTM+WdNh/zfYnnv91M62+9YZrO1D9dQPXZJkpySJdKcJTC+di dVrZC5/CwteGsMp1DxeKFWVzOaNUPmSXn69U6ul+GCy0IFleKNW4Th3KESm42mseXdaekNvLzGIt 7rLbK8uVb7rb0lZz68LQWXKsg4AsCDfm/SffYc3R5FtymY2boRF2RwPYut4U7wstN1T5BSwXL0LW HeVY/8j3W7Ll9/ssY2suFSj5Zn5DmJZf3M7Xz77DFLeOQ9KX9X5hiMHxtuVAfSePxOpynbz9iNi4 CA2b8PYy8N/B9sBbprFctedF6UFnWUDHdefPH7LCxqNFLkoPJrvW6+DXos5rclM6TOlw7juaw603 /g0HnvllHVdat4NX8bGRIg2XtpuhoX+gLX/NN3bT87FRSveWjOsseld6+FTzueOUhoZAbSbvjO2w r+qsFepaAUptzGmWzzSlrbXMdeWLFTF3b1OKdvCJ5rn76hua6ivIzWsXotURZkxbdLJlJbV0jIdM Yuv19rHikxbT0DiqqLtZHssZudqvffWuIi8mfOeETL7nHt3CAvPj7RcqC2CuxjZ5GKknUdNcRUhb BUnCftc+rsoCmwuxXz0Wo3PtD34n9lpJovYevp+ce5RRI1dxvu1eK8Zl0jg8pPJuuLyXWfMNOdP2 ZFaJ79q5zDmUKN8K2bCGWQt3tNy/TezV1sfeq9XyZTg7O+F+/W7+xwosdKbx6xwLwtMVLUt+hvQw nReI6shFhCjd6vGu8xm//nQHT+MfLUxbiV5hjIt/Uscmc/cEPjdUutZZe+Z5tbauNbj30eTuPndJ kKoZEl5aR5T3ZhwC250wZTeCsdVahYGxKZZ7A0gtaUDQjhCmytRdQW+cBvrO2zhwNJir6R0n49Wn Sp3VpAF81bkbfXp9yrPPTCOgWFHhbQxN2BqudEfVl8mXi5Q39gc3MsdaqXI315OXm0Wp7G47rYPK I+/x/Q+96dG9O716Sk/RH73F+L0tlb8oGM0Zqgz5sQedO/fkF9XVhOS03KaVl3HcuIwR/XrwTece DBgxF8ew1ie+ei5v06J/12/o0rUzX3z1K4b7rtwiMH5bmBb4GzDVOeDW1pxd2osYMbSvlJ7OfDNw ItZH2+flpLhOZsbhzDt1LVw/uYeVM8fQpVtXuvTuy6T1u0govfdZN4VB1nzwTBdM45Ralkh9Opmf lefF0MSCPXFSt1Z4BLU+bijPdL2TME2UOmHTHQFtwi7liBWGLkepaWk8Iw+Zoz5mED27daHnd8NY 7XyCvJY+J+WMP96+fhw/flz68+PosQBik9rrS115PgVl9TRVFbUs99hCrB3vbDjaXgJHtRm/OVwp VU0Ezu3L2vCaW3JfS5C1HfaucW3bIba2WNmdV/KO1pN1MRSP4+fv2LlXX/NG29KmozBNP8KXH39B t9696CnVvx69+vDtew/xqEaLd6kokN4zHcm+W6EUn+IHNQfS79IH1eZdw/fQSRKKOza8pzf9wpJQ 5cleZexcM449sn6hOY3d6ybz+Ved6dmnu1Tmn6ATovwAc4YZry/h3J3q2Ak7xgzoI9Wx7nzz2ZcM mmJOSkNLXZ86kVNSJ1zqs5IpeyQ7Nqez0VKX3fF18nvYeekshg3+UarX3/DNkBm4hXSsx3WFCfj7 +HM1507WjaXva88yzupsu71zIrFdsQ5Zrct0Gc3cIOk6xWFMMnbgYoGST/s3hGlDWTqnjvpzLk25 LWokaPEYHK6315nQZWMxv1DbUs4BmK2Yxc+du9C5Sx+GTtYj4GZJx4jLk/A9eIy4/I4T7mqkc9fo WhEn3ZYFgWuZpBfavtxpTgTrpv7MV990lcqlCx++9D2H89vvww8tzioVsBHvGssekgvZpGfKjmjl 8ithx8+a7I5TfnSs4KK/F8djc+64pn22hyaq2zsK0/BVPXjkg+788G1PunfvQa9vO/Ph233Y19J0 cs2GD+cF3L1BuWHLe7P9b99fn4nrsil0++obunb+mq+Gzmb/ldK2eiqbPz64Tze69ujJV59+IQms k4oHs0xXPh19uGP9L0ohpUh2cxSzvfcUPDsUQyVJ8Xny/16zR/H5+59LeZDlpSff9fkUFZVBnJRH XIj/biNmjBxAty5d6P3TGDbsCqO85Z67FuTAvAm/8l2vrnTt1o8Fmw6SVNF+jYMbR/PpF53pJusL uo/HM6VlxGP/XH7ddaNDektTbko5bOKMqTFWu265wzJ28K6a7J2DOg5pWbPzWOvTbCle2pZs9WiJ qyEb802mbI7MvbPdK26yfuNKnGI69q9F0n35y+aztxwcx7IPVqHcct9ZmEr93dbV9O32dUt/NxyT A1dvWcL3t4RpJX7zNuB8oqMwpTSCNXOmMvQnRf87aPwy/JJb2+YCtnabg/ddX6lopCQ7l0rJ3DVl BRRX3DK5tbmajMthuO/bjsnK1WxyDhfTeVoQwrRDK3KWKe+9xUDtfdwovWU2SIofM1abEXYzl9LS UqoLIln600bCShWN1X5dQ2wP3vmtzoSj1mhq+nGnOdfN4Wt5e9kJKmrKKCoqoqiwgIKiEqrld1Qz l1wt8Eutkyq2FFZaRm7EJvoP3S8XT+n++zgQnUxdRQlFJaUUXd3HgG+N24Y+6suL5OuMZ2ZmkJ6e 074meHvvhOs3c/G/y8Na+SkTZrh2HAJsvrofXe8bNNWUUyilsyI/ijX9J3Gypd1Odplw5zmm5cns 9/EhLqOY0pISykpSObxuOQbuZ+6tbGpuYK67FlOr9Qwft6XdcxMlE6bn5I2OgbE5e69IlinwYtaP uzt4u04fNGTBrsQOUab62HYQpum+9phu95d3jHV5cfgeOEJiUaU8vaU5l7DQXI/z8TR5w2w7/D/S A8UTPP300zz91BM8/NQ7TLaI+f3J7TE2vLHBr20z31sL1W3RHQ45Nf9Xttym7RsIs3fEfuvltkYv wtERu833/hJAc/JxdOwcSVOuiCkH+WKOLclSWZYUS3WsqJCCggJKa1rkQWEA3ac73X2OaVUkfeds Ifc+b7Uok5/o55KiXBrYzlAjsiADm5lr2RGVSHmpVE+qs/FaOJlNUcqt/3lmdTLn1lqWeNKJZUt3 cqNQOq+slBsR+zCU7tkUeVby2TxtIiFS9Sg5slwSpldkJY6+9UYOyBygV3dhIJVtQ3UZhcWllGQG s2KgOpH3uHDX6Q3SA5mZM9raWhxVXJD6XIUwlfkqMzaPYs6pepmbnsmbnLhSrNS+lAfyzTRX7sdn ErZsHHZKTtCIFROwkffeFYTu8yY8PpMKyX4lZcUkeOrRz8DjHue3leCx1og9J7zQ7j6bk619cGM0 c35axamsYqmeFEvtVTJOI4dysLVinDXmQ3Ole/mcCR+YyURGLQc3GGHvqdw2XkXzw+m4Xb73N6CL vFe2lFk7oSv7s/xEjtQ2FsvbzkKp3haVVrbbMd6S9+f9xhzTVCc+mH/qDgGNlBfmkSFrO6W/9Ox8 KusV1ju3bS5qThEUSn1AaXkFl46Ys0DthMLTXuvHr1+b3eWt71pOqA/HKLbujjY/MHs91lJbWFJe Kr8HC+X9QIW8zCqSz+BzJIDMkgpKpLaoJOM02uo6HIgplNfrk25uXMqvprykmLLidPYaaaHbNpLS TGVxjtT+K/qBjAxJKLUYqP7Uer7ccGf7XHUzQHvzyY47o434aPUJeVvks96WHb6t928lR3Wkbe+W 7YYsTE1M2HLLKEkbdWkY2htxOKVjjawNN+Jzbd+Ox1b7MUayqfLErOu+G5nidO32aMsLO/R3JZW3 tsZluHyhTuAdE9VI4EJ9XIOVG94mruyyxedmZUv/W0r+GRv6DdzR0rcUsPkb9d+YY3pv5J3exQTp QW+0lg9lCGQIYXoHssJ3MGvMSKYsNeVISLK8cWi8eZRF2vocOBlOVHgwe03VeOXpH9A/fEUe3iCF L1myEtfD/oSHn+LoDhMm6O5GPu2m8joO6+eju/kwoWFhBBxxZck6E07crJNX7i2qk7A6HEpUVCSR EafYu20L3qdz5Y2K39RP6K97gLDI0/LwgG2rUdVXdACXLCbx3YwNBEWdIVIKCztoxpB5u6n9vQw2 1ZJ65QzhZw+x6D/9MfANJez0edJbviNUX5xMxKlQDptM5YdFpoSFRRBzpWXeYvByVH5cxYlQKa2R kYQH72T56I1cadExNVFG9JxjTWBEOGGBPmw2sCRY5lUpOsf4GeOYZ3OI6NNRUj79sJaE3raAG7+T 2BqSwn1ZM20Y860UT/AZOyfwer91nEiQGtlQXV6YuVveQBusWsIa2XBSnie/vreG81LBVCZfIjL0 FJZrJjFwmSshYZFcK5Ds3lyAr+5MJi7QIzxDslhdliSUpW0NQy4Wyebp+aAxtB9G7kFESumNCvRk nbYxnrGF/13lKgllzIhlHAiWbCc9WGh0+4QPJ21SDF3Xl3L92ikM+3/JvJ2hRJ4K53JSoUJQlMVj KQk3tblu3KiSkl90AZNZasycs4eUtrfgy/BfP5gnv9akw8zdhiKig0Pw267H+Nnz2Hk0iIjTKS3D 77VEai1g5eajREt1KCIynBMHtmDl3uKRaEpAZ+RCLD38iQw7hc8eR4wOKOpfQ2U+N49u4oN+GrgH nSIkKIIrySUdXiAoCLPkg5d64XShY5N7xvgHnvhoBi7eQdL9EozbBjXmuMiGAlPR19iAo3S9M1Hh +O01pt+LHzLO+Jh8hKGuII0rp6z58dmp7I2JIjhEqrelis4+4YQD8xY7EBgVzelTR9GZ+BNfSx2H 9/UK+X1mPuwnXCV9VHR0KX0099Fck8F6rTnonyqgzm8uKgP1CJDqh+xeCjm5lRWTLFCuncVn7en9 YTcM2uZFN5KbfBbXxYP5dPZBxTGB1gz9RRVnr4vkZEWgO2UmJyTxlrFlKH03xUp1M5zRC5ez/5Ls Sa6UKxFhnD1syH++W4RvRASnzyd0+JxXxfWDDPioG0vc231GtcVXsB7aGTWXEHKrG6nKvYDVkC7M 2hotm6nJtrEzmbLAntDoKE5HhnHIejUL3E51rIc3dvDVY++wIeIO8ypz/Bj5+cdM9FCqRZXhTB6u jUeoFKdUDw47a/KJyifonUikSnpIjXWZxtNTLEnIrKK+tpCzjlN4aooF8hV5U7yZor4Ai11HCQk+ weYNqrym8gPbril7npPQ6/MyXyw92WFaSFVuAhGhYRxcP5w+y504ExHFxYRCRR0rPIbqmPUcDpfa Rsl2Ead8cd3iSnR2S2NUepLxPRezLzhMasMCcHcwZOtpxRN0WXoi53fM4dkBJoSeCycwIIbM8t9/ NDi9RQ11cy8io6MJP3lQEuud+OBHCy4WK+rgabtpTNfZQWCI1KaGncBCex66x1ukaskJxg5dxI7j pwgPDcXffRPqqq7yecxNCftRW2HMsTBFuyprO7eYuhInZaXkjCvTRo7E7nAIp6NOE3F8D0tXSe1q itRuNV5Fq/8XLNsm3Z+RUjslXdNy43rsj9/LZ/6K2DVtAqtcj0ntotReS/nRm6nGoWzFfb9RYyn6 W70IjQgl0Gcr80auIFA2lakkFp0R01mgdZBMKdt12RFoj5K21x4hX94UVXDMzIBl610ICg/j5NF9 2Gw7yLVCqdQaCzl9yJWJsyex1s2P8FOnuFrYavdSDs+dxGL7w5yS7BPk74HepJFYxyvCy5LjpL43 ki06qvSet4VT0u/LmfegCptqSImT9XeeLHylL0bHI6T+LpaMMkW8RUnnCYn0xWjQRBYZ7yJcsv/V lvmyQfM689PaHYRKbYqsXQjaocUY7ZCWNq6OcK3JzLXxIly6jwO9d6NvdJB7efW3viSdUHd7Fg7p y1jtHSSLT3IIYXrPGuJmAJb6vm3zJ/NP72fe5AlMm2uE3+VrRDroMnWSU5sIqEsLx3TeFEZPms5K 68MkFbc/HTeXJrBbdxETx45hlo4rZ1PKlMLicNNdyrRxYxk7aSW7A2PJa/kWZKKXA/Y7trNh4XTG jpmKpuXRtoY7N+oQbvv2YL5yFmPGTEJj/TbiS+/hrev6Ig7bLGHU2EmoacxhxqTxjF2gg2+CIk3l lw8ya/hoJs9QZ47adMaPn8o6mwjFfLbUk6xx3MnmjUtRlfIyYfEmznUYymgiZqckgEaNQ22xLrv8 LyiGJ6qz8Dyym+2bzVCfOIEJ0zWwORZ3Ry9yR7LYpj6ZsRPnY7nztNxTfGWfHpNVVZklNSJJ10+h OdeS+Io6oneasMg5iIbyOIxna+J+PZfr7iZMmTCB6TNleZnC2BEzcT5TQHPeaczmTZXimcRq30Tq b/qhPUmViRPm4hglNS2VSfjusMPZciPTJk1gyixtPM9l/SH1quLiAdR/HcN87a2EhB5i+awpWMZI PXhJHOaSUJqkNodZ0yYydrQ6Fvtj5R6g0lh35kt5nqi6jH2xpeSGO6I6Udqeosex663DjNVc9LBh ge6+DtMYqIhl6egxqE6dgfqsWUyZOJqZCw8qeXYqCdhqgPqYMXI7b3Q6TEKR0uNNbgQbZoxn9BR1 1tl7ciFDUU9KE06ycdYk1NXVmDZZlbHj5mF78EqHB6Oy+BNoLTEiIK3jLNQz5r+yeJ8kSHU0JKEu 5dNTaQ5lXjRGcyYxYdpStpy4wM2I7cyZtoyTeU0URu1l2dRJzNKYxbSJ4xg1Qxff+OLWG4nQbXpM GzOehXq7iUu/yvYNC1m367RMznHUch02fmlUph9nwQwDLpZUc9LFmA27z1CRcIy1Dm7YrV8kiZ3R TFphx7VbJs5WJgWgv9oA3ystDyeN5fhv00F1giqqmgfldTMjZB9rp6syaoQ20bnp7DY1Yf+FIiri dqE+dwtJRTnsMFyPsV+SpLquYKMu3fOTZ6AxV41J41VZoONGgpKGr8k6i+VafXafaa17jSQf28Ji 9RlMm7UYjxuFXN1nydxpU5k1W4+o/EquHDrMvp1b0FJTZcyEmay1O07+rc6j7DC0563D6/odXMJF gahNteTmLU+4ZVK9XThuNFM1NuJ1MYVLBzcye6UD5y5HYLBaA7UpU9DeEUdekj/aC9WlOjwFff+W dBddx33TSibN1OPIlXPsHb6CvXElSrHn4qGviZ57xzYhM8yNmSPGMHnmbOaqTWXcuFmYuLVPVSmN 80Zn8SzGjR3L5BVmBF5IQ/kzuimBjmiMH81o9RXYHQhBMXOhkQRPK9SnTGP+7BlMnjSOkWN0OJF4 DwOptWm4Gy5i7MiZrHH2JzM1HMMJC9jsd7NlCkIlYds2oi5dc+RsLQ6f7jj0UZN0Ar0FUxk9eiar LA6SrqSFqxOC0Fs4lbFjJzNvlRmHIm7K7/2azAt47XRi8yZtqa5Jbdl8ffyutLiqm/IJcrPAyd6M eTMmMmHiIrYFJ3LP395ozmKv0VLGj56A+gpzTip/H7QmhQPmq6S0jmPGYqneX1eUV1qIG/MmTUR1 3EqOJVZx45gFkyZL155kREROS+lVJbNfildV6tPm6Gwh+HKGol3ID2Pu8DGozVJn5rTJjButikOs srgs4YiVFrOktmj0rNXsiGob/yPBwxK1ieOZKvVLc2dJdWHkDMz8k38/j3X5eFotbu/vpDjGLtTD 76aivC+4azNcyv+MOeqoTZfSNHUWdi3T8lJ8XXDcuQO9JTPk/e9i00O3fDovm23asxklC1vviP+l zHt6s78gPoz9mw9zU7z8dEeEMBUIBH861x3HYnJT2OFBJMbZDpvjf+DH5uur6Sh/s9k4UBOvxMq/ mGUEAsGfgRCmAoHgT+W6ywz553/kf5+OxfOmWG3lQaAp4xA/tZbL8+pcavpj4m3MjMJw1vdtZf7E f7qxdHu0+Ni4QCC4I0KYCgQCgUAgEAgeCIQwFQgEAoFAIBA8EAhhKhAIBAKBQCB4IBDCVCAQCAQC gUDwQCCE6YPOBTueefwxHlJ5k6l6offweSWBQCAQCASCvyZCmP5FSNvnhqNVEOKzZwKBQCAQCP6u CGH6J9BQmYqX2RIGfNuZTz7pzByrkxR2WI0tl/3ak/n284/4dOBcdDetY+sl5U/oNBLrbI+N5S3C tL7xH2E/gUAgEAgE/wyEMP3/QMlNf7RGjWelQ6h85Y7aopsE+54iuaCc2toyvG0Wo+ES13J0LQdW jWSp22myC4opz7+OzszvUfPLV4rxLsK06jSTOw9F/2AUebX/GPMKBAKBQCD4myKE6R9EXUkaZ056 YLpkLH0nGRGS1HEN6tK0q0SGBBEaHs4ekzUsXeCvEJm5e/j5x10d5o5mnPXE96ry8nh3EaZyqgnY psfUERPQcdjHsXNpf0fzCgQCgUAg+AcghOkfxM19y/n4oz4YeSfeFpYY7sKq5SvRmD2DWXPmMn7w EGauClGsfJLqQo8xh2n+zdh/S5i2ksau+b1QeX/FLWv5CgQCgUAgEPw1EML0D6K+JJ3Ik15sMVnO hFGL2Xs2jdYV/Q7oDGdNSEPLViq64wagqhPbsp2BychR2J5r9ZA247/Hgm1RhR3iz9i3m+1bL9zh ytns26TJxAlLsNp2gIAY4TEVCAQCgUDw10QI0z+axjryUs7isnwea7cGyr2iZfEHGf/1q6ioPEuP WRZ4uSzhPyr/ZqHbZfkp9XkRrPv1a56WrSX9ajfWuZ4iu2Uh6ZyD6u3rirf8fWVyURFYFMSIERq4 +V8kt7KWpn+mxQUCgUAgEPxNEMJUIBAIBAKBQPBAIISpQCAQCAQCgeCBQAhTgUAgEAgEAsEDgRCm AoFAIBAIBIIHAiFMBQKBQCAQCAQPBEKYCgSC/zlNxVcIuVoiDCEQCAT/cIQw/btSepX1aoN4/713 +XnsbjKFRe6PulxctcZK9nuPz7vpkfgHR1908RjOOscp/gubqColkEVDv+a99zoxwDzyv4or1mwi uqEV/2WZ5eCyVlFmX3bX/8PLTCAQCAT//xHC9O9KcyOV5ZXUNZ1hxX/mEyMscr8GpKaykpqmOPRe n0rQH/yR2MJgJ+b94PTHPzCke/Hdk13YfONPMFFTPRWVNTTF2vL6pP3/93hqAxnVy5j0P7DMdP8/ lJlAIBAI/v8jhOmDSssapc01hVyOPoWvjzfeJ8KIz6u65bgSYoL9OOJ9goizMZyJSqauwwEp6L27 4N6FaX0uQT7+nL+ZQ2ZiLP6+3pw4dZWytjVTa0i/dp4gab+3tz+RcVmK3bVFXIg+zYXLFwnxCyI+ u4TMuEiO+sdS1th6bgMFSRfx8/HBL+A0qcW1t2b37skqS+d08Anpmr6cOnOB+KtJVDQqzqzISSQq +Dg+PkfxD79MSYPiWhlXzhIeE8ulsJOEXsqkJDeBoGPBXCuup6kkidCj4SRm5pJ4IRwv72OEnEui 6raE5GH7ododRE4zhZJ9Ao4f5YhvGCml96iCGos5F3Ac34BIbuYqLTDbXE9qXATHouMpKkgj8uRR fI4HczmzXB6cfz0cn2PHOBYcS67MbJUZnPHz5djRYK5mV7aUQSKuRtrM6tMDh4R7r2i1xZnESDby 9j4qlfU5sioaOh4h2T7Czwdvv0BOS3UsOjmvYxSZu/lg2sF7vNztJR1rOo9lgdntO+pKSboUha+3 t2SDU1xIL7nljAqunwmW6rxUZhFnOHsmidKG5g5lZn3HMrsLDcVE+0v3z5UccjOuEHxCKtNjZyhq i7KOgvR4gn2PSHXsOKHnk6W7QKKpmoTzUZw5f5GI4yc4n1ZGYVIMx0+clmzY2Gbfssx4gqSy8vUL 5XpO5T3XeYFAIPgnIoTpA0bW5ZM4b9rDzRbNUhm7nyWLFjBr5izUNWYzfswm2hYdbUxnp6EuixbN Y6baQjasmcobKvNuGcJMROd+hGlNPIv7fs37b49hg9lGFmmoM27YRNbtu9kSHofF6hVoqM1glroG s8bPZMd1SSnVJ2I0vhddhs9hhfo0xs+cz9r1a5nQt58kOhRC5saxPeitXslcdXXmzl3AAt1dXM5T iNOm4iQO7t7Gkeg7+M2aCzisMx+1BZIdZs1Dc8UchvUaS7B8HLyGMGcDFi6Yi9qsOWjMmsZUx7Py 06Jt1Xm68y9oLV/AqHFqaKzWZ8WU4fw034fSvEDmdfqAj3uOZ/W61aipzWH+7CVsOBhOdYeLZ2PV 6XaRk3Z2O8sXL5OuO4eZMxez2sCGiKJ7kBo1iTiuWsroQf0Y+Ytzu8e0uYbI7Zq8+PpnDJmzCu1l Un7mz2XOXH2CUipIPLaRHz/5iE49VnFWplVzgpny+du83XkW7hcK5FHEHt2MhU8AxxaPxfbKvaqy Oq54OrNMVodmzUZDfTpjDXwUwktWLrlRWBlpsVhtJmoamqycMYAnZjvTQbqm7eD93xSmzdyM8mar /WHSam4JKo9i/ixz4tqffKi9fgL9tZrMnKEmr/MTxhkQnVfXVhe8nc0l22swQ20ea5bP4uuXZnEs p65DmVl2ug9hWpuCw/yfefHhAay1NJJsMZfJQ4aiZnNJEV6fxG6LjWjMmC6vf7MnqmESlCoFlLFj 2WC+/mE0mhpzGas6nZUbdZk5eCDj3BR3XM45X0xXLWf+vDnMlu6XRevsCb5e1mL6Qk7u38zuoAQa RdMnEAgEcoQwfUBIDHRh5sQZLNExx9P3UruHsrajh/TklF9xadFuqQd1mW7krRR6keWDzUjpGPP9 CVOJhvg9qP9gQetocHXsFtTGeaLw3dVTo9zhR67la9ur8p/Je3RZs/00sg7bceV49sgU9BltPrK6 DFWXsbG250JZ+6nX3e1wPN6yvGp9CeeCD+JovIwRgxfjfia1/cCqaFZ2H8up+tYd9UQePERyi8ip q1Lu1i8w7ktzcmU/M47Rb91W+TzOs7tWMcn+mvTrEpM6GZMv/UravJyRU0zJaM2PTCQN0SYwS1k9 3UmYZrFluhYR9e17MgIcMbU421Gw/QaNaScxV3W8Zfg6Fc3+k9B0v9K2J/ewDp3XHVFUhdjD6Dju p0heSJnsNNfmWOtTSvFFrBYacr6hmchlo7G5eu/lXVdV1yFvi74zJE5hEPz09Nm465xSoR1ggvkR 6pUjuKswbSTe1w7VsTNYY2KPd8BVbp1FenOnNVpbAjvGV1/TYfuizjzMIuQlSl6IC0t1t5LRZugU LNQtCS+o7VBm9yVM5YQw4Y1Vkv1a7ztvhn7pTKHijqBSOfobm/lc/7j8Z37oNvTM98i9n17LeqN/ XnbLbeFD3aPSj0LcHQzwVXpSLAzfh8PO4y33Ui3XTh/ByVyL0QNn4ewfR61oCgUCwT8cIUz/52Sj 3eVNRukd5Gpu5W2h1TePM6XHa6ioqPDo4w9L/99nX44spALvaavYEpH3O/HfWZimHTehx+Mq8nhV VB6j90R3uViTUXTWjaWqR2iVxCWxO1g8xkPRmdamYLdgIM/LznvkMR6R/n/mcE1+3FVXHTYeiJF7 tbYZzuaIbJQ/cj0f2kjCNMWTX96T0v/Qozz8kAoPPfyQdN3H+UnX77YUNxRdY9vqCXw3YQUxRYp9 V4+aMuyzN3lMdt2HPmaunT+5cuFRS8zu9XR+QZaPh3nsUen/v/UUguLmIfob7pKLoaj9+szbmST9 Os/Md42QDRzHbrLCcft5pStX4TF8OdvPF3Yon9uEaW0gPWXpePIxeV5UZH8qzzNg1mFK5AdksuTV VtvK/sZx8ZY8Fl05gvGEW4SpJN7VVtgRUaAkb0v86DTOWSFYmpMwmmvE0Zv1VF7cjqaGJ606/6Tx OFb4yAzeiP+C4VjEdvT7Bur2VkrPs6w5VdoSUk9q8BYGvPWYtP8hHntMFj4DuTSuu8GyteYcuVn5 21XsTsK05iJLu3/EZJMj3CyqufN5VTfZqG+E5+WSDrvrMiLZMOZLeVofeewR6f8bbAiRPV40EWW0 Cfvtv/eYdRdhWhrPyqFvttnhmbd/xSu15QmwwpfJX7vQlpJqPyZ+7oTcF12fyTHr2bwkr/P/ktfB hxZ4yg9L99+Cid1Befkc1R2MnexWiHfmfb0T0nmxqH8u1fOH/sUj8noiq/OP0mX2Zgrqb0lbbQ6H LRbw08/jOJxUL5pFgUDwj0UI0/855exfM5Upmqbs8jjJ+RtZ7V63unB+/ViD623HluAyeAA7WxRk yv4NTDE8ohRXJQnnbtJRRuRh0mk5CfeRotr4/aya4teWjoaEA6ycpBCQxyYPYn10e4+fu2cGnzon yX/Hu+pi7CWTYPm4Gc/FV5bOyHV87HQDCiPYZOZA8i3XqmtQ9nbWUZB8ieOHdmGwTIMFG/eSLeuj s4+xbv4RmpSOs1s6HNNYKYUha/h0uZK4LT7CwA8tkcuuREmYmu6TD0tH7jdg4V6ZDJSE6QcWcgFy xXoBw6aYtg+nF4azWNWY0/nKHsQKNn8ynzMdUn0Z3X763LwlL80Ndfc8b7AhLQDrqdspVd5Zf435 P45Hc3+7xzT90Eb6m/u3becfMWLe9pP46kxj08X6tnphM+AL3v/wIz7/+kvef+4xXv36FxwuVP5+ Os7Z032+s1LhR6D6xcYWb3m5dB09Nu6Ibg+vyeXCzRw6aL5iDz6efaxjxE2ZbFsxnVmrLdhzKIAr aQW3DVdnRO7DyHBn2wORnMbLLPx5Cb4F7WXtNWcSFmcVvtbcYGcW6WxR8pjWkXo5iaK6pg5l5nxb mf0eQczssoP28YlTzOi8U+65jV6vLj3UtJdJpf8G3tkYqMiDvwvmzofkeTuqNwQn2a0gCdNOxkHS jzRcjNYRfsunFxobG5TqSROlGVcJOe6J5YbFqC+x4XKJeGtLIBD8cxHC9AGhLuci+6xM0TMwwtp2 H0lyF1kqDitXM3+eBpordbByMGbsm6/Te54TV2SusuY0XHW1WbxsKQsWarJWS4vFmrsVnyAqisdl kxZLlk/ic5X3GLNwMRpmUrwVvzObrTaBVUO68sZzQ7E9eZOm/DPMGd5d2h7LzvMpxO/YxByNhSzQ XIGuhS1Gk75EpeskDiSUcHPnYrqNsaKwuQDTSd2ZvfUqDRHrpfAlxJfXcMZjC+tWr2bhokVSOpez Ts+EbacUEqipLIkj2zdhoLeOdTYHiVdyKTXe3MmPKgNYZazLisULWLhgNRvMN3NRplVSD6OxQMrb giWsWm+Go6kar6h8zkq3y9SkefPF99M4mlzHWWc1PhxvS0ntOSaqdEYnroD4LWsY9P0olmutYeGS JVK6VmHlG6MQUDU5HHbSYdGyaXRTeZNhGkskoexEdJZisDXumDFLlq1hxfJFLFgg2cLACnf/S/ye FKxJDmL9muWojR/AN6/1ZNqC+cxzDmmx/XUWqY5iqJom2osXslQq14VLrIhMUR4Aj2fhLx/TeZRr R1GrsBThRx2Z8PFr/LjIivCs3/e8NWedQnetJnM1FrF8jTF25kv4+JEPUdX2VdSjnHDM9FajuUCD hVKZr1m7hmVu4XJhVZEchs3KxSyf+j0qb/RlwdJlGG0LpFBJ11eln2WHqSF6hsY4bD1MettYdTU+ VouxOHGrxz8X9036aMyZJ+Vfm002ppJg/IzPfllJtNyRnc8he2M0NWV1XirzVVpoLnflemWT3Ot4 yGmDvMy6KpdZdvXv3HxpbF02jOdVvmXj/hgqCq5itnyItP0DlifiueG7jRULF6CxeClaptaYzeuH ygffYX+miJxQKwYP1eSCVGkOzPmYQbrhVF/ewuNfjiU8v4mk0H2sW75Kqu9S/Vq8mLW6Jmz2PUel rJI1FBPivgn9jbqsMtrKubT/8nNZAoFA8DdACNMHjKaKHC6djqHNaVeRjN/+fXh6BxKXVUJZSjSH joSQ0eraaSokyu8Q7u6H8Dt1gZwahS+muSqXyABv9h84hM/xoxw+6I57QIwkGn7HG1OfzfEDHhw+ 4ktkXC5N5ckc8vDEy/sEMZL4lL1sdCHwCHs9jnDqYhq1ZRn4HPHidHoV9YXXOXZSJs4aSToXQtjF LBor0jkmpT1Fnt5q0i6GceDAAQ4e9iE0NpHiaoXrq6laEopxF0gpvoNwrs3j4qmznI0MxEvKx0Gv EFKUvEqF8REc2HuAo4HnyasqJeGED34hKdQ1lnD6ZDgJUpzVGRcl+5yntL6SeP+jhOcUc97GAefN J4k7F8z+g4cJik1r/6JBfRkXw31x3++J93FfvDz24+4XRmppq9irI/VCKEcOHWT//iNEXEqmqOr3 Z5g2FCZw1MsTj0Ne+Ph6c+jAPvaFt/heq68wW8uWk1euEOp1AE+fIOJzq26Lozg2kOCUqjuUXSnn w07g6eUtf2P9csG9zXitSrvAof0H8PKLIq2khPSok3j5XGqbD9pckkLQoQO4ex4hSOaRbymi2sJE Th3ez4FDRzjue4SD+z3wP51A1R2KsK4wjUvnLlPUYr7m/EA0x5hwx69aVWcR5uMhxetHTFIeZVmX 8ZF+32ydt9BcxpUwP/a5e3D05BlSy+rayyzsqLzMfNrKLFwKr/+9QiHcx4fD3t4ER6dQW5HFCZ8j kg18CT8vm9taT/KZAPbK8nfmBuWluZw6dgj/hDKaKtM5FXSOHMnUeVdCCYhIpKYqnyAfPxTrBTSQ ez0ar0NSfjwOEXjmGvnlLeq8oYqkK2e5nlcjGj6BQCBoQQhTwT+UOsL0jDB3DH9wXjgpOcukRaac SCn721s/w3sl8w9li2ooEAgEgg4IYSr4R5Id5sSITu/x0Wcf8OYb3+F2/X88r6+xhN06qnz64Ud8 +O5rdBmw+Q/44LxAIBAIBH8thDAVCAQCgUAgEDwQCGEqEAgEAoFAIHggEMJUIPgr0yQWthQIBALB 3wchTP+u1JcSG3ESTw9PAsJSqP475KmmgLPXM6j9K2uxqiwCjnnjefgYZ+Ly73mlqNupJcJzG9u8 rvzXy1mWJ0bj6emJ18lIkkrEx90FAoFA8L9DCNO/K5Xp7LLWRWPBr3R9YiEX7ufcumLOhfpyveQB U4DXdvD4YG2u/tGv0Tens32TKUEZdf//81Bwno2rNZk4bCCjfnFu/7j//VKegN2aFXj8AasEZQVv YZ76NHr2/4WlXsn3fmJDMQGnIrmS97d47BEIBALBA4AQpn978jB6//YlSX+T5nx2WizhVPmDl5uU 3JL/wst4Z5IcZvNxr16sDCn+0/LRmHYSc1XH//Ob91lRdszV8vlDPeHHd29C+1DifZyRzXoTR/wy EQgEAoHgD0EI0weOJiqK8ylvcd7VXjvM+N7vKdb3fuZjVM2DOxxdeWkfA955XAp/mi4//kCnl1aR 2uGIRHTevT9hGqDTS3G9hx6W/3/yhcmEyb7nnnmM3u88Ie37N1rhim9tlvqvkB/z0WejGNBDSme3 WbiYz+XjZ6XzX/icOc6R7RGXXMVt5Uj5WuOPv9KTNXtj2oRVU101pSWl1N/RSVuB06xPFGn6VktJ zGWzZYhs/zDMnLTp/uaT0u83UTU+gexj/nsXD+Jh+broPxMkXag00o5uL6nI1yufdbxIEcX1XQxf 5cnh3ZosDyy8ZxvFH9Ljx09eU6Tp1e+wP5XTITzGbSlfv/qoFP4a/cYMoH+fnRQphRddOYLxhN8T pk1UFRZTWn/rYH0D+zRG46q0JmpNynEWDfya5+X5fYVJhsdQltnV8Z5M6v6GPL2vfT+Ecd+O4GiH tUBr8dxqgNZ9CNPT9jPkZami8pBiXfsP+uJ6RfbYcJ25z6jIy2LeNsVSno0X7OVpe3LofHYajOeJ R95inpk1al3flpdH58mbuN6mspu5vH+jVJ6PSWEv0muaDW2O4fpqikrLqPtv5y8IBAKB4IFECNMH hKq8RKICvHE21WTKSCOutAxX16ZcJL5tncsmnL4djnuLfqq54MLPw/XIaIskiNEfadNRWty/MIVC 3O1WE3HH9TVTWP/LRtpWDi/0ZOa0Qy0bVxj28sdMcotr2a7GY9owZvvKPqSehet6HbaGtcqzOvZs 1McttGXouPAyRqtns1DXgcMnzpBWfKfVcK7w6wJnEjuMuDdi94EKXTacalt//IzVGIboKXLcFGTA tB3XWkIKcJmvT1DrOuz18WyarUtUQT0BLhpoBhTcs4XyEy7TfnQGq7pNJ6IlyXlHVzJgjme7NzPJ hcE9XFCWvb8lTJur8jgXdAQ3qzUMnaBPSOYtqzylOjF4tCfKZqgtvsn1rPbtQO2BLA1s+VB/6UnG 951DWNt3+9PQHzycw7nKkd6/MJUtH2pgtZWAnDuFVbJ/wwqOtWaw6gImy0xonShw3eZ7Huq+sa2u VkZbMniombwuFx0xYpT+ybaYms6YM3K1n2KjIRmrufNZuMGGQyfCSch+AN36AoFAIPg/I4Tp/5xK /G11MLawQsfIEe+oG3RwGjZk4m6+mlmz57Fo2VwGvv0NbvLOvpaApcuxDM5QOriM84GX6NhV31mY Fl09gfFCddTnzkVdfSGbtp5rW4KSyiScDTTwTrnzHNME90UssLku/SrHTX0Ojq1KsTSI3r+YkdHh YBveWHiCuuzjzBjxA6qzF7FQQ4OFSxYyqU8PRm/yUzq4lsyLfpiv34SVtQXWe/zosMx5SRg/z3G4 RZhmYfbBePyVp1pWh7L0Kz0UDsXLzO+3FJlUbojZjbrJPork39KvI8bDBZsTikUxw/YuZ91Z5Yib yT17GF0NdWbPncMs9aXYuV9qE5tVaRHY6y1n9pz5LFg0k2G9JhJUIgspxrXXGA53GGPPIzooocMK U3cWpqVE7HLD0soKEwNjdgVd5fZngyp8pk3CPPGWsqnPxm+zEYvVZ8vXkB87uAvTfBXSOX/vNAbt yepweFp0OGkd0ngXYVqXzq6Na1CfPYd5s9VQ2+hKXOu6orVJrNW14EDcnadAXD7mwAZzP/nLWecM Z6KppIRPmw5E/aSy4C7GbZkqPll57Br8C4OnzGXpQg3maSxi+dJRvPfwXK4qlU12fCibjTZiZWWB lo036XXi6wQCgUDwd0AI0/85Oaz87Em+mO54i+CSkYj5dC1c/fw5duw4p6L80O/7I9vkyq+BcO3F bDiW9Dvxp6D37qLbXn6qzrtBiM8hDh85wmHZuvXnMts9cBWJOBtq4Jdx5xgb8k6zUVOLk8fsUV21 hzZNWBZMn17riFc++KIBH66PoC7JmxUac3E7cpITfr74+h7D70QocRl3WH6zOQGTib35sP8SLhQr CY7yCAbOcyKlwzBuNps+GMjBUqVd5f7M7mXV9mJRgsMMpvulEeZsjeORFm9u6UXm/PAGDz/zBp9+ 9imvv/goD70/ju1n8tqiqci8SqD3YbyOeEk28iXqUo5ifmv1aVaNX8def3/8pLI5FebJyiGSMJVn pYK9g35hW/5vl0rpNR9MVZ3pIBebM7Aa0ZO3+i4kpuQuJ2Z50n/mllvmltbhs1Ydo91+km39CAwJ x2HNUEmYKny0ZYdm09Ph5u/UkwYObzNinVdKx92NpcQGnZDy78WRw4fwDIohr7qlAGpuslLPkkPX K+4cZe4ZVm+w5vS5PfQfuQllB22USX9Geyh7qAvZOncKwUVZ2PdRk/LiTcCJY1I9keqKlKdTUcl3 WDo2m71Lf+bJT9WIKvsfr9wlEAgEgj8EIUwfBJqquBGyg5nf/8jwBZs4m9HiJ6sK49c+qzgvcyzV FXHJx5DPVDrh0Lp8Zu4xRvw8n+OpZdTWVpB7xZt5P+uh8AE2Ul1VQ7MkSVe9PovQyiaqq2u4p+67 NgubDTPRP3aTuvoa0s8fZ+9uXzLaFGgz0Ts06PShKh7XlBRh1WkGvfom/XV8yK+poyIjhGUD1DiQ KhMyGdiuW4eVzxV5GprrK0iMPMKuU63D7E0U3Yxky7JhfNR3Hu5RSVS1JbaJGikvpPvx/TQzLhSU ybcV8qgIk3dVeGeWGzeKqqgvu4799F9YH1LSnq76syx851tG65pzQWk8vamxgYaGWmqK89huMgW1 AzfurbwydtN3oI1cIDdXZBLooMb7T/7KsRbl1XjFgR+HGhCTW0FdbRnJoZuZq7odueRtqqOqtp7U 6L1sGGFOfFUdldXK7t5Giq+dYvm47+kzZgPHYtNpdwbWELRhHZYnbxWZ+Vj+MIzdNyUbNVeSGrWD vu89w3jPVn/sNVb/NAKnqEyq62oozziN6Rx1Dreo4saaamor8tlpq43m7otS+qrvcQ5nNg6L1mC8 L4YaKd7sK8Fs2+9HakljWz255q7Lt2/3xOpiR99vtFEfVN6bi//NQqmOlXDKTp1RG0LlowUF3uv4 VceTkiZF2VdlX8LD6UDbsH91ziV26M+gy9cTsD9+mVLxhSuBQCD42yCE6QNG6bWTGC/ZQHSL3muI 30P/d1/nkx6j2HT0LOe3z+Oz7tM41urNLIlibv8vePOtL+g/UQf/VIX3qiEjDI1RPXjnvU/o0rsb n3/wFm+NWkdM8b314tXJASweKp3/ZieGzbcg8Eo2ymcmBWxF12QvJconFQfz43wbfN11+Om9t/ii nxq7Lym98lOTwgG96Xzw/nt0+upbpuls53yGYuJBXU4Mjhb67Iu5wwtI9VfQ6v42b3/0BT27fcMn nT6gx+BlhMmFYDaWH6vj4uPEuJ4f8+9vRmAVfOukx2Z8LBeyyC7mDm/0p2PRtwsfffkVn/WYwrbo 3Huyz6VdmvR6922+6S+J6Is3cNfsz4/TNhHfUm75YfaM6f0Zb73ZlVFLnUhpEdkV57fxXddP+fDT L+nS4xs+lcr2zdm77niNxuww9BdaEZzaMjkjLZB56+2JLbpdNVYneTOjz6f856v+rHA7TZyPDu99 O5qt51vsXxGLzsQfee+tD+g2dCHe8a1ezipC1ozm3fc68dU3Xej61Se89VoXTKLu8QsFhWfRG9uH 96Tzv5uygUPRidQoPf3URLkyUs/9tikJZy2GM9/lANpje/PWv7sxzza0Q3jyUUt+6fYh77zzGT+M W87e0JuKh6rKqxjqbmL3qRTRWAgEAsHfECFMBf8HKthvKomQK7e8oFQfzU8L9v3JaSnD6TNNEv72 Nm/gnLsDFpsDqP3LpLmKfdZWHD6fd1vINYexmNz4y2REIBAIBH8SQpgK7ouEbfN47ZWn5J/4Ga3n 3/7CVEUixjO6yj8b9Oqbnfh19iHy/7+nJp8Ds/vJPwn19H868fNcO5Iq/66Wb6I4J5vcgpq/RGpz /HV57enH5fXh7aX7OqxOlbx/Ba/IPjP19Gu8+fN8/FL+toUmEAgEgvtECFPB/dFYT01tHQ2NjTQ2 Ks9YbaahoUE+b7Outpa6+qY/KTn1NDQ3Ui+/pvi45QNDU4O8njRKdaK+8Za6IKsjDU1S2dVSU1eP eG1JIBAIBK0IYSoQCAQCgUAgeCAQwlQgEAgEAoFA8EAghKlAIBAIBAKB4IFACFPBn0ZDdQUlRcWU lv/G91SbG6iu+wfMOpTNixULvgsEAoFA0AEhTAV/EpWEblpIrw/f5ZWnX0fv7F2+pxqyHJWhO+4r 5qbSZKKuF/+puakryyXpUsb/+dNNad4mqH5lfsuSpAKBQCAQ/LMRwlTwp3PJ5lc2RN5F0jUk4ByU dH8RxlnyzdrYPzUP5VePYTl1F//njzdVphB55CpVojoIBAKBQNCGEKYPKA0NinUo69NCWD7+e958 5RVe/mQA2keudzywKIwZvT/gxZc/ZsjEaYz5xaF9TfKqazjOH8jzL71Jr75jmTTRjOCUllWEqtPY u06VTm+/yntdZ+FxRXnN+ipCnTTo/sF/ePmVbkxcsBhdo6i29dnT/U35+dPXpbAvGDZjCrOmeHI/ /spQo8G3CdPGgvOsGNeZl155g35mEbedk3t2O6N7f8zLL7/Fd+PnoLXaEvn3/atOM+rNZ1F5/GXe fe9t/v3Cy/zsdP6e05IW4srYz9/i5Xc/Z6qlP6VyszfjseYn3hsxn4OHXZne5V1eer8bK/bGtUxB yGbdZ0/w8MPP8ca77/D6qy/SZ8HJltWNyvGe3pOn3ujOqt03qMwLY+WgT+n0kw7nZKavjkG96ye8 9MY3zDUIo/y2FGVzxHgmr7/wCh/3msrOGKVVrCqT2LFyJB+8+RoffPIzqjPXseNoEoqaIqYFCAQC geCvjxCmDwrNjVQX3MDHeTmDeyzlXIsKrIoLxC+uVfYlovONKr6t3yPPOMLQ/kuIKJQttNlM9c09 9HlBU7GmeNlFtGZrYhegWGG8Pj+MBd8vZu/lEmmrEDeTZZgcbVl9vDAG4/XLORiv8N/lhlkxYepu WhcTvbRrLVMmeSlEVKk3/bttbFu3vD7emb4fW5FzH1m9kzCVIRd9ia68NXF/x4Cay+j/Oo3jLQsI 1aX5sWzkLCJalv+sjDSh5+pTijga6mm4xymqqcdsWazrSrb8+FoiHAzQdwtRLL1amcDiST/z/ZKd ZEpJrc+UBOYaTXwS6+Tn5pw+gPG0LchXhm1soKGxuUPcKf7WjPtoBHOtd5JQ1kBalDdhae3+1dwL HuiPsb9lKD8LV83VbPJpefgoPY/2fAOO3yyXp8/XeiNadlEtQjSfnZor0Xe+KN+uyznF8v59Wbsj hPSiSprFHSUQCASCvyBCmP7PaeBasAeu1jqMV9XA8mAUHWdfVnEpxAd394N4+e1nzfffsjlZtr+e 0LVLMAxIVTq2gONuQcj0WvIhJ4ytvJSGmquJPRFOghRYlXAQjZ5T2Ozty2EPD7yO7EdffTEbLCLl 4rDs0l5mTduA60FPPA4exOOYH1GXW1RhdTRqI5fhcMCDg1KY59HDHAu52fYyU112LHv27GGf+z72 7DpA0JXbJevdhKmczN18MPXgLSZKYvOMmRi5uOPpcZCDHkcJCL1ISYv6qjtrRs814XeOrz6PgAPu 7Nm3D/c9u9gVcFHh2azPwGT1QhYYbePIkUN4HDrC0c2r+HyeJamypFXdRM/eGO+0lotUJaNnrcee qwrxXhBzmE3TXdu907eQfdKGKYOsFML1DpTG+2AywbGDMC2N2c2MhQvZ6u7FIalcDku2tZk5gtk7 FR7gKHdblqy0ZLenB56HPKRyOcW1LCWfa3MhEdv1GDF9MTbbDnIqKoW/xjpRAoFAIBAoEML0f04W mp0eo+v8HdKvW8nFY6MJuobrWaq5gnUbVzPqg25sl6udWoI0l2FyMvWOsV7f74ixufcdhUnxuc0M f6U/C9drsWLZMpZJfyvWWnHsnEJEVqSESwLQHSsDLZYuXcri1WvQN9mvEGGlV/D08cbNUpclS5ai qb0azfmbiG9R01Xx3ixatBhNzaUs0liJ48nbV7H/TWGavov3bxWmtekEeXiy3c6E1VJ6li1dw7IN hhxPa5AH15w2pbtW5J3jq76J3erlLF6qiebiBSyw9aFQvj+J1YvG8vO0JaxdtUJhg+Ur2bAjmBK5 ERLYYKmH+7WWWaDlN9CV8rwvXuHKzjvryaZp2+4qTNNObmHt/JN3FYZFV45gfIswzQt3ZtKoISxY vlpKi6xclrNilTEHzsuu0kjSpSCOuG9jw9qVaK5YxsKFq3HwiL79GvXX2TD6az7tY0iSGOEXCAQC wV8IIUz/5zSTHR+N9y5rZg0eyWyD3WS2jsNWBvLDZyvIbtmsuLyDnx79Gs+WYf66y670G7yGm61R VV3AcIYtKbLf2aEsVVvKzkutr9dks1fHkcDkSii5iMmC5fgqLWZfmRDDuasKmXTedQb9zM+0B6Ye ZNGwtcTLfkds4I35B5SGipNY8sko/O9jufMrdqPYdP0ugbXefDznZIddDSkHmNxFv236gKSOsdD4 FZvzCkPUx1rRe8juNq9tYvghfK+U/04qKjhhp4fO1milfUWEBJ2nVC7m8jDbatk2fUA2/cF8qwXH Mlu2Lu5nzSQdWh8L0qP9CYhKbZvpWXPOHf2l0Xe/fG4oDjP2dHyrPz9KEsu6HFNSq43pZzl+SSqo pgJsDDRY45PZFpa4w5DVugcUQlpmh9I4ti6bwuBJS9h+JJjLacVi5qlAIBAI/lIIYfpAUU3CqZ0s GjuPUy3TSvMCTXlHRYVHXurM0q3eeK7ohcrz/TmYogivv+7BwHcfR0XlMd7rNZOtUe2qpjErgvUj PpfCVHjx3V/YeCiG6hZFWZESzOpfv+QxKeyhR99nzKrNRKcoJm3G7lDjo2ET6fvRK/JzXx2witAM hXeS08a8PHgGU/q8Lw9Teftntp8v+f2sNWZjP/0HHpGd8/DDPPyQ9F/la/SOJivyedqZn56S7XuI hx9W/P9snCkpMuWWcZjxb/3C6F++5mnZ+U/3xtw/WUkcV+O1+hdelIW98DkzNrhytfgeJppKYi/I aSmfPSq73uO833Mq1r6X5EF7Fn6hyN9L04ioLsJ+yAuK7d7LUYzmVxJiP5e35Gn+D+PWbyVaJvol wbv/V4VtHn74IR6SnfPGagpaLlkWacHrzz/SEv6wIs6hdm1JasiMwEC1h2L/s28ycL45ockV0vNL EXYG0xg45lc+eO4xeXn30thCQpnCCpVZgWgPns2es6nUiQmmAoFAIPiLIoSpQCAQCAQCgeCBQAhT gUAgEAgEAsEDgRCmAoFAIBAIBIIHAiFMBQKBQCAQCAQPBEKYCgQCgUAgEAgeCIQwFQgEAoFAIBA8 EAhhKhAIBAKBQCB4IBDCVCAQCAQCgUDwQCCE6d+Vhioy40/juXc323fuwScygfIOywDVk3HpFPt2 7WDPPl9OhcdyI619taSa/GucOOSOm+segi5m0f65+qZ/jg0FAoFAIBD8qQhh+nehuZCoPZtY635O vtlUcJ2DToasWLGK1WtWMk99LS6Hr7QsUdnIpRNurF66klVr17BeewPTB6qyyipGvppSU34Mlos0 Wb1+A6tXrmXtGm0cjqa1XKgELx1tdoQnC4kqEAgEAoHgD0UI0788JRw01mDEwCnoOu4hJLGoZX8z yitTNsW4s8lyL7LQ5tJL2KxYgm9iuwv19K7NuLjHyX/HbF2AeajSKu61l3Fcb0p8rSLe9ChvNhss Y9j46RjuOyuKQCAQCAQCwR+CEKZ/YWpOm/H0Oz/icPwqtbeE1RVeZ/faMTz3xCPytelVVJ5nyCoP ZKu5VyYew3C4FZl3jLUR+35PSsf/i389/JBizXaVR/jgh8VEFdxyaH0uQS6zeffRMYRUifIQCAQC gUDw3yGE6V+YptwIdGcvRMdmC3u9TnIptbQlpBJvsw2s33K17dhLO4xYb36YOtlG+RVsli/A/VK7 msxPiOdGSon8d7DxVGzOdLxWY20FtQ2tWw1kXInCe58bdhuXorZmD5mNojwEAoFAIBD8dwhh+jcg 82IgbrabMNmozbL9F+T7rgXtYuHESUxUncxyXXN05o7is3e/Y4Nfkjz8Rpg7azXmMGXKJKZMXchy bWuOn82Wh9VkhmGwZDGzZ89EdcJ41Jatx2bXMVLk70aVcWTNavSMzbHd6kFMaqUoAIFAIBAIBH8I Qpj+jajOS+RccqFio7ma9CtnCDoZSMy1LMorC7kaHcmF9FavahNFqXGEBgcSfOocSfkVHeak1hQk cSY8hMCAk4THJpBXWtMSXktqTBw5lcJFKhAIBAKB4I9FCFOBQCAQCAQCwQOBEKYCgUAgEAgEggcC IUwFAoFAIBAIBA8EQpgKBAKBQCAQCB4IhDAVCP6B1JVXi5W7BAKBQPDAIYSp4A+kkqtHD7Bly1YO +J0lv1ZY5DYqkvHcs50tW/cQEJ2p+K7sn01VEOqzdlPyX0bTUJpGgIcbm7e44BGTLcpWIBAIBP81 QpgK/kBKOe1izRrNefw6fCyHkpuFSW6lOA5bUwMWTB2D6mCnu6y+dWdqy3OIC/Vjm9kazKIK/89J SDRTY8qhjP86K3UF8eyxNUBX7TseGrtPlK1AIBAI/muEMBX8f6CUXSbqeCaKweK7UZ/qj7mqI+n3 fgbXT+3BSN8Bl6W9ed/u+v/twnVnUR1vyI0/smiKDvLh9IOiUAUCgUDwXyOEqUA24ZCsrEyKKxRr jp7c0AMVFRX6znfl+iV/1Hu/gcqbI/AIPYnap4+j8rYFRbID0/3o86oKKlO8OsZXm8lW/Vm3CdPG 7BgcFg/jMSnux1/uxpKt4ZT+rkAqxrrz0zzy8i/oGqzg61efkNL2CrOcz0tSTX4xIh2W0fnNJ+Rp fvajQVhH5Uv7y9mp3huVj7oz4uOX+HffFdgazedtlecZsOl0S4LyCXbVoudzD6HyyLP0nufItQJF rDTVU5STQU5x9R3SlMpiWb5VvmDd/jOc8zbhy6ce4ZOxVpz1t+QVKR3ddyqGtpPcF/EvaVszvOOg fdGVIxhPuF2Y1qdFYT6nvzwvT7/+HWv3xVBz6+VDVtDJ5tpvWq28KJeMzMIWG7VzfcdGlu893b6j MoaZn/5Hfr1JHvFcPWxI72dVeGGQBWciNtNN5VFGtaxPm+CxgldVXmWp+42Okabt4P1ptwvTrDM7 mdnrA3l5P9FlCh4xv+/lrb7qTs/XVHhkoh5OiwbJbany75/ZGV/eUmSX2LxyBM/K9j/0FJ+M1udM piyXiai/oMK/v/iBN1/txND1blhN/xqV53/AKbJlmkF9PidsFvDpq09K+X2aISt3cb289coVpCWk U1YnvPwCgUDwv0QI038wtYWJhHofxMFoLXNX6hGS1dAeeNOLFVOGMlPXkzLZdkUWSVkyFRnLjE6W tM0oLD1IpxlHbon4DsK0JgkX3Y3sPlvRsqMZTxMjtoUk3kNKizEb0YUVHgkt2wlsHDydcLmoaCD1 8g2lVauO8+13dsjXt8r154eFlnLxF+00h8F656RfFxj1uSkF0q/z+yxY7xLSdmaJvwsrnY+hWGS1 kuCtJixYoIOj6z4i47Nvmw96ztqAaYOmY+Sn8F4WZtxQCPaolXzu1J6v/O2jme3fcenWOwrTijgs Vm3k0LXW3FSxXWsj+y7kdDi3MUBTEqbxd7BTJYlnA9m/04k1C2ezZttlOqzPVXUFo5Wm+MeX33Zm jtccXh+2kl3eFxS2uHRBPgc123MTBu6RbcfFGFiy2SOu48l3EKZNBaFozdej/cgkrBatwi/nHoo7 0ZnHey+gVU8SsIKPDRXl1FyWy42sdlumbDdD3ylQkYcgF5bO8JJVSnSe78N2KZtlfo4Y2Psgq9mX D+qxzvZM27lZgQ6sN/FW1BWpRmydOYolRg64HQrgcmqJaCAEAoHgf4AQpv9EGkvx32vOemNLLEwd ORGbeptXLjdyG8tWmZHccEtAUxCqysI01ZX3pnt1POYOwrQi/jCTBnVl0JhJTJwwgYlTJvLLl58z zMhXcUCzlCYnHSaMGMXYsaMZqbYc98vFirCGRJzmzeNMVWsaUnCaPZOQluCSS0dZO3Mco8epMlX1 e97+jx55soCbh+hvtBvZaacPGKCxOxmZsFZ734RcSewazf2Vzn1HMnmSKhNUJzF1aFceHaLNjar2 rFQXJOC33QE7W2vWGTgRcLOsJaSSYzq6rLeMus28Vcc0+MK5XZgm2A1jzj0I0+Kz2/h1QC+Gj5+E qsxGUycy8KMPGW7f8RqNJ28XphUJ/hgu1cVSSqf9nuOkFN++ZGz6iV3obXIn/w5V4pLbDH6wjL1t /9VtuujubRWm1QSvMcTxHoRpjs9SHn/rJ6bOmMyE8ROYNGEsXX/4lqW+2W1l6Kw2guFjxjFu7HDG Tt3aPt820oBOFmfbIztjzLuGrQ8QZcQetmbyhHFMmDSeQd36oG51Uh5y09uJDcvDZDUCuw/nIEt1 9lFbDLf40kQ9tqPf4/NfJjJt0gSpvCcyZvBP9B+pyfnStspN1oUgtrk44WBviv46DzLEyrsCgUDw pyKE6T+R+mxMJ3XlowErOZV/50Pyo/ZKImfP7W9uN55k7Pt2FLdu5+7i/Vk+txyTh5vRbLxS23cV XzjI6mWaeIXHEnP2DNHRZzgbE0daYetQeT3ZNy4RHhJKeFgooafPk1rS4qNslkTM3NlEtmpC0nCe o06k7NRrboxctZnomPNSfJe4cX4bgz/YpBBfkjDtZ7hL7gGNdN/I/J0yYXqemZ3MKZSk6/r1S9mw 9xQXY89J6Ynm7NlzXE7Jp+EO9gi0VOfDD37AMqxVktfgZ2TH1gM3bzu2wmc2n29rf7kozXk484M6 fqKg/LovmyZuRvld9rzwLSxZvYGTUbGck9nozBnOxVwho+SWzxsEL+dD+47XLThlwKfPfcKyvRfv UugVHHDSwvLEnV+3urpvDmO9Cm7bH+eyAYMD7SIxcr0ZWw7fMo0gaw+dZhzqsCv98Hw6aR7g6pVY zki2lZV37NVECmtavcGV3IgKISQsXCrvEEIjb9I2aSLaiPdNlcT4WZOW7UaCN9tgbHOQyHPnuBAX yxHT1WxwURKmy0KRT//opK4Qpj62GG/1o1kqL+ep32N49AKXY87Iy/vM2VgS0m6f7kBtIm6LevL0 u0u5XC+aC4FAIPgzEcL0H0zpjUB0R/Wgx3QDvM8mUdni4KyvyiNy3yZWrDHhbGImGekF1LaNlaew sftYtl3IJDflLPZj30dluDP58nMbKMzOJvV6FEZLRuMQkkhmWp7CG9uUzWa9DRjvjSCvoID8nFRi TuzFNeDq76azPPUU60aNZP81hdexOFnaHjmSQ2lQdUqPAVruZJYUkXnjLDtX9kPlGQ0uyjxdSYfo rWlNhqTronatYZzcCxfDlFeXSvJUCt5vwxrdbVzLzKcgP4eki4E4uZ0gr0U8VebEc8RpBd0/7Ive wXO06WJJ5lRmX2bz4rXoWfiTnJ1OZn51+3SChM10G2FDXE42yad3MuixZ5l6MEkRXl9GZnYOF05s ZvkgXSLTM0nNaxlar0/CbMU6rH1iKS4qIC8rmdNHd+ISnKQIrigiKzOXmzun8591JynOzaGwTGmC QVMBQU5L+eqboehL+UgubA+rSj+B7kwzkm81bnM9pYWF+JqNpq/taan80qSHhXbvbnGYDeNX2nA1 I5uEsG30/U8PZpiFKKY11JeTk5lDcbgZ/x5uJ10vh+z8MsX3USsuYDxuDgdi08kvyCc3Ix5v9z0E Xsj7ndJuIuvwUl5eso8qeaVrUGwvdZeCitlraoiBawh5RYVcj9yLWpcuDF6wA9ns1WQvaxapeUlC swjLt0dxoAQyfS1ZsXG7fIpFwrFNzFm1i2vZsvLO42bMCXZ7+pHc4jHNOu+H8exR/DBsNjvD0hEI BALBn48QpgIak0OxdrDlZKJiQP/MFnW+6v4d/fv3o3evLvz0sw6xSiPRpXH7mNa3B9+PW41/sBcz +vdnnv0lKSQZo0m/0q3Ht/QbMIi+33Xj8280OdM6pbE2A2/zRfTo3o2ePw1h4ab9XM6u+J3UlXFQ bRDd+/zIwCXWpJYnYzPkR3p8P5Cp63ZLgqSZ8y7L6PZFD4bONCY86RJbRg1i7AIfisuvsnLSEvbE VZJ1woKRc0xIKElly9iBqO1PQSYwr/s7M/m7b+nS4wfGzjHCOzZNMS+zsYTj+5yx2X/uDh+iz8Fi SFd69u1H/37f06PL14zZEI7ya1JRDgv44fPvmLR2B2E+RvQeMJ5dCfU0XXNn2IA+9PruRwb80p/v un7F18uUhsGrkzigP4evv+lMrwEjWG5ziOsFCo9pgpcFo7p8Q68ff2ZYv9507jISY/crd/Dw1hKy zwErh9O0zkqIslFDw/MO3xqtvo6+6jC+/b4/v/T9jh7fdOEX0+PKB3B+uxZdu/Vk/IYt+LjpMqLr BA6nNVIVf4j5P3WlW5++DBv0k2SHb5m0bg9ZLfNCqjNC2DhtBH26dqFnv1k4HT1DXtVvv+1Wm+TP nInD6NenNzOkB4msa56ojRxAv+/6sMBLEot1CdhrjKR7l+9YaOlDbLQHc4YMRTcwm5rYvWjM1udy dRkBy35lnEEUOck+zByiiU+yzIaNxHmZM+rn7+kqpWnUMjuCLme2eEwz2DpnPcdvlokGQSAQCP6H CGEqEPztucCSAau4KgwhEAgEggccIUwFgr87zeWkpghPoEAgEAgefIQwFQgEAoFAIBA8EAhhKhAI BAKBQCB4IBDCVCAQCAQCgUDwQCCEqUAgEAgEAoHggUAIU8EfSmNVMcU1Tfd3UvUZpjymwnMDtLgm 3tERCAQCgeAfixCmgj+UnG1jmXS09P5PLD2PuZ0Z8ZXChgKBQCAQ/FMRwlTQgfKzLkyYvh5LfS3U V7lw7UYoq8eOZs3WM4qPtTcXcMLNBPWRgxkyZDIr7QPbPuJenx7M7H5v81q3X1AdO5LBA9VwCkxR ir2OBD9HJgwbxtiZC9HTt8TztCK8LiUIIwsdfHw9WKM6nIka1pzJaV+5qKk8gV26Cxk3dCCqq11I UP6afflVrJZPY/CQEcxYroP5RmtiWzyvjWKtc4FAIBAI/jIIYSrgqocpk2bO4UiSTMXdQLNHJ5bs icDXXJ2eMwyJCD+K1uol7E9sgoarbHU6QNjZC8RdiWGP5lhWB+QrImoq44SeJFhNfbh64SyREedJ zm+VrQ1c3GrEQi07gs/EcD7mFDYzRjDXPlge2px1inH9uzNCaxexF2PwtDJAR9+TYnloAXuWTcH0 QDiX4y4R5uvMmrnWpMjDqjg0eyL6R88RdzmOK7GHmfXxV2xNU1y17JQxXcdqEZIkXLECgUAgEDzo CGH6j6SZsrwbBLmbMPSznixwOEZq28qgdeyaMgI/SU82hJkw3TVMvs/FYSVm0Qo3ZGNVEZmpaWTm FZKybzbvmV9sizlzx1RmHc2//ZLZESwyMCVCKSj/zDEORd5QXDUlAF3L9qH88ivecs+nTF9WRhry w5wDZBTlkZmRSW56IlvM5qIdKJOtFewcNoyN3hdJz8ogMzuDS6HhZNS3X6c+6zRGc0YzYMhStp88 R25lg6gCAoFAIBA8gAhh+k+kLoMN477mszGmXL1No1XhpjqMIyWSIAwyZOpmmUezHGe7VVhfrKTh 4mG0l81m8Ld9+OnnX+j/2XN8Zt++2GXK1kmoed++Jnt98klWm27i0l2mn9YmB7LR3ITLRYrtwguH MNO3I1P6neMxC5XXuzJ4YD9+/OEHfvj+e/pPWoz7ZZlQbiQx8gSWWrMZ8u239O49lEnqK/BIuV18 1qccQ+3jF/na6P+1dx9gVVx5H8dJ2ySbsskmm2zeTXaTzaZtsrvpZU01JpaoMfbee0PBAkgRBJSO NBEQBUFFEbALFooFFUWl996k9w7f93K5NCWJ7mYTov/P85jcmTNz5syZ6/P8PDN3zin5DgghhBB9 kATTO1IDyWcOsMVxI2uXzkXH7Rg5nSOmNWybOIJj9VCrCKazvC8o1lXj7KSLe3YZQeOHYBrTsW0J vove4fUt2Z0152+fyIcb41VLraSeDiVOmR+z2aSrwdpdUZ3b5obtxedMoqqqCGw2O5Kleqy0Pv0k m2230pZjm5O9mTbfje434yuzkkgraNv4Egv+tZor3crC9T9nzN6izuWmrAg2GS1nqa4Zdg7bCUkp /3VfPiGEEOI2JcH0TtZaR2FmPEFeVkxX18Anpo620Gr89v28qX2BoguG3KP2D3xSS7CZ/A+eHmdH RoQv3772BGoP/oF/zzBh9/rRqKn9hgleKe111kexYsgb3K12D0+88AFTVjgRrwq9LQWXcdUYwcN3 38NDT7zEsAWWnM5si5s5GHz6oKIeNZ6ct4PWlmjm/F5Nufz5uiDlvtE+6xj6+vOKfdX4ze/fZY6J Oxdz256JDWeY2tt8O+VLnrtfsc+9f+W7VVvJVr2x6trhtYrj6ON74hKp+WXIb6GEEEKIvkuCqRBC CCGE6BMkmAohhBBCiD5BgqkQQgghhOgTJJgKIYQQQog+QYKpEEIIIYToEySYCiGEEEKIPkGCqRA/ KBtvdU9SpCNuQStnbWfz1YzVnMhqlO4QQghx0ySYCvGDIhihNoTA1p+42rpoNIePxmBf2s9yFuGb 5uIa9/P1Wk36BXRWTkQvrEy+QkIIIW6aBFPxk+jMba01ZCfHER0TT2pGFllZJTR126q6KJuYmBji E9IprukoqSMnPp6swur2eporSY9OILe0vr24voT4q1Ek5bbPV1pXnE1cTCL5FQ2dNdcWZZEYE010 Ygb5Bblcq2npLGsoLyApJoqYhFSuVTfd5Bm1UFGQSWxsIrkV9T1Kaq+lkZCWT3VtJbkpCcREx5Nb 1t6WusIs4uMSSElVnF99+7mkpqSQGJ9AVlFtZx2h1uN5+905OHrEcjOZt7mqgIT4dEqrayjNSyM6 Opb0vHJaul+D+jIykhOIjooju7i2W0EJTvM+YMmuK4ryOKKuJlPe2H49qq7lkhoXS0Z518hmdW46 CcnJXFNV0VRdRLLimsXEJ5JVXNPVDyW5xEXFkKo8Visl2SnEJmRQruyKJnZtUmft6QrFx1KSE+IU /Z98C/0vhBDiTiTBVPwXGsi+Eoj7rouq6UJLCbQzZsp3X/HpZ4OZNHEwT6tN43xL+7ZXgnZgsHgq n37+OYOGTmSBljMRmW2zTSWj996LfDrFlty2lFZ+iqlP/ZXhM31pm820NSWAEa89z2MDRuHguZvN psv56oP+LN98mra9q+N2s2zGJIZ+9jGfjpzNjEHP8657lrJFjYkHMVyxmDH9+/HZN98xbakD8eU3 EY5aqznhpMPgz9/gd2qDCOsqIG7bYv74uz/y5RQNFowaxhefDGLaMjMOxhYQt8OEb157ALW/fMee TMXJlIcz9o17UXt+IOt2xbeH0DhXliz1IsDRFUe3qzcVTMvOOfHWQ8/x8fCl6C2fxqf9+vHvQcvx u1rWvkFFIlvXLGHsyKF81u9rJi8xwjeivazmkjOvPP0Af3m3PwO/+oz3357O0bz2a3LedCxqdz+F RlA+rZWFFNWUc8VmHA+ovcLG5AYaYo+zUX8p3376OV8MHsrEBXp4R7T3bWyABUNefBy1CfqE+W7D UH0y//5wNI6nchSl9Xg5LsciporEDV+h9vjf+GTULNwiipX7Nueex8PzOOkVMheXEEKILhJMxX+g jksBTqxcvhw9IxPs/OPbp/qsOcXAtxZwujNrVLHbLIBsxaf6lED0NPUITOka5UzcacoYy4PKz7XJ R9m43p4MVXHh6b3YLPehpHPrHFYtm8IUve2ktqdgyosrFf9NZ/2AWWxP7wo4yV6LmbSngLbnQ620 13M4p1vLD1sy2Tv2Fs61FpdXZ3Gipeda72Vv8alBcOeIZdZJe5YusqX9UKHMHumkiOntfbV/gqJ9 5R17JrB60nLCGls4bWXLRtebC6ZtLjltYOnC7eSplk9u3ICJw2Xl5yjvlazz7Xai14Kx1Heio1vC LUdgm9jbpTzDqInutI157jKYx2yrK9AUxMAFJ5T9t0FXC6eg1M7NmxN9mDjGmvSOEy85yjsjpmPj GUJZ23JTFSWV7VPb7nKcw6Q11thbO3Imt2cHtpZE4bLOFIOVGqxav4XIXHkWVQghhARTcauqg/n2 r4PQ336IyKQcKut7xqqMQ44Mfe8vynnu20bJvl27j7bIkRbgjsVqP9XIqkpVKP+eYU+u4mNZpC8W xvZkqoJpVqA3lsu6BdPSKyxdZ4h/as/b6uRu5/lRO3uua6qmqi2Q5R/jo1ee5q577+Xee+7hnnvv 5/62dg3b2r5dXRwrP39V2da72ta/PJTtMRXXnXAe1i/OuC6YtrBn7be4JHRbVR6FtfFyTqiy4V7t kRhdVXzI8eSD+V6qjRq5tNEYs+NFyqVLzu54+Gb1OFrl2Y385YnftPef2m94b54rxcoB3npO2Nhh 5xKl2rKekI0bsba7rFxy/OpBxfb388B9ivNUnGvb+Tz+2lhOXGvfOnDtIEwv9Bb+SvEcOhe/vHSM +z3OO8s9SfFbxcyDRW0XAS0LS5Jrum9fjvuH89mToxp1TvTm7VVuVN5QbyPbdL7l5Xf7M0DxHehd C1Ul2cScOcD6uYP5Su8UcqNfCCHubBJMxa2pj2LpF/2YYuhOcGQKRZVdI6CkHGDOpuPdNm5m2zdD sEtopD7GD/01ZkR3y30Vp5wYoOetvB1fetkXE8ONdIz5Xfa0Za3mfjozUX0iq+xtCC26vkFXWPLm UsK65dXm6iIK2hJwSSgjV7sog+9/rhynV+YRft1a1yXvMXJzfOdy4WUfjDQtSO4Y8Y3YjbG6E67a a9gcrjqrhjRMRvfjt3fdzf0PPcwD97aFz1fQOZR5E+1o5YyTM07uXaO955ydcXRp/0XTQe1RbP2B VwccNfgK/XNd6bqmvIKOf1OUBCziswXLMZlqh6abPmPfHcuhsrZTj0RDfy3+sT0uGnO+NOBSnWo5 y5ePzPx7be/eLSuxjG2kep8BUy2P9TIyXE9pTiKn9rkxf9DHLNgSQ4v8DRNCiDuaBFPxH8mL8Edv +TJW6JmyZWcUyjwW584fvpyAhaMzG62ssLbbwPKpxkQoc005BzabsULbGAsbG6wsjVGfZ8j+iHxl fa3FkVjrzmf5WnPsNjuxaNhHvPbqLAISKhWpNYbN2gt4+6svma69HlsbB45ldCXRrCNGTF28Fmsr S6wcHFivuwzTE+0JNtF9A5prLXG0tsLSxg57G3PMvCJ+/AQbignxc8PGUZeB977ObPONWG3ZS2z7 8CWe897gjYHL2GBti42lDbqrVrM5rLBr//pMNs96l+eGWJBWe2P1xRe8WTp8FKPGWXOxsOHHm5N5 goWffs7nA9YQkttIbdI+pn3xOZ99ZcolRf/WJAewfJ4OFnZ2yn6wsbfDYZs/yapHCOL9VzNsjr6i D2yxt7fF2sKDhI5wWR7AH9TUUL9YQarVENSemklG+1Uhfb8LqzR1sbJQ9J+VBWuWLmHd/svK0vyo Ezgs/ZZHPxvDBksrbLfsJlrVP0URXgz5bgD6p2uV1379G8/y8UJLAk7EKR8boCgSBwsTNBYuQ99+ P9kyVCqEEAIJpuK/VJl9Ef/dV9rDRkUaAcGhhOzzxNzEhA32HoSldRtta6kg5sRuNqxfj8VGd4IT eg5/liWdwcVmA+buB4lKjMDX1pEjUSW0KkKM/br12ClCl42lORvMbAhM73lLPyXUF/v1xhgr6j12 uduzlorInHR6H3bGJpia2+O17xTppfU/fmL1RZzc44SxqQUbnR2wMTPFZPMeoovab4fvNRyGxaEI 9m3ZiPE6J0ISyq6roJn0Myc5ciqJG3/e08rFPXaKUGuNpZkrwUnlP9qc6pRQHM3MMFdsH5JaQ3ns QczMzTG33EFETnvyLUkIwc3BGlNTExx2BRGfXdp1a7yljDN7XFhvsgG7rQFczej+toQKzm0/SKZi RUveJXafje82utlMXvRJNiuumYmFPTtDEumI0TmXDmGj6B9HO1sszBTXdPNOooraa82/4IOp8w5i lQ/alhPiYq+47tbsPBKj/K60XrvErkORlMkQqRBCiG4kmArxHwgyH8vOa9IPQgghxE9JgqkQt6SF 02s+Qe2uh/ht2w+UPlAnqlKG/YQQQoifggRTIYQQQgjRJ0gwFUIIIYQQfYIEUyGEEEII0SdIMBWi zyrEy2QzxxKLpSuEEELcESSYip9NfVURaVfPcdBvJycz627coKmQcH9X1m9w4njszYexhvJ8Yi+F 4LcriJjcmhvKW4uv4GFjho37QVLLbnbqyxZqSnKIiQjFb7s/qb28i7Q87RxuG83Y4HaYm/6Bfksd RVlJhB7dz5ETkZT/wO+mGmL2s9DQifiON261VpEY5oeNmTHWXifIqu5lp8ZsAlz2Elch3zchhBC/ PhJMxc+kioj92zA3tUZz4pt8vTP3hvKTm61YsdpQ+a5SDS1ddsbX3ES9TZzfao6pmR4jP5yO7f60 nsWtyZhMWoS+rT3WehpMsPSn9GZ+RF9XxAlva9ZtNGXSS//E9brJmRoLInDUmMdqMxssTTVZtPwo 1TfTDZmnsFScn6H2AqaOX0XU955iPYFbLbDwuqCaDame0G1mzJqrg8VGW0wM9TAw9SK/uWdfRO4w 5Z0H/ox1vHzjhBBC/PpIMBU/kxZqqyqpVQSpWK/ZDN6Z3bP42nm0jI0JVuXVqB12GOsE8uPRtJXa 8nKamgrYscIS9wOpPUrrwgz4t+EJ1VIW5l9rcSj9JgJvazPVlZU0KuJmwLRBuKT3LE46bMtS7UBV aCzDccZ3XDftfe8aayirqqcsMxSbFWu4+n1ptiIBJ4OVHM1Wveq+tY6oU4GExpW1LzfnYGW6jC3d km1DciDmTtY4TBqKfVyrfOWEEEL86kgwFT+7BO/ZDNrRM5iWXt2PrZUTWao77SWX/bAw3Eh6w83W Wo5PWzDd3zOYXrGYi8mpgs7l8wazWHcy5xZa28T+6YPYfN1A7AmPJSw80jVzVZDzNBYcKbrpWuty w7DR/P5gmnrIiEWrQnqZNapdS0E463VXczxHNfzbdI0tJmvxjivitOZIbKLl3apCCCF+fSSYip9d vNesG4JpUaQv5sYbyVDNFlp82R9LY3sybjqYlrLrhmDayjnD6Yogmtu5HG44G9OQWwmmDezrJZge 3jSLuYe7niwNcp7FoqM3H0xrcsKw/t5gWsGmcWPZkf89O1fGYqm9Cqs9KZ2rssKcMLM/o/wcuWos LpnyPRNCCPHrI8FU/OzivW8MpvUpQehaWhKj+tFOzgkfLFd6c/NRr7dgCtleixi9K1G1VEPA+OVs vVpyC61tVAZTl+uCacQuPRY6xHYuH1j3HTaXbjpFU5vzAyOmybZ8MeNAr6Ol9QkHWK2hzbaw7s/o VmH4qhoPvPEFw4Z+xZtPP8wLn01kW0wNQgghxK+JBFPxs8vft4hh+69LZE2ZWKmvwuFkoXLR02A6 q3al9NikIi6A+dNXcjit9/vfB3Wd8Aku7bmyxJ9P39NFGePy9jF4igkxPaYQbSV+pw7jNTzI/p5c eXLeMLzLeq4rvrIbzRkGKGNw1QFG/kuLuO4btFZwzGENi838KO0tYdZcYbOuMTcObNazf+RoHHsZ 8cwL28bKVes51d5F7PY2Z0tUZXt70pJJTEqloCKbPTO/xjAkH7mZL4QQ4tdGgqn4mVRyZOVInlRT 4/5Hn+TpR+5BTe0tjA52G4qsjcV09OuK9c+yyDXyhmBVELKRt/7cH/tLZd3WtnB46VuKfe7i0Sce 49GH70XtrldxjO1Kgy1x7rz76N387rWJ+Cdc/x6lJkL1BvOnj/S42n2AsS4H85nvK+t9+MmnePRe NdRe+oZtUeWdm2QEmfPPJ+9G7bXJhF//9qvGa2xZMIS3x9v2DLxpvrzxx0e4674HeeyJ3/Ogoj/U hjl0lUe58M+FPjd2X10GJhNf5Te/fZRHfvsA996lxqMfjMI/rb5rm5p4ln/7Jg8+/BiP//FV9E7L O6OEEEL8ukgwFaLPKGevtg6bTmVIVwghhLgjSTAVos+oJu5SEkXVTdIVQggh7kgSTIUQQgghRJ8g wVQIIYQQQvQJEkyFEEIIIUSfIMFU/A/VcNEnuHM2JyGEEEKIHyLBVPzv5B9iwBIXCm/bE8zDdZQe OyKL5Vrfijg3Hla7hw/nH6NWekMIIUQ3EkzF/0gdxzeswSrgym18jlXsmrKBPZdLfvKafRd8xF9e W0LUz5Hccpx5dEzAz9x1R5n78TZK5S+KEEKIbiSYip9A642zDF07j56RDWdyu93Hr80ldJcTa9ca YWXnjteOkyQUdL3Vvjr3MjtszRXlhmwKOEeh8t3xDZxzMWej5ymKle/ML+aQmSnOPtEo539qSMfd 2BCTTd4kVDZTmRyGg6ER7ifS6HivfUX8CewMddE3c8JntzfbL+V1HrMiPQJPi3Xom1iw81QyNzup aHHMEcx0DTB3PEByRdfZl0UfxmKDM+EpyQRvd8RY1xjHPeeU04tWJ4biusEEM2MT9iYpTq6pgIM7 XdlgpIfN7oTOY7de2cS48cvQ115LVPVNNKY2EVsDM3YHx3A5dA/m6/QxczxK966nKgl/N1vW6hlj tyNMEalVWko4vn4Sv31jPKZWG1inb4DloWhlUUlcCFsM12JzJKrrskYcwXG9ER6qUeKqnMj2a6bo c+d95ylSve+/Oe8cFlo6WO4JURyrmdSw3aw3suVwVPv4eUvGbmZ94a0oK+eQlxOGBmtx2h6Jch6r llb5KyWEEHcoCabiv1BBxG5jpqw80BV0VOL2uWK0YT9dcw+Vc8TRBgMjCzY5b8bN0YShr09kY2BW e2l0IGYaK1hv48gmJwesNxiga7+bQkXojfY2ZPQXUzilnHSpipMb1Rn2qj6JbYtNOQRssmXyxI8Z vNwSV2dX3OxMMdiwh7b42XjFnZnL1uJo74CjqzsOCz/mgVVHlcesid6Hoa4+Dg5OOCnq0NPQZ/ux eG4mFpUlnWKr0zrG/3kkDuFdDytUZ4ZjPPJlHnpjOhYOrjg7OWFvuJh55ucpKYzDf+0o1F4ay4ni 9v47sG4YT385FZ8TWSjfXtp0mWWzjDiVHcnmldpEVt1EY1rycJj/Da8+MQhDZzdcXJzRnT+TpQ5X VeeSi/WkBRg5ubHJcZMiWGowz/Rce1lrBefsZ/PIO7Nx2uqCg40tbsHKnqXq0nY+/ewLlgUktc0H S3B4NlUZ/ox8pj82sZU0Jh5jw/IVbLB2wMnJEev1imvm4EN+W04viWWL3mL6TZvAilUmOG3zxM7Y CPtdZ5X/oGjN3MO8wf7UVQXy77c+Y95aK3z2xbX/Y6PyPBqTdQi4WiB/xYQQ4g4jwVT8B4o4YLmQ z78cxkobH6LyanoWtxThaTafrZe63YduzsR4zlIMfFM7V2VcjCTxWttcnrXssFmM7v70bpVk4ai+ Dq+wttBXgMu8mYR13PdtvYLJR3rEd9vaz3Qcn67y5VrHDJ1NbWOUmVh/p8Wu+MquDa+4Md7lEm1B 2cPelu3nu92Gzz/GNJtdXXX8qGYOT9Zm6/lrPdbmuH7N/2mf7bYmA4OBwzlY0t53Fp/O4bRyfTUH l67F+VxHsG0ifL0hJocVYb3+Ko4rdYmuu7mW1ERtZ9Ewj87neasj3Zg/aq/yGc6iverM9snt0W6v OVM51PFobL4nL84+2kut+Tho2nA4oYlkj4k8/bELDbUXGKLtQyMN7Nq4GP0D3WepysRh6Tq8w3JU p5PC4jmTUd96jo7B25Ym1adsP8b9dQwzjIzwvXz9M7oNZF85ibXmFAZ9PQH7wGT5KyeEEHcICabi 1pT786La0yzwvvi9I4vlUe4smuBFeY+1rZSnhGC7cBAP/OY33Pe7p3lzhDbHU9vGVItxM5yCd2r3 7ZsJW7MeO++228rpOM6apRoxVWi8iPGH3YNpI7udlqB39rr73hVnGDxjIwm93Z+vTkVjzD9Qu/e3 PPrwb3nwwd/y8G8f5IkRJqSptk/y0eXNR+7m3vt/w913P83wZYeuO6cK/MatZMt1wTRx4xDmnOh5 0H1aX2N3tf2Wf/OpZXxkHAd5Qcw1cyNNld/Lz2/hu3ka7D8bxdkjriwbNxmvy9c6H5NozDzGuH5/ 4q57FP13z/387YvlnFNluuLz7iwbH0BHD5RGuLN0tJ/y8YAInU9Qu/9hHnv4IcV5PsgDDz7A/706 Er8M1RVMd+UvM/b1ei1jNplge/Q4roPfod+sxbg422AacE75CICb0VR2XnfNQnVMsfNSPVdcHMky aytC8nr5pmTuZtij/VmyxhznvVe+f5S6MR2POf9C7bV1VMrfPiGEuO1JMBW3pjkbD6PV6G+wxsJ+ G4fPp92wSdDKSay9dN1QX/FV9CxtON71eCfnjTRY4x6u/HzUdTXL7IO7nvEsCsdwkR5+l9uiYDZ2 cydwWBXCsk+aM+JtK7rf6D3isYJ1kde3pJg9C5awxi+uc01TzgV8zraN6JWwzW4DLmFFPfYoLSih seXmu+P49LXsSej5Pqw05wHcN8SVzrHYvP3M/E6L6M6Ty8Bk0EzW2dvh6HWWjglICyMD0Js6iu8U gXT6xKG8/9JrjLc5RNlNzFDamLAb7elBnQGvNXEPWlMC27vSV4NZLkk9tm8qz6WoY6A7dxsvDdjS GYDr8xO4mtUecZujtzNm4sd8NWw7x44b8ubfhuIU2jZK2sJhl1VoOIR2u2ZnWbtQH/+OtxS0pqG9 yYFz5b00uOwIiwf5K6JsIZ4bTHA+fd2oaWsx4Yd2YmdhxXo9bUy8IpTP6QohhLi9STAV/5HqnFiO 7vXCyXINS9T3dY0klu/jy+F23PA79cLzjJnyDd9OncbAj//NR18MYNwiG86mtu/ZVBDDdmN1xvT/ go8++pDPRy/G4WCEagSwibPb1Pmi30e8O3Aqqw1n85La40w2D6G58iqL+/fjmT/czyMvv0e/d95j qndM13GLzmGlNZ/BH77L+/2HMnn+KuxD259rrUs+zSb9JYz85GPe//fnDB+/CMOtJym/iSAYZD2Z tz98h+fvfpj/e+Ut/v31SMxC2qNyqssIXv9Wnfnjv+GDdwcwZqoGO6N6Pix6yWowz/xtBoGZvbzk tew4X7z3On9+9HH66/tQ9GO/yKo6x9DnHkVN7XU0tl6iMeMA7z3/mGL5XQx9226DK0K4gSbjRgzk ww/ep9/wKehbexBV0hFj83GcMYZP3lf00YBvmbFUF5+rHc9NxDH7wd8yuO1RgCsOvPLqF3jEqa5K QTTb1y1l9Bdt1+wjPh+juGaHImj7J0mLIhh/8/Lz3P/EE7z45gf8++OvsbygGvOsjmTav57lpU93 KLe95jEJtXue5t9jFuKf2qI8n8ULtbHatI29gRfIrZG/b0IIcaeQYCr+Ow0V5OdWqEazWjinPRGt kF5en9TaREVFGaXFBaSlJJOcmkFhVc/E1dpYRX5GGsnJyWReq+g5QtZcR0FWKompOVQ0NlCek05u oSIgtdaTk5pCekYWWemKfZOSyCq77iHRujIyk5NIUhwzr6RnymmuLSNbsX9ySiqZuUVUN9zcuFxV USaJSSlkZGeRkZ6qOJ90CqvbxxxTHUewJETRtirFuSYr2lly4zufWuurKCwop9fB2YYyktrqzsgg vaCUph/7NVZLDZmK9qdnZJJfooh6TRWkKJYzMrMp7OiL5mryMtv7NiUzj4qa6wJxQ2l7H6VlUlBS RXO3Y9YVllCrbGgDZZWVNLb2vGZ5bf2enNLzmtWXk6Y4h6zMTDLSFP2TnEphrepsW2vJSkkjv6xB 1bQSsjJSSUnPVlzb9vPJyS9B5mUQQog7jwRT8dNpTcJspQ/X7uAuaK7OZdeitxhsdYLo+BRKJV0J IYQQN02CqRA/oYJQV2ZMncKkUcP5Zp4BgWlV0ilCCCHETZJgKoQQQggh+gQJpkIIIYQQok+QYCqE EEIIIfoECabiR7XUFZJ4MZ166QohhBBC/A9JMBU/KjtsAzMtz93UHPI/vQp2TulP/6mmXCqRayGE EELcziSYih9RjduwYWzP+u9rqgzfjMb2k7fegqxLbFg2Bi+ZMl0IIYS4rUkwFd30MiYaYcyHmqfb P1flc+liNKkp8Vw4H0NhZQXpl89yNipX9WL1JioLM4k8HUpI6GkuxmRR2/kG+Toi3JcwYKkpp86G ExZyhqjkQnpMstT2YvjIc4SGnSLiajwJ2XnUKCuuwNtkMtsiC8i62lYeSV5Na492X0uOIjw0mNDz 0RT2eOagifykywSHhHI24gpxMYkUVDd/39kKIYQQ4hckwVRQEheG104frhRcP/dlKe6TZuGR2Z4u m7KPMuLFZ/hsxgpmjhjB5OVaaC+YzGf9x7I1pW2LHPY6rGPWyBGMHD2eCSNnYHo4ur2qyhRs5vXj qdc/ZOy4sYwYPhlD11NUdqTDumz2bzFi/qTxjB47nhnTx/PaxIUcUR67EqfF/RiyyAiDRdMZOfg7 Fuj40jHLfd5RaxbNX8j0Md8yctosNLS3U9hRFuiK+qLZfDdyNNPmzWHoi6+hcShbWVafdxmPHXs4 l1IuXwIhhBCiD5Bgegcrjj6AzqSpqBtY4LL3GJnVPccQW+PdGbnMi+5x9fyq4RhGKLa7dpRFWgYk Kdalek/hu915bXtQUd1t45xdfLZud+c0lbVn7ZnvEdxrW1IOu6G1wkMRbVXKIllrs5EzuW3BtBwn jYGs9E1TFaZhMWYGp9reXd8QzpxZtuR2qyt1y3KWnmibl70W/wnfsnxv13MIhcf3EJjcPmd7a2UG h/ZswVxfncnTTQlMlIdYhRBCiF+SBNM7UUMelku/YeAiO07F59LQ6z3tSgKWG2B3LLXbumZOLPmO jfGKj+lH0LOxJbMJ4r1nMXx3AW3Po4ZvW8Gf1dRQu+te7mv7/1Tnzr1LTlgww+lAL8dq4oCbISt2 pvZY29KiirQtJXgYTWFXR3FLGo6zphPWFoLj7FFTu4f7f3MPdymOd9dd9yiW1fiXZUz7tvmn0Z/+ JU+0tUXtYV75cgVh+deNDDfVkxsXis28oXymsZnSJvmKCCGEEL8ECaZ3opZy9lksYcIMHdz8jhGf XULjdeG0OSkI9Q1OxFT0WKsIpiNxarttn34YfTt75Uhl/I45TAi6RobLauZtDOnaPMKefxnu7Vws CzZnlKV/V21VZZRWt4fEeP9NaK3c1XkLvm20Mysnn6rG9s+7zWbim9lRls+WBfM431aW48UHS/fe eI7KTJuF0yJ7LtZ0ra7eO4+/G3drY2sDhRmxBO11ZdW0ScyzOaI4mhBCCCF+CRJM72AtZUkE2K5h iY4x5u67uVrYMVTYROh2Kza4num8Da/ag+BF7/PZukjq8o8wcfh3bImsJdZlFM/NdiFi33Z0l2ug tUaXddZ2mM0fyL2vfYzxEdUt+Pxg1NUXo75KG30DI4wNrfGLVN28r0rC00YbTU0t1uiuQd9oLZrW O0ipbiF1/3r6/f2PDDXdTxkNRDgt493/e57FbuGKpWYubFiJuq4xRjraaK8xZoOZBd5hbSO46ei9 OpRpWiaYGWijs2YtOurq2J5tv/HfeO0qO9ysWKe9HG37/aRUyHdCCCGE+CVJMBVQkcW5C+dJLVEF 08pEHLU02Jd+4z3tsrjjeB9JprG1hLB9BzibVkVNxnl2BpympLGe9PBDbHZxZdexSAqLcjnm74lX eOeTo1SnnsfDxQV3zz0EX0qhrL5b9K3J44y/Ny6K/XccOU9uefvxs8764eLmgffRc5S1NpBwwBvX rV74n7xCpXL3KiKD/PDYvBlnNx9OXkykXDXSmhQWQUREKHu2OOPs6sWhc+mdv8ZvLE7lzIVL5FTL V0AIIYToCySYihsUXfVi9fIAJK8JIYQQ4uckwVQIIYQQQvQJEkyFEEIIIUSfIMFUCCGEEEL0CRJM hRBCCCFEnyDBVPzsStPjyK+RfhBCCCFETxJMxU+qIuogR5KqfmCLOjZ99QzLT9VLZwkhhBCiBwmm 4idVsn0iM4/V/eA2TdnRZMuIqRBCCCGuI8FUKDU11lOvetl9Q9Yxlg95i98p55d/gknmx3u807Q5 8wjTP3xWOSf9U598w8QvxnG0HFqj3Xnj6buV6++5u23f/2PulisdexFpP4c/3aXGXY++j1tCy3Ut aCT+sCWf//FR5f4vjTYkLLNtutIKbN76HU+8NgMHO13eeup+RfmzaPimde2ZdoBR/3qivT3/+pRB 7wzGL7+9rL6qmia5vEIIIcSvggTTO1hL9TUSLoWxbf1yRs9czOEM5XRJ1BcnEp3ZFeeCtAagflw1 X2dVCBM/nsKxko7SdNZ+NQRfVRAs95nNopDGHzxutO0Q1pzufiu/lYs71zFriRMdc0S1xO9m/lxt QrOVtWI66BVmu19Wlcah++UUTiufGCjB9oOPcS3oqKuGLdMm45enWgq34cNvF+C08zAXYjOoaJbr LoQQQvRVEkzvRC3VhB92x8LKAp2luniFxvec5am5iJNeG1mjoYmWjh7TvnuPSfsLlUXFO6fzpWd2 t41bSTt1gjTVrfkMt4lM9cv5wcOHmgxC70y3YNpcjJvJDJxjuqfGOg5rbcDZL6mtVjbNm8+F2o72 p+M0ZzohpcqdCd+gwcIVeqxZuYIVq4ywdTtIfmv3qrI5vM0WA10zbCwt8IrIl++AEEII0QdJML0T NeZiOv4tXhmow9myGwo5arAAQxcffHbswDfgAGbqXzH5QLGytNx3Nh86Jn9v1Wku45l5oOAHD3/K dDD64d1GVZtLcTWZid3V7jfd69i30gQHv7ZjZSmC6CxOdbS1NQ3HWTMILW9byOfQ1kOcunACX8/t 7NixC5sVU1lzuvyG41ZG7+C7557g31bh8h0QQggh+iAJpneo1royEs/6snLwW/x7ng1nUspUJdcw /3AQO3Pbl4ou7+DLvz7KpIPFqh2jWNLvW9yvqm7tl13FZsFs9qoGUcsC5vKaVlD7Qm0Ox1zdCM7v +ZRnqPHX6J7t+av8hAO2zJ1tQmRJ+7bpxxyYu8SQi22PDLSmYDdjmmqEVKFJsTx9KsHK7Hmecb8d ze70jjHfRvavGMDCwI5g2kL2KW9mDv6Qr+dbExybR73czhdCCCH6JAmmgvq4Q6wxMsA/rv1+fG2K L6P/+QwP/uVd5juFcsVPi8df/xL7c0XtO1RGsGr42zz+yJO8/Ml0fK6UdautkYPaQ/n9Q4/x17eH ssYliOK2INh6jS1LhvPMo4/z7Iuv8rfnnuShR7/AMiizc8/00M2Mev0FHv/9k7w1xYqryiBahdvA V/n9M3/m5TF6JJUloPf6n3niTy/xxVxHimoTWT9wCZorxvLGHx7l4SfeRcMzurPOwkAzphtvI71W rrMQQgjR10kwFUIIIYQQfYIEUyGEEEII0SdIMBVCCCGEEH2CBFMhhBBCCNEnSDAVQgghhBB9ggRT cUepvHSAg4ml0hFCCCFEHyTBVPxP5Iba8fFDaqipfcmh4j7TKjaO1ME/uVIukBBCCNEHSTAV/1P7 vljM3ty+8Ub78hA3Jln5UNkq10UIIYToiySYip9AK53RszqVnZZrmL9Ym81HAjB/Zx4BBR1JsIrY Y9tZsWQJK/UdCElS3VJvysRLWwtn39NcCd7N6qVLWG28lcjCtlqL8NXWYPEaS/aeU81xn3cGw8Xq aDv5klHVcpNtLGWnuRlbA1M717RIQBVCCCH6FAmm4r9QymkPLYYv8FNEToXaq6yapcGGLd7s2e2D 64bZPK02EH/lhFGNhLvYorPOkd2+e9nj6Yi65kbClFMyVXPMYg7vv/Uxy2w82eu7C1ttTXTWB1BD E5d2rGfY25+zNUY1jWllOLNefw2N3ZeoaLy5ljZkhrJe15iIkq519SlHWKShw/bQTLmUQgghRB8g wVTcstbKNHabzuWzASNYs/kwmapRy/ita9F0Odltw4tMfHQi/m3PmOaGYmRuwcWCruIYDxOMd59V fq6I3Y+5oTUpquxZFROAmYEt6argedJzHcZ72kc7ay5aM0rv1C21+ZyPMRpOkdetbaQo5RzuhtN5 962puJyMpapvPHUghBBC3JEkmIpbU7GPl9SeYt72C/S8iV7HcU0DHPYldFuXh/nrc9hXCvWxOxn+ +u95+rnn+fNzz/Ks4s9zz73NHJdw5ZbFkb5YGDuQpQqixZf3Ym5kR3pD+3J13GEMtKxIr0lAe8BE gutuoc0tKZhPm83xH/oxfkMUpt/+iz+P30BRk1xmIYQQ4pcgwVTcmpZ8fG2NMTG3YK2pPXtCEuh4 VLPwmDUjNF2p6Ng0wZ2/q43keFuCLTnPeiNzzpV1r6yMtIL2rWtTgnC23Ua5qqQh/TjONu50/aC/ GG97YzQmjGSU45VbanL5aQMmaIX3XliTzxlfB3QMN2BmasWWwGgklwohhBC/DAmm4j9SV5jKmaAA tthoMXOmD8rByNZigjzXM+LD13nh7+8zapk6w596kD+8toQrdZB1xhedGcN5+eWXeOXN9/lurh7e 53OhOY4Vf38QNbV7eEv/EC2lYUz8/T2K5ccYbRfWeczmyy689c0yIqtupaXFOH82Ee9eRktrEg6x Zs1KLF12ciIimbLGX/lFEUIIIX7lJJiK/1IjVZX1dP3AvZWaijJKSsupbVKsba6loqy681f7zfXV lJaWUlZWTnVdo2q/FmoryqmoqKCiti0dNlNV1rZcqdima/zysosV5rsibq11Z0z5QO9Y74XNDdTU 1tPya+puIYQQ4jYmwVT0eQ1FCexz38CAYSPQP5JyC3s2EbVlE0fSq6UThRBCiF8BCaaizyu/soMp k2aweN4CVnqGyTOgQgghxG1KgqkQQgghhOgTJJgKIYQQQog+QYKp+FGtTdUUZhbLLXQhhBBC/E9J MBU/quCCE0s3hPGzvE0p7zTmBxOk04UQQog7kART8SOa2TNlGDYx//14adWVPVgeOP/DG4VqoDZw i3S7EEIIcQeSYCp+WPpmPpy2t8e7PlubG6mvraW2to6G3l4C2txAbU0tdQ2NNLd0bZB/ZB3jrXZT 29hMnWL/+sbuE9O30thQr6i3hprG1l6b0qwor1WU1zZ0heSWRsU+qqHcpoY6amrqaO6lPTVt7VFs 2Nwsby0VQggh+ioJpoLagiTOhIeTXnL9zfoa/OdNxi6x22hpfSzGs77j7b/8H88++zofDVzIsYKu KFgZ6c+ysf157o9/5l8DBvHZ03/D+FKDoiAKzWF/Re2hJ3jxxRf40x9fZ7LuPkpVGbS5KJJVEz7k 2YfVUBvudV07qjm3TRFq+3/Ii8/8kVcHTMLMK4wqRQS9YDKGR9SeZIrBBqZ89S7P/eFZ3h1jy7XO 9uxlydjPeeb//sw/+n3OB0+/yPJD2cqyhuI0ToVfIK2oXr4EQgghRB8gwfQOVpl+Dvf1JhgZGWJg u4UrxdeNJmb6MHqGKxXd1zWXklXYbUTz8GI+3BTf/rn0NDMnLScwu6O8iYPLpmF/pVa5VH/eiUVe p364UbX7eHnKnh6ris5aMmLOJrI6D1vEVu0FmO/JVC4FznmPGduiVbNIteI+8Cs8cts+1xAw6Ts0 9+d31pW804HdUe3zk7YUXsbe2gRjE2PWme/gYk5Vn71WQgghxJ1AgumdqKmI7eaLmaVjyy7/48Tn lvcyLWc9wXoGmByIu259NQFms3nrT8/x4iuv8dLv1XjVLlZZUnFiA6Psj/TYuu5aDkXtuZSSkxZM dzrww23L8uSFybt7rAo3G4x6aM/R3Oxj3pgu8qGt6r1Th7CjM3s2sHfaINwzVMeP3seqmd/x9nN/ 5i/P/4sBk9ZzqaT7zf5mSrLiOO7vg63WPGZa7aWyWb4iQgghxC9BgumdqKkQl6VD+GjYCvyv5PS+ Td4Zlhnbcv5a9x89NXBy+VhWH0xTLrWNUF7bM5dXHFS/oo/14ONlrlT2qKiFFtVIZ8kJMyY7HOxW 1qoou+550sJd/G16QI9VCZ4z+MYlqce6S9vN0dEPUX7eP3MoOwq6yvbPGIqXcrmAXet3cKW8QVXS TPLWebxvefq6k20lN9IX9cGf0F/T87r2CyGEEOLnIsH0DtZUcBGnxSP5Zt5a3A6cJru6Y9y0lQu7 7DBzOEFDjz3qOa2zBE2HnRw6cpCAPVtY9smTPDjJmtjCtgBbR6jBYhaauuO/bz8H/L0xnTcbt9j2 uepbUgMYt1CLLbv92e+/hy3WdvhcaL8d31CaRtjBAwQ6L+Ch99XZe+QQx88nKkdEqYvDatJU1rn4 sG9fAF5u1mgu0+F0uaJFGSdRf/dF5nuc5VptPYXRR1F/+0UWeUcrInEqBq8NZ976rRw5coCDB/bh qjef1YdS2ttTlUXovi3ozRnBcHVnLhfKD6OEEEKIX5IEUwEFV9nj70tEjupHQLXpbNJfwY7Y2t42 ZoeJBtMXaGDpc5bijLNoLFuG89mOnxvVErbdnLkz5rBMxxL/iNweexed34P63DksWq7Plv3nyatq v0VfmRaG9dLZzFm0DO2V6sybtQBD10CKVMm4qTgKT1MdFs2ayfy1bkSVtK1tIcHHFnV1dZbpWROe X8QF5/UsWaKO9jp3kivLueDpz16/bRgsnMWseSux3n2x832sdVkR7PTbT0yRfAWEEEKIvkCCqbhB SbQ3K+Z7UCJdIYQQQoifkQRTcaPWFuR1n0IIIYT4uUkwFUIIIYQQfYIEUyGEEEII0SdIMBVCCCGE EH2CBNM7RUUsDtsDSC5ulL4QQgghRJ8kwfQOkXzQGQMbH0qlK4QQQgjRR0kwvRM0F7DdfA3uIYXS F0IIIYTosySY3m56ec9TdepRjOZtJKVj9s/WWq4EmDP8o3/wp6ee5NVvdQnL63mLvyLGl8mf/pM/ /uHPfDlLE2OjzSSr3rffmnOUxUPe55knXuDDSRZkdR38upmihBBCCCFungTT20BrUx35CaHYzOzP B+sO31AeZjuRxfvyu1Y0VhFz5iSxqmmVSi95oTnWklRVcWX8HhaNUud4RhVtWTb7rCvzRy7gQo1i oek0Mz9bRqjq7fu1VzYzbNxWypVL1QQuGMIgDXvOJRfRIO9CFUIIIcQtkGD6a1aZybFAf6xWzWXy 1DX4Xb3Wy0anmdFPn4zr1tYXpxB8OADfvQHs2mqO+owVRFa1l4Vaj2R+UFXXxk1FXDh6jALFx1S7 UfRb48HxQwHs3evPwSBfVn35Ce5pXZtfi9iHzsLJzNGzxWtnCHl1cqmEEEII8eMkmP6K1UdY8shv X8MoIO57t8lymsFYn7we62qzT2O9XJtVOitRX76C5YunM2GMNtGqW/Unzb5l+YnqXus7r/cVb49f ivaKZSxdulTxR501xtuIKb9x2+idy3hK7S22JMubAIQQQgjx4ySY/po1lJJ4PgTXDRqMGTkRU9+r 9Lx7fpXpX+sQf91uWYHGjJpzqHP5kMkUvv5Cv/NZ0Wvhjkwcb0RCR2W5p9hs7UhM28hnpAVfz/Sh tVt9ieGBROY1q5ZauLjXmilDhqFhsY2Dp2OpaJZLJYQQQogfJ8H0NtFYlkHQxvm8r98VONO9tJnq dqaXjXNwm/8JD6mp8djrE/E+GcCMv/+OV6c6UqD69VLGMVs+ef4x1BTb/P2bFeyP6vpFf+rB9Xz8 QnuZ2p/7obf5CLn1bSVl7J46nVWbDpNVLQ+YCiGEEOLWSDC9XdVGo7/QnJOp1dIXQgghhPhVkGB6 uyrP4OSVGMrl8U4hhBBC/EpIMBVCCCGEEH2CBFMhhBBCCNEnSDAVQgghhBB9ggTTX5uKqwREFEk/ CCGEEOK2I8H0VybJegzLjlfedudVnXaUWR//hd899nveXnuy941yg5lsupPcptv9Kjfgrz8H37RW +cILIYS4o0gw/TWpDWb4B8bk3qanp4xh6e48O2FX7xvkHeFfc21JbriFSgt388KkXT/zmSSz9m+a N0xscCu2TPkEpxiZmUAIIcSdRYJpX9V6/WhZK9EOq1niH9O1pr6MlMhgvLZtw2OnHyGxeT1nfmqt JP70IbZu88L/4HGCg6PJr+4YbmwkJyqUXd6e7PQ5TOiZyyRndY3E1hUlEuTvwzb3HQRH9ay3Lu8q h3y24+Gxh6OhIZwKzaAzK9bmEBKwg20eOzkQeJzjQbHc0vhuznb+Onn3dSubSArfxzav3QRFZnBD XGsq5uyRPWxTnKfvkROcCQknX/marDoSdq3m8ffm4hWwB28PD3afSaDpZgcim6tIOheE13YPfPaH k1vVvmNN2mm2+R4iLjuLy8cC2K7o/6OXr6lmw2qlINyRQY8PwHTnXnZ5bWPL3khV/7RQdDWUnZ7b OBJR3FYT8acOss3zCNl17fsWRYfh4+nJwdA4ym4YGW6hJO0i/ju92L7jAJczy3uUFcSfxm+np+K6 +HHy7DkuRxWqrptMdiCEEOLXQYJpH5N1aT+Wem4k1F5XUB3J6uXmhGV1FTSkhmBrqo/6Mg00Vy9j 6jh9DiWUtRe2lnDIxZpVK1eyXGMVhnrqfPLXaXhcKVEWRwVuZfVSTTRXrkBbS5cpX41lpfVFZbhq KbyE9RJ1VurooLl8JatWr8HxkGrC0tYE1k1bwmrdVWho6LF+zUief2SdahQ3j+16a1mtsxJNTW3W 6c7ghbtncO5WBv6yPHnhhmDawNndlqyYMYh7Pl1DSo/A1sw5K03mKtqoqTjPteu1+ObZv+OmbG4Z QRum8uBfv2aFrhaaS9XR3XGK+psKphUc91H032odVq5U9JP6KnQ27SRNcey66F18+tb/8co4bayM 9VmtOY/RkxawN71F2Z7Y7Zr844F/MnWVDqs0FjPf8KAigra3NT3IC6MlA3jxGQ22BGzGynwdi8ZO w+lqWzJtJeOYJ2u1ljLkg7exvtIzmeac3YfxilWKNq1ipcZKlunYcDS6/XrXpB5FZ8YSVmqvZMUK QzSnD2bgkN2qfxSU4Wegi+eZdImoQggh+jQJpn1E4mE7Rg8dywI9aw6FJHH9fE1Z/m6stfRTRIxu Wpp7jB6mOWpjGBCr/Fx8YSfaBvYkVHWUXmPrajuOpihWVMewUXMpB1K69g73cGbzzmjl54uuCzEP qeuquO4qjrpmxLdtXuTFyy/rdXucoJC9Lmfa21t9iq/fnMuJmo6yZoK9Qsi/lY7oNZh2nO8lhixw IqXHrfxCLN/4AIfUrjUp+3dxpWOYttSfl6bvveXrUR5/HHt9Twq7rTvmsIldgZnKz6EuMxmzJbqz LHDjBOYf7vhRWgYmr60m5XtrP883dw1g0/lUlDO5UktJTc8QGrRuEFaR3dbVZeNtb8ThzK5VFed9 cHDfr+z7nMO6fDHWu6uwKooj++JUI7WtpJ/2Y9O65QwdM531PhHyF04IIUSfJMH0F5eD5iu/Y7Cu L+lV37NJQy52Zvq4nSvusboq7TSW0z9Szll/z2/uUfz/aebtSlaWXXVzxNrsGL39Tqgi+SDGw60V R+5NM/b9H1TUdR/33X2Xsm41tXt4od9izioP30qEpy79Xn6ivezJf7Lc+RTtMbbtNrY3E/s93172 u7/w1RLXzmBaHbmFfz77gKrOu/n7eAvSb0jgPxBMy8IYMMfhumCq6If4fczu/zqPKOt9gk+mWxDT EY5zd/L8RO/e66uLQ/PTl1XtUfz52xA8Yyram3FAn5cU6+66/17uavv/3W3bvMFKz/bgf8R5NouC SjqrCnSexbzDHTE2Dt0XlxP1fZe84QjjXnGi9Ae+Ffv0BvYIps2l4cz6+92o3XUf99ylaEvbH7UH +WCBGyVtI8BNefgZT+elpx9SnssD/xzFpsDEG6+/4rt03GU2zz8whtAa+dsnhBCib5Fg+ourxt9o PnNWmuGyzY+wKx2jaF1KY/0xXOnQM0i2JKM3TpOt0R33pes5sGwWBqohtbJIH1ZomRPZmZ0aSbsU R261YvvKWGw0FrIrqiuZFCUlkJxRpvx8wmQyGy/0bENLQw3KxzbPmTPEoXvkKmD1PwZzoC1Up/kz doNfj/22DR7Kxujam++Oir28PPvw9xReZsjSrT1GMeESKwdbk9dtzcV1/RnmU6Bq3m5eGuDYObLc WplHSn7VjzbjWoQ/6zV3Xvd8bBN1je01hXkuZnlYV/+d8VzIspCOlJ3Impen0zku2VBManpJt9Ht U0x9fSs/NFvsCdPhOCd3LbdWJuNmosOJgp7b1dW1f1uid61E81C3qJu3n+XfanKlvqvtObHhHNjp jt3aJUxb5UWO/LZKCCFEHyPBtI9oLIwjwNWeDRtMMVvvRkK30awQm+no+V1/Q7yMQFdLZo8fz5Rp 89E3s2DpgHf5099HcVh5n72SYC87li+YzYSJk5k9dxka2m5cudY+tpkYugOthXOZOmUyU6ctQVPH hsMX2m/Q12WHYrR0KXPnzWLihHHM0tDD1vMQmW1JKkQTtfemsU5rKZMnjGfi/IXoGfmjHEyNd+cP /cewRkeTqRMmMHnuXOYvciTpJnJpRfJxjGdPZvrwt1D7/XtMnDqD1XYHKGwbHW3JwHX+BKaM+pz7 n3qdb8ZNYOFqJ6KUv/0JZ7jaR8xbt4YFU8YzYdI81FesVQS4jsCehcOsWYwZN46JM+ejsdoA59DM H29QcxFB3qYsWzSfqZMnMW3GYrQNHTmRXExZhBv/fOEhfvf5Ko6nl5J5yIw3//oQj48w4GxuWxJs 4oDOBEaOn6zov7ksXaWLs1+c8vndFH8Hloz/gEfUXmfUrMmMmmPLxWLVEHBTIQFWukybMokPX3iA V78ey4Txazma3B6kk07tRm+ZIlROn8qkKVNZvNoIl0MXlQH3tO0gHh24AC31eYrrMo4pi7Vx8jyn eiSkHH8tLdauN8fGxYeIjKo+9d0XQgghOkgw7Wtqi0m6Gkdpxz3Y5nPM/Vi391cPNZUSe+YkR4+F Ep1RTHVpBqePh5DaOcxXR1bMOY4cDSLk9FVyKruPxbZQnHaVk8cDOXbiPMnXKun+m6C6whTOhp4g 8OhRQi8mUFBe115enUtEXDLxF88QpCgLOnWF4o621pcQnZJKSvQFjrWVhZ4ntfTm3u3UUJ7NxROB BJ4I4eypYMX+xzh7NZ065a91qogNPsrR48GcPhXKiWNBBJ+Jpj3P1ZB6KYHExMuEBSm2CTpNfH7P JNxalcnpwCMcPXGKyIQsKhtu8idATZWkXjnLsaBAjgeHE5dZqBzNbiiIIfDYSU6GRJBZUU9l+iXl ckj4ZXKr2jujpTafS2HHOXo0mPPRaVTUtx+zPPUqwcdOcOpM23kEcvjkFQpVZbTWknb5HEGBivML O03oySDFtTtPZnnH2GozJRnRBB8/RpCijnMx6ZTWtJfVKK7X5bh4Is+GKq7LEcKupNP1b5t60i5c Ja9ahkiFEEL0bRJM+7iaE3pM882XjhBCCCHEbU+CqRBCCCGE6BMkmAohhBBCiD5BgqkQQgghhOgT JJgKIYQQQog+QYLpL6GphoLcLCqbpCuEEEIIITpIMP0FlMUcxUZ7K1mt/2VF186zYt5URo2ZhfmW yBumMRVCCCGE+DWRYPoLCHGbwzKv1P++orpCIs6dxW+zIUu+sSdbulYIIYQQv2ISTH9uzRdY8fka Erqtaqgu51p+LtlZ2eQV9zIrT3MNhXk5ZGXlUVxeTkVFz5fW16YcwWy0PVnSu0IIIYT4FZNg+r/Q WsrVk8cIjczk+rl2crbMYbRX91nvK9itM5OBn3/Im2++y2eDx2IZUtStrlycV89l6Bcf8I9/DmDG zP689px9j/niy+L2YTrqumDaVMqF4ycIu5xB623XwUIIIYS4HUkw/Sk1FhG205JF6roYGtiwLzyT npNfRjNviAZXeqxrorSwa/JIWvwZ8LEHHbOKJmyawRTbyK7y4r1M/npr+9z0Kr0G09YKzuxyx2y9 MToaOniFJNFwO/SxEEIIIW5bEkx/IplHNjJ9ynzsvI9wJSWfml6mJS/y12KU7dkb1l/YvIz3nnuM Rx57gicfv5cXPt1JubLkGnYvTSCwx9YNFBdU9gi8vQZTlZa6MhIjw/BzWMNX4/Q4ll0jF0sIIYQQ fZIE059IQZgTg/sPR8txH6lF1TTecP88kbVTTAjOqu2xtnTvbN5fd75rRf4Ohr/jQfuTpo0cXzqE Nae6h8kmKstqewTThvQgrMa79hhF7dTcQH7iGVy0ptBv2ApOXZNxUyGEEEL0TRJMf1L1RB1yZMaI aehaunIiOrfz+c6Coy6o2/l13qLvUBZizHfLLHHf6oGnpydWSz7l/kemsPtyfvvzqWXBzBy9BCtX d7a4bWOLvQGaGvuUI6ot16LZ6e2JjcE8hrw6ig1ubmwOjGmvuKWSS8F+bDRezrhxWuyNzJfLI4QQ Qog+TYLp/0QDiSGHOXYxFeU79FsK2Gq+ji3HervZ3sSFXbZordDHatsx8iqz8NVdi1tAHB1jqzVp oThv0GfVynU4+IRS2nGUrNOYrdNjjb4hxuvXoa+1gpUeqkcFGos4eTSIkKgCuRxCCCGE+FWQYPoz qE4OxlzXlKvyBnwhhBBCiO8lwVQIIYQQQvQJEkyFEEIIIUSfIMFUCCGEEEL0CRJMhRBCCCFEnyDB 9L+QtNUch/N5t915tTZWkZuSQlp6DsXVjb1v01RHZVU1zfI1EEIIIcRPRILpf6ohEo2JxpzNq7/t Tq027QBz3vknrz71JG/pHup1m4KQjUyat5LYilvosmsJnE/Ole+OEEIIIXolwfQ/lLl3E5qOh7id J/hsOWfFtM3Hvqe0mOjoWKpuYci07ow1M9xPypdHCCGEEL2SYPqjmrhhEs/mfBwt1+N5pms2pYrU MMymfs7vHrqfh596g6XuZ+k++Whz3mlW9n+Fh+67j7/0G8NYXWOCMlSjra3ZOM/8lKfvv4v7XvqG +StmY3a+vHPf2O2avP/CY6j95iXGrg/uVmsjibu0eVZNjXuffpmvh3zFBxZdQTIvzJlBf3qCex5+ gn99PoSv9TeTWtF602deFLiOyZuuD6YlrP/XI4q2/JGvNbdTeN2d/ubUAEb9/XHuuvcJ3vxsIP37 mZKkrOwC8/r/ETW1e3n00Ye47+6nGbrMh+LO5tRy0VuLV575HQ8+/AwfD52KjtVurilnKGilFSGE EELc7iSY9qKptoysuNN46I/jr185cv3d6sIrezHWtiWzc7SwlaKUGCKTO+ZkKsdmjQ72J9pneqrP CmbV7PnsjFVF1dyTzFy6CK/4tshbgdO0QegeyVHtW4nN4q+Ye6RIuVQcoEl/3eDOYye6TGW0a1p7 vaHreHW+Z2dZZdBaXtYNUH5uSd7PRA0jLnYM6Sb7MnKNNTElLTfdD70HU5WsIPSsLUko77au/hxj P1jKmY4kX3eKae/ocVnVT9WnNzLP/Xiv1eWGurNysSUdUT/vuAM6epvIVgbTajx0hvLVQjuCr6RS XtsoX1IhhBDiNiTBtLvWYkK9vbE302b+Yi08TiT3slEzR+3VMQi47lnJpnKiT+xls/Nm3LfYMnfI Qmz3tO8f7WfGkrXh3aqoIvLiWZLKFJ/zPfns6109fkSUHxVISEpbusvG5KXPWL7Fm22um3F22YrX luV8+pcNKGOsImzO0tTD2dUFZ2c3PLduxz9S1a7CCMxMtDC2dmTzZhfc3TzxC4uhTpVLq7Ii8d1s j4OTEw4Om/ELSqbuujP9oWBal3QQXStrErsH0+Y0LJdqY2jnrGiPMy4e29jmf56OCa9KT1ow3elA r/VVxB/HYqkG5hs3K9q7GTe3PZy8nN5jtLrgsj/as5awxtyRHfuOkV4p46hCCCHE7USCaXe1IQy4 7/cMMz/C9/6mp+4iWt9pc7Wp27qGQvZ7WWJgZIrxOmMsLNYy4as52PqnKouj9pqy0Ci89/qy3en3 jQ9NvRbGof7Y5yyytmS9kSGGhoo/RsZs8Y1RhsjKxHCOHQvEw9YY/bXrMDNexejpnspHCBqvJXEm 6CC+7hvRNzBk/TodZs+353xee/wsTzmNq7GeYr+16Om11Rl9w/OyPxRMaxMPsub6YFqZypGTJzjs 7YS+vgFGZkYsnqBOYH57Gi4+Yc4s595/TFWWcZVAfz887CyU52mkpcViy60klF8fPps4tnEOf/2/ 93GLa5DvrBBCCHEbkWDaQyOF6VEEuBgy/OuhzDHxo+S6LfL8ZjFmc3qPda2FirC6ein7r7UvV1xw 5Ys3vsHsZLFyuTY1kOVT57M3XRWyaqOxtN5IYGJbSCzGevRAjIKLVbU14eugheWJQuXSBb0xTPMt 6Ha0XI7vDVa2K9ZhAWOM9nQVlfvxj/eNaMuK10KcWaRuSHRn4o1n/kQtAnokyR9xwYY53hd7Lys5 zXpXV0q7r0vw4vXJa4ntHHqtxu7TEbgktT9LW3PWineWunRunh5ykKNX2x9huOKxgQXTtnf9g6Dg EPM0tDirCrW0lnPGRZN+n49Ax8mPy0kF1Mq7qoQQQojbigTT71VP4glbhn9mSdebSi+z5I3lRPey df5pZz597reoqT3LPOcD+K2dwhNqH7Ilrv1Gdl3GMRZ98KyiXI1H35/B9lMZXbfvG5KwGvcODyvK 1P7wPht8o7rdVm/hgN5o/vyookztfl7sPwff8+236xM9tJi+dDFDXn1UUXYXf3x3Focy2p9jvXZu OyvnTWDyl68rj/nwc1+xMTjtps68MFCX37W15b4Heej+exX738d7o71R5u7Sg7zUVnb3fTz4wAPc pfj84J90UD60kBbAl/OWsGTE28pjqj35Jhq7Y7vV3MBVlwU8qCi759EXGb3KlUt57f0T72vHnK/H MugfTyn3ffLNuexPUMXUljK89May0ivihscNhBBCCHH7kGB6C/K8VzF861XpCCGEEEKI/wEJpjet hbwL4SSWynONQgghhBD/CxJMhRBCCCFEnyDBVAghhBBC9AkSTIUQQgghRJ8gwbQ5n/CAS1TJd0EI IYQQ4hd1xwfT6vB1DDC8/uX3LcR5ruTVB9V48GkNEuR7IoQQQgjxP3eHB9MCLL4azaHvfed8PQ5/ nUHwzcx8WX2egXNsia6XL5UQQgghxH/iDgqmrdwwueVZM/rrBvdcWZZEgLsDFjZbOZkUgumLswlT 7V9TkMyJPe5YWdnguNWPK7kdDwA0kxW0kX+8P5yV5rY4blT88Qkiu6p91qKWxjLiTh3EbZMd1tZ2 +J9Npb5bu4QQQgghxJ0QTEuustlsPZsPp9BzBssiXKcvxyOhsmtVzUU0Z2iw1swMU1MLjLXH8tw9 k4lQFjaScNiLDaamGJuux8xAg++0PMhUvta0mdRDFvz9rYEsNjDBzHgdZtsOkF7ZHkxri6LZvsEI I8V+69ebskJzOZbHcjsPe2rrGvS2hlEm30chhBBC3MFu22DaWnwJ25kDeG/0ctz3nSHtuhfjN8dt Z4qhB2Xd0mqU7XwWenSb2alwN2+rTeF8r0eoYsOw9ZwsUI191kUyZrkLiTcxf3v1aVdWLQ6iVrVc lnkR381rGfbRUOZt8JWAKoQQQog70m0ZTM9Yz+Cl50ew9UrZ92xRxm4dE9wOJnVbV4rXVwvZmdx9 NvY0tJ6eySnl5yquHLBn+CuPKedyv/83bXPXj+ZYWfuoKBXn+HaxHVcqbkymlVkhGE78lCfub5tj /m7Fn6cZoXOaxl5alnDQjH/+4RnWhtfIt1MIIYQQd5TbMpgWRPpjuGo1663s2bzrJOkldT3KG9NP sdbYivMlPfdLcl3MKKvQzuWmqxt5Xm0W8W0L8V4MWmpDUUdhWTATP9AlvONh0eoIxo5fx9mOx07r i0jMKFR+9Fv3HRpBtZ31BlouZ6FWzzcBFCeGs9vDFTtrI1as2MiFouZf9TUQQgghhLhVt/EzpvVk XDzKJjtbDNeY4nEwqfMZ0/N+FmhvDKPp+l0aErE10GTyt4MZMHwiS/UW8LbaQ3y5yJvMwkS2GC9m 8NcDGT5mCRts9Oj/5F/4+xfmZCt3ruDkRkNGfT2AgUO/ZdKC1Vj6RSiPmXjYlLEjvuXrAaOYr2+N 0dwB/OGeATgEZyn3DN+6khWGlmzcsoczCYXyrRRCCCHEHekO+FV+CyV5OeQXqm6Nt2bjvGAGflnf s3lDCQlXLhJxOZbsimoqMmKJjs1R/oq+tbKAqMiLXI5Kobi2nuqcFC5fyqBzPLalirSYy0REXiYu LY/KOlX0ba0nNymaiAtXSMwpo7mhnJRIRf3F7XuW56WSU9Yg30YhhBBC3NHuuPeYNuQcwmBNMHKj XAghhBCib5EpSYUQQgghRJ8gwVQIIYQQQvQJEkyFEEIIIUSfIMFUCCGEEEL0CRJMhRBCCCFEnyDB VAghhBBC9AkSTIUQQgghRJ/w//8eOg42/7uYAAAAAElFTkSuQmCC --_004_4A95BA014132FF49AE685FAB4B9F17F657E85BEFdfweml501mbb_-- From nobody Fri May 13 13:51:25 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED3912D17E; Fri, 13 May 2016 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.959 X-Spam-Level: X-Spam-Status: No, score=-14.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM6j5Dn7tia8; Fri, 13 May 2016 13:51:20 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E7212D167; Fri, 13 May 2016 13:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=81735; q=dns/txt; s=iport; t=1463172680; x=1464382280; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=A08L9ikggngZwbbcF+S534cx5Zn12fpr3+2YC2UL7sE=; b=LM/KZgcVOPB9Teg5FZHFbp+TRiZrUUvgq0Pqr89eiQWc34mVJpCU/rp7 zxDVoUl+1IaELzqM55gixNRjHgGh4oH3F+RCLWe0SWGGs6tLh24LiL7kx WQ679qQ9MJXjHWS0/ZkmlxgB50MvINJHxeHLMf476wwcuPhLk7iEQqhhI w=; X-Files: image001.png : 55044 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAwAxPTZX/4kNJK1egmwMP1V+BrRbg?= =?us-ascii?q?WeDEA6BdoYRAoEtOBQBAQEBAQEBZSeEQgEBAQQFIAgBWwIBCBEEAQEGAQEBGwQ?= =?us-ascii?q?HAgUQAQ4MFAkIAQEEAREBBgIGiCHCWgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4Oi?= =?us-ascii?q?nKBW4MahSMFiACQJwGFEAGJBY8gj0ABHgFDggYbFoE1bocHAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,615,1454976000"; d="png'150?scan'150,208,217,150";a="272514576" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2016 20:51:19 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4DKpIeL003532 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 20:51:19 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 16:51:18 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 13 May 2016 16:51:18 -0400 From: "Alexander Clemm (alex)" To: Linda Dunbar , "i2rs@ietf.org" , "draft-ietf-i2rs-yang-network-topo@ietf.org" Thread-Topic: draft-ietf-i2rs-yang-network-topo should add a section to show the XML formated Topology exchanged over the wire Thread-Index: AdGtWMYcvTozCjVmS/2fDSj0Cwq1aQAAFjGQ Date: Fri, 13 May 2016 20:51:18 +0000 Message-ID: <77da5a7334bd4f25a955fb0c5392b512@XCH-RTP-001.cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F657E85BEF@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E85BEF@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.77] Content-Type: multipart/related; boundary="_004_77da5a7334bd4f25a955fb0c5392b512XCHRTP001ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-yang-network-topo should add a section to show the XML formated Topology exchanged over the wire X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 20:51:22 -0000 --_004_77da5a7334bd4f25a955fb0c5392b512XCHRTP001ciscocom_ Content-Type: multipart/alternative; boundary="_000_77da5a7334bd4f25a955fb0c5392b512XCHRTP001ciscocom_" --_000_77da5a7334bd4f25a955fb0c5392b512XCHRTP001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, thank you for the suggestion. I agree. We will incorporate examples. --- Alex From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Friday, May 13, 2016 1:48 PM To: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org Subject: draft-ietf-i2rs-yang-network-topo should add a section to show the= XML formated Topology exchanged over the wire Dear Draft-i2rs-yang-network-topo authors, As I2RS is to define the interface between Client and Agent, it will be ver= y beneficial in the draft to provide an instance of the data model you have= specified. You should have a section on Examples over the wire between Agent and Clien= t based on the YANG modules specified in the document. For example, the "draft-ietf-netmod-acl-model-07" has a section on the ACL = configuration XML: [cid:image001.png@01D1AD1E.85630BE0] Thanks, Linda Dunbar --_000_77da5a7334bd4f25a955fb0c5392b512XCHRTP001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

thank you for the sugg= estion.  I agree.  We will incorporate examples.

--- Alex

 

From: Linda Dunbar [mailto:linda.dunbar@huawe= i.com]
Sent: Friday, May 13, 2016 1:48 PM
To: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org
Subject: draft-ietf-i2rs-yang-network-topo should add a section to s= how the XML formated Topology exchanged over the wire

 

Dear  Draft-i2rs-yang-network-topo authors,

 

 

As I2RS is to define the interface between Client an= d Agent, it will be very beneficial in the draft to provide an instance of = the data model you have specified.

 

You should have a section on Examples over the wire = between Agent and Client based on the YANG modules specified in the documen= t.

 

For example, the “draft-ietf-netmod-acl-model-= 07” has a section on the ACL configuration XML:

 

 

 

Thanks, Linda Du= nbar

--_000_77da5a7334bd4f25a955fb0c5392b512XCHRTP001ciscocom_-- --_004_77da5a7334bd4f25a955fb0c5392b512XCHRTP001ciscocom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=55044; creation-date="Fri, 13 May 2016 20:51:17 GMT"; modification-date="Fri, 13 May 2016 20:51:17 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAqYAAAFKCAYAAADPFZ37AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAANaESURBVHja 7J0HWBXH+v9Juem93ZteTK92o2mWaCyxF+yK2LBiF1RAuvSOImIXFRRBRJEiXVTEgqIovffe2+e/ 5xzKwZLo7+afa5L5PA8PZ3d2Z2femZ357juzOyoIBAKBQCAQCAQPACrCBAKBQCAQCASCBwEhTAUC gUAgEAgEDwRCmAoEAoFAIBAIHgiEMBUIBAKBQCAQPBAIYSoQCAQCgUAgeCAQwlQgEAgEAoFA8EAg hKlAIBAIBAKB4IFACNMO1JJxKZZz5y+SkFZAffNfI9WNNaXkZZbSKArwwaK5juyb8cScO09SUV3H MqsWZSYQCAQCwa38ZYVpTeENjrvZYWhohN32AFLLm/6AWDPYPHkk3/fsTNfRy4gp/GvYIv2oMeM+ 3UTan3jN0htRHD4SRmGt8t4mKosyiYsM4ODRY1wpbLi/SBvyiTq0BSMjBwKuFNwWXJt9nm0Hg8lp 4K9BfTa7dZcy7KvneGp+cIegtCPGjP/SnPQ/MTkl16Uy8w6nsE0j13EzwBMHawtMzS05cq2Igosn cLSwwM7Wln1hpzm62w4TYxPMLKxxsLFgk6kxRiY7iS9tIu/CcezMzLC0NMPU1FT6M8bYdDfRyeX3 lp6kMLZZm6BruZPYwvrb6/XZADx946jq8IBYQ9bFk9hL1zLcZI1HVBJ1f9VGTCAQCAS38RcVpnWc NtFm5qSlWNs7YGW0kfWO+0iv/oOir7iEldVGzuT9VexRTMLp9D+xg27gqPZkeo2yIauDSMzGx9EW MwM9Rk0dhXF02f0YnaDNFqxaa4CdJJSWr13HvvgqpfAmLpjP4MNfdMn8q7kZy3bx4Rz/28ss+s8s s3qOrJ3Et2NsyW5qL8fMc7tRffpzJhlKDwNJJRRfj2DrvJ48MlyL/e52zFUdjY61K8YaA/jPT0tw 3mmL+jfdMD1fTd0NLyZ+0Zfxc3Wwd3TAcfMmZnUfz8Zdl+/BJucxHrEIk82bsTJbyeShjlLtUaYa q2md+XFtAB2efcrPM2PiLBbrm+PkaMWG5frsCbjx12zGBAKBQHAbfzFh2tDSSTWScymOhLzWLiuD NesN2XdFUqZ53vykooKKyreYBxdD4nbekW13mYSL82Je/XdvJo3qx1ufT+JQ4B6GvPQIH0/eQa7S VeozIjDepHfPwjRupwbPy6/5BcZhJVAUwdxvX5K2VfhQT+EpK4rzYOY3/5Hv66RqQVyrZkvfxyvS vid/mkVUbhHRjuo8pfIU462iUOjscrapf8ezsvhf/pKRg7sxwiNLcW55FKPfeE6K80WGLzxGyS3p qrh+FI3eb8iv+XrXORy+pjji2OrOqHzaH+sd9kz86Fkp/GlGbQqj5l6LofYm2lP7sc4v+7byqSit oKGqgK32yzE5XXrvRZsbzVojQ0Jasha3zw5D7RO0SdO6FLRVp7J8T9x91pkaAi1n85bMfi98xvzt 5+V7S+N2MuDJfzNRZxsuy4bIbfTv3gsJzlSyQm0y2xb24xEp7LnXujNw2DK2HU9RhDWlSWG/8Mq/ ZOX+CWv3XVIalq/loNav/Ft2zbd/ZavjYr5cckoRVBbJqNdlNn+JEYv9lMqsCp/1I/jXM0Nw8d3J uE+eko55hREbfSXJrqAxL4rV/TrxsBTv89/NlwTdfL54vDtmYbn3YIYE1k4dwPrjt5ZZObt7L+KE 8jPAGV0+33ITrhzEyNAJWSnWn7NgkLFCcJ5eNgL9aFmqKtm/zA6vcxVtp0av0cPCLeZ3k1MZZUyP pRFt2+5jf2aHsvu4MowZb/dj/60u5bo8ws4k0OpfrYl2Zq7lbkplD0jNTfwR4yYCgUAg+N/xwAvT hspCbl4MZY/pXD75UZebt3jLitLiOLJZn2UGziRXtu6tZr+VCU6BCSQft2Shpm+baDg2sye6sdKP syZ0mWiAbNDRx3IyujJB2cL9ClM5NzxZ6eTVIu6aid7qhOsRhSen7NoR1izZyNXWY68eYt0yC65W tafX1mQK3w9ZyM6zsvkDDSScuyRPW+6OUXxjmdh2maxdavy4I7XjtfNCsBhj22EoPy/MlemztQlt nY5QFsH8KUvZf0WhiJ1WjaDHwj0twqgQc+3pOF1QGLCmMJkz0WeJiYmR/507G8OVhBxqW4ZUa7JC sFS3Iuluc3Cby3C1XyYJ05J7Nl/xJR9sLJ1Ib1EchRcOY7bRlpQWl2KdVCabbG2ILbyfib+VnNSb g+b+do9a4OoFrA/MlP8uDTfnp/7j2BevuMiNbQZoWfooHn6qk7DQ1MDYO6W1puEybyWWB2VlUYzV hIGsP5HVFq+v8XRmmYQqriGJ2TE7Wsssm029HueJlVEdk5Z7Cotx9rdMv6hk74hR9J3h2PJQksVa 1XV4XJMqSnE02tPV2J3Q4qKuCEP1w69RNTinsE9h0m+WWXVGMJZzrEm+TbkV4NpjLl5KMyeaQ9bS yVJ2kzRSUqqoE4UhRvTTPa24VnEhJXUKm+xduAHjzSc4E7KZ2Z+tI+Vei6YkEq3hK/A8H8+VU7YM /0yPZKXg6lgnxmud4q6zNhrKuH7GD5OFa3A6chVFNkvw2LiEMZPXcTA4hqziKtHCCwQCwV+MB1eY NhcTuW8fTnYmrFq+FtcTV7l9FtpZRj/xIar2J8i5dRi/OYF1M77j455aSvP4ajk49VcOFEn92hkn Fmz2ke/1dFrI6uCitqP+T8JUkhiGalp4J0vStPwKpgb6+KUoUhzmpE7nX5dhZWOOickmLPVX02/K TLbGtrhNq1LQWauBQVDObbHWXHBAdYEOluYmGBmb4eDgSkRmR0uUxHtjPNZeKZ/lHLAwxsIjqcNx 6Xu0mL8zGpmwsnNYx9YWQUZ9PvZ2a7A5p0hPVpgzquMmMn3GDGbMmM6UydNZY3KU3HsdQm8swdXu /oRpQawnZoa2pLY4wQsveGFhaE/qfzPWXRDCkCFTWG1khrmpCSbm1lgv7sdT84/Ig5MOWWG2u33u Z4q3NYYuR+XD60UXvTBdYktmW2gD6ZcvEZ8uJTBtG9/96tnBO9dUcA7rDTokpIUw8HsrKpTTEbac 5zSCOiSt6MoRjCc43jLHNB2biRacSGmtzFk4qJpwNKGWnBALZqwM7XD0BUcrNq47IU9vdpjjLWU2 g7WmUpn97nzcArZ2nccR5fnUoVq8b37+FlO2C9N2SvHUmEqfLj/xy8+9+P6bTR3EZdZ5X8x0NmJk ZIS+oTH7YpUuUhnHyjE/0aP/IAb06kL/BS5SrbyPovWZw6OdJrD3TNptXtKytGic1yxGy9QOux0+ XMz5o+b4CAQCgeD/Nw+uMK2PY8FH79J1nhOpdx2fKycuNP/OIRcOob10DrPmzsM1rlXIyYTpUPZK p9SddmCuw2H5Xk/HBaw91d4t1mcqhOnZ/PtLcpHHOga7Xqby0n7WaR9sG6Y9YaPKN2pGuG11lgSg Pfb2jrgeDialvNX7lYShrR77rt0+mJ4Z6oVPQDAHtjlga+/EFvMVqK8O6TA3sSTeRxKmDmQo2eWg uSRMDyZ2iCt992pmu8nERRG2Nmuwj215SaUuDzubVdjFKLYzgqwYMmgYo8eMYcyY0Yz4dTSLN3iS fa8vHTWVtnhM730ovzYxgPUW7VMcMoMOYLFqLwX/TR3KOMa3qnMwluzm5GCPnb0Djo6bOXBGITeT DlliuPVY2xzGZC8rSZj6yh+Aii95YbTY6s4vJ6Vs5fshBzsIouaCs1hor+NacjAD+ljSIeehy3hW o+PLT8VXFcI0o2MJYTPBmMNXW+tiJraqxhy9UUt+uA3qmic7HB1taYj2On95ejODLG8pszEs1jl0 D2VWwp6BMzmkVNcbgzX50vpCh6MK7yhMC9i5yBqv8zLhV0a4W2CH8sq9HICjuSW2trZY29jhdbn9 HotzmYjatvYHp1CDcagevfcbrrk4nrO/845VpON8Puz0A2Yh2aKlFwgEgr8ID/BQfjO15TlEezsz 5Zcf+XWhM1dLOnoKK6+6oz5Zi9DcW4Z3C85grm9IUJok30pjMFqyBL8W19fByUM4KKmGhig75m05 qtjntJB1kZXt55dfxNrOlPj79tZdY023aZKIU8fpTHt8WVFuLJtnreR9qyDSP5Ar6a09awHmm43w vE0FNXBCvSezDij5oWL1+XyER8cXQjKCsJ64DeVXjQqitjNjzloCW/vkrBPMnLoMz2uya1axZYsO rtdbVUsVW7esx+Wqwr71pVlcvRrP9evX5X/Xrl0jOa3wDh7ru7PXdS3WV+4UkskWjYlo77vSMb7G dKyWSmI5UDZfsomdOmqsOZD0X9ahXNxmz8Y0QMkTnR/D7kMX5D+z/Rwx3xPSfrS/E+a7WzybtSlY r5jHhgPxLaGFeOqbsdNflqZS7KcMZO3RlJawetwNpjHbPFKWEY7N/onZrfOAG6+i/ZUKT2pd6JCy pvRArKe40fH1sAKcJ1vjn9Za8YpxmWrFybRGqYgusmbSCFZ6XJeH5IQ50fuZNxm5Pkw+3N1QdmuZ XSc5veiePnl2w2403TeeatkqxWX4EPRu8XbXx1jys8mt83srOKBpx6EzZfddMqkeGgy1vNxWz/fP GYjW6Xud5VxFiPkC5m4K5LZHn6YSYg4b0OfDH1ju4M3F5HzqxMRTgUAg+Mvwl3n5qTjuANMG6XNJ yQNUHGTIu68PYvfNdomT6a0pf5Hl0XfGsvtqNZQFM/qph6R9H7Bk32l8V/Wnx6JgirO86Pvuj9jG FHNq00S+GGtGXmYoP7/wFA8/8Qwvv/wKzzyuwsPPabTPDb0Hcrzm02nIHm7tqrOiXBj50b/5l5S2 lz4chYlHJIWyofHMA/IXc1546RVefOYJKZ0PM/Voq9+pkWijqUxavIjvP5C95PQMn40zbxvyrIi2 4b3XnuRfTz3Hy/95iadkL9uMcGi7ZsWVI8z58R3pvH/x1tezOHJdIYRP6HzPw48+xiOvT8C3sJS9 0zrxyKOP8+R3GoTl1v4XpZSBQ9/PeOjhf/HiS6/yyjMPS9f+lYASpUOa41nU7X2GGobe/rJVdTwm 47+Szn+Hxa4X/qAXWYo4uH6C4kWkx97g+4nr8U8spzLhAKPffIrHH36MblZnqY625dvHH+FfD7/B jL3XFKc2pLNr2WCeelSFZ1/ri47nOdoeNyQhvXXBQP797MPyurVqX7zSNevYvbCv/IW4l7rPxu/E Fj55/DUmWF+g6JIj77/6JI8pl9koZ/lZx/Qn8foz/5Li64VvTjW7VgzgqWcelbYncEF2gCSWD2iP 5dlH3mWigSsejltwNjnecdrA/4kmTppO5b2HVXjo9a4s3XVBKSwTxwGf868nnuPfzzzOy0NWcbFY oXajHOfy5hNP8rRknzeWHr/vq0bZzuDDZ6X8v9QZLZ+0+yrTnVN78Nkkt45v8jfks8dah1V2QeIT UgKBQPAXRXxgXyD4i3CrUL/gYomxaRBiBqVAIBAI/i4IYSoQ/BVoKOXUttUMHfwz333/PT/2HcQk TWtOXSsTthEIBALB3wYhTAWCvwRNVJXkkpx4k4SEBBJuJJFXVivMIhAIBIK/FUKYCgQCgUAgEAge CIQwFQgEAoFAIBA8EAhhKhAIBAKBQCB4IPgHC9MqAhb9JP+01Jf9Xcn6K2YhyYMvXntC/hmpgTO9 KPon1+Sy62gZGbP3cskfG29+KHN6/lteT1Se7Y3ZqUzRatwLzams//FZhd366yE+cf9/ozY9mMW9 3lbY8an30Y387VUFskIs6f7wv5mz/bIwnkAg+EsiPKaksKm7NvH3cmjePl4cuevBy0JeCBZjbEn7 ky5X4LeWt58awfEAW6nD7M+x0gfBCDkY29lx4Np9JKYimv5qVsTfdXWkRnxV5+MS/yDk76/KFQbP cyKp/q+diyTLH5kW0PynX9fLwRCj4/f35YX0/cboHzjzAFmvnEsn3DFdqsZXPb5AM+h+Fp+t5ZKv GQPfeYVHnviKlVvDOny398qWWXT6YC6Rx3WltmgY58UNJxD85fkHCdNmWruVoquBOJttRFtvMycv +GDQRw/FejoVXA33wUZvHevXG7PF82x7I9hcRoTtXJ79ZCQbzY3RW78B08PR1LR8XLK2OI3wQ67o 6+mw0dgOv9gM7mVp+YxTbqxZZ4CLZySl0hnJPlvZsMGEfSeucCPsENabPTlywBnbvSGk3DiNnYEB 7ucKO8RREu+N8Vj79uUzG0oJ2W+DmUcgqfEROOppscHMhfDEdtHWUJLI0S3WUj7WY+y8h4P+AcQX 3duaoxUXXJn4xXKu3/Dh3fc1udxiu+hDW9Gz8FMsAFBfgP9eezbsjlB87LwiAy83M7TWbyW+EmpS Ithstgl7n8s0NOVwZJMJe/zOEX/aFxPdDZjYH+RK4b2pmbyz7qzR1sVq70nSK2//LH/G2WNY60g2 2OTEiauty142cOOIKZ98/TMa6/Qw0NXBcNsRUspbC7SA4EMmjOr0LaM11mKop4/tniDyfudF+OLL xzA1diLq5g2CdtqzUUsfu4On21a5aq7KIcZ/L3ra69hgaIV7xM22sMaSm7hvMUFrw3bSpGSUJQRj b7IJx+MKZVyeHYf3Vhv0ddejb7KD6FRF7ay5fgwji10c3uuGtesJsnKu4Kqvj5v/jbYPzZfeCMbZ VFeq12a47t+Hx/44fm+dpbqCeNwlYaSjZ0tYVj1NBXHst9Rjre5BriVE4mTlgOd+N0xtPEkuSMbL 1gxnr3NUKBdBcRj9ZjuQfI/L2Tbkx7HVxgS309dICHbHfIMWOk5HyVZKbHliJJsNNrLewJTN23ez IzSO2t/TjMUX2bTeHK/wOM6d3COV93osXYPJVUpXY+Fl9jubs0HbAAeP0222a8w7h9bID/lm6nrM jPTQXmvDyYQS5VSTGnUIHa11GNtuwX3vIaKSW8PrSDl9BFNDPfQM7PGNSWsp7yoCLA3YvD+c+Nhg HEw2omfiSnRmawWrIdxWm1+H9OOnKcsxNJTuCetT9zQqEu+mh9EuH8I8nNFaZ8TWw+cob7VPQyVJ 545hv8mIDTp62HlEoLymRlNFOv5udmyU2gUD+114HvfjQl77fZgd44u9mb5UR204dulel5At4cKp U5y5dB03qzmsDr73sZ3a9FB0NLUIK1PY2WXxeIxPt3uN049uYuoAUzLid/L0f9aQq9TeN4oVvwSC vyR/f2GaHyOJkvXYHrkh36xLPMg01ZXYuLjgsmUz2rP68uVXm0iVB17H1dIWBwcnXLa6YDxvOjon U1siquLSjuW82Hk6zru24Wxvz7bAy9TJG/xmci4GSR2qDY5bXNhqv4l5q43xuQfvXUGsL9rqv9Jv uB550rbH4E50mW9L4Nl0Ci640FPlOzZ67GHDdDXmLJI6mW2GzBymRZxSh3qbMG2uJtZdize/7sP0 9XbsdtuMxfoFTDJwQ97vNRdzZMs6Vhk44OqylS2ORgwaNxzz31t8vNUSSV4s67OR7LxgvvzZqMVT W8fNICs6PzNf4bVoruSi+yoe76ePfEHQmjzCTrgyr2dP5ks2NjFyZoerBUs3eFAodVzHdKfQrctP LLfYitvWzegvXcw6c58OS05WJ59CV8uKiKyO6rDoqj9O5uv5cdx8tp7vKNoLT1iioW0hXWszzpIQ X6m2jsA0hcrJCLDnm2/HsM7aERcn6e9wMJmVLT14XQnngl2Y+WV/pmub47p5M3t8oylSXlKoNgPP TYbYnLjRbpv0aKksPuGpL2Zg4biNrZu34Ki/iNmG0fKlQxuTQnG0s8feeQsuLtYsnqCF5yVFmpvK Mwg45oL6l9+wwMEFM9PN7NhiyoL1h+ViJjHSA5tNNlI+tkj5NWb1elNiZQYqDmLEB28zy2wHlpqT GbrEiJ0Oxsxashq/DFnMF1k+dgW2213ZsmUHu62n0+l5o47D640FeEvnOHhfblvutr4klSB3A356 4WMMpSe3ppitjPz2R5abB5CddpqZv3Rj0EpbXA006DlyPTvdLJk6eQM+V5Q8Yr8lTJtKOLXNkk17 o9rEeVN5Gl4bh6Hy8Shstu5gu6sjOrNHM21/y2pcWWHSA+VGbG0347LNDad1E3lphinZylWi9BJW S9fhlaikZmuSMZ38M1+9NwrjrW5sc3VmzZy5rN/Z6g5PxEh1PiZb3KR2wQVHo2Ustb7UeoOxafIX 9F5ky07pPDvr3USltN4rDVzdZcEKbRMcpbLettOZ5T//iMZexfKtUZ52rFhlhK1Uf1ykP/3VOrge UVwzynEp3332FWr6zmzbtg1LHemamq5kNivupwt7rJmq+itDNQyluiLdq7vPdVxRTiqzI/bGOPrE dVjpKlm67z7vPIR1ti5slto4K+0lLDtwusU2qRyTHpgs7J2lNs4J/VXaWGyOaFmkoYaA7Vos0XVg m6x93GrNmNF9WR1SIg8tv+zC9AVSWtykeuTsjP4yDbbe6LjG1g1/VwwtPcm4y6oPXs7zWRlYeM/N d2bEfsyWHqCkZfuqjxmLDCLbHvqzw9xYPdqJ0uzD/Od7S5QWlibvhCETdPaTWI5AIPgL8bcVplUZ UWya+hNdx63EPeAiOVWy1r6eI/N+xSKm3QNQE21B79f1Sb5TJBdM+dAkrH278DAfT/e4p+sfN7Rm 84Hr95paghw2sVJ1KKONjyrtv8zcdzcg0xY3XGwxNT0l3+s6dhhHlZwVtwlTGQWRTN5oQXhGS8dR EMpkQxsuypwVtVInvXICJmElbYcnXo7kWoFCPcTvmC6f0/bY44/z+OOP8bDK43w9aBM3Wjr/urIr eLsEUFl9A9ttgUqdwU1Wd91IbKt3pjKcH2Y5dxBAlwwG8d3KAxS0CpUGRRdTHu+DyYZNcm+q/NQ4 L0x1bEhR6vcyfbV5VOV1NoTfqWMrZNMmSYDGFLTvqr7I4qV2XFbuJGNs+cE6usXssYxduoUbd3Vt 1+E7URv3+Lv0snkhjH7lSf4zx7PD7sytg3hz3WmlPels/GU43rm3R5FgtwKdIx3nCpxZ3oMfNwZS 0uLxaa67k6qrxtl2NQ6xVbIj2DN5KN5SB9wQos8YmwB52rdIcVvFSueW7ufzz7Wl0mkln5OeFzt6 TCVbTXvnaT6avuN2r1xZBJr9prNw7WJ2x7ZKo1r2Oi9D/5yUyOJ9vDXeHdnUh/1LzdnR9jDHbwvT quus6fUmT/1sSony/lhz3tbyVTKIAe8ahCju11hXBs7X5XJr4puzCYi5Rp2ydyx+C69K9Vf1YMf5 wFmBW1k561Dbw07GCUdWzj8hF8UZu2ez6KjyY1AFLnPUCW7ZleY8koVhd8hDdiiztM2IzG7PYMI+ KxxDpbu2+AybFi3jVE774U0JPszUt+eqzIxVl7FZtIiw1ipbcR6rBZqcaxNSzRx2M8PoZN5dmo3z TJXK7OMZOylW8hjf3LmYHzS30paiurPM/mk9MXdwkTde88bMwJEM2T3QXIjT6uGsOdF+vYy4MC7m NMnrzJahiwhUHsTIOozmJA/adV8Tngu7ofK6KsHZdxrtkMId592XML3h44z2koC2upp0bDNaGsep aq2aGec4uv80dRWXMN4ScsvtW0CYlyNzhkvt6hxLonIaEAgEDz5/S2EaYTmTD94ejtvFWx+VMzB5 fzqRyrsqglnypS6Jst9Z0VgtH8ubjzzGMy+8zIuPqPCajlJjl7Wf96fsvcMVa7kZuYeFv3zD8888 wwsvPoPKE70xOpp6z2nOP+tCj09/YfWhJKW9Mai9q4ese72y2QFbS1la6nBRHf77wjQjCFUTR660 9lhZwUw2tudigWy7mZxYH9ZP6MOrzz3JM8+/zcA51pxOUTT3jRV53LyZSEpKivwvOSmJ9OzSe5ia cIWlX2/kYutmWSjfqTkpCdMmQldOwjbu9pXM8897Ym7kSHpLf1Z44RDm+nYdhOlvUp+OgdGmjsI0 3Y9uX7/DM889x3NSuTzzzLPy/5+tbBH/pdEMX2hPXMXdclaKx9iVbD9fcF/1L8F2KHOCOibce+0v OF1roOySH/pTv+ehfz3BCy8/z2Mqb6HhcVPpyEb8Zw9lS/otkTZVcN7DmBFfd+K5J5/mhWef5onO A9lxrV5e/9wm/IqPJHaqAg2YKu+gy3CwW4V1jEzp1xPjYcKwru/y2GOP8eg73Vls5ttRDP4m5Wxf 3J/3+llwrVURNJezw34phmekfObu4YMZh6WdlexdZMauexWmdyPSgPdNItq3TxvxnlFoix1Kuezj iGqPt3n0sSf59/s9mKp/lOJ7GLZN9JVEzuKTbR7hZD9ntOb7y5d6Ddb4CpXHX+Dl55+V6skzPP30 M3z07VxOtrwVed1mKPMDbn9Aqby4l8WWW8m7Q/5KrvlgOMam44uVtfGor7bgZKZUbkXnsNVcxYWW h7G6wrPYLF1OTFuzVck+ZwN0vVPuq/7Fb9uA7oFzyilha8/5HJHajOaCOLatnsh7/3mRp6X74unH XmbAvG20NicFV06gP60vr7/4JE8982/6zjDh1E1ZHbvIeJVHefLVl3j+2WcUNnruNQbO9CDvnlN2 /8I0LWgHBhoebXX1up8Ny5U8pvdK8SV3hr+gwjDPQgQCwYPN31KY5scdx2KjHpvMzDHfepSEvLbe lFMbRqNxMKPt2Cuus/nkPTv5XNJTCyaw+mS7vyjOfhIfWChNp8/35LMfrNs6tsaCRGJTpV6l5DLa azU53KrA6q+ycepynPxz7im91Tf90DN0JuJKFDYrNuAa0+qVikXtfRO5ByvO2ZnNjjJPXwOuk8cQ qDxmlR2C3dQdHYaxZN6amXY7SG/tMMvOoS5tp8n6mNILOGqt57ySU8NTfwXr3RSzRTMCrRn2yzDG jBkj/Y1m5PAxLNbxJOt3p3zeZP03Cwhs0WTlIWa8Psa2g2fuku5MnG/efmbVTX+crbe3dUC1yQE4 W21DWRLWF9/kuHcQSaV3UjkVWNk6cihRSaFUXUBT04SoDjMqmshMbxlqrjjH+HEbOd1quOpsLt/M ol4pipNTdfFMuovqaSjlUuBxgq917JqTN//Mo0NcaOsCs7yZNWYDKTVp6E5cxd62kf98dsyYhI5/ R89e9JJRuN2ihavSA1g/aRltPvj0YDQWz2aP3NVfz/aJIzkpVczqAANm7pa9+FKOo6M2WxKkn+dN +dHsrFJsWaz64leOKY8LN1cSF36SsEuZt3T65QRsNWDtrnNcCdnBWmNP0uXPOrXsdFrOpovSRt4e Os05ITMgexfb4Bmh7Bq+xJAlO7nj6y7N1SRGB3EyJokOFr5syce2l9q3r1jzsY3icSftuDP6W44p HRzH1CHahBYoPQjUZBN62Ft6COtYT/LD92C4uv2xtDhC2l6hEMAZuzRYsKfj/VpdmElRixZNdhzK UPfi9jp06SJZsugrpHt/2Wq2RrbnOS82mNAkybiV8dL9vJDtp9vFUIb/FtR1tyoeuOqv46qtw81W b2dTAq7SfXldqQB891hjFnKXKUFSmV0OO0n45awOZZZ3ZBWfDl1NYsv92nzDnfFjreXzLyNc9Fhu HtN27Dk3PVZo71R4PRuS2LJ8KWFKDUmQ9XKWWsXKrMWW4Qs4UtExCYXZeR3u7/zrUfgHx1J8l7bi 5K7l6MTcKaSK6yG+nIrL71AXqlNOYbBcl7MtTfjedVNZF3zv4rIy+SwH3eyxsDKTysmAgAzhNRUI HnT+xnNM68m6Es5et83ordLF5dA1eYPXVBiNnsZUhvzQky4DJrJsvRofqbzANIuT3Ajey7xRA+jS +ycmaBrjvGoYKs+9z5LDrR6gAvavUOe7bp3p/tMQpi7QwjVKpkbLCNquxeAfv6NHj+GsNLdkQb+u vPz8RHzTf+ttmUxcJ/zMy088RlfV7XJhmWrzIyoqz9NnjjHXCs6hpvIfFl0sJ3XbEj59ZyrRzaUY fvMcQzZESp3AIUYN/pHOn73DCyqv8k33LnRZcQiZmNih+R0qjz3BG4McpC4lC7vJX6Dyryd4f/Fh 6qvPsfynjxk9fSYDfvyW3n2GMkdvO+eyav5LmzeSuMeQQd/14rtBqmhpzuClZ1/i2wW+VNTdxGTx EN7+lwovfdqNXl37s9jMXzFnruE663u+yuP/eo4fTQJpLj3NnPee57FHX2fGlvYh8azjOjyl8g4b I5QHm8vxnPMLXbt+xfMvvMjrn3xNr28n4JGs6O1LT3uyYbEag7p1o3vvgajOXoGtz9WWcyuIdNZn WO/udP+uLyNnLsPySIxivl5lCg5rhvKKyuO8/mlXevfozVhNZxKVO+b8cFTfeI63FxzuYIUkl1F8 MUqTeRMG06NLf8ZOX8GBKzKFU0v0Pism/NSLXt8NZZGeOevGfsvTL/Vin6yK5Z9hzZyBvKmiwitf 9aZnl0Gsdo5QPAjVpHNAawb9Jdt2HjQZY2srRvX+D48PNSBVyod5n1cYZnedoihdXvr3EE5llWA1 uzffLDtMacBKVLpPQnPGSL7t3pWeQydi4BBCh/GEmsvM+ugFvlBrF5GpAc6M//g5qT524ZBMe+cc Z8jHT/Pka5+j6R2Hm+ZAvl3uLz0Y7ZfK7gsc4jPxmj6Yd361obg5EZPB3enV5UOp3r3Kl917MmSy LtHKgrvqBut/eJcXhpi1Da/XpQYxp++/UXniPebanic74Qgze70g314pCfjUozr8Onw4s6eMpHv3 bxkwZDLLnYMpVVYz17fxjmTDKYeVJpHk+vPDC4/zkJSX9Z7XqIvfw0cvPcHDKj9geVL2oJrD5rUL GTNsAD26d6PPyJkYO3tyvaS18vkyfmBfKawXA0ZMk9qNzdxs0cIl530xWjyNHl278+PA0cxZZsqJ m4oT02K80Z03me+/702vPn1RXWxBcJzMwlU4Dv6AJ1QepeuyXVQ0pLCuy1vS9jMM1z8q1cFKto/r zosvPcdz735N7287M2DUVjKUy6z6AjM/epEvZ+1ue6Arurwf1bde5u3vVZk7cThde/zAkHGL2XZW MRM854IXS0ZK5dbtW8bO1WXTenW+eOkDZrjGyoWx1g/vMGz6bAb3ldLbaxBqUj7DUxXqvDLRi1Vz pjGk/7d07/YT4+euwc07tsNQvpfmtzz+7iRCcpSVaRE+K6fzXY/uvPXqYzz1wVd06baIkxnKbeNV NN5S4d8zvOiofSs57WXGxH4/0KPXUDTNPMm9x48jZPvpM3OtOVv3HCYsLvO+vawCgeB/wz/irfzK kmJKlNYVb64qIiMlicTUHCobG6nISSe7QPFIXp6XQWJyCtlFkkxsric3I5XsMqVGtqmCzOREklLT yS2qaPeuNVaTJx2blJROcXUDTTWl0nHZUofzW61oAyXpqSSnZpIvXU92ZEN5AelpqaRmFVDX3ERl TgZ5NVJIfRlZGfly70RVYTY5hdU01ZeTnppCSlo6mdkZpErpSsyVdRPNlOZnkSHFk5ReLHs/lWIp j7Lt5DxZs99EVWkRxYV5pKUmk5ySSWnNH/UKawMFGSkkp2VTXl1Leb4kJrJl16ynIDud1IwsMmV5 TkqV8lDZ4h2po1Dal5aWRnqRVA7NNeSmpEjbGeSWtA+fNtdVkJudT2UHmzZTnpUqlVkqmZmZUh5l Uw8yKFcqstqyfNKSkkhKSZPKuZS6JuXza8mX0psknZ+VX0pNQ+vEznqKciWbyuKUpTc5mfScYuo7 XLqekrxc8m9Zsz7JcRSLQ6R8VOVLZZJGTrGy4JfymimVS3I6BeW1NDdUkJWaRoksvU1SvrPSpGtm yfORJNkot7i67WsSTXXl0rHJUr3NplI6vq6igGSpnshOrSrKkWxVJ/dCZku2r5KyUVOST7ZkYxqq yCsuledHNi0jWapHt8+QaKQsP5eCspq269VXFkv3iawccqmS9epNtRTnSuUp2SKnsoG68iLyZOUl pSA/I4PiOqmmSfU3LadUiqOewtQk+X2SnSXZMSWZNOm61Y0dr1lRlC/lsap9V32ldHwmWVJdzSqq ldfxLClu2XaObMpFQzVlZSUUSnlJSpLizCyg9taqK7sXs3IoVX5Vv7GSdOm+Tk/PlPIo5b6uVKr3 qaRnZFNc0VJZpLLIyUiV2yglM4/K2o5SpqYoSwpLlsonl9KqjhZsqCgkOVE6Ly2LosqOXrk6ySay /CenpFNY2fZ9Bkqkepeank56nsxeDeRLx6RK6csuVEizkgzFdmZ6GinJSdLvEhpuuddKbymzxpoy qfyzKK+R7r28TBKlOpRdVN3hfqksyiZFymNmfjmNzQ1S25BBdkmNPKyqpFBqF/KldkVKr1RHi6s6 2qCuTBEmq5vye+kWtVdbXkiOdB91uE+ku7xCqjfJMvtL939WegqJiVIdbril/uVlk1d6hwd52b0o 3RdJyVlU3kcz1VCeT155HQKB4K+F+I6pQPAH0liRwb4FnRlsfpKLV29QKPpFgUAgEAjuGSFMBYI/ kNywbajPnMm0CaMYobGRgORKYRSBQCAQCO4RIUwFAoFAIBAIBA8EQpgKBAKBQCAQCB4IhDAVCAQC gUAgEDwQCGH6T6S5hhhfF1avXo3WhoNk3eXDASXxofhfSvtLZ7Uw5jC62mvQMnUiMOmfvTZhTW48 4afPU1b/x8ZblxaBzTpt1q5Zi+F2P7Krm/+aBvqzb8PabHyd9aT7cC0b9p1BWO037uNYf/zjC/7w eBMDt6Mv2X/tqrVY+F//C1rmn0PxJV+MdNaiZWjDsetl935iUzVnfDazRurv1m7w4M5fF6/iqm8E l9LE+rUPAkKY/iOp4/rpY2zfbcLwR4fjW3Xnoy5ZTeQnHY/7ijk/yAb7M0UPTE7LEsLY7ebCIvWx THOL/9OuG+q0mpV2IVw8ZMLojT4PhC1yTlkxcc4q4u+jTZd9QF7L4cTdV4lquMa6OWvZ5LQVt61b 2X38DEW1QmLdE/VFnD66l92ms3l0gBlVwiJ3JVq7Hz9ZRtzfSVm+LNx86e7hpScY/ssKNu/awbbN Luw/ly4M/UfQWIz3ES/8E0r/0GjLE6Nwl8pqzbxfGW53+d5PbK4jPtKX7XtM+PWhXzlxxy+lZGLe eRp6+xPuJ0UErnLmXMXd7u8kLGdo4BKTjr+9DnrbL/AH+wT+tghh+o+mErfOs/G9241FE/WN9ycy 0rdNZLp33gOX07MehszbdvVPu56X9jC6LT5B7OYxPDN3zwNjh8bG+/zMeGkQPWY4c1dfVUU4P85y ufPKToJ7oyqYzlM2UyEs8Rs0dFiR7Z64YcN7c4PvHp7iyAfzwoRp/2iacjHbZMqWM/9/WoWbxzYy 0fbi/+HMCly/VMPvbmveNDRyf1WsmK3fSP3nXZ2s11n8dHfMzuWwZeEYhhtEi1GRe0QI09+gMu8m keHXWjqMeumGcGLidx/zxFPP8p9OPZhmG9i+DGhjHiG7dOj79ks8+eo79OzZmaenG5Eu/7Z6DVcD nJjU/UNefOZZ3u/en0/HTGLHVcWHrzPDNjP75+68+exjPPfVUBx8E9pvkLJolgzvwztPPcXTnXox pPNTvGmXpAirSWC77kzee+wJnn7rU37s+iYqarvuI4f5OH856zZhWl8Qwuz3n0JFRYUvtI7dck45 nuum0/ndF3jq6ff5YdA3UroN5cMjDVf28O17j6Py2PO8+vJzPP7IZ2jujms1EKmhe5jT7zOeffYF On3ShQ9eG4ntyd/zUjRxfMW38rT85+eNFEm2tHxfRdr+kEXam1nw7b9R6fYLwz//gF5T1qE/fxgv PfYhSw91WCOH0L26zFUSpqXX9zP4Xw/z2fClbNQYzguPPclrH49m++nW5UGriPEyYfDH7/H8M8/x ftfevDdMlV3x1fdk2VNWMxmoHUnKEQ0+1PZW2DU1gHGfSWmfuFPRrF3cTb8XVfhoQ5B8uy41kCkD 3pby9gKWZ27gY7WYLm/9m/emu5N12ojnVJ7mpymrWKbamycef4b3+mhyMqnjx9Or8tOIT8q7ZZWb Qky7vijF+zDvjjEg5VbXXF4keurD+fT5x3jm/W5M3uChqPPNebjNHyCd9xAvvPwyLzz1NG+NXsfl YkXzmndmGyPf/JcU/jgvvizVh6c+Rs0orIPnr6m6iBvXUyipa2+Sb+6cx5Mqj9Fv/lpm9PmcFx97 lZ7j1nA8QZGX+ht+aI7/juefkOr86x/xw3QHUqoV+UvYv4GeL8nKfxFnMkIxUR/Ia499hIaXbG3W Io5azuWr917n2Wee5s0+amwLUKzalnZghnTOy3z/fR/e+3o05lv06CYd00XdieRahY3clozmy7dl 9fpD+g7+hk/fc2xbQ16el9piUm4mU9j20fkGLmxdyVcPydIzEFkKfJYPkNfVZ2bvxMfoJx57qhN9 vv6at/vMxt56ER8/9Sq/bDxCB6d1gR9fTnK+ozBtri8nVbpmbtuH4hu4tHkeL6v8izEbLJg96Cue /ddzvPWDFoktH6yvSw6T7PIzzzz7HG98+BVd3v2caQ6ht3TCZSReuUFBTdvyDRxd0kWe9l7zD7as yHaBac9IeXtyCLuuVVAU4cjQXp/I68ETb3VhxsbjKFZWPcSAd6TjBq/AZvFwPnj2UR5+8yfszreM nDTmELRjPT+8+QJPvPg2301VZ+S7T6Ly7Lz2JXZlC3MkXyMpr+P9VZbgwYR3FG3RdzbnbrFOPaGO qxjQ9UOeefxVvh68AN+EFtVReZapnV6SznuSV159iWelNvIz3ZMt59VxZtNMOj0rpfmhp3n1lWd5 9PFBbDn/+0KqsTwex3nD+OitV3j6yefpJtVbn5vtC2iUJfqyYlQf3n7mCZ76ZCBDB37McI/stjbF V7qne3/0Kk88+QGDRn7L+y+ZtAwtlxKxbxNDu73L40//hy6DFnPgassDfnMxobulvuXdN3jmhVf4 tEtXXh2tQWCmosATQxwZ1/VTXnn6aV77+kc6D/gerdCSe2qn8kK3ofqD1CY/8QIfDRjMT69/wY4M RXkkhOxj0fAu/OuJ53nviwEssvST93c33BfyqMorjFikzfyhX/PYYy/wyS+6ROcq6uiN/ct5SSqv f0nt/EvPP8uLn/TF8UJLT5l6gA+lMJWvBrDleCjuBjN447GXGW0UIF88pjLWiwWjv+ONx5/g+U++ ZbKW221D75cPb0D1/yRM83D8dMZtwjT3pD7vPyq7hz9hw7Fbpq5VxbJ2Qn/eefJJnv6gG4O/kfJj ovDWXnZZIF9h7vEXX+bl55/i4bfG4R6v7CVOx/CDgbjEl3BIfwFq1rHt2qIgiYvnr5JfjeAOCGF6 B1LPncDV3gwTnZXMNjipWBJSariL07OU1qPPYuk4I8ILG+RhcXusWKC7t91zlHCQsfrbyJOCy+O8 WDnbgDOtT1bVV9A10sHrpmwlm7Noqutzrb3pY8eyhey4qej8Ml1/5RvL9sXlG8MtWOCruFUrA9ZL T/w7lRLuxWy3yPvI6Z2FaRtnrZnpEthxX8Fevv7MQGloNwadeYfa8l2yX50Fp+7wSNqYiqH6cqyC 22/cAIfdnIy7x3ljuWdx1LPjxFFX1q4w5XKrco+34vWlvjKjsnHxYoxlC32XH2Js/10oNxG3ClMZ xaG2TJq1mtal3VPdzdCx9VGUd8F5Vi2fx/62ZewL2blnG+EZ9fJGO9xtI8tXr0VbWxttrbWs0jJk b0hGmyBMCLRH1yuFsigH1ngqDTslutFJr13s14QYMHFrxyHKOO3+9NO05ki0ImFpVxUiO87ZgBkT bbnZkvdAG0MMnC4oPeWXcmhBd1ReVyPlTjYsCEXf3o6bHZ7w07FdsoKDqe17btiuYElAS6dYF03f hXt/YwjqEoMW7+Zu7WvOCR2ekB4iTM+WdNh/zfYnnv91M62+9YZrO1D9dQPXZJkpySJdKcJTC+di dVrZC5/CwteGsMp1DxeKFWVzOaNUPmSXn69U6ul+GCy0IFleKNW4Th3KESm42mseXdaekNvLzGIt 7rLbK8uVb7rb0lZz68LQWXKsg4AsCDfm/SffYc3R5FtymY2boRF2RwPYut4U7wstN1T5BSwXL0LW HeVY/8j3W7Ll9/ssY2suFSj5Zn5DmJZf3M7Xz77DFLeOQ9KX9X5hiMHxtuVAfSePxOpynbz9iNi4 CA2b8PYy8N/B9sBbprFctedF6UFnWUDHdefPH7LCxqNFLkoPJrvW6+DXos5rclM6TOlw7juaw603 /g0HnvllHVdat4NX8bGRIg2XtpuhoX+gLX/NN3bT87FRSveWjOsseld6+FTzueOUhoZAbSbvjO2w r+qsFepaAUptzGmWzzSlrbXMdeWLFTF3b1OKdvCJ5rn76hua6ivIzWsXotURZkxbdLJlJbV0jIdM Yuv19rHikxbT0DiqqLtZHssZudqvffWuIi8mfOeETL7nHt3CAvPj7RcqC2CuxjZ5GKknUdNcRUhb BUnCftc+rsoCmwuxXz0Wo3PtD34n9lpJovYevp+ce5RRI1dxvu1eK8Zl0jg8pPJuuLyXWfMNOdP2 ZFaJ79q5zDmUKN8K2bCGWQt3tNy/TezV1sfeq9XyZTg7O+F+/W7+xwosdKbx6xwLwtMVLUt+hvQw nReI6shFhCjd6vGu8xm//nQHT+MfLUxbiV5hjIt/Uscmc/cEPjdUutZZe+Z5tbauNbj30eTuPndJ kKoZEl5aR5T3ZhwC250wZTeCsdVahYGxKZZ7A0gtaUDQjhCmytRdQW+cBvrO2zhwNJir6R0n49Wn Sp3VpAF81bkbfXp9yrPPTCOgWFHhbQxN2BqudEfVl8mXi5Q39gc3MsdaqXI315OXm0Wp7G47rYPK I+/x/Q+96dG9O716Sk/RH73F+L0tlb8oGM0Zqgz5sQedO/fkF9XVhOS03KaVl3HcuIwR/XrwTece DBgxF8ew1ie+ei5v06J/12/o0rUzX3z1K4b7rtwiMH5bmBb4GzDVOeDW1pxd2osYMbSvlJ7OfDNw ItZH2+flpLhOZsbhzDt1LVw/uYeVM8fQpVtXuvTuy6T1u0govfdZN4VB1nzwTBdM45Ralkh9Opmf lefF0MSCPXFSt1Z4BLU+bijPdL2TME2UOmHTHQFtwi7liBWGLkepaWk8Iw+Zoz5mED27daHnd8NY 7XyCvJY+J+WMP96+fhw/flz68+PosQBik9rrS115PgVl9TRVFbUs99hCrB3vbDjaXgJHtRm/OVwp VU0Ezu3L2vCaW3JfS5C1HfaucW3bIba2WNmdV/KO1pN1MRSP4+fv2LlXX/NG29KmozBNP8KXH39B t9696CnVvx69+vDtew/xqEaLd6kokN4zHcm+W6EUn+IHNQfS79IH1eZdw/fQSRKKOza8pzf9wpJQ 5cleZexcM449sn6hOY3d6ybz+Ved6dmnu1Tmn6ATovwAc4YZry/h3J3q2Ak7xgzoI9Wx7nzz2ZcM mmJOSkNLXZ86kVNSJ1zqs5IpeyQ7Nqez0VKX3fF18nvYeekshg3+UarX3/DNkBm4hXSsx3WFCfj7 +HM1507WjaXva88yzupsu71zIrFdsQ5Zrct0Gc3cIOk6xWFMMnbgYoGST/s3hGlDWTqnjvpzLk25 LWokaPEYHK6315nQZWMxv1DbUs4BmK2Yxc+du9C5Sx+GTtYj4GZJx4jLk/A9eIy4/I4T7mqkc9fo WhEn3ZYFgWuZpBfavtxpTgTrpv7MV990lcqlCx++9D2H89vvww8tzioVsBHvGssekgvZpGfKjmjl 8ithx8+a7I5TfnSs4KK/F8djc+64pn22hyaq2zsK0/BVPXjkg+788G1PunfvQa9vO/Ph233Y19J0 cs2GD+cF3L1BuWHLe7P9b99fn4nrsil0++obunb+mq+Gzmb/ldK2eiqbPz64Tze69ujJV59+IQms k4oHs0xXPh19uGP9L0ohpUh2cxSzvfcUPDsUQyVJ8Xny/16zR/H5+59LeZDlpSff9fkUFZVBnJRH XIj/biNmjBxAty5d6P3TGDbsCqO85Z67FuTAvAm/8l2vrnTt1o8Fmw6SVNF+jYMbR/PpF53pJusL uo/HM6VlxGP/XH7ddaNDektTbko5bOKMqTFWu265wzJ28K6a7J2DOg5pWbPzWOvTbCle2pZs9WiJ qyEb802mbI7MvbPdK26yfuNKnGI69q9F0n35y+aztxwcx7IPVqHcct9ZmEr93dbV9O32dUt/NxyT A1dvWcL3t4RpJX7zNuB8oqMwpTSCNXOmMvQnRf87aPwy/JJb2+YCtnabg/ddX6lopCQ7l0rJ3DVl BRRX3DK5tbmajMthuO/bjsnK1WxyDhfTeVoQwrRDK3KWKe+9xUDtfdwovWU2SIofM1abEXYzl9LS UqoLIln600bCShWN1X5dQ2wP3vmtzoSj1mhq+nGnOdfN4Wt5e9kJKmrKKCoqoqiwgIKiEqrld1Qz l1wt8Eutkyq2FFZaRm7EJvoP3S8XT+n++zgQnUxdRQlFJaUUXd3HgG+N24Y+6suL5OuMZ2ZmkJ6e 074meHvvhOs3c/G/y8Na+SkTZrh2HAJsvrofXe8bNNWUUyilsyI/ijX9J3Gypd1Odplw5zmm5cns 9/EhLqOY0pISykpSObxuOQbuZ+6tbGpuYK67FlOr9Qwft6XdcxMlE6bn5I2OgbE5e69IlinwYtaP uzt4u04fNGTBrsQOUab62HYQpum+9phu95d3jHV5cfgeOEJiUaU8vaU5l7DQXI/z8TR5w2w7/D/S A8UTPP300zz91BM8/NQ7TLaI+f3J7TE2vLHBr20z31sL1W3RHQ45Nf9Xttym7RsIs3fEfuvltkYv wtERu833/hJAc/JxdOwcSVOuiCkH+WKOLclSWZYUS3WsqJCCggJKa1rkQWEA3ac73X2OaVUkfeds Ifc+b7Uok5/o55KiXBrYzlAjsiADm5lr2RGVSHmpVE+qs/FaOJlNUcqt/3lmdTLn1lqWeNKJZUt3 cqNQOq+slBsR+zCU7tkUeVby2TxtIiFS9Sg5slwSpldkJY6+9UYOyBygV3dhIJVtQ3UZhcWllGQG s2KgOpH3uHDX6Q3SA5mZM9raWhxVXJD6XIUwlfkqMzaPYs6pepmbnsmbnLhSrNS+lAfyzTRX7sdn ErZsHHZKTtCIFROwkffeFYTu8yY8PpMKyX4lZcUkeOrRz8DjHue3leCx1og9J7zQ7j6bk619cGM0 c35axamsYqmeFEvtVTJOI4dysLVinDXmQ3Ole/mcCR+YyURGLQc3GGHvqdw2XkXzw+m4Xb73N6CL vFe2lFk7oSv7s/xEjtQ2FsvbzkKp3haVVrbbMd6S9+f9xhzTVCc+mH/qDgGNlBfmkSFrO6W/9Ox8 KusV1ju3bS5qThEUSn1AaXkFl46Ys0DthMLTXuvHr1+b3eWt71pOqA/HKLbujjY/MHs91lJbWFJe Kr8HC+X9QIW8zCqSz+BzJIDMkgpKpLaoJOM02uo6HIgplNfrk25uXMqvprykmLLidPYaaaHbNpLS TGVxjtT+K/qBjAxJKLUYqP7Uer7ccGf7XHUzQHvzyY47o434aPUJeVvks96WHb6t928lR3Wkbe+W 7YYsTE1M2HLLKEkbdWkY2htxOKVjjawNN+Jzbd+Ox1b7MUayqfLErOu+G5nidO32aMsLO/R3JZW3 tsZluHyhTuAdE9VI4EJ9XIOVG94mruyyxedmZUv/W0r+GRv6DdzR0rcUsPkb9d+YY3pv5J3exQTp QW+0lg9lCGQIYXoHssJ3MGvMSKYsNeVISLK8cWi8eZRF2vocOBlOVHgwe03VeOXpH9A/fEUe3iCF L1myEtfD/oSHn+LoDhMm6O5GPu2m8joO6+eju/kwoWFhBBxxZck6E07crJNX7i2qk7A6HEpUVCSR EafYu20L3qdz5Y2K39RP6K97gLDI0/LwgG2rUdVXdACXLCbx3YwNBEWdIVIKCztoxpB5u6n9vQw2 1ZJ65QzhZw+x6D/9MfANJez0edJbviNUX5xMxKlQDptM5YdFpoSFRRBzpWXeYvByVH5cxYlQKa2R kYQH72T56I1cadExNVFG9JxjTWBEOGGBPmw2sCRY5lUpOsf4GeOYZ3OI6NNRUj79sJaE3raAG7+T 2BqSwn1ZM20Y860UT/AZOyfwer91nEiQGtlQXV6YuVveQBusWsIa2XBSnie/vreG81LBVCZfIjL0 FJZrJjFwmSshYZFcK5Ds3lyAr+5MJi7QIzxDslhdliSUpW0NQy4Wyebp+aAxtB9G7kFESumNCvRk nbYxnrGF/13lKgllzIhlHAiWbCc9WGh0+4QPJ21SDF3Xl3L92ikM+3/JvJ2hRJ4K53JSoUJQlMVj KQk3tblu3KiSkl90AZNZasycs4eUtrfgy/BfP5gnv9akw8zdhiKig0Pw267H+Nnz2Hk0iIjTKS3D 77VEai1g5eajREt1KCIynBMHtmDl3uKRaEpAZ+RCLD38iQw7hc8eR4wOKOpfQ2U+N49u4oN+GrgH nSIkKIIrySUdXiAoCLPkg5d64XShY5N7xvgHnvhoBi7eQdL9EozbBjXmuMiGAlPR19iAo3S9M1Hh +O01pt+LHzLO+Jh8hKGuII0rp6z58dmp7I2JIjhEqrelis4+4YQD8xY7EBgVzelTR9GZ+BNfSx2H 9/UK+X1mPuwnXCV9VHR0KX0099Fck8F6rTnonyqgzm8uKgP1CJDqh+xeCjm5lRWTLFCuncVn7en9 YTcM2uZFN5KbfBbXxYP5dPZBxTGB1gz9RRVnr4vkZEWgO2UmJyTxlrFlKH03xUp1M5zRC5ez/5Ls Sa6UKxFhnD1syH++W4RvRASnzyd0+JxXxfWDDPioG0vc231GtcVXsB7aGTWXEHKrG6nKvYDVkC7M 2hotm6nJtrEzmbLAntDoKE5HhnHIejUL3E51rIc3dvDVY++wIeIO8ypz/Bj5+cdM9FCqRZXhTB6u jUeoFKdUDw47a/KJyifonUikSnpIjXWZxtNTLEnIrKK+tpCzjlN4aooF8hV5U7yZor4Ai11HCQk+ weYNqrym8gPbril7npPQ6/MyXyw92WFaSFVuAhGhYRxcP5w+y504ExHFxYRCRR0rPIbqmPUcDpfa Rsl2Ead8cd3iSnR2S2NUepLxPRezLzhMasMCcHcwZOtpxRN0WXoi53fM4dkBJoSeCycwIIbM8t9/ NDi9RQ11cy8io6MJP3lQEuud+OBHCy4WK+rgabtpTNfZQWCI1KaGncBCex66x1ukaskJxg5dxI7j pwgPDcXffRPqqq7yecxNCftRW2HMsTBFuyprO7eYuhInZaXkjCvTRo7E7nAIp6NOE3F8D0tXSe1q itRuNV5Fq/8XLNsm3Z+RUjslXdNy43rsj9/LZ/6K2DVtAqtcj0ntotReS/nRm6nGoWzFfb9RYyn6 W70IjQgl0Gcr80auIFA2lakkFp0R01mgdZBMKdt12RFoj5K21x4hX94UVXDMzIBl610ICg/j5NF9 2Gw7yLVCqdQaCzl9yJWJsyex1s2P8FOnuFrYavdSDs+dxGL7w5yS7BPk74HepJFYxyvCy5LjpL43 ki06qvSet4VT0u/LmfegCptqSImT9XeeLHylL0bHI6T+LpaMMkW8RUnnCYn0xWjQRBYZ7yJcsv/V lvmyQfM689PaHYRKbYqsXQjaocUY7ZCWNq6OcK3JzLXxIly6jwO9d6NvdJB7efW3viSdUHd7Fg7p y1jtHSSLT3IIYXrPGuJmAJb6vm3zJ/NP72fe5AlMm2uE3+VrRDroMnWSU5sIqEsLx3TeFEZPms5K 68MkFbc/HTeXJrBbdxETx45hlo4rZ1PKlMLicNNdyrRxYxk7aSW7A2PJa/kWZKKXA/Y7trNh4XTG jpmKpuXRtoY7N+oQbvv2YL5yFmPGTEJj/TbiS+/hrev6Ig7bLGHU2EmoacxhxqTxjF2gg2+CIk3l lw8ya/hoJs9QZ47adMaPn8o6mwjFfLbUk6xx3MnmjUtRlfIyYfEmznUYymgiZqckgEaNQ22xLrv8 LyiGJ6qz8Dyym+2bzVCfOIEJ0zWwORZ3Ry9yR7LYpj6ZsRPnY7nztNxTfGWfHpNVVZklNSJJ10+h OdeS+Io6oneasMg5iIbyOIxna+J+PZfr7iZMmTCB6TNleZnC2BEzcT5TQHPeaczmTZXimcRq30Tq b/qhPUmViRPm4hglNS2VSfjusMPZciPTJk1gyixtPM9l/SH1quLiAdR/HcN87a2EhB5i+awpWMZI PXhJHOaSUJqkNodZ0yYydrQ6Fvtj5R6g0lh35kt5nqi6jH2xpeSGO6I6Udqeosex663DjNVc9LBh ge6+DtMYqIhl6egxqE6dgfqsWUyZOJqZCw8qeXYqCdhqgPqYMXI7b3Q6TEKR0uNNbgQbZoxn9BR1 1tl7ciFDUU9KE06ycdYk1NXVmDZZlbHj5mF78EqHB6Oy+BNoLTEiIK3jLNQz5r+yeJ8kSHU0JKEu 5dNTaQ5lXjRGcyYxYdpStpy4wM2I7cyZtoyTeU0URu1l2dRJzNKYxbSJ4xg1Qxff+OLWG4nQbXpM GzOehXq7iUu/yvYNC1m367RMznHUch02fmlUph9nwQwDLpZUc9LFmA27z1CRcIy1Dm7YrV8kiZ3R TFphx7VbJs5WJgWgv9oA3ystDyeN5fhv00F1giqqmgfldTMjZB9rp6syaoQ20bnp7DY1Yf+FIiri dqE+dwtJRTnsMFyPsV+SpLquYKMu3fOTZ6AxV41J41VZoONGgpKGr8k6i+VafXafaa17jSQf28Ji 9RlMm7UYjxuFXN1nydxpU5k1W4+o/EquHDrMvp1b0FJTZcyEmay1O07+rc6j7DC0563D6/odXMJF gahNteTmLU+4ZVK9XThuNFM1NuJ1MYVLBzcye6UD5y5HYLBaA7UpU9DeEUdekj/aC9WlOjwFff+W dBddx33TSibN1OPIlXPsHb6CvXElSrHn4qGviZ57xzYhM8yNmSPGMHnmbOaqTWXcuFmYuLVPVSmN 80Zn8SzGjR3L5BVmBF5IQ/kzuimBjmiMH81o9RXYHQhBMXOhkQRPK9SnTGP+7BlMnjSOkWN0OJF4 DwOptWm4Gy5i7MiZrHH2JzM1HMMJC9jsd7NlCkIlYds2oi5dc+RsLQ6f7jj0UZN0Ar0FUxk9eiar LA6SrqSFqxOC0Fs4lbFjJzNvlRmHIm7K7/2azAt47XRi8yZtqa5Jbdl8ffyutLiqm/IJcrPAyd6M eTMmMmHiIrYFJ3LP395ozmKv0VLGj56A+gpzTip/H7QmhQPmq6S0jmPGYqneX1eUV1qIG/MmTUR1 3EqOJVZx45gFkyZL155kREROS+lVJbNfildV6tPm6Gwh+HKGol3ID2Pu8DGozVJn5rTJjButikOs srgs4YiVFrOktmj0rNXsiGob/yPBwxK1ieOZKvVLc2dJdWHkDMz8k38/j3X5eFotbu/vpDjGLtTD 76aivC+4azNcyv+MOeqoTZfSNHUWdi3T8lJ8XXDcuQO9JTPk/e9i00O3fDovm23asxklC1vviP+l zHt6s78gPoz9mw9zU7z8dEeEMBUIBH861x3HYnJT2OFBJMbZDpvjf+DH5uur6Sh/s9k4UBOvxMq/ mGUEAsGfgRCmAoHgT+W6ywz553/kf5+OxfOmWG3lQaAp4xA/tZbL8+pcavpj4m3MjMJw1vdtZf7E f7qxdHu0+Ni4QCC4I0KYCgQCgUAgEAgeCIQwFQgEAoFAIBA8EAhhKhAIBAKBQCB4IBDCVCAQCAQC gUDwQCCE6YPOBTueefwxHlJ5k6l6offweSWBQCAQCASCvyZCmP5FSNvnhqNVEOKzZwKBQCAQCP6u CGH6J9BQmYqX2RIGfNuZTz7pzByrkxR2WI0tl/3ak/n284/4dOBcdDetY+sl5U/oNBLrbI+N5S3C tL7xH2E/gUAgEAgE/wyEMP3/QMlNf7RGjWelQ6h85Y7aopsE+54iuaCc2toyvG0Wo+ES13J0LQdW jWSp22myC4opz7+OzszvUfPLV4rxLsK06jSTOw9F/2AUebX/GPMKBAKBQCD4myKE6R9EXUkaZ056 YLpkLH0nGRGS1HEN6tK0q0SGBBEaHs4ekzUsXeCvEJm5e/j5x10d5o5mnPXE96ry8nh3EaZyqgnY psfUERPQcdjHsXNpf0fzCgQCgUAg+AcghOkfxM19y/n4oz4YeSfeFpYY7sKq5SvRmD2DWXPmMn7w EGauClGsfJLqQo8xh2n+zdh/S5i2ksau+b1QeX/FLWv5CgQCgUAgEPw1EML0D6K+JJ3Ik15sMVnO hFGL2Xs2jdYV/Q7oDGdNSEPLViq64wagqhPbsp2BychR2J5r9ZA247/Hgm1RhR3iz9i3m+1bL9zh ytns26TJxAlLsNp2gIAY4TEVCAQCgUDw10QI0z+axjryUs7isnwea7cGyr2iZfEHGf/1q6ioPEuP WRZ4uSzhPyr/ZqHbZfkp9XkRrPv1a56WrSX9ajfWuZ4iu2Uh6ZyD6u3rirf8fWVyURFYFMSIERq4 +V8kt7KWpn+mxQUCgUAgEPxNEMJUIBAIBAKBQPBAIISpQCAQCAQCgeCBQAhTgUAgEAgEAsEDgRCm AoFAIBAIBIIHAiFMBQKBQCAQCAQPBEKYCgSC/zlNxVcIuVoiDCEQCAT/cIQw/btSepX1aoN4/713 +XnsbjKFRe6PulxctcZK9nuPz7vpkfgHR1908RjOOscp/gubqColkEVDv+a99zoxwDzyv4or1mwi uqEV/2WZ5eCyVlFmX3bX/8PLTCAQCAT//xHC9O9KcyOV5ZXUNZ1hxX/mEyMscr8GpKaykpqmOPRe n0rQH/yR2MJgJ+b94PTHPzCke/Hdk13YfONPMFFTPRWVNTTF2vL6pP3/93hqAxnVy5j0P7DMdP8/ lJlAIBAI/v8jhOmDSssapc01hVyOPoWvjzfeJ8KIz6u65bgSYoL9OOJ9goizMZyJSqauwwEp6L27 4N6FaX0uQT7+nL+ZQ2ZiLP6+3pw4dZWytjVTa0i/dp4gab+3tz+RcVmK3bVFXIg+zYXLFwnxCyI+ u4TMuEiO+sdS1th6bgMFSRfx8/HBL+A0qcW1t2b37skqS+d08Anpmr6cOnOB+KtJVDQqzqzISSQq +Dg+PkfxD79MSYPiWhlXzhIeE8ulsJOEXsqkJDeBoGPBXCuup6kkidCj4SRm5pJ4IRwv72OEnEui 6raE5GH7ododRE4zhZJ9Ao4f5YhvGCml96iCGos5F3Ac34BIbuYqLTDbXE9qXATHouMpKkgj8uRR fI4HczmzXB6cfz0cn2PHOBYcS67MbJUZnPHz5djRYK5mV7aUQSKuRtrM6tMDh4R7r2i1xZnESDby 9j4qlfU5sioaOh4h2T7Czwdvv0BOS3UsOjmvYxSZu/lg2sF7vNztJR1rOo9lgdntO+pKSboUha+3 t2SDU1xIL7nljAqunwmW6rxUZhFnOHsmidKG5g5lZn3HMrsLDcVE+0v3z5UccjOuEHxCKtNjZyhq i7KOgvR4gn2PSHXsOKHnk6W7QKKpmoTzUZw5f5GI4yc4n1ZGYVIMx0+clmzY2Gbfssx4gqSy8vUL 5XpO5T3XeYFAIPgnIoTpA0bW5ZM4b9rDzRbNUhm7nyWLFjBr5izUNWYzfswm2hYdbUxnp6EuixbN Y6baQjasmcobKvNuGcJMROd+hGlNPIv7fs37b49hg9lGFmmoM27YRNbtu9kSHofF6hVoqM1glroG s8bPZMd1SSnVJ2I0vhddhs9hhfo0xs+cz9r1a5nQt58kOhRC5saxPeitXslcdXXmzl3AAt1dXM5T iNOm4iQO7t7Gkeg7+M2aCzisMx+1BZIdZs1Dc8UchvUaS7B8HLyGMGcDFi6Yi9qsOWjMmsZUx7Py 06Jt1Xm68y9oLV/AqHFqaKzWZ8WU4fw034fSvEDmdfqAj3uOZ/W61aipzWH+7CVsOBhOdYeLZ2PV 6XaRk3Z2O8sXL5OuO4eZMxez2sCGiKJ7kBo1iTiuWsroQf0Y+Ytzu8e0uYbI7Zq8+PpnDJmzCu1l Un7mz2XOXH2CUipIPLaRHz/5iE49VnFWplVzgpny+du83XkW7hcK5FHEHt2MhU8AxxaPxfbKvaqy Oq54OrNMVodmzUZDfTpjDXwUwktWLrlRWBlpsVhtJmoamqycMYAnZjvTQbqm7eD93xSmzdyM8mar /WHSam4JKo9i/ixz4tqffKi9fgL9tZrMnKEmr/MTxhkQnVfXVhe8nc0l22swQ20ea5bP4uuXZnEs p65DmVl2ug9hWpuCw/yfefHhAay1NJJsMZfJQ4aiZnNJEV6fxG6LjWjMmC6vf7MnqmESlCoFlLFj 2WC+/mE0mhpzGas6nZUbdZk5eCDj3BR3XM45X0xXLWf+vDnMlu6XRevsCb5e1mL6Qk7u38zuoAQa RdMnEAgEcoQwfUBIDHRh5sQZLNExx9P3UruHsrajh/TklF9xadFuqQd1mW7krRR6keWDzUjpGPP9 CVOJhvg9qP9gQetocHXsFtTGeaLw3dVTo9zhR67la9ur8p/Je3RZs/00sg7bceV49sgU9BltPrK6 DFWXsbG250JZ+6nX3e1wPN6yvGp9CeeCD+JovIwRgxfjfia1/cCqaFZ2H8up+tYd9UQePERyi8ip q1Lu1i8w7ktzcmU/M47Rb91W+TzOs7tWMcn+mvTrEpM6GZMv/UravJyRU0zJaM2PTCQN0SYwS1k9 3UmYZrFluhYR9e17MgIcMbU421Gw/QaNaScxV3W8Zfg6Fc3+k9B0v9K2J/ewDp3XHVFUhdjD6Dju p0heSJnsNNfmWOtTSvFFrBYacr6hmchlo7G5eu/lXVdV1yFvi74zJE5hEPz09Nm465xSoR1ggvkR 6pUjuKswbSTe1w7VsTNYY2KPd8BVbp1FenOnNVpbAjvGV1/TYfuizjzMIuQlSl6IC0t1t5LRZugU LNQtCS+o7VBm9yVM5YQw4Y1Vkv1a7ztvhn7pTKHijqBSOfobm/lc/7j8Z37oNvTM98i9n17LeqN/ XnbLbeFD3aPSj0LcHQzwVXpSLAzfh8PO4y33Ui3XTh/ByVyL0QNn4ewfR61oCgUCwT8cIUz/52Sj 3eVNRukd5Gpu5W2h1TePM6XHa6ioqPDo4w9L/99nX44spALvaavYEpH3O/HfWZimHTehx+Mq8nhV VB6j90R3uViTUXTWjaWqR2iVxCWxO1g8xkPRmdamYLdgIM/LznvkMR6R/n/mcE1+3FVXHTYeiJF7 tbYZzuaIbJQ/cj0f2kjCNMWTX96T0v/Qozz8kAoPPfyQdN3H+UnX77YUNxRdY9vqCXw3YQUxRYp9 V4+aMuyzN3lMdt2HPmaunT+5cuFRS8zu9XR+QZaPh3nsUen/v/UUguLmIfob7pKLoaj9+szbmST9 Os/Md42QDRzHbrLCcft5pStX4TF8OdvPF3Yon9uEaW0gPWXpePIxeV5UZH8qzzNg1mFK5AdksuTV VtvK/sZx8ZY8Fl05gvGEW4SpJN7VVtgRUaAkb0v86DTOWSFYmpMwmmvE0Zv1VF7cjqaGJ606/6Tx OFb4yAzeiP+C4VjEdvT7Bur2VkrPs6w5VdoSUk9q8BYGvPWYtP8hHntMFj4DuTSuu8GyteYcuVn5 21XsTsK05iJLu3/EZJMj3CyqufN5VTfZqG+E5+WSDrvrMiLZMOZLeVofeewR6f8bbAiRPV40EWW0 Cfvtv/eYdRdhWhrPyqFvttnhmbd/xSu15QmwwpfJX7vQlpJqPyZ+7oTcF12fyTHr2bwkr/P/ktfB hxZ4yg9L99+Cid1Befkc1R2MnexWiHfmfb0T0nmxqH8u1fOH/sUj8noiq/OP0mX2Zgrqb0lbbQ6H LRbw08/jOJxUL5pFgUDwj0UI0/855exfM5Upmqbs8jjJ+RtZ7V63unB+/ViD623HluAyeAA7WxRk yv4NTDE8ohRXJQnnbtJRRuRh0mk5CfeRotr4/aya4teWjoaEA6ycpBCQxyYPYn10e4+fu2cGnzon yX/Hu+pi7CWTYPm4Gc/FV5bOyHV87HQDCiPYZOZA8i3XqmtQ9nbWUZB8ieOHdmGwTIMFG/eSLeuj s4+xbv4RmpSOs1s6HNNYKYUha/h0uZK4LT7CwA8tkcuuREmYmu6TD0tH7jdg4V6ZDJSE6QcWcgFy xXoBw6aYtg+nF4azWNWY0/nKHsQKNn8ynzMdUn0Z3X763LwlL80Ndfc8b7AhLQDrqdspVd5Zf435 P45Hc3+7xzT90Eb6m/u3becfMWLe9pP46kxj08X6tnphM+AL3v/wIz7/+kvef+4xXv36FxwuVP5+ Os7Z032+s1LhR6D6xcYWb3m5dB09Nu6Ibg+vyeXCzRw6aL5iDz6efaxjxE2ZbFsxnVmrLdhzKIAr aQW3DVdnRO7DyHBn2wORnMbLLPx5Cb4F7WXtNWcSFmcVvtbcYGcW6WxR8pjWkXo5iaK6pg5l5nxb mf0eQczssoP28YlTzOi8U+65jV6vLj3UtJdJpf8G3tkYqMiDvwvmzofkeTuqNwQn2a0gCdNOxkHS jzRcjNYRfsunFxobG5TqSROlGVcJOe6J5YbFqC+x4XKJeGtLIBD8cxHC9AGhLuci+6xM0TMwwtp2 H0lyF1kqDitXM3+eBpordbByMGbsm6/Te54TV2SusuY0XHW1WbxsKQsWarJWS4vFmrsVnyAqisdl kxZLlk/ic5X3GLNwMRpmUrwVvzObrTaBVUO68sZzQ7E9eZOm/DPMGd5d2h7LzvMpxO/YxByNhSzQ XIGuhS1Gk75EpeskDiSUcHPnYrqNsaKwuQDTSd2ZvfUqDRHrpfAlxJfXcMZjC+tWr2bhokVSOpez Ts+EbacUEqipLIkj2zdhoLeOdTYHiVdyKTXe3MmPKgNYZazLisULWLhgNRvMN3NRplVSD6OxQMrb giWsWm+Go6kar6h8zkq3y9SkefPF99M4mlzHWWc1PhxvS0ntOSaqdEYnroD4LWsY9P0olmutYeGS JVK6VmHlG6MQUDU5HHbSYdGyaXRTeZNhGkskoexEdJZisDXumDFLlq1hxfJFLFgg2cLACnf/S/ye FKxJDmL9muWojR/AN6/1ZNqC+cxzDmmx/XUWqY5iqJom2osXslQq14VLrIhMUR4Aj2fhLx/TeZRr R1GrsBThRx2Z8PFr/LjIivCs3/e8NWedQnetJnM1FrF8jTF25kv4+JEPUdX2VdSjnHDM9FajuUCD hVKZr1m7hmVu4XJhVZEchs3KxSyf+j0qb/RlwdJlGG0LpFBJ11eln2WHqSF6hsY4bD1MettYdTU+ VouxOHGrxz8X9036aMyZJ+Vfm002ppJg/IzPfllJtNyRnc8he2M0NWV1XirzVVpoLnflemWT3Ot4 yGmDvMy6KpdZdvXv3HxpbF02jOdVvmXj/hgqCq5itnyItP0DlifiueG7jRULF6CxeClaptaYzeuH ygffYX+miJxQKwYP1eSCVGkOzPmYQbrhVF/ewuNfjiU8v4mk0H2sW75Kqu9S/Vq8mLW6Jmz2PUel rJI1FBPivgn9jbqsMtrKubT/8nNZAoFA8DdACNMHjKaKHC6djqHNaVeRjN/+fXh6BxKXVUJZSjSH joSQ0eraaSokyu8Q7u6H8Dt1gZwahS+muSqXyABv9h84hM/xoxw+6I57QIwkGn7HG1OfzfEDHhw+ 4ktkXC5N5ckc8vDEy/sEMZL4lL1sdCHwCHs9jnDqYhq1ZRn4HPHidHoV9YXXOXZSJs4aSToXQtjF LBor0jkmpT1Fnt5q0i6GceDAAQ4e9iE0NpHiaoXrq6laEopxF0gpvoNwrs3j4qmznI0MxEvKx0Gv EFKUvEqF8REc2HuAo4HnyasqJeGED34hKdQ1lnD6ZDgJUpzVGRcl+5yntL6SeP+jhOcUc97GAefN J4k7F8z+g4cJik1r/6JBfRkXw31x3++J93FfvDz24+4XRmppq9irI/VCKEcOHWT//iNEXEqmqOr3 Z5g2FCZw1MsTj0Ne+Ph6c+jAPvaFt/heq68wW8uWk1euEOp1AE+fIOJzq26Lozg2kOCUqjuUXSnn w07g6eUtf2P9csG9zXitSrvAof0H8PKLIq2khPSok3j5XGqbD9pckkLQoQO4ex4hSOaRbymi2sJE Th3ez4FDRzjue4SD+z3wP51A1R2KsK4wjUvnLlPUYr7m/EA0x5hwx69aVWcR5uMhxetHTFIeZVmX 8ZF+32ydt9BcxpUwP/a5e3D05BlSy+rayyzsqLzMfNrKLFwKr/+9QiHcx4fD3t4ER6dQW5HFCZ8j kg18CT8vm9taT/KZAPbK8nfmBuWluZw6dgj/hDKaKtM5FXSOHMnUeVdCCYhIpKYqnyAfPxTrBTSQ ez0ar0NSfjwOEXjmGvnlLeq8oYqkK2e5nlcjGj6BQCBoQQhTwT+UOsL0jDB3DH9wXjgpOcukRaac SCn721s/w3sl8w9li2ooEAgEgg4IYSr4R5Id5sSITu/x0Wcf8OYb3+F2/X88r6+xhN06qnz64Ud8 +O5rdBmw+Q/44LxAIBAIBH8thDAVCAQCgUAgEDwQCGEqEAgEAoFAIHggEMJUIPgr0yQWthQIBALB 3wchTP+u1JcSG3ESTw9PAsJSqP475KmmgLPXM6j9K2uxqiwCjnnjefgYZ+Ly73mlqNupJcJzG9u8 rvzXy1mWJ0bj6emJ18lIkkrEx90FAoFA8L9DCNO/K5Xp7LLWRWPBr3R9YiEX7ufcumLOhfpyveQB U4DXdvD4YG2u/tGv0Tens32TKUEZdf//81Bwno2rNZk4bCCjfnFu/7j//VKegN2aFXj8AasEZQVv YZ76NHr2/4WlXsn3fmJDMQGnIrmS97d47BEIBALBA4AQpn978jB6//YlSX+T5nx2WizhVPmDl5uU 3JL/wst4Z5IcZvNxr16sDCn+0/LRmHYSc1XH//Ob91lRdszV8vlDPeHHd29C+1DifZyRzXoTR/wy EQgEAoHgD0EI0weOJiqK8ylvcd7VXjvM+N7vKdb3fuZjVM2DOxxdeWkfA955XAp/mi4//kCnl1aR 2uGIRHTevT9hGqDTS3G9hx6W/3/yhcmEyb7nnnmM3u88Ie37N1rhim9tlvqvkB/z0WejGNBDSme3 WbiYz+XjZ6XzX/icOc6R7RGXXMVt5Uj5WuOPv9KTNXtj2oRVU101pSWl1N/RSVuB06xPFGn6VktJ zGWzZYhs/zDMnLTp/uaT0u83UTU+gexj/nsXD+Jh+broPxMkXag00o5uL6nI1yufdbxIEcX1XQxf 5cnh3ZosDyy8ZxvFH9Ljx09eU6Tp1e+wP5XTITzGbSlfv/qoFP4a/cYMoH+fnRQphRddOYLxhN8T pk1UFRZTWn/rYH0D+zRG46q0JmpNynEWDfya5+X5fYVJhsdQltnV8Z5M6v6GPL2vfT+Ecd+O4GiH tUBr8dxqgNZ9CNPT9jPkZami8pBiXfsP+uJ6RfbYcJ25z6jIy2LeNsVSno0X7OVpe3LofHYajOeJ R95inpk1al3flpdH58mbuN6mspu5vH+jVJ6PSWEv0muaDW2O4fpqikrLqPtv5y8IBAKB4IFECNMH hKq8RKICvHE21WTKSCOutAxX16ZcJL5tncsmnL4djnuLfqq54MLPw/XIaIskiNEfadNRWty/MIVC 3O1WE3HH9TVTWP/LRtpWDi/0ZOa0Qy0bVxj28sdMcotr2a7GY9owZvvKPqSehet6HbaGtcqzOvZs 1McttGXouPAyRqtns1DXgcMnzpBWfKfVcK7w6wJnEjuMuDdi94EKXTacalt//IzVGIboKXLcFGTA tB3XWkIKcJmvT1DrOuz18WyarUtUQT0BLhpoBhTcs4XyEy7TfnQGq7pNJ6IlyXlHVzJgjme7NzPJ hcE9XFCWvb8lTJur8jgXdAQ3qzUMnaBPSOYtqzylOjF4tCfKZqgtvsn1rPbtQO2BLA1s+VB/6UnG 951DWNt3+9PQHzycw7nKkd6/MJUtH2pgtZWAnDuFVbJ/wwqOtWaw6gImy0xonShw3eZ7Huq+sa2u VkZbMniombwuFx0xYpT+ybaYms6YM3K1n2KjIRmrufNZuMGGQyfCSch+AN36AoFAIPg/I4Tp/5xK /G11MLawQsfIEe+oG3RwGjZk4m6+mlmz57Fo2VwGvv0NbvLOvpaApcuxDM5QOriM84GX6NhV31mY Fl09gfFCddTnzkVdfSGbtp5rW4KSyiScDTTwTrnzHNME90UssLku/SrHTX0Ojq1KsTSI3r+YkdHh YBveWHiCuuzjzBjxA6qzF7FQQ4OFSxYyqU8PRm/yUzq4lsyLfpiv34SVtQXWe/zosMx5SRg/z3G4 RZhmYfbBePyVp1pWh7L0Kz0UDsXLzO+3FJlUbojZjbrJPork39KvI8bDBZsTikUxw/YuZ91Z5Yib yT17GF0NdWbPncMs9aXYuV9qE5tVaRHY6y1n9pz5LFg0k2G9JhJUIgspxrXXGA53GGPPIzooocMK U3cWpqVE7HLD0soKEwNjdgVd5fZngyp8pk3CPPGWsqnPxm+zEYvVZ8vXkB87uAvTfBXSOX/vNAbt yepweFp0OGkd0ngXYVqXzq6Na1CfPYd5s9VQ2+hKXOu6orVJrNW14EDcnadAXD7mwAZzP/nLWecM Z6KppIRPmw5E/aSy4C7GbZkqPll57Br8C4OnzGXpQg3maSxi+dJRvPfwXK4qlU12fCibjTZiZWWB lo036XXi6wQCgUDwd0AI0/85Oaz87Em+mO54i+CSkYj5dC1c/fw5duw4p6L80O/7I9vkyq+BcO3F bDiW9Dvxp6D37qLbXn6qzrtBiM8hDh85wmHZuvXnMts9cBWJOBtq4Jdx5xgb8k6zUVOLk8fsUV21 hzZNWBZMn17riFc++KIBH66PoC7JmxUac3E7cpITfr74+h7D70QocRl3WH6zOQGTib35sP8SLhQr CY7yCAbOcyKlwzBuNps+GMjBUqVd5f7M7mXV9mJRgsMMpvulEeZsjeORFm9u6UXm/PAGDz/zBp9+ 9imvv/goD70/ju1n8tqiqci8SqD3YbyOeEk28iXqUo5ifmv1aVaNX8def3/8pLI5FebJyiGSMJVn pYK9g35hW/5vl0rpNR9MVZ3pIBebM7Aa0ZO3+i4kpuQuJ2Z50n/mllvmltbhs1Ydo91+km39CAwJ x2HNUEmYKny0ZYdm09Ph5u/UkwYObzNinVdKx92NpcQGnZDy78WRw4fwDIohr7qlAGpuslLPkkPX K+4cZe4ZVm+w5vS5PfQfuQllB22USX9Geyh7qAvZOncKwUVZ2PdRk/LiTcCJY1I9keqKlKdTUcl3 WDo2m71Lf+bJT9WIKvsfr9wlEAgEgj8EIUwfBJqquBGyg5nf/8jwBZs4m9HiJ6sK49c+qzgvcyzV FXHJx5DPVDrh0Lp8Zu4xRvw8n+OpZdTWVpB7xZt5P+uh8AE2Ul1VQ7MkSVe9PovQyiaqq2u4p+67 NgubDTPRP3aTuvoa0s8fZ+9uXzLaFGgz0Ts06PShKh7XlBRh1WkGvfom/XV8yK+poyIjhGUD1DiQ KhMyGdiuW4eVzxV5GprrK0iMPMKuU63D7E0U3Yxky7JhfNR3Hu5RSVS1JbaJGikvpPvx/TQzLhSU ybcV8qgIk3dVeGeWGzeKqqgvu4799F9YH1LSnq76syx851tG65pzQWk8vamxgYaGWmqK89huMgW1 AzfurbwydtN3oI1cIDdXZBLooMb7T/7KsRbl1XjFgR+HGhCTW0FdbRnJoZuZq7odueRtqqOqtp7U 6L1sGGFOfFUdldXK7t5Giq+dYvm47+kzZgPHYtNpdwbWELRhHZYnbxWZ+Vj+MIzdNyUbNVeSGrWD vu89w3jPVn/sNVb/NAKnqEyq62oozziN6Rx1Dreo4saaamor8tlpq43m7otS+qrvcQ5nNg6L1mC8 L4YaKd7sK8Fs2+9HakljWz255q7Lt2/3xOpiR99vtFEfVN6bi//NQqmOlXDKTp1RG0LlowUF3uv4 VceTkiZF2VdlX8LD6UDbsH91ziV26M+gy9cTsD9+mVLxhSuBQCD42yCE6QNG6bWTGC/ZQHSL3muI 30P/d1/nkx6j2HT0LOe3z+Oz7tM41urNLIlibv8vePOtL+g/UQf/VIX3qiEjDI1RPXjnvU/o0rsb n3/wFm+NWkdM8b314tXJASweKp3/ZieGzbcg8Eo2ymcmBWxF12QvJconFQfz43wbfN11+Om9t/ii nxq7Lym98lOTwgG96Xzw/nt0+upbpuls53yGYuJBXU4Mjhb67Iu5wwtI9VfQ6v42b3/0BT27fcMn nT6gx+BlhMmFYDaWH6vj4uPEuJ4f8+9vRmAVfOukx2Z8LBeyyC7mDm/0p2PRtwsfffkVn/WYwrbo 3Huyz6VdmvR6922+6S+J6Is3cNfsz4/TNhHfUm75YfaM6f0Zb73ZlVFLnUhpEdkV57fxXddP+fDT L+nS4xs+lcr2zdm77niNxuww9BdaEZzaMjkjLZB56+2JLbpdNVYneTOjz6f856v+rHA7TZyPDu99 O5qt51vsXxGLzsQfee+tD+g2dCHe8a1ezipC1ozm3fc68dU3Xej61Se89VoXTKLu8QsFhWfRG9uH 96Tzv5uygUPRidQoPf3URLkyUs/9tikJZy2GM9/lANpje/PWv7sxzza0Q3jyUUt+6fYh77zzGT+M W87e0JuKh6rKqxjqbmL3qRTRWAgEAsHfECFMBf8HKthvKomQK7e8oFQfzU8L9v3JaSnD6TNNEv72 Nm/gnLsDFpsDqP3LpLmKfdZWHD6fd1vINYexmNz4y2REIBAIBH8SQpgK7ouEbfN47ZWn5J/4Ga3n 3/7CVEUixjO6yj8b9Oqbnfh19iHy/7+nJp8Ds/vJPwn19H868fNcO5Iq/66Wb6I4J5vcgpq/RGpz /HV57enH5fXh7aX7OqxOlbx/Ba/IPjP19Gu8+fN8/FL+toUmEAgEgvtECFPB/dFYT01tHQ2NjTQ2 Ks9YbaahoUE+b7Outpa6+qY/KTn1NDQ3Ui+/pvi45QNDU4O8njRKdaK+8Za6IKsjDU1S2dVSU1eP eG1JIBAIBK0IYSoQCAQCgUAgeCAQwlQgEAgEAoFA8EAghKlAIBAIBAKB4IFACFPBn0ZDdQUlRcWU lv/G91SbG6iu+wfMOpTNixULvgsEAoFA0AEhTAV/EpWEblpIrw/f5ZWnX0fv7F2+pxqyHJWhO+4r 5qbSZKKuF/+puakryyXpUsb/+dNNad4mqH5lfsuSpAKBQCAQ/LMRwlTwp3PJ5lc2RN5F0jUk4ByU dH8RxlnyzdrYPzUP5VePYTl1F//njzdVphB55CpVojoIBAKBQNCGEKYPKA0NinUo69NCWD7+e958 5RVe/mQA2keudzywKIwZvT/gxZc/ZsjEaYz5xaF9TfKqazjOH8jzL71Jr75jmTTRjOCUllWEqtPY u06VTm+/yntdZ+FxRXnN+ipCnTTo/sF/ePmVbkxcsBhdo6i29dnT/U35+dPXpbAvGDZjCrOmeHI/ /spQo8G3CdPGgvOsGNeZl155g35mEbedk3t2O6N7f8zLL7/Fd+PnoLXaEvn3/atOM+rNZ1F5/GXe fe9t/v3Cy/zsdP6e05IW4srYz9/i5Xc/Z6qlP6VyszfjseYn3hsxn4OHXZne5V1eer8bK/bGtUxB yGbdZ0/w8MPP8ca77/D6qy/SZ8HJltWNyvGe3pOn3ujOqt03qMwLY+WgT+n0kw7nZKavjkG96ye8 9MY3zDUIo/y2FGVzxHgmr7/wCh/3msrOGKVVrCqT2LFyJB+8+RoffPIzqjPXseNoEoqaIqYFCAQC geCvjxCmDwrNjVQX3MDHeTmDeyzlXIsKrIoLxC+uVfYlovONKr6t3yPPOMLQ/kuIKJQttNlM9c09 9HlBU7GmeNlFtGZrYhegWGG8Pj+MBd8vZu/lEmmrEDeTZZgcbVl9vDAG4/XLORiv8N/lhlkxYepu WhcTvbRrLVMmeSlEVKk3/bttbFu3vD7emb4fW5FzH1m9kzCVIRd9ia68NXF/x4Cay+j/Oo3jLQsI 1aX5sWzkLCJalv+sjDSh5+pTijga6mm4xymqqcdsWazrSrb8+FoiHAzQdwtRLL1amcDiST/z/ZKd ZEpJrc+UBOYaTXwS6+Tn5pw+gPG0LchXhm1soKGxuUPcKf7WjPtoBHOtd5JQ1kBalDdhae3+1dwL HuiPsb9lKD8LV83VbPJpefgoPY/2fAOO3yyXp8/XeiNadlEtQjSfnZor0Xe+KN+uyznF8v59Wbsj hPSiSprFHSUQCASCvyBCmP7PaeBasAeu1jqMV9XA8mAUHWdfVnEpxAd394N4+e1nzfffsjlZtr+e 0LVLMAxIVTq2gONuQcj0WvIhJ4ytvJSGmquJPRFOghRYlXAQjZ5T2Ozty2EPD7yO7EdffTEbLCLl 4rDs0l5mTduA60FPPA4exOOYH1GXW1RhdTRqI5fhcMCDg1KY59HDHAu52fYyU112LHv27GGf+z72 7DpA0JXbJevdhKmczN18MPXgLSZKYvOMmRi5uOPpcZCDHkcJCL1ISYv6qjtrRs814XeOrz6PgAPu 7Nm3D/c9u9gVcFHh2azPwGT1QhYYbePIkUN4HDrC0c2r+HyeJamypFXdRM/eGO+0lotUJaNnrcee qwrxXhBzmE3TXdu907eQfdKGKYOsFML1DpTG+2AywbGDMC2N2c2MhQvZ6u7FIalcDku2tZk5gtk7 FR7gKHdblqy0ZLenB56HPKRyOcW1LCWfa3MhEdv1GDF9MTbbDnIqKoW/xjpRAoFAIBAoEML0f04W mp0eo+v8HdKvW8nFY6MJuobrWaq5gnUbVzPqg25sl6udWoI0l2FyMvWOsV7f74ixufcdhUnxuc0M f6U/C9drsWLZMpZJfyvWWnHsnEJEVqSESwLQHSsDLZYuXcri1WvQN9mvEGGlV/D08cbNUpclS5ai qb0azfmbiG9R01Xx3ixatBhNzaUs0liJ48nbV7H/TWGavov3bxWmtekEeXiy3c6E1VJ6li1dw7IN hhxPa5AH15w2pbtW5J3jq76J3erlLF6qiebiBSyw9aFQvj+J1YvG8vO0JaxdtUJhg+Ur2bAjmBK5 ERLYYKmH+7WWWaDlN9CV8rwvXuHKzjvryaZp2+4qTNNObmHt/JN3FYZFV45gfIswzQt3ZtKoISxY vlpKi6xclrNilTEHzsuu0kjSpSCOuG9jw9qVaK5YxsKFq3HwiL79GvXX2TD6az7tY0iSGOEXCAQC wV8IIUz/5zSTHR+N9y5rZg0eyWyD3WS2jsNWBvLDZyvIbtmsuLyDnx79Gs+WYf66y670G7yGm61R VV3AcIYtKbLf2aEsVVvKzkutr9dks1fHkcDkSii5iMmC5fgqLWZfmRDDuasKmXTedQb9zM+0B6Ye ZNGwtcTLfkds4I35B5SGipNY8sko/O9jufMrdqPYdP0ugbXefDznZIddDSkHmNxFv236gKSOsdD4 FZvzCkPUx1rRe8juNq9tYvghfK+U/04qKjhhp4fO1milfUWEBJ2nVC7m8jDbatk2fUA2/cF8qwXH Mlu2Lu5nzSQdWh8L0qP9CYhKbZvpWXPOHf2l0Xe/fG4oDjP2dHyrPz9KEsu6HFNSq43pZzl+SSqo pgJsDDRY45PZFpa4w5DVugcUQlpmh9I4ti6bwuBJS9h+JJjLacVi5qlAIBAI/lIIYfpAUU3CqZ0s GjuPUy3TSvMCTXlHRYVHXurM0q3eeK7ohcrz/TmYogivv+7BwHcfR0XlMd7rNZOtUe2qpjErgvUj PpfCVHjx3V/YeCiG6hZFWZESzOpfv+QxKeyhR99nzKrNRKcoJm3G7lDjo2ET6fvRK/JzXx2witAM hXeS08a8PHgGU/q8Lw9Teftntp8v+f2sNWZjP/0HHpGd8/DDPPyQ9F/la/SOJivyedqZn56S7XuI hx9W/P9snCkpMuWWcZjxb/3C6F++5mnZ+U/3xtw/WUkcV+O1+hdelIW98DkzNrhytfgeJppKYi/I aSmfPSq73uO833Mq1r6X5EF7Fn6hyN9L04ioLsJ+yAuK7d7LUYzmVxJiP5e35Gn+D+PWbyVaJvol wbv/V4VtHn74IR6SnfPGagpaLlkWacHrzz/SEv6wIs6hdm1JasiMwEC1h2L/s28ycL45ockV0vNL EXYG0xg45lc+eO4xeXn30thCQpnCCpVZgWgPns2es6nUiQmmAoFAIPiLIoSpQCAQCAQCgeCBQAhT gUAgEAgEAsEDgRCmAoFAIBAIBIIHAiFMBQKBQCAQCAQPBEKYCgQCgUAgEAgeCIQwFQgEAoFAIBA8 EAhhKhAIBAKBQCB4IBDCVCAQCAQCgUDwQCCE6d+Vhioy40/juXc323fuwScygfIOywDVk3HpFPt2 7WDPPl9OhcdyI619taSa/GucOOSOm+segi5m0f65+qZ/jg0FAoFAIBD8qQhh+nehuZCoPZtY635O vtlUcJ2DToasWLGK1WtWMk99LS6Hr7QsUdnIpRNurF66klVr17BeewPTB6qyyipGvppSU34Mlos0 Wb1+A6tXrmXtGm0cjqa1XKgELx1tdoQnC4kqEAgEAoHgD0UI0788JRw01mDEwCnoOu4hJLGoZX8z yitTNsW4s8lyL7LQ5tJL2KxYgm9iuwv19K7NuLjHyX/HbF2AeajSKu61l3Fcb0p8rSLe9ChvNhss Y9j46RjuOyuKQCAQCAQCwR+CEKZ/YWpOm/H0Oz/icPwqtbeE1RVeZ/faMTz3xCPytelVVJ5nyCoP ZKu5VyYew3C4FZl3jLUR+35PSsf/i389/JBizXaVR/jgh8VEFdxyaH0uQS6zeffRMYRUifIQCAQC gUDw3yGE6V+YptwIdGcvRMdmC3u9TnIptbQlpBJvsw2s33K17dhLO4xYb36YOtlG+RVsli/A/VK7 msxPiOdGSon8d7DxVGzOdLxWY20FtQ2tWw1kXInCe58bdhuXorZmD5mNojwEAoFAIBD8dwhh+jcg 82IgbrabMNmozbL9F+T7rgXtYuHESUxUncxyXXN05o7is3e/Y4Nfkjz8Rpg7azXmMGXKJKZMXchy bWuOn82Wh9VkhmGwZDGzZ89EdcJ41Jatx2bXMVLk70aVcWTNavSMzbHd6kFMaqUoAIFAIBAIBH8I Qpj+jajOS+RccqFio7ma9CtnCDoZSMy1LMorC7kaHcmF9FavahNFqXGEBgcSfOocSfkVHeak1hQk cSY8hMCAk4THJpBXWtMSXktqTBw5lcJFKhAIBAKB4I9FCFOBQCAQCAQCwQOBEKYCgUAgEAgEggcC IUwFAoFAIBAIBA8EQpgKBAKBQCAQCB4IhDAVCP6B1JVXi5W7BAKBQPDAIYSp4A+kkqtHD7Bly1YO +J0lv1ZY5DYqkvHcs50tW/cQEJ2p+K7sn01VEOqzdlPyX0bTUJpGgIcbm7e44BGTLcpWIBAIBP81 QpgK/kBKOe1izRrNefw6fCyHkpuFSW6lOA5bUwMWTB2D6mCnu6y+dWdqy3OIC/Vjm9kazKIK/89J SDRTY8qhjP86K3UF8eyxNUBX7TseGrtPlK1AIBAI/muEMBX8f6CUXSbqeCaKweK7UZ/qj7mqI+n3 fgbXT+3BSN8Bl6W9ed/u+v/twnVnUR1vyI0/smiKDvLh9IOiUAUCgUDwXyOEqUA24ZCsrEyKKxRr jp7c0AMVFRX6znfl+iV/1Hu/gcqbI/AIPYnap4+j8rYFRbID0/3o86oKKlO8OsZXm8lW/Vm3CdPG 7BgcFg/jMSnux1/uxpKt4ZT+rkAqxrrz0zzy8i/oGqzg61efkNL2CrOcz0tSTX4xIh2W0fnNJ+Rp fvajQVhH5Uv7y9mp3huVj7oz4uOX+HffFdgazedtlecZsOl0S4LyCXbVoudzD6HyyLP0nufItQJF rDTVU5STQU5x9R3SlMpiWb5VvmDd/jOc8zbhy6ce4ZOxVpz1t+QVKR3ddyqGtpPcF/EvaVszvOOg fdGVIxhPuF2Y1qdFYT6nvzwvT7/+HWv3xVBz6+VDVtDJ5tpvWq28KJeMzMIWG7VzfcdGlu893b6j MoaZn/5Hfr1JHvFcPWxI72dVeGGQBWciNtNN5VFGtaxPm+CxgldVXmWp+42Okabt4P1ptwvTrDM7 mdnrA3l5P9FlCh4xv+/lrb7qTs/XVHhkoh5OiwbJbany75/ZGV/eUmSX2LxyBM/K9j/0FJ+M1udM piyXiai/oMK/v/iBN1/txND1blhN/xqV53/AKbJlmkF9PidsFvDpq09K+X2aISt3cb289coVpCWk U1YnvPwCgUDwv0QI038wtYWJhHofxMFoLXNX6hGS1dAeeNOLFVOGMlPXkzLZdkUWSVkyFRnLjE6W tM0oLD1IpxlHbon4DsK0JgkX3Y3sPlvRsqMZTxMjtoUk3kNKizEb0YUVHgkt2wlsHDydcLmoaCD1 8g2lVauO8+13dsjXt8r154eFlnLxF+00h8F656RfFxj1uSkF0q/z+yxY7xLSdmaJvwsrnY+hWGS1 kuCtJixYoIOj6z4i47Nvmw96ztqAaYOmY+Sn8F4WZtxQCPaolXzu1J6v/O2jme3fcenWOwrTijgs Vm3k0LXW3FSxXWsj+y7kdDi3MUBTEqbxd7BTJYlnA9m/04k1C2ezZttlOqzPVXUFo5Wm+MeX33Zm jtccXh+2kl3eFxS2uHRBPgc123MTBu6RbcfFGFiy2SOu48l3EKZNBaFozdej/cgkrBatwi/nHoo7 0ZnHey+gVU8SsIKPDRXl1FyWy42sdlumbDdD3ylQkYcgF5bO8JJVSnSe78N2KZtlfo4Y2Psgq9mX D+qxzvZM27lZgQ6sN/FW1BWpRmydOYolRg64HQrgcmqJaCAEAoHgf4AQpv9EGkvx32vOemNLLEwd ORGbeptXLjdyG8tWmZHccEtAUxCqysI01ZX3pnt1POYOwrQi/jCTBnVl0JhJTJwwgYlTJvLLl58z zMhXcUCzlCYnHSaMGMXYsaMZqbYc98vFirCGRJzmzeNMVWsaUnCaPZOQluCSS0dZO3Mco8epMlX1 e97+jx55soCbh+hvtBvZaacPGKCxOxmZsFZ734RcSewazf2Vzn1HMnmSKhNUJzF1aFceHaLNjar2 rFQXJOC33QE7W2vWGTgRcLOsJaSSYzq6rLeMus28Vcc0+MK5XZgm2A1jzj0I0+Kz2/h1QC+Gj5+E qsxGUycy8KMPGW7f8RqNJ28XphUJ/hgu1cVSSqf9nuOkFN++ZGz6iV3obXIn/w5V4pLbDH6wjL1t /9VtuujubRWm1QSvMcTxHoRpjs9SHn/rJ6bOmMyE8ROYNGEsXX/4lqW+2W1l6Kw2guFjxjFu7HDG Tt3aPt820oBOFmfbIztjzLuGrQ8QZcQetmbyhHFMmDSeQd36oG51Uh5y09uJDcvDZDUCuw/nIEt1 9lFbDLf40kQ9tqPf4/NfJjJt0gSpvCcyZvBP9B+pyfnStspN1oUgtrk44WBviv46DzLEyrsCgUDw pyKE6T+R+mxMJ3XlowErOZV/50Pyo/ZKImfP7W9uN55k7Pt2FLdu5+7i/Vk+txyTh5vRbLxS23cV XzjI6mWaeIXHEnP2DNHRZzgbE0daYetQeT3ZNy4RHhJKeFgooafPk1rS4qNslkTM3NlEtmpC0nCe o06k7NRrboxctZnomPNSfJe4cX4bgz/YpBBfkjDtZ7hL7gGNdN/I/J0yYXqemZ3MKZSk6/r1S9mw 9xQXY89J6Ynm7NlzXE7Jp+EO9gi0VOfDD37AMqxVktfgZ2TH1gM3bzu2wmc2n29rf7kozXk484M6 fqKg/LovmyZuRvld9rzwLSxZvYGTUbGck9nozBnOxVwho+SWzxsEL+dD+47XLThlwKfPfcKyvRfv UugVHHDSwvLEnV+3urpvDmO9Cm7bH+eyAYMD7SIxcr0ZWw7fMo0gaw+dZhzqsCv98Hw6aR7g6pVY zki2lZV37NVECmtavcGV3IgKISQsXCrvEEIjb9I2aSLaiPdNlcT4WZOW7UaCN9tgbHOQyHPnuBAX yxHT1WxwURKmy0KRT//opK4Qpj62GG/1o1kqL+ep32N49AKXY87Iy/vM2VgS0m6f7kBtIm6LevL0 u0u5XC+aC4FAIPgzEcL0H0zpjUB0R/Wgx3QDvM8mUdni4KyvyiNy3yZWrDHhbGImGekF1LaNlaew sftYtl3IJDflLPZj30dluDP58nMbKMzOJvV6FEZLRuMQkkhmWp7CG9uUzWa9DRjvjSCvoID8nFRi TuzFNeDq76azPPUU60aNZP81hdexOFnaHjmSQ2lQdUqPAVruZJYUkXnjLDtX9kPlGQ0uyjxdSYfo rWlNhqTronatYZzcCxfDlFeXSvJUCt5vwxrdbVzLzKcgP4eki4E4uZ0gr0U8VebEc8RpBd0/7Ive wXO06WJJ5lRmX2bz4rXoWfiTnJ1OZn51+3SChM10G2FDXE42yad3MuixZ5l6MEkRXl9GZnYOF05s ZvkgXSLTM0nNaxlar0/CbMU6rH1iKS4qIC8rmdNHd+ISnKQIrigiKzOXmzun8591JynOzaGwTGmC QVMBQU5L+eqboehL+UgubA+rSj+B7kwzkm81bnM9pYWF+JqNpq/taan80qSHhXbvbnGYDeNX2nA1 I5uEsG30/U8PZpiFKKY11JeTk5lDcbgZ/x5uJ10vh+z8MsX3USsuYDxuDgdi08kvyCc3Ix5v9z0E Xsj7ndJuIuvwUl5eso8qeaVrUGwvdZeCitlraoiBawh5RYVcj9yLWpcuDF6wA9ns1WQvaxapeUlC swjLt0dxoAQyfS1ZsXG7fIpFwrFNzFm1i2vZsvLO42bMCXZ7+pHc4jHNOu+H8exR/DBsNjvD0hEI BALBn48QpgIak0OxdrDlZKJiQP/MFnW+6v4d/fv3o3evLvz0sw6xSiPRpXH7mNa3B9+PW41/sBcz +vdnnv0lKSQZo0m/0q3Ht/QbMIi+33Xj8280OdM6pbE2A2/zRfTo3o2ePw1h4ab9XM6u+J3UlXFQ bRDd+/zIwCXWpJYnYzPkR3p8P5Cp63ZLgqSZ8y7L6PZFD4bONCY86RJbRg1i7AIfisuvsnLSEvbE VZJ1woKRc0xIKElly9iBqO1PQSYwr/s7M/m7b+nS4wfGzjHCOzZNMS+zsYTj+5yx2X/uDh+iz8Fi SFd69u1H/37f06PL14zZEI7ya1JRDgv44fPvmLR2B2E+RvQeMJ5dCfU0XXNn2IA+9PruRwb80p/v un7F18uUhsGrkzigP4evv+lMrwEjWG5ziOsFCo9pgpcFo7p8Q68ff2ZYv9507jISY/crd/Dw1hKy zwErh9O0zkqIslFDw/MO3xqtvo6+6jC+/b4/v/T9jh7fdOEX0+PKB3B+uxZdu/Vk/IYt+LjpMqLr BA6nNVIVf4j5P3WlW5++DBv0k2SHb5m0bg9ZLfNCqjNC2DhtBH26dqFnv1k4HT1DXtVvv+1Wm+TP nInD6NenNzOkB4msa56ojRxAv+/6sMBLEot1CdhrjKR7l+9YaOlDbLQHc4YMRTcwm5rYvWjM1udy dRkBy35lnEEUOck+zByiiU+yzIaNxHmZM+rn7+kqpWnUMjuCLme2eEwz2DpnPcdvlokGQSAQCP6H CGEqEPztucCSAau4KgwhEAgEggccIUwFgr87zeWkpghPoEAgEAgefIQwFQgEAoFAIBA8EAhhKhAI BAKBQCB4IBDCVCAQCAQCgUDwQCCEqUAgEAgEAoHggUAIU8EfSmNVMcU1Tfd3UvUZpjymwnMDtLgm 3tERCAQCgeAfixCmgj+UnG1jmXS09P5PLD2PuZ0Z8ZXChgKBQCAQ/FMRwlTQgfKzLkyYvh5LfS3U V7lw7UYoq8eOZs3WM4qPtTcXcMLNBPWRgxkyZDIr7QPbPuJenx7M7H5v81q3X1AdO5LBA9VwCkxR ir2OBD9HJgwbxtiZC9HTt8TztCK8LiUIIwsdfHw9WKM6nIka1pzJaV+5qKk8gV26Cxk3dCCqq11I UP6afflVrJZPY/CQEcxYroP5RmtiWzyvjWKtc4FAIBAI/jIIYSrgqocpk2bO4UiSTMXdQLNHJ5bs icDXXJ2eMwyJCD+K1uol7E9sgoarbHU6QNjZC8RdiWGP5lhWB+QrImoq44SeJFhNfbh64SyREedJ zm+VrQ1c3GrEQi07gs/EcD7mFDYzRjDXPlge2px1inH9uzNCaxexF2PwtDJAR9+TYnloAXuWTcH0 QDiX4y4R5uvMmrnWpMjDqjg0eyL6R88RdzmOK7GHmfXxV2xNU1y17JQxXcdqEZIkXLECgUAgEDzo CGH6j6SZsrwbBLmbMPSznixwOEZq28qgdeyaMgI/SU82hJkw3TVMvs/FYSVm0Qo3ZGNVEZmpaWTm FZKybzbvmV9sizlzx1RmHc2//ZLZESwyMCVCKSj/zDEORd5QXDUlAF3L9qH88ivecs+nTF9WRhry w5wDZBTlkZmRSW56IlvM5qIdKJOtFewcNoyN3hdJz8ogMzuDS6HhZNS3X6c+6zRGc0YzYMhStp88 R25lg6gCAoFAIBA8gAhh+k+kLoMN477mszGmXL1No1XhpjqMIyWSIAwyZOpmmUezHGe7VVhfrKTh 4mG0l81m8Ld9+OnnX+j/2XN8Zt++2GXK1kmoed++Jnt98klWm27i0l2mn9YmB7LR3ITLRYrtwguH MNO3I1P6neMxC5XXuzJ4YD9+/OEHfvj+e/pPWoz7ZZlQbiQx8gSWWrMZ8u239O49lEnqK/BIuV18 1qccQ+3jF/na6P+1dx9gVVx5H8dJ2ySbsskmm2zeTXaTzaZtsrvpZU01JpaoMfbee0PBAkgRBJSO NBEQBUFFEbALFooFFUWl996k9w7f93K5NCWJ7mYTov/P85jcmTNz5syZ6/P8PDN3zin5DgghhBB9 kATTO1IDyWcOsMVxI2uXzkXH7Rg5nSOmNWybOIJj9VCrCKazvC8o1lXj7KSLe3YZQeOHYBrTsW0J vove4fUt2Z0152+fyIcb41VLraSeDiVOmR+z2aSrwdpdUZ3b5obtxedMoqqqCGw2O5Kleqy0Pv0k m2230pZjm5O9mTbfje434yuzkkgraNv4Egv+tZor3crC9T9nzN6izuWmrAg2GS1nqa4Zdg7bCUkp /3VfPiGEEOI2JcH0TtZaR2FmPEFeVkxX18Anpo620Gr89v28qX2BoguG3KP2D3xSS7CZ/A+eHmdH RoQv3772BGoP/oF/zzBh9/rRqKn9hgleKe111kexYsgb3K12D0+88AFTVjgRrwq9LQWXcdUYwcN3 38NDT7zEsAWWnM5si5s5GHz6oKIeNZ6ct4PWlmjm/F5Nufz5uiDlvtE+6xj6+vOKfdX4ze/fZY6J Oxdz256JDWeY2tt8O+VLnrtfsc+9f+W7VVvJVr2x6trhtYrj6ON74hKp+WXIb6GEEEKIvkuCqRBC CCGE6BMkmAohhBBCiD5BgqkQQgghhOgTJJgKIYQQQog+QYKpEEIIIYToEySYCiGEEEKIPkGCqRA/ KBtvdU9SpCNuQStnbWfz1YzVnMhqlO4QQghx0ySYCvGDIhihNoTA1p+42rpoNIePxmBf2s9yFuGb 5uIa9/P1Wk36BXRWTkQvrEy+QkIIIW6aBFPxk+jMba01ZCfHER0TT2pGFllZJTR126q6KJuYmBji E9IprukoqSMnPp6swur2eporSY9OILe0vr24voT4q1Ek5bbPV1pXnE1cTCL5FQ2dNdcWZZEYE010 Ygb5Bblcq2npLGsoLyApJoqYhFSuVTfd5Bm1UFGQSWxsIrkV9T1Kaq+lkZCWT3VtJbkpCcREx5Nb 1t6WusIs4uMSSElVnF99+7mkpqSQGJ9AVlFtZx2h1uN5+905OHrEcjOZt7mqgIT4dEqrayjNSyM6 Opb0vHJaul+D+jIykhOIjooju7i2W0EJTvM+YMmuK4ryOKKuJlPe2H49qq7lkhoXS0Z518hmdW46 CcnJXFNV0VRdRLLimsXEJ5JVXNPVDyW5xEXFkKo8Visl2SnEJmRQruyKJnZtUmft6QrFx1KSE+IU /Z98C/0vhBDiTiTBVPwXGsi+Eoj7rouq6UJLCbQzZsp3X/HpZ4OZNHEwT6tN43xL+7ZXgnZgsHgq n37+OYOGTmSBljMRmW2zTSWj996LfDrFlty2lFZ+iqlP/ZXhM31pm820NSWAEa89z2MDRuHguZvN psv56oP+LN98mra9q+N2s2zGJIZ+9jGfjpzNjEHP8657lrJFjYkHMVyxmDH9+/HZN98xbakD8eU3 EY5aqznhpMPgz9/gd2qDCOsqIG7bYv74uz/y5RQNFowaxhefDGLaMjMOxhYQt8OEb157ALW/fMee TMXJlIcz9o17UXt+IOt2xbeH0DhXliz1IsDRFUe3qzcVTMvOOfHWQ8/x8fCl6C2fxqf9+vHvQcvx u1rWvkFFIlvXLGHsyKF81u9rJi8xwjeivazmkjOvPP0Af3m3PwO/+oz3357O0bz2a3LedCxqdz+F RlA+rZWFFNWUc8VmHA+ovcLG5AYaYo+zUX8p3376OV8MHsrEBXp4R7T3bWyABUNefBy1CfqE+W7D UH0y//5wNI6nchSl9Xg5LsciporEDV+h9vjf+GTULNwiipX7Nueex8PzOOkVMheXEEKILhJMxX+g jksBTqxcvhw9IxPs/OPbp/qsOcXAtxZwujNrVLHbLIBsxaf6lED0NPUITOka5UzcacoYy4PKz7XJ R9m43p4MVXHh6b3YLPehpHPrHFYtm8IUve2ktqdgyosrFf9NZ/2AWWxP7wo4yV6LmbSngLbnQ620 13M4p1vLD1sy2Tv2Fs61FpdXZ3Gipeda72Vv8alBcOeIZdZJe5YusqX9UKHMHumkiOntfbV/gqJ9 5R17JrB60nLCGls4bWXLRtebC6ZtLjltYOnC7eSplk9u3ICJw2Xl5yjvlazz7Xai14Kx1Heio1vC LUdgm9jbpTzDqInutI157jKYx2yrK9AUxMAFJ5T9t0FXC6eg1M7NmxN9mDjGmvSOEy85yjsjpmPj GUJZ23JTFSWV7VPb7nKcw6Q11thbO3Imt2cHtpZE4bLOFIOVGqxav4XIXHkWVQghhARTcauqg/n2 r4PQ336IyKQcKut7xqqMQ44Mfe8vynnu20bJvl27j7bIkRbgjsVqP9XIqkpVKP+eYU+u4mNZpC8W xvZkqoJpVqA3lsu6BdPSKyxdZ4h/as/b6uRu5/lRO3uua6qmqi2Q5R/jo1ee5q577+Xee+7hnnvv 5/62dg3b2r5dXRwrP39V2da72ta/PJTtMRXXnXAe1i/OuC6YtrBn7be4JHRbVR6FtfFyTqiy4V7t kRhdVXzI8eSD+V6qjRq5tNEYs+NFyqVLzu54+Gb1OFrl2Y385YnftPef2m94b54rxcoB3npO2Nhh 5xKl2rKekI0bsba7rFxy/OpBxfb388B9ivNUnGvb+Tz+2lhOXGvfOnDtIEwv9Bb+SvEcOhe/vHSM +z3OO8s9SfFbxcyDRW0XAS0LS5Jrum9fjvuH89mToxp1TvTm7VVuVN5QbyPbdL7l5Xf7M0DxHehd C1Ul2cScOcD6uYP5Su8UcqNfCCHubBJMxa2pj2LpF/2YYuhOcGQKRZVdI6CkHGDOpuPdNm5m2zdD sEtopD7GD/01ZkR3y30Vp5wYoOetvB1fetkXE8ONdIz5Xfa0Za3mfjozUX0iq+xtCC26vkFXWPLm UsK65dXm6iIK2hJwSSgjV7sog+9/rhynV+YRft1a1yXvMXJzfOdy4WUfjDQtSO4Y8Y3YjbG6E67a a9gcrjqrhjRMRvfjt3fdzf0PPcwD97aFz1fQOZR5E+1o5YyTM07uXaO955ydcXRp/0XTQe1RbP2B VwccNfgK/XNd6bqmvIKOf1OUBCziswXLMZlqh6abPmPfHcuhsrZTj0RDfy3+sT0uGnO+NOBSnWo5 y5ePzPx7be/eLSuxjG2kep8BUy2P9TIyXE9pTiKn9rkxf9DHLNgSQ4v8DRNCiDuaBFPxH8mL8Edv +TJW6JmyZWcUyjwW584fvpyAhaMzG62ssLbbwPKpxkQoc005BzabsULbGAsbG6wsjVGfZ8j+iHxl fa3FkVjrzmf5WnPsNjuxaNhHvPbqLAISKhWpNYbN2gt4+6svma69HlsbB45ldCXRrCNGTF28Fmsr S6wcHFivuwzTE+0JNtF9A5prLXG0tsLSxg57G3PMvCJ+/AQbignxc8PGUZeB977ObPONWG3ZS2z7 8CWe897gjYHL2GBti42lDbqrVrM5rLBr//pMNs96l+eGWJBWe2P1xRe8WTp8FKPGWXOxsOHHm5N5 goWffs7nA9YQkttIbdI+pn3xOZ99ZcolRf/WJAewfJ4OFnZ2yn6wsbfDYZs/yapHCOL9VzNsjr6i D2yxt7fF2sKDhI5wWR7AH9TUUL9YQarVENSemklG+1Uhfb8LqzR1sbJQ9J+VBWuWLmHd/svK0vyo Ezgs/ZZHPxvDBksrbLfsJlrVP0URXgz5bgD6p2uV1379G8/y8UJLAk7EKR8boCgSBwsTNBYuQ99+ P9kyVCqEEAIJpuK/VJl9Ef/dV9rDRkUaAcGhhOzzxNzEhA32HoSldRtta6kg5sRuNqxfj8VGd4IT eg5/liWdwcVmA+buB4lKjMDX1pEjUSW0KkKM/br12ClCl42lORvMbAhM73lLPyXUF/v1xhgr6j12 uduzlorInHR6H3bGJpia2+O17xTppfU/fmL1RZzc44SxqQUbnR2wMTPFZPMeoovab4fvNRyGxaEI 9m3ZiPE6J0ISyq6roJn0Myc5ciqJG3/e08rFPXaKUGuNpZkrwUnlP9qc6pRQHM3MMFdsH5JaQ3ns QczMzTG33EFETnvyLUkIwc3BGlNTExx2BRGfXdp1a7yljDN7XFhvsgG7rQFczej+toQKzm0/SKZi RUveJXafje82utlMXvRJNiuumYmFPTtDEumI0TmXDmGj6B9HO1sszBTXdPNOooraa82/4IOp8w5i lQ/alhPiYq+47tbsPBKj/K60XrvErkORlMkQqRBCiG4kmArxHwgyH8vOa9IPQgghxE9JgqkQt6SF 02s+Qe2uh/ht2w+UPlAnqlKG/YQQQoifggRTIYQQQgjRJ0gwFUIIIYQQfYIEUyGEEEII0SdIMBWi zyrEy2QzxxKLpSuEEELcESSYip9NfVURaVfPcdBvJycz627coKmQcH9X1m9w4njszYexhvJ8Yi+F 4LcriJjcmhvKW4uv4GFjho37QVLLbnbqyxZqSnKIiQjFb7s/qb28i7Q87RxuG83Y4HaYm/6Bfksd RVlJhB7dz5ETkZT/wO+mGmL2s9DQifiON261VpEY5oeNmTHWXifIqu5lp8ZsAlz2Elch3zchhBC/ PhJMxc+kioj92zA3tUZz4pt8vTP3hvKTm61YsdpQ+a5SDS1ddsbX3ES9TZzfao6pmR4jP5yO7f60 nsWtyZhMWoS+rT3WehpMsPSn9GZ+RF9XxAlva9ZtNGXSS//E9brJmRoLInDUmMdqMxssTTVZtPwo 1TfTDZmnsFScn6H2AqaOX0XU955iPYFbLbDwuqCaDame0G1mzJqrg8VGW0wM9TAw9SK/uWdfRO4w 5Z0H/ox1vHzjhBBC/PpIMBU/kxZqqyqpVQSpWK/ZDN6Z3bP42nm0jI0JVuXVqB12GOsE8uPRtJXa 8nKamgrYscIS9wOpPUrrwgz4t+EJ1VIW5l9rcSj9JgJvazPVlZU0KuJmwLRBuKT3LE46bMtS7UBV aCzDccZ3XDftfe8aayirqqcsMxSbFWu4+n1ptiIBJ4OVHM1Wveq+tY6oU4GExpW1LzfnYGW6jC3d km1DciDmTtY4TBqKfVyrfOWEEEL86kgwFT+7BO/ZDNrRM5iWXt2PrZUTWao77SWX/bAw3Eh6w83W Wo5PWzDd3zOYXrGYi8mpgs7l8wazWHcy5xZa28T+6YPYfN1A7AmPJSw80jVzVZDzNBYcKbrpWuty w7DR/P5gmnrIiEWrQnqZNapdS0E463VXczxHNfzbdI0tJmvxjivitOZIbKLl3apCCCF+fSSYip9d vNesG4JpUaQv5sYbyVDNFlp82R9LY3sybjqYlrLrhmDayjnD6Yogmtu5HG44G9OQWwmmDezrJZge 3jSLuYe7niwNcp7FoqM3H0xrcsKw/t5gWsGmcWPZkf89O1fGYqm9Cqs9KZ2rssKcMLM/o/wcuWos LpnyPRNCCPHrI8FU/OzivW8MpvUpQehaWhKj+tFOzgkfLFd6c/NRr7dgCtleixi9K1G1VEPA+OVs vVpyC61tVAZTl+uCacQuPRY6xHYuH1j3HTaXbjpFU5vzAyOmybZ8MeNAr6Ol9QkHWK2hzbaw7s/o VmH4qhoPvPEFw4Z+xZtPP8wLn01kW0wNQgghxK+JBFPxs8vft4hh+69LZE2ZWKmvwuFkoXLR02A6 q3al9NikIi6A+dNXcjit9/vfB3Wd8Aku7bmyxJ9P39NFGePy9jF4igkxPaYQbSV+pw7jNTzI/p5c eXLeMLzLeq4rvrIbzRkGKGNw1QFG/kuLuO4btFZwzGENi838KO0tYdZcYbOuMTcObNazf+RoHHsZ 8cwL28bKVes51d5F7PY2Z0tUZXt70pJJTEqloCKbPTO/xjAkH7mZL4QQ4tdGgqn4mVRyZOVInlRT 4/5Hn+TpR+5BTe0tjA52G4qsjcV09OuK9c+yyDXyhmBVELKRt/7cH/tLZd3WtnB46VuKfe7i0Sce 49GH70XtrldxjO1Kgy1x7rz76N387rWJ+Cdc/x6lJkL1BvOnj/S42n2AsS4H85nvK+t9+MmnePRe NdRe+oZtUeWdm2QEmfPPJ+9G7bXJhF//9qvGa2xZMIS3x9v2DLxpvrzxx0e4674HeeyJ3/Ogoj/U hjl0lUe58M+FPjd2X10GJhNf5Te/fZRHfvsA996lxqMfjMI/rb5rm5p4ln/7Jg8+/BiP//FV9E7L O6OEEEL8ukgwFaLPKGevtg6bTmVIVwghhLgjSTAVos+oJu5SEkXVTdIVQggh7kgSTIUQQgghRJ8g wVQIIYQQQvQJEkyFEEIIIUSfIMFU/A/VcNEnuHM2JyGEEEKIHyLBVPzv5B9iwBIXCm/bE8zDdZQe OyKL5Vrfijg3Hla7hw/nH6NWekMIIUQ3EkzF/0gdxzeswSrgym18jlXsmrKBPZdLfvKafRd8xF9e W0LUz5Hccpx5dEzAz9x1R5n78TZK5S+KEEKIbiSYip9A642zDF07j56RDWdyu93Hr80ldJcTa9ca YWXnjteOkyQUdL3Vvjr3MjtszRXlhmwKOEeh8t3xDZxzMWej5ymKle/ML+aQmSnOPtEo539qSMfd 2BCTTd4kVDZTmRyGg6ER7ifS6HivfUX8CewMddE3c8JntzfbL+V1HrMiPQJPi3Xom1iw81QyNzup aHHMEcx0DTB3PEByRdfZl0UfxmKDM+EpyQRvd8RY1xjHPeeU04tWJ4biusEEM2MT9iYpTq6pgIM7 XdlgpIfN7oTOY7de2cS48cvQ115LVPVNNKY2EVsDM3YHx3A5dA/m6/QxczxK966nKgl/N1vW6hlj tyNMEalVWko4vn4Sv31jPKZWG1inb4DloWhlUUlcCFsM12JzJKrrskYcwXG9ER6qUeKqnMj2a6bo c+d95ylSve+/Oe8cFlo6WO4JURyrmdSw3aw3suVwVPv4eUvGbmZ94a0oK+eQlxOGBmtx2h6Jch6r llb5KyWEEHcoCabiv1BBxG5jpqw80BV0VOL2uWK0YT9dcw+Vc8TRBgMjCzY5b8bN0YShr09kY2BW e2l0IGYaK1hv48gmJwesNxiga7+bQkXojfY2ZPQXUzilnHSpipMb1Rn2qj6JbYtNOQRssmXyxI8Z vNwSV2dX3OxMMdiwh7b42XjFnZnL1uJo74CjqzsOCz/mgVVHlcesid6Hoa4+Dg5OOCnq0NPQZ/ux eG4mFpUlnWKr0zrG/3kkDuFdDytUZ4ZjPPJlHnpjOhYOrjg7OWFvuJh55ucpKYzDf+0o1F4ay4ni 9v47sG4YT385FZ8TWSjfXtp0mWWzjDiVHcnmldpEVt1EY1rycJj/Da8+MQhDZzdcXJzRnT+TpQ5X VeeSi/WkBRg5ubHJcZMiWGowz/Rce1lrBefsZ/PIO7Nx2uqCg40tbsHKnqXq0nY+/ewLlgUktc0H S3B4NlUZ/ox8pj82sZU0Jh5jw/IVbLB2wMnJEev1imvm4EN+W04viWWL3mL6TZvAilUmOG3zxM7Y CPtdZ5X/oGjN3MO8wf7UVQXy77c+Y95aK3z2xbX/Y6PyPBqTdQi4WiB/xYQQ4g4jwVT8B4o4YLmQ z78cxkobH6LyanoWtxThaTafrZe63YduzsR4zlIMfFM7V2VcjCTxWttcnrXssFmM7v70bpVk4ai+ Dq+wttBXgMu8mYR13PdtvYLJR3rEd9vaz3Qcn67y5VrHDJ1NbWOUmVh/p8Wu+MquDa+4Md7lEm1B 2cPelu3nu92Gzz/GNJtdXXX8qGYOT9Zm6/lrPdbmuH7N/2mf7bYmA4OBwzlY0t53Fp/O4bRyfTUH l67F+VxHsG0ifL0hJocVYb3+Ko4rdYmuu7mW1ERtZ9Ewj87neasj3Zg/aq/yGc6iverM9snt0W6v OVM51PFobL4nL84+2kut+Tho2nA4oYlkj4k8/bELDbUXGKLtQyMN7Nq4GP0D3WepysRh6Tq8w3JU p5PC4jmTUd96jo7B25Ym1adsP8b9dQwzjIzwvXz9M7oNZF85ibXmFAZ9PQH7wGT5KyeEEHcICabi 1pT786La0yzwvvi9I4vlUe4smuBFeY+1rZSnhGC7cBAP/OY33Pe7p3lzhDbHU9vGVItxM5yCd2r3 7ZsJW7MeO++228rpOM6apRoxVWi8iPGH3YNpI7udlqB39rr73hVnGDxjIwm93Z+vTkVjzD9Qu/e3 PPrwb3nwwd/y8G8f5IkRJqSptk/y0eXNR+7m3vt/w913P83wZYeuO6cK/MatZMt1wTRx4xDmnOh5 0H1aX2N3tf2Wf/OpZXxkHAd5Qcw1cyNNld/Lz2/hu3ka7D8bxdkjriwbNxmvy9c6H5NozDzGuH5/ 4q57FP13z/387YvlnFNluuLz7iwbH0BHD5RGuLN0tJ/y8YAInU9Qu/9hHnv4IcV5PsgDDz7A/706 Er8M1RVMd+UvM/b1ei1jNplge/Q4roPfod+sxbg422AacE75CICb0VR2XnfNQnVMsfNSPVdcHMky aytC8nr5pmTuZtij/VmyxhznvVe+f5S6MR2POf9C7bV1VMrfPiGEuO1JMBW3pjkbD6PV6G+wxsJ+ G4fPp92wSdDKSay9dN1QX/FV9CxtON71eCfnjTRY4x6u/HzUdTXL7IO7nvEsCsdwkR5+l9uiYDZ2 cydwWBXCsk+aM+JtK7rf6D3isYJ1kde3pJg9C5awxi+uc01TzgV8zraN6JWwzW4DLmFFPfYoLSih seXmu+P49LXsSej5Pqw05wHcN8SVzrHYvP3M/E6L6M6Ty8Bk0EzW2dvh6HWWjglICyMD0Js6iu8U gXT6xKG8/9JrjLc5RNlNzFDamLAb7elBnQGvNXEPWlMC27vSV4NZLkk9tm8qz6WoY6A7dxsvDdjS GYDr8xO4mtUecZujtzNm4sd8NWw7x44b8ubfhuIU2jZK2sJhl1VoOIR2u2ZnWbtQH/+OtxS0pqG9 yYFz5b00uOwIiwf5K6JsIZ4bTHA+fd2oaWsx4Yd2YmdhxXo9bUy8IpTP6QohhLi9STAV/5HqnFiO 7vXCyXINS9T3dY0klu/jy+F23PA79cLzjJnyDd9OncbAj//NR18MYNwiG86mtu/ZVBDDdmN1xvT/ go8++pDPRy/G4WCEagSwibPb1Pmi30e8O3Aqqw1n85La40w2D6G58iqL+/fjmT/czyMvv0e/d95j qndM13GLzmGlNZ/BH77L+/2HMnn+KuxD259rrUs+zSb9JYz85GPe//fnDB+/CMOtJym/iSAYZD2Z tz98h+fvfpj/e+Ut/v31SMxC2qNyqssIXv9Wnfnjv+GDdwcwZqoGO6N6Pix6yWowz/xtBoGZvbzk tew4X7z3On9+9HH66/tQ9GO/yKo6x9DnHkVN7XU0tl6iMeMA7z3/mGL5XQx9226DK0K4gSbjRgzk ww/ep9/wKehbexBV0hFj83GcMYZP3lf00YBvmbFUF5+rHc9NxDH7wd8yuO1RgCsOvPLqF3jEqa5K QTTb1y1l9Bdt1+wjPh+juGaHImj7J0mLIhh/8/Lz3P/EE7z45gf8++OvsbygGvOsjmTav57lpU93 KLe95jEJtXue5t9jFuKf2qI8n8ULtbHatI29gRfIrZG/b0IIcaeQYCr+Ow0V5OdWqEazWjinPRGt kF5en9TaREVFGaXFBaSlJJOcmkFhVc/E1dpYRX5GGsnJyWReq+g5QtZcR0FWKompOVQ0NlCek05u oSIgtdaTk5pCekYWWemKfZOSyCq77iHRujIyk5NIUhwzr6RnymmuLSNbsX9ySiqZuUVUN9zcuFxV USaJSSlkZGeRkZ6qOJ90CqvbxxxTHUewJETRtirFuSYr2lly4zufWuurKCwop9fB2YYyktrqzsgg vaCUph/7NVZLDZmK9qdnZJJfooh6TRWkKJYzMrMp7OiL5mryMtv7NiUzj4qa6wJxQ2l7H6VlUlBS RXO3Y9YVllCrbGgDZZWVNLb2vGZ5bf2enNLzmtWXk6Y4h6zMTDLSFP2TnEphrepsW2vJSkkjv6xB 1bQSsjJSSUnPVlzb9vPJyS9B5mUQQog7jwRT8dNpTcJspQ/X7uAuaK7OZdeitxhsdYLo+BRKJV0J IYQQN02CqRA/oYJQV2ZMncKkUcP5Zp4BgWlV0ilCCCHETZJgKoQQQggh+gQJpkIIIYQQok+QYCqE EEIIIfoECabiR7XUFZJ4MZ166QohhBBC/A9JMBU/KjtsAzMtz93UHPI/vQp2TulP/6mmXCqRayGE EELcziSYih9RjduwYWzP+u9rqgzfjMb2k7fegqxLbFg2Bi+ZMl0IIYS4rUkwFd30MiYaYcyHmqfb P1flc+liNKkp8Vw4H0NhZQXpl89yNipX9WL1JioLM4k8HUpI6GkuxmRR2/kG+Toi3JcwYKkpp86G ExZyhqjkQnpMstT2YvjIc4SGnSLiajwJ2XnUKCuuwNtkMtsiC8i62lYeSV5Na492X0uOIjw0mNDz 0RT2eOagifykywSHhHI24gpxMYkUVDd/39kKIYQQ4hckwVRQEheG104frhRcP/dlKe6TZuGR2Z4u m7KPMuLFZ/hsxgpmjhjB5OVaaC+YzGf9x7I1pW2LHPY6rGPWyBGMHD2eCSNnYHo4ur2qyhRs5vXj qdc/ZOy4sYwYPhlD11NUdqTDumz2bzFi/qTxjB47nhnTx/PaxIUcUR67EqfF/RiyyAiDRdMZOfg7 Fuj40jHLfd5RaxbNX8j0Md8yctosNLS3U9hRFuiK+qLZfDdyNNPmzWHoi6+hcShbWVafdxmPHXs4 l1IuXwIhhBCiD5Bgegcrjj6AzqSpqBtY4LL3GJnVPccQW+PdGbnMi+5x9fyq4RhGKLa7dpRFWgYk Kdalek/hu915bXtQUd1t45xdfLZud+c0lbVn7ZnvEdxrW1IOu6G1wkMRbVXKIllrs5EzuW3BtBwn jYGs9E1TFaZhMWYGp9reXd8QzpxZtuR2qyt1y3KWnmibl70W/wnfsnxv13MIhcf3EJjcPmd7a2UG h/ZswVxfncnTTQlMlIdYhRBCiF+SBNM7UUMelku/YeAiO07F59LQ6z3tSgKWG2B3LLXbumZOLPmO jfGKj+lH0LOxJbMJ4r1nMXx3AW3Po4ZvW8Gf1dRQu+te7mv7/1Tnzr1LTlgww+lAL8dq4oCbISt2 pvZY29KiirQtJXgYTWFXR3FLGo6zphPWFoLj7FFTu4f7f3MPdymOd9dd9yiW1fiXZUz7tvmn0Z/+ JU+0tUXtYV75cgVh+deNDDfVkxsXis28oXymsZnSJvmKCCGEEL8ECaZ3opZy9lksYcIMHdz8jhGf XULjdeG0OSkI9Q1OxFT0WKsIpiNxarttn34YfTt75Uhl/I45TAi6RobLauZtDOnaPMKefxnu7Vws CzZnlKV/V21VZZRWt4fEeP9NaK3c1XkLvm20Mysnn6rG9s+7zWbim9lRls+WBfM431aW48UHS/fe eI7KTJuF0yJ7LtZ0ra7eO4+/G3drY2sDhRmxBO11ZdW0ScyzOaI4mhBCCCF+CRJM72AtZUkE2K5h iY4x5u67uVrYMVTYROh2Kza4num8Da/ag+BF7/PZukjq8o8wcfh3bImsJdZlFM/NdiFi33Z0l2ug tUaXddZ2mM0fyL2vfYzxEdUt+Pxg1NUXo75KG30DI4wNrfGLVN28r0rC00YbTU0t1uiuQd9oLZrW O0ipbiF1/3r6/f2PDDXdTxkNRDgt493/e57FbuGKpWYubFiJuq4xRjraaK8xZoOZBd5hbSO46ei9 OpRpWiaYGWijs2YtOurq2J5tv/HfeO0qO9ysWKe9HG37/aRUyHdCCCGE+CVJMBVQkcW5C+dJLVEF 08pEHLU02Jd+4z3tsrjjeB9JprG1hLB9BzibVkVNxnl2BpympLGe9PBDbHZxZdexSAqLcjnm74lX eOeTo1SnnsfDxQV3zz0EX0qhrL5b9K3J44y/Ny6K/XccOU9uefvxs8764eLmgffRc5S1NpBwwBvX rV74n7xCpXL3KiKD/PDYvBlnNx9OXkykXDXSmhQWQUREKHu2OOPs6sWhc+mdv8ZvLE7lzIVL5FTL V0AIIYToCySYihsUXfVi9fIAJK8JIYQQ4uckwVQIIYQQQvQJEkyFEEIIIUSfIMFUCCGEEEL0CRJM hRBCCCFEnyDBVPzsStPjyK+RfhBCCCFETxJMxU+qIuogR5KqfmCLOjZ99QzLT9VLZwkhhBCiBwmm 4idVsn0iM4/V/eA2TdnRZMuIqRBCCCGuI8FUKDU11lOvetl9Q9Yxlg95i98p55d/gknmx3u807Q5 8wjTP3xWOSf9U598w8QvxnG0HFqj3Xnj6buV6++5u23f/2PulisdexFpP4c/3aXGXY++j1tCy3Ut aCT+sCWf//FR5f4vjTYkLLNtutIKbN76HU+8NgMHO13eeup+RfmzaPimde2ZdoBR/3qivT3/+pRB 7wzGL7+9rL6qmia5vEIIIcSvggTTO1hL9TUSLoWxbf1yRs9czOEM5XRJ1BcnEp3ZFeeCtAagflw1 X2dVCBM/nsKxko7SdNZ+NQRfVRAs95nNopDGHzxutO0Q1pzufiu/lYs71zFriRMdc0S1xO9m/lxt QrOVtWI66BVmu19Wlcah++UUTiufGCjB9oOPcS3oqKuGLdMm45enWgq34cNvF+C08zAXYjOoaJbr LoQQQvRVEkzvRC3VhB92x8LKAp2luniFxvec5am5iJNeG1mjoYmWjh7TvnuPSfsLlUXFO6fzpWd2 t41bSTt1gjTVrfkMt4lM9cv5wcOHmgxC70y3YNpcjJvJDJxjuqfGOg5rbcDZL6mtVjbNm8+F2o72 p+M0ZzohpcqdCd+gwcIVeqxZuYIVq4ywdTtIfmv3qrI5vM0WA10zbCwt8IrIl++AEEII0QdJML0T NeZiOv4tXhmow9myGwo5arAAQxcffHbswDfgAGbqXzH5QLGytNx3Nh86Jn9v1Wku45l5oOAHD3/K dDD64d1GVZtLcTWZid3V7jfd69i30gQHv7ZjZSmC6CxOdbS1NQ3HWTMILW9byOfQ1kOcunACX8/t 7NixC5sVU1lzuvyG41ZG7+C7557g31bh8h0QQggh+iAJpneo1royEs/6snLwW/x7ng1nUspUJdcw /3AQO3Pbl4ou7+DLvz7KpIPFqh2jWNLvW9yvqm7tl13FZsFs9qoGUcsC5vKaVlD7Qm0Ox1zdCM7v +ZRnqPHX6J7t+av8hAO2zJ1tQmRJ+7bpxxyYu8SQi22PDLSmYDdjmmqEVKFJsTx9KsHK7Hmecb8d ze70jjHfRvavGMDCwI5g2kL2KW9mDv6Qr+dbExybR73czhdCCCH6JAmmgvq4Q6wxMsA/rv1+fG2K L6P/+QwP/uVd5juFcsVPi8df/xL7c0XtO1RGsGr42zz+yJO8/Ml0fK6UdautkYPaQ/n9Q4/x17eH ssYliOK2INh6jS1LhvPMo4/z7Iuv8rfnnuShR7/AMiizc8/00M2Mev0FHv/9k7w1xYqryiBahdvA V/n9M3/m5TF6JJUloPf6n3niTy/xxVxHimoTWT9wCZorxvLGHx7l4SfeRcMzurPOwkAzphtvI71W rrMQQgjR10kwFUIIIYQQfYIEUyGEEEII0SdIMBVCCCGEEH2CBFMhhBBCCNEnSDAVQgghhBB9ggRT cUepvHSAg4ml0hFCCCFEHyTBVPxP5Iba8fFDaqipfcmh4j7TKjaO1ME/uVIukBBCCNEHSTAV/1P7 vljM3ty+8Ub78hA3Jln5UNkq10UIIYToiySYip9AK53RszqVnZZrmL9Ym81HAjB/Zx4BBR1JsIrY Y9tZsWQJK/UdCElS3VJvysRLWwtn39NcCd7N6qVLWG28lcjCtlqL8NXWYPEaS/aeU81xn3cGw8Xq aDv5klHVcpNtLGWnuRlbA1M717RIQBVCCCH6FAmm4r9QymkPLYYv8FNEToXaq6yapcGGLd7s2e2D 64bZPK02EH/lhFGNhLvYorPOkd2+e9nj6Yi65kbClFMyVXPMYg7vv/Uxy2w82eu7C1ttTXTWB1BD E5d2rGfY25+zNUY1jWllOLNefw2N3ZeoaLy5ljZkhrJe15iIkq519SlHWKShw/bQTLmUQgghRB8g wVTcstbKNHabzuWzASNYs/kwmapRy/ita9F0Odltw4tMfHQi/m3PmOaGYmRuwcWCruIYDxOMd59V fq6I3Y+5oTUpquxZFROAmYEt6argedJzHcZ72kc7ay5aM0rv1C21+ZyPMRpOkdetbaQo5RzuhtN5 962puJyMpapvPHUghBBC3JEkmIpbU7GPl9SeYt72C/S8iV7HcU0DHPYldFuXh/nrc9hXCvWxOxn+ +u95+rnn+fNzz/Ks4s9zz73NHJdw5ZbFkb5YGDuQpQqixZf3Ym5kR3pD+3J13GEMtKxIr0lAe8BE gutuoc0tKZhPm83xH/oxfkMUpt/+iz+P30BRk1xmIYQQ4pcgwVTcmpZ8fG2NMTG3YK2pPXtCEuh4 VLPwmDUjNF2p6Ng0wZ2/q43keFuCLTnPeiNzzpV1r6yMtIL2rWtTgnC23Ua5qqQh/TjONu50/aC/ GG97YzQmjGSU45VbanL5aQMmaIX3XliTzxlfB3QMN2BmasWWwGgklwohhBC/DAmm4j9SV5jKmaAA tthoMXOmD8rByNZigjzXM+LD13nh7+8zapk6w596kD+8toQrdZB1xhedGcN5+eWXeOXN9/lurh7e 53OhOY4Vf38QNbV7eEv/EC2lYUz8/T2K5ccYbRfWeczmyy689c0yIqtupaXFOH82Ee9eRktrEg6x Zs1KLF12ciIimbLGX/lFEUIIIX7lJJiK/1IjVZX1dP3AvZWaijJKSsupbVKsba6loqy681f7zfXV lJaWUlZWTnVdo2q/FmoryqmoqKCiti0dNlNV1rZcqdima/zysosV5rsibq11Z0z5QO9Y74XNDdTU 1tPya+puIYQQ4jYmwVT0eQ1FCexz38CAYSPQP5JyC3s2EbVlE0fSq6UThRBCiF8BCaaizyu/soMp k2aweN4CVnqGyTOgQgghxG1KgqkQQgghhOgTJJgKIYQQQog+QYKp+FGtTdUUZhbLLXQhhBBC/E9J MBU/quCCE0s3hPGzvE0p7zTmBxOk04UQQog7kART8SOa2TNlGDYx//14adWVPVgeOP/DG4VqoDZw i3S7EEIIcQeSYCp+WPpmPpy2t8e7PlubG6mvraW2to6G3l4C2txAbU0tdQ2NNLd0bZB/ZB3jrXZT 29hMnWL/+sbuE9O30thQr6i3hprG1l6b0qwor1WU1zZ0heSWRsU+qqHcpoY6amrqaO6lPTVt7VFs 2Nwsby0VQggh+ioJpoLagiTOhIeTXnL9zfoa/OdNxi6x22hpfSzGs77j7b/8H88++zofDVzIsYKu KFgZ6c+ysf157o9/5l8DBvHZ03/D+FKDoiAKzWF/Re2hJ3jxxRf40x9fZ7LuPkpVGbS5KJJVEz7k 2YfVUBvudV07qjm3TRFq+3/Ii8/8kVcHTMLMK4wqRQS9YDKGR9SeZIrBBqZ89S7P/eFZ3h1jy7XO 9uxlydjPeeb//sw/+n3OB0+/yPJD2cqyhuI0ToVfIK2oXr4EQgghRB8gwfQOVpl+Dvf1JhgZGWJg u4UrxdeNJmb6MHqGKxXd1zWXklXYbUTz8GI+3BTf/rn0NDMnLScwu6O8iYPLpmF/pVa5VH/eiUVe p364UbX7eHnKnh6ris5aMmLOJrI6D1vEVu0FmO/JVC4FznmPGduiVbNIteI+8Cs8cts+1xAw6Ts0 9+d31pW804HdUe3zk7YUXsbe2gRjE2PWme/gYk5Vn71WQgghxJ1AgumdqKmI7eaLmaVjyy7/48Tn lvcyLWc9wXoGmByIu259NQFms3nrT8/x4iuv8dLv1XjVLlZZUnFiA6Psj/TYuu5aDkXtuZSSkxZM dzrww23L8uSFybt7rAo3G4x6aM/R3Oxj3pgu8qGt6r1Th7CjM3s2sHfaINwzVMeP3seqmd/x9nN/ 5i/P/4sBk9ZzqaT7zf5mSrLiOO7vg63WPGZa7aWyWb4iQgghxC9BgumdqKkQl6VD+GjYCvyv5PS+ Td4Zlhnbcv5a9x89NXBy+VhWH0xTLrWNUF7bM5dXHFS/oo/14ONlrlT2qKiFFtVIZ8kJMyY7HOxW 1qoou+550sJd/G16QI9VCZ4z+MYlqce6S9vN0dEPUX7eP3MoOwq6yvbPGIqXcrmAXet3cKW8QVXS TPLWebxvefq6k20lN9IX9cGf0F/T87r2CyGEEOLnIsH0DtZUcBGnxSP5Zt5a3A6cJru6Y9y0lQu7 7DBzOEFDjz3qOa2zBE2HnRw6cpCAPVtY9smTPDjJmtjCtgBbR6jBYhaauuO/bz8H/L0xnTcbt9j2 uepbUgMYt1CLLbv92e+/hy3WdvhcaL8d31CaRtjBAwQ6L+Ch99XZe+QQx88nKkdEqYvDatJU1rn4 sG9fAF5u1mgu0+F0uaJFGSdRf/dF5nuc5VptPYXRR1F/+0UWeUcrInEqBq8NZ976rRw5coCDB/bh qjef1YdS2ttTlUXovi3ozRnBcHVnLhfKD6OEEEKIX5IEUwEFV9nj70tEjupHQLXpbNJfwY7Y2t42 ZoeJBtMXaGDpc5bijLNoLFuG89mOnxvVErbdnLkz5rBMxxL/iNweexed34P63DksWq7Plv3nyatq v0VfmRaG9dLZzFm0DO2V6sybtQBD10CKVMm4qTgKT1MdFs2ayfy1bkSVtK1tIcHHFnV1dZbpWROe X8QF5/UsWaKO9jp3kivLueDpz16/bRgsnMWseSux3n2x832sdVkR7PTbT0yRfAWEEEKIvkCCqbhB SbQ3K+Z7UCJdIYQQQoifkQRTcaPWFuR1n0IIIYT4uUkwFUIIIYQQfYIEUyGEEEII0SdIMBVCCCGE EH2CBNM7RUUsDtsDSC5ulL4QQgghRJ8kwfQOkXzQGQMbH0qlK4QQQgjRR0kwvRM0F7DdfA3uIYXS F0IIIYTosySY3m56ec9TdepRjOZtJKVj9s/WWq4EmDP8o3/wp6ee5NVvdQnL63mLvyLGl8mf/pM/ /uHPfDlLE2OjzSSr3rffmnOUxUPe55knXuDDSRZkdR38upmihBBCCCFungTT20BrUx35CaHYzOzP B+sO31AeZjuRxfvyu1Y0VhFz5iSxqmmVSi95oTnWklRVcWX8HhaNUud4RhVtWTb7rCvzRy7gQo1i oek0Mz9bRqjq7fu1VzYzbNxWypVL1QQuGMIgDXvOJRfRIO9CFUIIIcQtkGD6a1aZybFAf6xWzWXy 1DX4Xb3Wy0anmdFPn4zr1tYXpxB8OADfvQHs2mqO+owVRFa1l4Vaj2R+UFXXxk1FXDh6jALFx1S7 UfRb48HxQwHs3evPwSBfVn35Ce5pXZtfi9iHzsLJzNGzxWtnCHl1cqmEEEII8eMkmP6K1UdY8shv X8MoIO57t8lymsFYn7we62qzT2O9XJtVOitRX76C5YunM2GMNtGqW/Unzb5l+YnqXus7r/cVb49f ivaKZSxdulTxR501xtuIKb9x2+idy3hK7S22JMubAIQQQgjx4ySY/po1lJJ4PgTXDRqMGTkRU9+r 9Lx7fpXpX+sQf91uWYHGjJpzqHP5kMkUvv5Cv/NZ0Wvhjkwcb0RCR2W5p9hs7UhM28hnpAVfz/Sh tVt9ieGBROY1q5ZauLjXmilDhqFhsY2Dp2OpaJZLJYQQQogfJ8H0NtFYlkHQxvm8r98VONO9tJnq dqaXjXNwm/8JD6mp8djrE/E+GcCMv/+OV6c6UqD69VLGMVs+ef4x1BTb/P2bFeyP6vpFf+rB9Xz8 QnuZ2p/7obf5CLn1bSVl7J46nVWbDpNVLQ+YCiGEEOLWSDC9XdVGo7/QnJOp1dIXQgghhPhVkGB6 uyrP4OSVGMrl8U4hhBBC/EpIMBVCCCGEEH2CBFMhhBBCCNEnSDAVQgghhBB9ggTTX5uKqwREFEk/ CCGEEOK2I8H0VybJegzLjlfedudVnXaUWR//hd899nveXnuy941yg5lsupPcptv9Kjfgrz8H37RW +cILIYS4o0gw/TWpDWb4B8bk3qanp4xh6e48O2FX7xvkHeFfc21JbriFSgt388KkXT/zmSSz9m+a N0xscCu2TPkEpxiZmUAIIcSdRYJpX9V6/WhZK9EOq1niH9O1pr6MlMhgvLZtw2OnHyGxeT1nfmqt JP70IbZu88L/4HGCg6PJr+4YbmwkJyqUXd6e7PQ5TOiZyyRndY3E1hUlEuTvwzb3HQRH9ay3Lu8q h3y24+Gxh6OhIZwKzaAzK9bmEBKwg20eOzkQeJzjQbHc0vhuznb+Onn3dSubSArfxzav3QRFZnBD XGsq5uyRPWxTnKfvkROcCQknX/marDoSdq3m8ffm4hWwB28PD3afSaDpZgcim6tIOheE13YPfPaH k1vVvmNN2mm2+R4iLjuLy8cC2K7o/6OXr6lmw2qlINyRQY8PwHTnXnZ5bWPL3khV/7RQdDWUnZ7b OBJR3FYT8acOss3zCNl17fsWRYfh4+nJwdA4ym4YGW6hJO0i/ju92L7jAJczy3uUFcSfxm+np+K6 +HHy7DkuRxWqrptMdiCEEOLXQYJpH5N1aT+Wem4k1F5XUB3J6uXmhGV1FTSkhmBrqo/6Mg00Vy9j 6jh9DiWUtRe2lnDIxZpVK1eyXGMVhnrqfPLXaXhcKVEWRwVuZfVSTTRXrkBbS5cpX41lpfVFZbhq KbyE9RJ1VurooLl8JatWr8HxkGrC0tYE1k1bwmrdVWho6LF+zUief2SdahQ3j+16a1mtsxJNTW3W 6c7ghbtncO5WBv6yPHnhhmDawNndlqyYMYh7Pl1DSo/A1sw5K03mKtqoqTjPteu1+ObZv+OmbG4Z QRum8uBfv2aFrhaaS9XR3XGK+psKphUc91H032odVq5U9JP6KnQ27SRNcey66F18+tb/8co4bayM 9VmtOY/RkxawN71F2Z7Y7Zr844F/MnWVDqs0FjPf8KAigra3NT3IC6MlA3jxGQ22BGzGynwdi8ZO w+lqWzJtJeOYJ2u1ljLkg7exvtIzmeac3YfxilWKNq1ipcZKlunYcDS6/XrXpB5FZ8YSVmqvZMUK QzSnD2bgkN2qfxSU4Wegi+eZdImoQggh+jQJpn1E4mE7Rg8dywI9aw6FJHH9fE1Z/m6stfRTRIxu Wpp7jB6mOWpjGBCr/Fx8YSfaBvYkVHWUXmPrajuOpihWVMewUXMpB1K69g73cGbzzmjl54uuCzEP qeuquO4qjrpmxLdtXuTFyy/rdXucoJC9Lmfa21t9iq/fnMuJmo6yZoK9Qsi/lY7oNZh2nO8lhixw IqXHrfxCLN/4AIfUrjUp+3dxpWOYttSfl6bvveXrUR5/HHt9Twq7rTvmsIldgZnKz6EuMxmzJbqz LHDjBOYf7vhRWgYmr60m5XtrP883dw1g0/lUlDO5UktJTc8QGrRuEFaR3dbVZeNtb8ThzK5VFed9 cHDfr+z7nMO6fDHWu6uwKooj++JUI7WtpJ/2Y9O65QwdM531PhHyF04IIUSfJMH0F5eD5iu/Y7Cu L+lV37NJQy52Zvq4nSvusboq7TSW0z9Szll/z2/uUfz/aebtSlaWXXVzxNrsGL39Tqgi+SDGw60V R+5NM/b9H1TUdR/33X2Xsm41tXt4od9izioP30qEpy79Xn6ivezJf7Lc+RTtMbbtNrY3E/s93172 u7/w1RLXzmBaHbmFfz77gKrOu/n7eAvSb0jgPxBMy8IYMMfhumCq6If4fczu/zqPKOt9gk+mWxDT EY5zd/L8RO/e66uLQ/PTl1XtUfz52xA8Yyram3FAn5cU6+66/17uavv/3W3bvMFKz/bgf8R5NouC SjqrCnSexbzDHTE2Dt0XlxP1fZe84QjjXnGi9Ae+Ffv0BvYIps2l4cz6+92o3XUf99ylaEvbH7UH +WCBGyVtI8BNefgZT+elpx9SnssD/xzFpsDEG6+/4rt03GU2zz8whtAa+dsnhBCib5Fg+ourxt9o PnNWmuGyzY+wKx2jaF1KY/0xXOnQM0i2JKM3TpOt0R33pes5sGwWBqohtbJIH1ZomRPZmZ0aSbsU R261YvvKWGw0FrIrqiuZFCUlkJxRpvx8wmQyGy/0bENLQw3KxzbPmTPEoXvkKmD1PwZzoC1Up/kz doNfj/22DR7Kxujam++Oir28PPvw9xReZsjSrT1GMeESKwdbk9dtzcV1/RnmU6Bq3m5eGuDYObLc WplHSn7VjzbjWoQ/6zV3Xvd8bBN1je01hXkuZnlYV/+d8VzIspCOlJ3Impen0zku2VBManpJt9Ht U0x9fSs/NFvsCdPhOCd3LbdWJuNmosOJgp7b1dW1f1uid61E81C3qJu3n+XfanKlvqvtObHhHNjp jt3aJUxb5UWO/LZKCCFEHyPBtI9oLIwjwNWeDRtMMVvvRkK30awQm+no+V1/Q7yMQFdLZo8fz5Rp 89E3s2DpgHf5099HcVh5n72SYC87li+YzYSJk5k9dxka2m5cudY+tpkYugOthXOZOmUyU6ctQVPH hsMX2m/Q12WHYrR0KXPnzWLihHHM0tDD1vMQmW1JKkQTtfemsU5rKZMnjGfi/IXoGfmjHEyNd+cP /cewRkeTqRMmMHnuXOYvciTpJnJpRfJxjGdPZvrwt1D7/XtMnDqD1XYHKGwbHW3JwHX+BKaM+pz7 n3qdb8ZNYOFqJ6KUv/0JZ7jaR8xbt4YFU8YzYdI81FesVQS4jsCehcOsWYwZN46JM+ejsdoA59DM H29QcxFB3qYsWzSfqZMnMW3GYrQNHTmRXExZhBv/fOEhfvf5Ko6nl5J5yIw3//oQj48w4GxuWxJs 4oDOBEaOn6zov7ksXaWLs1+c8vndFH8Hloz/gEfUXmfUrMmMmmPLxWLVEHBTIQFWukybMokPX3iA V78ey4Txazma3B6kk07tRm+ZIlROn8qkKVNZvNoIl0MXlQH3tO0gHh24AC31eYrrMo4pi7Vx8jyn eiSkHH8tLdauN8fGxYeIjKo+9d0XQgghOkgw7Wtqi0m6Gkdpxz3Y5nPM/Vi391cPNZUSe+YkR4+F Ep1RTHVpBqePh5DaOcxXR1bMOY4cDSLk9FVyKruPxbZQnHaVk8cDOXbiPMnXKun+m6C6whTOhp4g 8OhRQi8mUFBe115enUtEXDLxF88QpCgLOnWF4o621pcQnZJKSvQFjrWVhZ4ntfTm3u3UUJ7NxROB BJ4I4eypYMX+xzh7NZ065a91qogNPsrR48GcPhXKiWNBBJ+Jpj3P1ZB6KYHExMuEBSm2CTpNfH7P JNxalcnpwCMcPXGKyIQsKhtu8idATZWkXjnLsaBAjgeHE5dZqBzNbiiIIfDYSU6GRJBZUU9l+iXl ckj4ZXKr2jujpTafS2HHOXo0mPPRaVTUtx+zPPUqwcdOcOpM23kEcvjkFQpVZbTWknb5HEGBivML O03oySDFtTtPZnnH2GozJRnRBB8/RpCijnMx6ZTWtJfVKK7X5bh4Is+GKq7LEcKupNP1b5t60i5c Ja9ahkiFEEL0bRJM+7iaE3pM882XjhBCCCHEbU+CqRBCCCGE6BMkmAohhBBCiD5BgqkQQgghhOgT JJgKIYQQQog+QYLpL6GphoLcLCqbpCuEEEIIITpIMP0FlMUcxUZ7K1mt/2VF186zYt5URo2ZhfmW yBumMRVCCCGE+DWRYPoLCHGbwzKv1P++orpCIs6dxW+zIUu+sSdbulYIIYQQv2ISTH9uzRdY8fka Erqtaqgu51p+LtlZ2eQV9zIrT3MNhXk5ZGXlUVxeTkVFz5fW16YcwWy0PVnSu0IIIYT4FZNg+r/Q WsrVk8cIjczk+rl2crbMYbRX91nvK9itM5OBn3/Im2++y2eDx2IZUtStrlycV89l6Bcf8I9/DmDG zP689px9j/niy+L2YTrqumDaVMqF4ycIu5xB623XwUIIIYS4HUkw/Sk1FhG205JF6roYGtiwLzyT npNfRjNviAZXeqxrorSwa/JIWvwZ8LEHHbOKJmyawRTbyK7y4r1M/npr+9z0Kr0G09YKzuxyx2y9 MToaOniFJNFwO/SxEEIIIW5bEkx/IplHNjJ9ynzsvI9wJSWfml6mJS/y12KU7dkb1l/YvIz3nnuM Rx57gicfv5cXPt1JubLkGnYvTSCwx9YNFBdU9gi8vQZTlZa6MhIjw/BzWMNX4/Q4ll0jF0sIIYQQ fZIE059IQZgTg/sPR8txH6lF1TTecP88kbVTTAjOqu2xtnTvbN5fd75rRf4Ohr/jQfuTpo0cXzqE Nae6h8kmKstqewTThvQgrMa79hhF7dTcQH7iGVy0ptBv2ApOXZNxUyGEEEL0TRJMf1L1RB1yZMaI aehaunIiOrfz+c6Coy6o2/l13qLvUBZizHfLLHHf6oGnpydWSz7l/kemsPtyfvvzqWXBzBy9BCtX d7a4bWOLvQGaGvuUI6ot16LZ6e2JjcE8hrw6ig1ubmwOjGmvuKWSS8F+bDRezrhxWuyNzJfLI4QQ Qog+TYLp/0QDiSGHOXYxFeU79FsK2Gq+ji3HervZ3sSFXbZordDHatsx8iqz8NVdi1tAHB1jqzVp oThv0GfVynU4+IRS2nGUrNOYrdNjjb4hxuvXoa+1gpUeqkcFGos4eTSIkKgCuRxCCCGE+FWQYPoz qE4OxlzXlKvyBnwhhBBCiO8lwVQIIYQQQvQJEkyFEEIIIUSfIMFUCCGEEEL0CRJMhRBCCCFEnyDB 9L+QtNUch/N5t915tTZWkZuSQlp6DsXVjb1v01RHZVU1zfI1EEIIIcRPRILpf6ohEo2JxpzNq7/t Tq027QBz3vknrz71JG/pHup1m4KQjUyat5LYilvosmsJnE/Ole+OEEIIIXolwfQ/lLl3E5qOh7id J/hsOWfFtM3Hvqe0mOjoWKpuYci07ow1M9xPypdHCCGEEL2SYPqjmrhhEs/mfBwt1+N5pms2pYrU MMymfs7vHrqfh596g6XuZ+k++Whz3mlW9n+Fh+67j7/0G8NYXWOCMlSjra3ZOM/8lKfvv4v7XvqG +StmY3a+vHPf2O2avP/CY6j95iXGrg/uVmsjibu0eVZNjXuffpmvh3zFBxZdQTIvzJlBf3qCex5+ gn99PoSv9TeTWtF602deFLiOyZuuD6YlrP/XI4q2/JGvNbdTeN2d/ubUAEb9/XHuuvcJ3vxsIP37 mZKkrOwC8/r/ETW1e3n00Ye47+6nGbrMh+LO5tRy0VuLV575HQ8+/AwfD52KjtVurilnKGilFSGE EELc7iSY9qKptoysuNN46I/jr185cv3d6sIrezHWtiWzc7SwlaKUGCKTO+ZkKsdmjQ72J9pneqrP CmbV7PnsjFVF1dyTzFy6CK/4tshbgdO0QegeyVHtW4nN4q+Ye6RIuVQcoEl/3eDOYye6TGW0a1p7 vaHreHW+Z2dZZdBaXtYNUH5uSd7PRA0jLnYM6Sb7MnKNNTElLTfdD70HU5WsIPSsLUko77au/hxj P1jKmY4kX3eKae/ocVnVT9WnNzLP/Xiv1eWGurNysSUdUT/vuAM6epvIVgbTajx0hvLVQjuCr6RS XtsoX1IhhBDiNiTBtLvWYkK9vbE302b+Yi08TiT3slEzR+3VMQi47lnJpnKiT+xls/Nm3LfYMnfI Qmz3tO8f7WfGkrXh3aqoIvLiWZLKFJ/zPfns6109fkSUHxVISEpbusvG5KXPWL7Fm22um3F22YrX luV8+pcNKGOsImzO0tTD2dUFZ2c3PLduxz9S1a7CCMxMtDC2dmTzZhfc3TzxC4uhTpVLq7Ii8d1s j4OTEw4Om/ELSqbuujP9oWBal3QQXStrErsH0+Y0LJdqY2jnrGiPMy4e29jmf56OCa9KT1ow3elA r/VVxB/HYqkG5hs3K9q7GTe3PZy8nN5jtLrgsj/as5awxtyRHfuOkV4p46hCCCHE7USCaXe1IQy4 7/cMMz/C9/6mp+4iWt9pc7Wp27qGQvZ7WWJgZIrxOmMsLNYy4as52PqnKouj9pqy0Ci89/qy3en3 jQ9NvRbGof7Y5yyytmS9kSGGhoo/RsZs8Y1RhsjKxHCOHQvEw9YY/bXrMDNexejpnspHCBqvJXEm 6CC+7hvRNzBk/TodZs+353xee/wsTzmNq7GeYr+16Om11Rl9w/OyPxRMaxMPsub6YFqZypGTJzjs 7YS+vgFGZkYsnqBOYH57Gi4+Yc4s595/TFWWcZVAfz887CyU52mkpcViy60klF8fPps4tnEOf/2/ 93GLa5DvrBBCCHEbkWDaQyOF6VEEuBgy/OuhzDHxo+S6LfL8ZjFmc3qPda2FirC6ein7r7UvV1xw 5Ys3vsHsZLFyuTY1kOVT57M3XRWyaqOxtN5IYGJbSCzGevRAjIKLVbU14eugheWJQuXSBb0xTPMt 6Ha0XI7vDVa2K9ZhAWOM9nQVlfvxj/eNaMuK10KcWaRuSHRn4o1n/kQtAnokyR9xwYY53hd7Lys5 zXpXV0q7r0vw4vXJa4ntHHqtxu7TEbgktT9LW3PWineWunRunh5ykKNX2x9huOKxgQXTtnf9g6Dg EPM0tDirCrW0lnPGRZN+n49Ax8mPy0kF1Mq7qoQQQojbigTT71VP4glbhn9mSdebSi+z5I3lRPey df5pZz597reoqT3LPOcD+K2dwhNqH7Ilrv1Gdl3GMRZ98KyiXI1H35/B9lMZXbfvG5KwGvcODyvK 1P7wPht8o7rdVm/hgN5o/vyookztfl7sPwff8+236xM9tJi+dDFDXn1UUXYXf3x3Focy2p9jvXZu OyvnTWDyl68rj/nwc1+xMTjtps68MFCX37W15b4Heej+exX738d7o71R5u7Sg7zUVnb3fTz4wAPc pfj84J90UD60kBbAl/OWsGTE28pjqj35Jhq7Y7vV3MBVlwU8qCi759EXGb3KlUt57f0T72vHnK/H MugfTyn3ffLNuexPUMXUljK89May0ivihscNhBBCCHH7kGB6C/K8VzF861XpCCGEEEKI/wEJpjet hbwL4SSWynONQgghhBD/CxJMhRBCCCFEnyDBVAghhBBC9AkSTIUQQgghRJ8gwbQ5n/CAS1TJd0EI IYQQ4hd1xwfT6vB1DDC8/uX3LcR5ruTVB9V48GkNEuR7IoQQQgjxP3eHB9MCLL4azaHvfed8PQ5/ nUHwzcx8WX2egXNsia6XL5UQQgghxH/iDgqmrdwwueVZM/rrBvdcWZZEgLsDFjZbOZkUgumLswlT 7V9TkMyJPe5YWdnguNWPK7kdDwA0kxW0kX+8P5yV5rY4blT88Qkiu6p91qKWxjLiTh3EbZMd1tZ2 +J9Npb5bu4QQQgghxJ0QTEuustlsPZsPp9BzBssiXKcvxyOhsmtVzUU0Z2iw1swMU1MLjLXH8tw9 k4lQFjaScNiLDaamGJuux8xAg++0PMhUvta0mdRDFvz9rYEsNjDBzHgdZtsOkF7ZHkxri6LZvsEI I8V+69ebskJzOZbHcjsPe2rrGvS2hlEm30chhBBC3MFu22DaWnwJ25kDeG/0ctz3nSHtuhfjN8dt Z4qhB2Xd0mqU7XwWenSb2alwN2+rTeF8r0eoYsOw9ZwsUI191kUyZrkLiTcxf3v1aVdWLQ6iVrVc lnkR381rGfbRUOZt8JWAKoQQQog70m0ZTM9Yz+Cl50ew9UrZ92xRxm4dE9wOJnVbV4rXVwvZmdx9 NvY0tJ6eySnl5yquHLBn+CuPKedyv/83bXPXj+ZYWfuoKBXn+HaxHVcqbkymlVkhGE78lCfub5tj /m7Fn6cZoXOaxl5alnDQjH/+4RnWhtfIt1MIIYQQd5TbMpgWRPpjuGo1663s2bzrJOkldT3KG9NP sdbYivMlPfdLcl3MKKvQzuWmqxt5Xm0W8W0L8V4MWmpDUUdhWTATP9AlvONh0eoIxo5fx9mOx07r i0jMKFR+9Fv3HRpBtZ31BlouZ6FWzzcBFCeGs9vDFTtrI1as2MiFouZf9TUQQgghhLhVt/EzpvVk XDzKJjtbDNeY4nEwqfMZ0/N+FmhvDKPp+l0aErE10GTyt4MZMHwiS/UW8LbaQ3y5yJvMwkS2GC9m 8NcDGT5mCRts9Oj/5F/4+xfmZCt3ruDkRkNGfT2AgUO/ZdKC1Vj6RSiPmXjYlLEjvuXrAaOYr2+N 0dwB/OGeATgEZyn3DN+6khWGlmzcsoczCYXyrRRCCCHEHekO+FV+CyV5OeQXqm6Nt2bjvGAGflnf s3lDCQlXLhJxOZbsimoqMmKJjs1R/oq+tbKAqMiLXI5Kobi2nuqcFC5fyqBzPLalirSYy0REXiYu LY/KOlX0ba0nNymaiAtXSMwpo7mhnJRIRf3F7XuW56WSU9Yg30YhhBBC3NHuuPeYNuQcwmBNMHKj XAghhBCib5EpSYUQQgghRJ8gwVQIIYQQQvQJEkyFEEIIIUSfIMFUCCGEEEL0CRJMhRBCCCFEnyDB VAghhBBC9AkSTIUQQgghRJ/w//8eOg42/7uYAAAAAElFTkSuQmCC --_004_77da5a7334bd4f25a955fb0c5392b512XCHRTP001ciscocom_-- From nobody Sat May 14 09:57:50 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A7312B062; Sat, 14 May 2016 09:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.724 X-Spam-Level: ** X-Spam-Status: No, score=2.724 tagged_above=-999 required=5 tests=[DOS_OUTLOOK_TO_MX=1.449, HTML_MESSAGE=0.001, RDNS_NONE=1.274] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QboKyODUYAze; Sat, 14 May 2016 09:57:40 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 2E5A312D163; Sat, 14 May 2016 09:57:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.63; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , "'Ben Campbell'" , "'Alia Atlas'" References: <9e9692bd22a041ba91e39a9f7dce8c9e@XCH-RTP-013.cisco.com> <00a901d1ad2e$f8a21e10$e9e65a30$@ndzh.com> In-Reply-To: Date: Sat, 14 May 2016 12:57:35 -0400 Message-ID: <000c01d1ae01$b77d2f50$26778df0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01D1ADE0.3074B710" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIU8vzK+Q9YGgizFl1gE64LnYjY+QJjnbK/AbOLQWACnTaZHJ78emyw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 16:57:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01D1ADE0.3074B710 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Eric:=20 =20 Thank you for making the change.=20 =20 Sue=20 =20 From: Eric Voit (evoit) [mailto:evoit@cisco.com]=20 Sent: Friday, May 13, 2016 1:16 PM To: Susan Hares; 'Ben Campbell'; 'Alia Atlas' Cc: 'The IESG'; i2rs@ietf.org; = draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org Subject: RE: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) =20 Sue, =20 Made your change (see green below). I will await everyone = else=E2=80=99s ok to see if there are any final changes before posting. =20 Eric =20 4.2.5. Security Requirements =20 Some uses of this Subscription Service will push privacy-sensitive updates and metadata. Good deployment practices will bind this generated information within secure, encrypted transport layer mechanisms. For example if NETCONF is used as transport, then [RFC5539] would be a valid option to secure the transported information. The Subscription Service can also be used with emerging deployment contexts as well. As an example, deployments based on [i2rs-usecase] can apply these requirements in conjunction with those documented within [i2rs-environment-security]and [i2rs-protocol-security] to secure ephemeral state information being pushed from a Network Element. =20 =20 From: Susan Hares, May 13, 2016 11:49 AM Eric:=20 =20 Thanks for jumping in and putting out text that resolves Ben=E2=80=99s = comments. This text works for me with one addition. Add reference to = the security environment draft.=20 =20 Sue=20 =20 From: Eric Voit (evoit) [mailto:evoit@cisco.com]=20 Sent: Friday, May 13, 2016 11:26 AM To: Susan Hares; Ben Campbell; Alia Atlas (akatlas@gmail.com) Cc: The IESG; i2rs@ietf.org; = draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org Subject: RE: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) =20 Hi Ben, =20 I have added the text below as the lead-in to section 4.2.5. I believe = this meets the intents of your suggestions below. =20 Hi Susan & Alia, =20 I have uploaded v08 of https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ If Ben concurs with the text below, I am not aware of any remaining = discuss items. =20 Thanks everyone for your reviews, Eric, Alex, & Alberto 4.2.5. Security Requirements =20 Some uses of this Subscription Service will push privacy-sensitive updates and metadata. Good deployment practices will bind this generated information within secure, encrypted transport layer mechanisms. For example if NETCONF is used as transport, then [RFC5539] would be a valid option to secure the transported information. The Subscription Service can also be used with emerging deployment contexts as well. As an example, deployments based on [i2rs-usecase] can apply these requirements in conjunction with those documented within [i2rs-protocol-security] to secure ephemeral state information being pushed from a Network Element. =20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Friday, May 06, 2016 7:09 PM To: Ben Campbell Cc: Eric Voit (evoit); The IESG; i2rs@ietf.org; = draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) =20 Ben: =20 This is wise idea. I will suggest some text to Eric and you in the = morning. =20 Sue =20 =20 =20 Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone -------- Original message -------- From: Ben Campbell =20 Date: 5/6/2016 2:38 PM (GMT-06:00)=20 To: Susan Hares =20 Cc: Eric Voit , The IESG , = i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, = i2rs-chairs@ietf.org=20 Subject: Re: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)=20 =20 Hi Susan, To be clear, I do not object to the wider context per se. My concern is=20 that the security and privacy requirements are left as implicit, based=20 on the more narrow i2rs/netconf context. I only mentioned the potential=20 of restricting the contextas one possible way forward; I am certainly=20 not wedded to it. My suggestion for a way forward would be to document the high level=20 security and privacy requirements in this document. IIUC, the larger=20 context includes potentially unknown contexts, so some of this may need=20 to be conditional. For example, language like the following might be=20 helpful (this is just an example--I don't mean to say that it is true or = applicable): "Some uses of this mechanism may carry privacy-sensitive information,=20 or generate privacy-sensitive metadata through the subscription=20 mechanism. In contexts where this is true, the following requirements=20 apply..." It might also be reasonable to say that, for the context of i2rs, these=20 requirements are documented in [references] and are expected to be=20 fulfilled by the [transport and or protocol] Eric's email also suggested that the actual transport of data from the=20 Yang datastore may be out of scope for these requirements. I don't=20 object to that, either, as long as it is clear and explicit, although it = would be good to point to where it is _in_ scope. Thanks! Ben. On 6 May 2016, at 1:06, Susan Hares wrote: > Ben: > > This is the first of the "re-use" management protocols. The=20 > requirements > are set-up so that we can suggest additions to the NETCONF and=20 > RESTCONF for > this first of I2RS. > > The I2RS ephemeral work, pub/sub, traceability, and security are=20 > target at > the I2RS protocol definition with the I2RS use case. However, since=20 > these > are general additions to NETCONF/RESTCONF, this work can be used=20 > elsewhere. > > I think the text you are highlighting has this larger context. Now,=20 > one of > the really important things to chat with Alia and Benoit is how do we=20 > handle > the wider use case. Do we mention the wider context? > > The WG thought mentioning it was important. > > Sue > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Thursday, May 05, 2016 5:31 PM > To: Susan Hares > Cc: Eric Voit; The IESG; i2rs@ietf.org; > draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ben Campbell's Discuss on > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > On 5 May 2016, at 5:15, Susan Hares wrote: > >> Eric, Ben and IESG members: >> >> >> >> The pub/sub requirements are part of a 5 part requirements. May I >> quote >> from the shepherd's report: >> >> --------------------- >> >> The requirements for the first version of I2RS are: >> >> 1) model driven ephemeral state - that is data models that do not >> survive >> >> a software or hardware reboot. >> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >> >> >> >> 2) a secure protocol - >> >> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req >> uireme >> nts/ >> >> >> >> 3) traceability - ability to record interactions between I2RS=20 >> elements >> >> (Client, Agent, Routing system) >> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ >> >> >> >> 4) notification publication via subscription >> >> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ >> >> >> >> 5) Protocol to pass Data for Analytics >> >> The first version of these requirements does not include a >> >> separate analytical protocol requirements as the simple use cases may >> >> pass information via query/poll or the notifications. >> >> >> >> The I2RS protocol exists in an secure environment described by: >> >> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment- >> reqs/ >> >> >> >> ------------------------- >> >> >> >> Eric - Perhaps it would be good to point to: >> >> . draft-ietf-i2rs-protocol-security-requirements and >> >> . draft-ietf-i2rs-security-environment-reqs/ >> >> >> >> Ben - Can you tell me how the shepherd report could have been=20 >> clearer? >> The >> I2rs protocol security requirements require: confidentiality, >> encryption, secure transport, protection against replay attack, >> protection against DDoS attack (if possible). > > I think my confusion lies in the fact that, while the shepherd's=20 > writeup > styles this draft as part of the I2RS protocol requirements, the draft > itself claims to describe requirements for a generally useful pub-sub > interface to a yang datastore. It's not clear to me how and when the=20 > I2RS > protocol security requirements apply to it. If the described interface = > is > intended to be useful in contexts other than I2RS (and the draft=20 > explicitly > sets that expectation in 2.2), it needs to talk more generally about > security and privacy. > > For example, it might make sense to say that certain security=20 > requirements > apply in environments where the mechanism might carry privacy=20 > sensitive > data, and then point to the i2rs requirements for when the mechanism=20 > is used > in an I2RS context. > > A different approach might be to more tightly constrain this to i2rs > >> >> >> >> Ben - On opting in, once the receive accepts a transport connection >> from the I2RS server - how is this not an opt-in to receive data?=20 >> What >> are you looking for? > > I guess that depends on the transport. The transport requirements say=20 > the > mechanism has to work over multiple transports. The last paragraph in=20 > 4.2.4 > says "In the case of connection-oriented transports..." which suggests = > that > non-connection-oriented transports are possible. > > Even with a connection-oriented transport, this may depend on how > connection-management is handled, and whether the receiver might be > receiving things it _wants_ to receive on the same transport. > >> >> >> >> Sue Hares >> >> (shepherd) >> >> >> >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit >> (evoit) >> Sent: Wednesday, May 04, 2016 7:25 PM >> To: Ben Campbell; The IESG >> Cc: i2rs@ietf.org; draft-ietf-i2rs-pub-sub-requirements@ietf.org; >> i2rs-chairs@ietf.org; shares@ndzh.com >> Subject: Re: [i2rs] Ben Campbell's Discuss on >> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) >> >> >> >> Hi Ben, >> >> >> >> Thanks for the comment. In-line.... >> >> >> >>> From: Ben Campbell, May 04, 2016 2:49 PM >> >>> = ---------------------------------------------------------------------- >> >>> DISCUSS: >> >>> = ---------------------------------------------------------------------- >> >>> >> >>> I have a couple of points I would like to discuss. Hopefully they=20 >>> can >> >>> be resolved >> >>> easily: >> >>> >> >>> Are there really no requirements for privacy or integrity=20 >>> protection? >> >>> Is there an expectation that this mechanism would ever carry privacy >> >>> sensitive or otherwise sensitive information? >> >> >> >> [eric's comment: >> >> When the subscription is established dynamically via an existing >> transport >> session (which is expected to be the dominant case) we have the same >> expectations for Privacy and integrity as would be provided via a >> "GET" >> instead of a "PUSH" over the same transport. We could have >> replicated all >> these requirements, but that was seen as unnecessary and likely less >> secure >> than adopting existing mechanisms. >> >> >> >> When the Subscriber and Receiver are different, then the transport >> connection will have credentials passed as part of the establishment. >> These >> credentials will be used as a Security Grooming Filter just like the >> above >> case so that pushed objects will be excluded from an Update >> Notification as >> per the permissions of the Receiver. (I.e., this is identical >> behavior to >> the above.) As several people have had questions about this, the >> new v07 >> will make this explicit in the Security section. >> >> End of eric's comment] >> >> >> >> Sue: The transport provides for privacy, integrity protection. Most >> configuration in network boxes would need privacy. >> >> >> >>> - 4.2.5, 2nd to last paragraph: >> >>> I am surprised to find that, when the receiver is not the=20 >>> subscriber, >> >>> that the receiver is expected to opt-out. It seems like some form of >> >>> opt-in or affirmative consent would be needed here. >> >> >> >> The question really was how heavy-weight should the mechanism be. >> Transports been considering are all encrypted. So there is already a >> level >> of trust between the peers. And a target can always pull down the >> connection if there are issues. >> >> >> >> In addition, multicast transports are viable for some future cases. >> We >> didn't want mechanisms which complicated this type of interaction, >> especially in a world where dumb IoT devices may be involved. >> >> >> >> Sue: If the receiver accepts a secure transport set-up from the >> server, can >> you provide the reason why this is not an "opt-in" once it receives >> the >> connection from the I2RS agent? >> >> >> >> >> >>> = ---------------------------------------------------------------------- >> >>> COMMENT: >> >>> = ---------------------------------------------------------------------- >> >>> >> >>> - General: I support Stephen's DISCUSS >> >>> >> >>> -2.2: What is the real scope of this work? Is it expected to=20 >>> supplant >> >>> the mentioned mechanisms? >> >> >> >> No. It is just showing that many specialized Push mechanism exist. >> This >> is not intended to supplant existing mechanisms, although perhaps it >> can >> help avoid future dedicated solutions. >> >>> - 2.3: "We need a new pub-sub >> >>> technology" >> >>> The shepherd write up mentioned a goal to use existing technologies. >> >>> Is the point of this sentence to suggest that is not feasible? >> >> >> >> Existing technologies cannot meet all the requirements specified. >> There are >> technology drafts progressing in NETCONF which can. >> >> >> >>> - 4.1, 4th paragraph: >> >>> The MAY doesn't seem right--is this a statement of fact that the >> >>> subscriber may have to resubscribe, or a requirement of the form=20 >>> that >> >>> the service MAY force the subscriber to resubscribe? (Be careful=20 >>> with >> >>> MAYs in requirements language--they imply unexpected things. For >> >>> example, several requirements say a SUBSCRIBE MAY do something--do >> >>> those imply that the service MUST allow the subscriber to do it ?) >> >> >> >> Good point. Reworded in v07. >> >> >> >>> -- 4.2.2, third bullet: The previous section said dampening periods >> >>> MUST be supported. >> >> >> >> Yes, but dampening is never for periodic subscriptions. >> >>> - 4.2.1, third paragraph: This is a bit ambiguous. I think it means >>> to >> >>> change the what subtrees the subscription applies to, but could be >> >>> interpreted to change the subtrees themselves. >> >> >> >> Fixed >> >>> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but >> >>> gave the subscriber a way to reconstruct the order fulfill this >> requirement? >> >> >> >> Yes, the timestamp within an update. But this requirement targets a >> specific object in a specific subscription. So there should be no >> issues. >> >>> Nits: >> >>> - The shepherd write up suggests this is standards track. The draft >> >>> and tracker both say informational. Please update the shepherd writ >>> up. >> >> >> >> Fixed >> >>> -3, last paragraph: What's the difference between a "Push" and an >> "Update"? >> >> >> >> Reworded >> >>> -4.1: A forward reference to the subscription QoS section would be >> helpful. >> >> >> >> Moved the requirement in question to 4.2.6. >> >>> -- Last paragraph, last sentence: Sentence doesn't parse. >> >> >> >> Fixed >> >>> >> >>> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY >> >> >> >> Fixed >> >> Thanks again for the review! >> >> Eric >> >> _______________________________________________ >> >> i2rs mailing list >> >> i2rs@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_000D_01D1ADE0.3074B710 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Eric:

 

Thank you for making the change.

 

Sue

 

From:= = Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Friday, May = 13, 2016 1:16 PM
To: Susan Hares; 'Ben Campbell'; 'Alia = Atlas'
Cc: 'The IESG'; i2rs@ietf.org; = draft-ietf-i2rs-pub-sub-requirements@ietf.org; = i2rs-chairs@ietf.org
Subject: RE: [i2rs] Ben Campbell's = Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = COMMENT)

 

Sue,

 

Made your change  (see green below).   I will await = everyone else=E2=80=99s ok to see if there are any final changes before = posting.

 

Eric

 

4.2.5.  Security = Requirements

 

   Some uses of this Subscription Service = will push privacy-sensitive

   updates and metadata.  Good = deployment practices will bind this

   generated information within secure, = encrypted transport layer

   mechanisms.  For example if NETCONF = is used as transport, then

   [RFC5539] would be a valid option to = secure the transported

   information.  The Subscription = Service can also be used with emerging

   deployment contexts as well.  As an = example, deployments based on

   [i2rs-usecase] can apply these = requirements in conjunction with those

   documented within [i2rs-environment-security]and

   [i2rs-protocol-security] to secure = ephemeral state information being

   pushed from a Network = Element.

 

 

From:= = Susan Hares, May 13, 2016 11:49 AM

Eric:

 

Thanks for jumping in and putting out text that resolves = Ben=E2=80=99s comments.  This text works for me with one = addition.  Add reference to the security environment draft. =

 

Sue

 

From:= = Eric Voit (evoit) [mailto:evoit@cisco.com] =
Sent: Friday, May 13, 2016 11:26 AM
To: Susan = Hares; Ben Campbell; Alia Atlas (akatlas@gmail.com)
Cc: = The IESG; i2rs@ietf.org; draft-ietf-= i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org
Subje= ct: RE: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = COMMENT)

 

Hi Ben,

 

I have added the text below as the lead-in to section 4.2.5.  I = believe this meets the intents of your suggestions = below.

 

Hi Susan & Alia,

 

I have uploaded v08 of

https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requireme= nts/

If Ben concurs with the text below, I am not aware of any remaining = discuss items.

 

Thanks everyone for your reviews,

Eric, Alex, & Alberto


4.2.5.  Security =
Requirements
 
   Some uses of this Subscription =
Service will push privacy-sensitive
   updates and metadata.  Good =
deployment practices will bind this
   generated information within secure, =
encrypted transport layer
   mechanisms.  For example if =
NETCONF is used as transport, then
   [RFC5539] would be a valid option to =
secure the transported
   information.  The Subscription =
Service can also be used with emerging
   deployment contexts as well.  As =
an example, deployments based on
   [i2rs-usecase] can apply these =
requirements in conjunction with those
   documented within =
[i2rs-protocol-security] to secure ephemeral =
state
   information being pushed from a =
Network Element.
 

 

From:= = Susan Hares [mailto:shares@ndzh.com] =
Sent: Friday, May 06, 2016 7:09 PM
To: Ben = Campbell
Cc: Eric Voit (evoit); The IESG; i2rs@ietf.org; draft-ietf-= i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org
Subje= ct: Re: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = COMMENT)

 

Ben:

 

This is wise idea.  I will suggest some text to = Eric and you in the morning.

 

Sue

 

 

 

Sent via the Samsung Galaxy = Note5, an AT&T 4G LTE = smartphone

-------- Original message = --------

From: Ben Campbell <ben@nostrum.com> =

Date: 5/6/2016 2:38 PM (GMT-06:00) =

To: Susan Hares <shares@ndzh.com> =

Subject: Re: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) =

 

Hi Susan,

To be clear, I do not object to the = wider context per se. My concern is
that the security and privacy = requirements are left as implicit, based
on the more narrow = i2rs/netconf context. I only mentioned the potential
of restricting = the contextas one possible way forward; I am certainly
not wedded to = it.

My suggestion for a way forward would be to document the high = level
security and privacy requirements in this document. IIUC, the = larger
context includes potentially unknown contexts, so some of = this may need
to be conditional. For example, language like the = following might be
helpful (this is just an example--I don't mean to = say that it is true or
applicable):

  "Some uses of = this mechanism may carry privacy-sensitive information,
or = generate    privacy-sensitive metadata through the = subscription
mechanism. In contexts where this is true, the = following requirements
apply..."

It might also be = reasonable to say that, for the context of i2rs, these
requirements = are documented in [references] and are expected to be
fulfilled by = the [transport and or protocol]

Eric's email also suggested that = the actual transport of data from the
Yang datastore may be out of = scope for these requirements. I don't
object to that, either, as = long as it is clear and explicit, although it
would be good to point = to where it is _in_ scope.

Thanks!

Ben.

On 6 May = 2016, at 1:06, Susan Hares wrote:

> Ben:
>
> This = is the first of the "re-use" management protocols.  The =
> requirements
> are set-up so that we can suggest = additions to the NETCONF and
> RESTCONF for
> this first of = I2RS.
>
> The I2RS ephemeral work, pub/sub, traceability, = and security are
> target at
> the I2RS protocol definition = with the I2RS use case.  However, since
> these
> are = general additions to NETCONF/RESTCONF, this work can be used
> = elsewhere.
>
> I think the text you are highlighting has = this larger context.   Now,
> one of
> the really = important things to chat with Alia and Benoit is how do we
> = handle
> the wider use case.   Do we mention the wider = context?
>
> The WG thought mentioning it was = important.
>
> Sue
>
> -----Original = Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> = Sent: Thursday, May 05, 2016 5:31 PM
> To: Susan Hares
> Cc: = Eric Voit; The IESG; i2rs@ietf.org;
> draft-ietf-= i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org
> = Subject: Re: [i2rs] Ben Campbell's Discuss on
> = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = COMMENT)
>
> On 5 May 2016, at 5:15, Susan Hares = wrote:
>
>> Eric, Ben and IESG = members:
>>
>>
>>
>> The pub/sub = requirements are part of a 5 part requirements.   May = I
>> quote
>> from the shepherd's = report:
>>
>> = ---------------------
>>
>> The requirements for the = first version of I2RS are:
>>
>> 1) model driven = ephemeral state - that is data models that do not
>> = survive
>>
>>     a software or = hardware reboot.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/>>
>>
>>
>> 2) a secure protocol = -
>>
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security= -req
>> uireme
>> = nts/
>>
>>
>>
>> 3) traceability - = ability to record interactions between I2RS
>> = elements
>>
>> (Client, Agent, Routing = system)
>>
>> h= ttps://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/
>= >
>>
>>
>> 4) notification publication via = subscription
>>
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requireme= nts/
>>
>>
>>
>> 5) Protocol to = pass Data for Analytics
>>
>> The first version of = these requirements does not include a
>>
>> separate = analytical protocol requirements as the simple use cases = may
>>
>> pass information via query/poll or the = notifications.
>>
>>
>>
>> The I2RS = protocol exists in an secure environment described = by:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environm= ent-
>> = reqs/
>>
>>
>>
>> = -------------------------
>>
>>
>>
>>= Eric - Perhaps it would be good to point to:
>>
>> = .         = draft-ietf-i2rs-protocol-security-requirements = and
>>
>> = .         = draft-ietf-i2rs-security-environment-reqs/
>>
>>
>= ;>
>> Ben - Can you tell me how the shepherd report could = have been
>> clearer?
>>  The
>> I2rs = protocol security requirements require:  = confidentiality,
>> encryption, secure transport, protection = against replay attack,
>> protection against DDoS attack (if = possible).
>
> I think my confusion lies in the fact that, = while the shepherd's
> writeup
> styles this draft as part = of the I2RS protocol requirements, the draft
> itself claims to = describe requirements for a generally useful pub-sub
> interface = to a yang datastore. It's not clear to me how and when the
> = I2RS
> protocol security requirements apply to it. If the = described interface
> is
> intended to be useful in = contexts other than I2RS (and the draft
> explicitly
> sets = that expectation in 2.2), it needs to talk more generally about
> = security and privacy.
>
> For example, it might make sense = to say that certain security
> requirements
> apply in = environments where the mechanism might carry privacy
> = sensitive
> data, and then point to the i2rs requirements for when = the mechanism
> is used
> in an I2RS = context.
>
> A different approach might be to more tightly = constrain this to = i2rs
>
>>
>>
>>
>> Ben - On = opting in, once the receive accepts a transport connection
>> = from the I2RS server - how is this not an opt-in to receive data? =
>> What
>> are you looking for?
>
> I = guess that depends on the transport. The transport requirements say =
> the
> mechanism has to work over multiple transports. The = last paragraph in
> 4.2.4
> says "In the case of = connection-oriented transports..." which suggests
> = that
> non-connection-oriented transports are = possible.
>
> Even with a connection-oriented transport, = this may depend on how
> connection-management is handled, and = whether the receiver might be
> receiving things it _wants_ to = receive on the same = transport.
>
>>
>>
>>
>> Sue = Hares
>>
>> = (shepherd)
>>
>>
>>
>>
>>>> -----Original Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Eric Voit
>> (evoit)
>> Sent: Wednesday, = May 04, 2016 7:25 PM
>> To: Ben Campbell; The IESG
>> = Cc: i2rs@ietf.org; draft-ietf-= i2rs-pub-sub-requirements@ietf.org;
>> i2rs-chairs@ietf.org; shares@ndzh.com
>> Subject: = Re: [i2rs] Ben Campbell's Discuss on
>> = draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = COMMENT)
>>
>>
>>
>> Hi = Ben,
>>
>>
>>
>> Thanks for the = comment.   = In-line....
>>
>>
>>
>>> From: = Ben Campbell, May 04, 2016 2:49 PM
>>
>>> = ---------------------------------------------------------------------->>
>>> DISCUSS:
>>
>>> = ---------------------------------------------------------------------->>
>>>
>>
>>> I have a couple of = points I would like to discuss. Hopefully they
>>> = can
>>
>>> be resolved
>>
>>> = easily:
>>
>>>
>>
>>> Are = there really no requirements for privacy or integrity
>>> = protection?
>>
>>> Is there an expectation that = this mechanism would ever carry privacy
>>
>>> = sensitive or otherwise sensitive = information?
>>
>>
>>
>> [eric's = comment:
>>
>> When the subscription is established = dynamically via an existing
>> transport
>> session = (which is expected to be the dominant case) we have the same
>> = expectations for Privacy and integrity as would be provided via = a
>> "GET"
>> instead of a "PUSH" = over the same transport.   We could have
>> = replicated all
>> these requirements, but that was seen as = unnecessary and likely less
>> secure
>> than adopting = existing mechanisms.
>>
>>
>>
>> = When the Subscriber and Receiver are different, then the = transport
>> connection will have credentials passed as part of = the establishment.
>> These
>> credentials will be = used as a Security Grooming Filter just like the
>> = above
>> case so that pushed objects will be excluded from an = Update
>> Notification as
>> per the permissions of = the Receiver.   (I.e., this is identical
>> behavior = to
>> the above.)    As several people have had = questions about this, the
>> new v07
>> will make this = explicit in the Security section.
>>
>> End of eric's = comment]
>>
>>
>>
>> Sue: The = transport provides for privacy, integrity protection.   = Most
>> configuration in network boxes would need = privacy.
>>
>>
>>
>>> - 4.2.5, = 2nd to last paragraph:
>>
>>> I am surprised to = find that, when the receiver is not the
>>> = subscriber,
>>
>>> that the receiver is expected to = opt-out. It seems like some form of
>>
>>> opt-in = or affirmative consent would be needed = here.
>>
>>
>>
>> The question = really was how heavy-weight should the mechanism be.
>> = Transports been considering are all encrypted.  So there is already = a
>> level
>> of trust between the peers.  And a = target can always pull down the
>> connection if there are = issues.
>>
>>
>>
>> In addition, = multicast transports are viable for some future cases.
>> = We
>> didn't want mechanisms which complicated this type of = interaction,
>> especially in a world where dumb IoT devices = may be involved.
>>
>>
>>
>> Sue: If = the receiver accepts a secure transport set-up from the
>> = server, can
>> you provide the reason why this is not an = "opt-in" once it receives
>> the
>> = connection from the I2RS = agent?
>>
>>
>>
>>
>>
>= ;>> = ---------------------------------------------------------------------->>
>>> COMMENT:
>>
>>> = ---------------------------------------------------------------------->>
>>>
>>
>>> - General: I = support Stephen's = DISCUSS
>>
>>>
>>
>>> -2.2: = What is the real scope of this work? Is it expected to
>>> = supplant
>>
>>> the mentioned = mechanisms?
>>
>>
>>
>> = No.   It is just showing that many specialized Push mechanism = exist.
>> This
>> is not intended to supplant existing = mechanisms, although perhaps it
>> can
>> help avoid = future dedicated solutions.
>>
>>> - 2.3: "We = need a new pub-sub
>>
>>>    = technology"
>>
>>> The shepherd write up = mentioned a goal to use existing = technologies.
>>
>>> Is the point of this sentence = to suggest that is not = feasible?
>>
>>
>>
>> Existing = technologies cannot meet all the requirements specified.
>> = There are
>> technology drafts progressing in NETCONF which = can.
>>
>>
>>
>>> - 4.1, 4th = paragraph:
>>
>>> The MAY doesn't seem right--is = this a statement of fact that the
>>
>>> subscriber = may have to resubscribe, or a requirement of the form
>>> = that
>>
>>> the service MAY force the subscriber to = resubscribe? (Be careful
>>> = with
>>
>>> MAYs in requirements language--they = imply unexpected things. For
>>
>>> example, = several requirements say a SUBSCRIBE MAY do = something--do
>>
>>> those imply that the service = MUST allow the subscriber to do it = ?)
>>
>>
>>
>> Good = point.   Reworded in = v07.
>>
>>
>>
>>> -- 4.2.2, third = bullet: The previous section said dampening = periods
>>
>>> MUST be = supported.
>>
>>
>>
>> Yes, but = dampening is never for periodic = subscriptions.
>>
>>> - 4.2.1, third paragraph: = This is a bit ambiguous. I think it means
>>> = to
>>
>>> change the what subtrees the subscription = applies to, but could be
>>
>>> interpreted to = change the subtrees = themselves.
>>
>>
>>
>> = Fixed
>>
>>> - 4.2.6.4: Would a mechanism that = allowed out-of-order delivery but
>>
>>> gave the = subscriber a way to reconstruct the order fulfill this
>> = requirement?
>>
>>
>>
>> Yes, the = timestamp within an update.  But this requirement targets = a
>> specific object in a specific subscription.  So there = should be no
>> issues.
>>
>>> = Nits:
>>
>>> - The shepherd write up suggests this = is standards track. The draft
>>
>>> and tracker = both say informational. Please update the shepherd writ
>>> = up.
>>
>>
>>
>> = Fixed
>>
>>> -3, last paragraph: What's the = difference between a "Push" and an
>> = "Update"?
>>
>>
>>
>> = Reworded
>>
>>> -4.1: A forward reference to the = subscription QoS section would be
>> = helpful.
>>
>>
>>
>> Moved the = requirement in question to 4.2.6.
>>
>>> -- Last = paragraph, last sentence: Sentence doesn't = parse.
>>
>>
>>
>> = Fixed
>>
>>>
>>
>>> - 4.2.8, = third paragraph: I don't think that should be a 2119 = MAY
>>
>>
>>
>> = Fixed
>>
>> Thanks again for the = review!
>>
>> Eric
>>
>> = _______________________________________________
>>
>> = i2rs mailing list
>>
>>  <mailto:i2rs@ietf.org> i2rs@ietf.org
>>
>>&n= bsp; <https://www.ietf.org/= mailman/listinfo/i2rs>
>> https://www.ietf.org/= mailman/listinfo/i2rs

------=_NextPart_000_000D_01D1ADE0.3074B710-- From nobody Sun May 15 06:39:27 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E578112D17A; Sun, 15 May 2016 06:39:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160515133925.14660.72669.idtracker@ietfa.amsl.com> Date: Sun, 15 May 2016 06:39:25 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-traceability-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 13:39:26 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-traceability-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my discuss point. The comments below are old and I didn't check if you'd done anything about them in -10 but that's fine either way unless you want to chat more about 'em. --------- OLD COMMENTS - 5.2: Requested/Applied Operation Data - I would guess this can include sensitive values, e.g. keys/passwords. Shouldn’t you say to at least be careful of those, or perhaps to not log them, or to zero out known sensitive values before logging? - 7.2: how is privacy an implementation detail? - 7.4: What does "being preferred" mean in 2119 terms? Why is one of the three options not mandatory-to-implement? From nobody Sun May 15 07:13:47 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E0112D1A1; Sun, 15 May 2016 07:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmFmiP4K1lLK; Sun, 15 May 2016 07:13:44 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAC712D18F; Sun, 15 May 2016 07:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=975; q=dns/txt; s=iport; t=1463321624; x=1464531224; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5Ji7gWEi8RXFzUHylrKGkKCm6IlgsIWnVuhbHME9Lbs=; b=LsR8t63XATDCUT/zWnKv7gyiDlpRO6rQlmJCwRL04/Z0z2M24qBLJWJi 68ZMkM0ehp6m4UV9JdDyUkP63/aFVpU1wgh9PHhTNJ9YNYmweaEeQybZB ERdEXxdWCdgW65zG9zxMCCcZZT9RXJ5/ZCVJANTA12yF0WgWua7tlQs26 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtBQDZgzhX/5tdJa1dgzeBALgogh2Bd?= =?us-ascii?q?oYRAoEWORMBAQEBAQEBZSeEQwEBBCMPAQVBEAsYAgImAgJXBgEMCAEBiCurSZB?= =?us-ascii?q?MAQEBAQEBAQEBAQEBAQEBAQEBH4EBhSSBdoJXhz+CWQEEh36QKY4eiT+FWo9BI?= =?us-ascii?q?gE/gjeBUSCIOAEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,623,1454976000"; d="scan'208";a="273870627" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2016 14:13:40 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4FEDe2D008652; Sun, 15 May 2016 14:13:40 GMT To: Stephen Farrell , The IESG References: <20160515133925.14660.72669.idtracker@ietfa.amsl.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <72fa2731-b940-b4d2-bc92-f20efbb67318@cisco.com> Date: Sun, 15 May 2016 10:13:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160515133925.14660.72669.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-traceability-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 14:13:46 -0000 On 5/15/16 09:39, Stephen Farrell wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Thanks for handling my discuss point. The comments below > are old and I didn't check if you'd done anything about them > in -10 but that's fine either way unless you want to chat more > about 'em. > > --------- OLD COMMENTS > > - 5.2: Requested/Applied Operation Data - I would guess > this can include sensitive values, e.g. keys/passwords. > Shouldn’t you say to at least be careful of those, or > perhaps to not log them, or to zero out known sensitive > values before logging? > > - 7.2: how is privacy an implementation detail? > > - 7.4: What does "being preferred" mean in 2119 terms? Why > is one of the three options not mandatory-to-implement? > > All of these should now be addressed in -10. Thanks again for the review. Joe From nobody Sun May 15 14:17:47 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1AF12D538 for ; Sun, 15 May 2016 14:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSUqwA5Y1ORi for ; Sun, 15 May 2016 14:17:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8FE1A12D537 for ; Sun, 15 May 2016 14:17:43 -0700 (PDT) Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4FLHdlf095111 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 15 May 2016 16:17:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Susan Hares" , "Eric Voit" Date: Sun, 15 May 2016 14:17:57 -0500 Message-ID: In-Reply-To: <00a901d1ad2e$f8a21e10$e9e65a30$@ndzh.com> References: <9e9692bd22a041ba91e39a9f7dce8c9e@XCH-RTP-013.cisco.com> <00a901d1ad2e$f8a21e10$e9e65a30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: i2rs@ietf.org, Eric Voit , i2rs-chairs@ietf.org, Alia Atlas , draft-ietf-i2rs-pub-sub-requirements@ietf.org, The IESG Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 21:17:46 -0000 Hi Eric and Sue, Thanks for the change, and I think it's on the right track. But I notice most of the other requirements, in the security considerations section and in other sections, use 2119 keywords. Is there a reason not to do so here? Would it be reasonable to say that any embodiment of these requirements MUST support a transport that provides encryption and integrity protection, and such a transport MUST be used when carrying privacy-sensitive information? Thanks! Ben. On 13 May 2016, at 10:49, Susan Hares wrote: > Eric: > > > > Thanks for jumping in and putting out text that resolves Ben’s > comments. This text works for me with one addition. Add reference to > the security environment draft. > > > > Sue > > > > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > Sent: Friday, May 13, 2016 11:26 AM > To: Susan Hares; Ben Campbell; Alia Atlas (akatlas@gmail.com) > Cc: The IESG; i2rs@ietf.org; > draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org > Subject: RE: [i2rs] Ben Campbell's Discuss on > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > > > Hi Ben, > > > > I have added the text below as the lead-in to section 4.2.5. I > believe this meets the intents of your suggestions below. > > > > Hi Susan & Alia, > > > > I have uploaded v08 of > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ > > If Ben concurs with the text below, I am not aware of any remaining > discuss items. > > > > Thanks everyone for your reviews, > > Eric, Alex, & Alberto > > > 4.2.5. Security Requirements > > Some uses of this Subscription Service will push privacy-sensitive > updates and metadata. Good deployment practices will bind this > generated information within secure, encrypted transport layer > mechanisms. For example if NETCONF is used as transport, then > [RFC5539] would be a valid option to secure the transported > information. The Subscription Service can also be used with > emerging > deployment contexts as well. As an example, deployments based on > [i2rs-usecase] can apply these requirements in conjunction with > those > documented within [i2rs-protocol-security] to secure ephemeral > state > information being pushed from a Network Element. > > > > > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Friday, May 06, 2016 7:09 PM > To: Ben Campbell > Cc: Eric Voit (evoit); The IESG; i2rs@ietf.org; > draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ben Campbell's Discuss on > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > > > Ben: > > > > This is wise idea. I will suggest some text to Eric and you in the > morning. > > > > Sue > > > > > > > > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > > -------- Original message -------- > > From: Ben Campbell > > Date: 5/6/2016 2:38 PM (GMT-06:00) > > To: Susan Hares > > Cc: Eric Voit , The IESG , > i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, > i2rs-chairs@ietf.org > > Subject: Re: [i2rs] Ben Campbell's Discuss on > draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > > > > Hi Susan, > > To be clear, I do not object to the wider context per se. My concern > is > that the security and privacy requirements are left as implicit, based > on the more narrow i2rs/netconf context. I only mentioned the > potential > of restricting the contextas one possible way forward; I am certainly > not wedded to it. > > My suggestion for a way forward would be to document the high level > security and privacy requirements in this document. IIUC, the larger > context includes potentially unknown contexts, so some of this may > need > to be conditional. For example, language like the following might be > helpful (this is just an example--I don't mean to say that it is true > or > applicable): > > "Some uses of this mechanism may carry privacy-sensitive > information, > or generate privacy-sensitive metadata through the subscription > mechanism. In contexts where this is true, the following requirements > apply..." > > It might also be reasonable to say that, for the context of i2rs, > these > requirements are documented in [references] and are expected to be > fulfilled by the [transport and or protocol] > > Eric's email also suggested that the actual transport of data from the > Yang datastore may be out of scope for these requirements. I don't > object to that, either, as long as it is clear and explicit, although > it > would be good to point to where it is _in_ scope. > > Thanks! > > Ben. > > On 6 May 2016, at 1:06, Susan Hares wrote: > >> Ben: >> >> This is the first of the "re-use" management protocols. The >> requirements >> are set-up so that we can suggest additions to the NETCONF and >> RESTCONF for >> this first of I2RS. >> >> The I2RS ephemeral work, pub/sub, traceability, and security are >> target at >> the I2RS protocol definition with the I2RS use case. However, since >> these >> are general additions to NETCONF/RESTCONF, this work can be used >> elsewhere. >> >> I think the text you are highlighting has this larger context. Now, >> one of >> the really important things to chat with Alia and Benoit is how do we >> handle >> the wider use case. Do we mention the wider context? >> >> The WG thought mentioning it was important. >> >> Sue >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Thursday, May 05, 2016 5:31 PM >> To: Susan Hares >> Cc: Eric Voit; The IESG; i2rs@ietf.org; >> draft-ietf-i2rs-pub-sub-requirements@ietf.org; i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Ben Campbell's Discuss on >> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) >> >> On 5 May 2016, at 5:15, Susan Hares wrote: >> >>> Eric, Ben and IESG members: >>> >>> >>> >>> The pub/sub requirements are part of a 5 part requirements. May I >>> quote >>> from the shepherd's report: >>> >>> --------------------- >>> >>> The requirements for the first version of I2RS are: >>> >>> 1) model driven ephemeral state - that is data models that do not >>> survive >>> >>> a software or hardware reboot. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >>> >>> >>> >>> 2) a secure protocol - >>> >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req >>> uireme >>> nts/ >>> >>> >>> >>> 3) traceability - ability to record interactions between I2RS >>> elements >>> >>> (Client, Agent, Routing system) >>> >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ >>> >>> >>> >>> 4) notification publication via subscription >>> >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ >>> >>> >>> >>> 5) Protocol to pass Data for Analytics >>> >>> The first version of these requirements does not include a >>> >>> separate analytical protocol requirements as the simple use cases >>> may >>> >>> pass information via query/poll or the notifications. >>> >>> >>> >>> The I2RS protocol exists in an secure environment described by: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment- >>> reqs/ >>> >>> >>> >>> ------------------------- >>> >>> >>> >>> Eric - Perhaps it would be good to point to: >>> >>> . draft-ietf-i2rs-protocol-security-requirements and >>> >>> . draft-ietf-i2rs-security-environment-reqs/ >>> >>> >>> >>> Ben - Can you tell me how the shepherd report could have been >>> clearer? >>> The >>> I2rs protocol security requirements require: confidentiality, >>> encryption, secure transport, protection against replay attack, >>> protection against DDoS attack (if possible). >> >> I think my confusion lies in the fact that, while the shepherd's >> writeup >> styles this draft as part of the I2RS protocol requirements, the >> draft >> itself claims to describe requirements for a generally useful pub-sub >> interface to a yang datastore. It's not clear to me how and when the >> I2RS >> protocol security requirements apply to it. If the described >> interface >> is >> intended to be useful in contexts other than I2RS (and the draft >> explicitly >> sets that expectation in 2.2), it needs to talk more generally about >> security and privacy. >> >> For example, it might make sense to say that certain security >> requirements >> apply in environments where the mechanism might carry privacy >> sensitive >> data, and then point to the i2rs requirements for when the mechanism >> is used >> in an I2RS context. >> >> A different approach might be to more tightly constrain this to i2rs >> >>> >>> >>> >>> Ben - On opting in, once the receive accepts a transport connection >>> from the I2RS server - how is this not an opt-in to receive data? >>> What >>> are you looking for? >> >> I guess that depends on the transport. The transport requirements say >> the >> mechanism has to work over multiple transports. The last paragraph in >> 4.2.4 >> says "In the case of connection-oriented transports..." which >> suggests >> that >> non-connection-oriented transports are possible. >> >> Even with a connection-oriented transport, this may depend on how >> connection-management is handled, and whether the receiver might be >> receiving things it _wants_ to receive on the same transport. >> >>> >>> >>> >>> Sue Hares >>> >>> (shepherd) >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit >>> (evoit) >>> Sent: Wednesday, May 04, 2016 7:25 PM >>> To: Ben Campbell; The IESG >>> Cc: i2rs@ietf.org; draft-ietf-i2rs-pub-sub-requirements@ietf.org; >>> i2rs-chairs@ietf.org; shares@ndzh.com >>> Subject: Re: [i2rs] Ben Campbell's Discuss on >>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) >>> >>> >>> >>> Hi Ben, >>> >>> >>> >>> Thanks for the comment. In-line.... >>> >>> >>> >>>> From: Ben Campbell, May 04, 2016 2:49 PM >>> >>>> ---------------------------------------------------------------------- >>> >>>> DISCUSS: >>> >>>> ---------------------------------------------------------------------- >>> >>>> >>> >>>> I have a couple of points I would like to discuss. Hopefully they >>>> can >>> >>>> be resolved >>> >>>> easily: >>> >>>> >>> >>>> Are there really no requirements for privacy or integrity >>>> protection? >>> >>>> Is there an expectation that this mechanism would ever carry >>>> privacy >>> >>>> sensitive or otherwise sensitive information? >>> >>> >>> >>> [eric's comment: >>> >>> When the subscription is established dynamically via an existing >>> transport >>> session (which is expected to be the dominant case) we have the same >>> expectations for Privacy and integrity as would be provided via a >>> "GET" >>> instead of a "PUSH" over the same transport. We could have >>> replicated all >>> these requirements, but that was seen as unnecessary and likely less >>> secure >>> than adopting existing mechanisms. >>> >>> >>> >>> When the Subscriber and Receiver are different, then the transport >>> connection will have credentials passed as part of the >>> establishment. >>> These >>> credentials will be used as a Security Grooming Filter just like the >>> above >>> case so that pushed objects will be excluded from an Update >>> Notification as >>> per the permissions of the Receiver. (I.e., this is identical >>> behavior to >>> the above.) As several people have had questions about this, the >>> new v07 >>> will make this explicit in the Security section. >>> >>> End of eric's comment] >>> >>> >>> >>> Sue: The transport provides for privacy, integrity protection. >>> Most >>> configuration in network boxes would need privacy. >>> >>> >>> >>>> - 4.2.5, 2nd to last paragraph: >>> >>>> I am surprised to find that, when the receiver is not the >>>> subscriber, >>> >>>> that the receiver is expected to opt-out. It seems like some form >>>> of >>> >>>> opt-in or affirmative consent would be needed here. >>> >>> >>> >>> The question really was how heavy-weight should the mechanism be. >>> Transports been considering are all encrypted. So there is already >>> a >>> level >>> of trust between the peers. And a target can always pull down the >>> connection if there are issues. >>> >>> >>> >>> In addition, multicast transports are viable for some future cases. >>> We >>> didn't want mechanisms which complicated this type of interaction, >>> especially in a world where dumb IoT devices may be involved. >>> >>> >>> >>> Sue: If the receiver accepts a secure transport set-up from the >>> server, can >>> you provide the reason why this is not an "opt-in" once it receives >>> the >>> connection from the I2RS agent? >>> >>> >>> >>> >>> >>>> ---------------------------------------------------------------------- >>> >>>> COMMENT: >>> >>>> ---------------------------------------------------------------------- >>> >>>> >>> >>>> - General: I support Stephen's DISCUSS >>> >>>> >>> >>>> -2.2: What is the real scope of this work? Is it expected to >>>> supplant >>> >>>> the mentioned mechanisms? >>> >>> >>> >>> No. It is just showing that many specialized Push mechanism exist. >>> This >>> is not intended to supplant existing mechanisms, although perhaps it >>> can >>> help avoid future dedicated solutions. >>> >>>> - 2.3: "We need a new pub-sub >>> >>>> technology" >>> >>>> The shepherd write up mentioned a goal to use existing >>>> technologies. >>> >>>> Is the point of this sentence to suggest that is not feasible? >>> >>> >>> >>> Existing technologies cannot meet all the requirements specified. >>> There are >>> technology drafts progressing in NETCONF which can. >>> >>> >>> >>>> - 4.1, 4th paragraph: >>> >>>> The MAY doesn't seem right--is this a statement of fact that the >>> >>>> subscriber may have to resubscribe, or a requirement of the form >>>> that >>> >>>> the service MAY force the subscriber to resubscribe? (Be careful >>>> with >>> >>>> MAYs in requirements language--they imply unexpected things. For >>> >>>> example, several requirements say a SUBSCRIBE MAY do something--do >>> >>>> those imply that the service MUST allow the subscriber to do it ?) >>> >>> >>> >>> Good point. Reworded in v07. >>> >>> >>> >>>> -- 4.2.2, third bullet: The previous section said dampening periods >>> >>>> MUST be supported. >>> >>> >>> >>> Yes, but dampening is never for periodic subscriptions. >>> >>>> - 4.2.1, third paragraph: This is a bit ambiguous. I think it means >>>> to >>> >>>> change the what subtrees the subscription applies to, but could be >>> >>>> interpreted to change the subtrees themselves. >>> >>> >>> >>> Fixed >>> >>>> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but >>> >>>> gave the subscriber a way to reconstruct the order fulfill this >>> requirement? >>> >>> >>> >>> Yes, the timestamp within an update. But this requirement targets a >>> specific object in a specific subscription. So there should be no >>> issues. >>> >>>> Nits: >>> >>>> - The shepherd write up suggests this is standards track. The draft >>> >>>> and tracker both say informational. Please update the shepherd writ >>>> up. >>> >>> >>> >>> Fixed >>> >>>> -3, last paragraph: What's the difference between a "Push" and an >>> "Update"? >>> >>> >>> >>> Reworded >>> >>>> -4.1: A forward reference to the subscription QoS section would be >>> helpful. >>> >>> >>> >>> Moved the requirement in question to 4.2.6. >>> >>>> -- Last paragraph, last sentence: Sentence doesn't parse. >>> >>> >>> >>> Fixed >>> >>>> >>> >>>> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY >>> >>> >>> >>> Fixed >>> >>> Thanks again for the review! >>> >>> Eric >>> >>> _______________________________________________ >>> >>> i2rs mailing list >>> >>> i2rs@ietf.org >>> >>> >>> https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon May 16 06:46:45 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DB212D68D; Mon, 16 May 2016 06:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.936 X-Spam-Level: X-Spam-Status: No, score=-15.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX5qbzBSqcp1; Mon, 16 May 2016 06:46:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF0612D185; Mon, 16 May 2016 06:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=96678; q=dns/txt; s=iport; t=1463406399; x=1464615999; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2D6bq4aG2Q+Ld0ro5FGjT+xLgc29qlbPCpI+g+pBH9E=; b=AYacQ6BuZ6bqr38pnuYjuF+0vCrwufrL3KUkTK+8kU0egH8MR4IYXk9z /ys/G6cbNtQ6VleIcztqn77RuAI3lE1JXWNJoHb9GzzbIWlSo1/CZRgds AfDGsO2ek7vcMUP9wMMU5oL4jvl43RkrJs6BjkuxYTYbwWtdsr1rKYXOP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7BQBvzjlX/4YNJK0VBUOCbEtVfgatf?= =?us-ascii?q?otlAQ2BcgQXAQqCPYMyAhyBBjgUAQEBAQEBAWUnhEIBAQEDAQEBARcBCApBCwU?= =?us-ascii?q?HBAIBCBEDAQEBDQETAQIEAwICAh8GCxQJCAIEAQ0FCBOHegMPCA6IWKVhjDENh?= =?us-ascii?q?CcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYlhE2CQ4FOEQEGLQmCYIJZBYY7CYE?= =?us-ascii?q?6j3gxAYV9gniCbUKBcoFwF4Q4iGGGLYEvh2QBHgEBQoIGGxaBNW6GSAUEFx9/A?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.24,627,1454976000"; d="scan'208,217";a="102675434" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2016 13:46:37 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4GDkbZU004379 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 May 2016 13:46:37 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 May 2016 09:46:37 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Mon, 16 May 2016 09:46:36 -0400 From: "Eric Voit (evoit)" To: Ben Campbell , Susan Hares Thread-Topic: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRp+xNYDspbfuo4UOD+L2iwgAMip+3BC7ggABM94CAA18KgIAA7L9g Date: Mon, 16 May 2016 13:46:36 +0000 Message-ID: <167d2323d3264287a30c36c1950984b5@XCH-RTP-013.cisco.com> References: <9e9692bd22a041ba91e39a9f7dce8c9e@XCH-RTP-013.cisco.com> <00a901d1ad2e$f8a21e10$e9e65a30$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_167d2323d3264287a30c36c1950984b5XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , The IESG , "i2rs-chairs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 13:46:43 -0000 --_000_167d2323d3264287a30c36c1950984b5XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkhpIEJlbiwNCg0KDQoNClRoZXJlIGlzIG5vIGlzc3VlIHdpdGggcmV3b3JkaW5nIHRvIGEg cmVxdWlyZW1lbnQgcmF0aGVyIHRoYW4gYW4gaW50cm8uICBUaGUgc2Vjb25kIHNlbnRlbmNlIGJl bG93IGhhcyBiZWVuIGNoYW5nZWQgdG8gbWVldCAyMTE5Lg0KDQoNCg0KU29tZSB1c2VzIG9mIHRo aXMgU3Vic2NyaXB0aW9uIFNlcnZpY2Ugd2lsbCBwdXNoIHByaXZhY3ktc2Vuc2l0aXZlIHVwZGF0 ZXMgYW5kIG1ldGFkYXRhLiAgRm9yIHByaXZhY3ktc2Vuc2l0aXZlIGRlcGxveW1lbnRzLCBzdWJz Y3JpcHRpb24gaW5mb3JtYXRpb24gTVVTVCBiZSBib3VuZCB3aXRoaW4gc2VjdXJlLCBlbmNyeXB0 ZWQgdHJhbnNwb3J0IGxheWVyIG1lY2hhbmlzbXMuICBGb3IgZXhhbXBsZSBpZiBORVRDT05GIGlz IHVzZWQgYXMgdHJhbnNwb3J0LCB0aGVuIFtSRkM1NTM5XSB3b3VsZCBiZSBhIHZhbGlkIG9wdGlv biB0byBzZWN1cmUgdGhlIHRyYW5zcG9ydGVkIGluZm9ybWF0aW9uLiAgVGhlIFN1YnNjcmlwdGlv biBTZXJ2aWNlIGNhbiBhbHNvIGJlIHVzZWQgd2l0aCBlbWVyZ2luZyBwcml2YWN5LXNlbnNpdGl2 ZSBkZXBsb3ltZW50IGNvbnRleHRzIGFzIHdlbGwuICBBcyBhbiBleGFtcGxlLCBkZXBsb3ltZW50 cyBiYXNlZCBvbiBbaTJycy11c2VjYXNlXSB3b3VsZCBhcHBseSB0aGVzZSByZXF1aXJlbWVudHMg aW4gY29uanVuY3Rpb24gd2l0aCB0aG9zZSBkb2N1bWVudGVkIHdpdGhpbiBbaTJycy1lbnZpcm9u bWVudC1zZWN1cml0eV0gYW5kIFtpMnJzLXByb3RvY29sLXNlY3VyaXR5XSB0byBzZWN1cmUgZXBo ZW1lcmFsIHN0YXRlIGluZm9ybWF0aW9uIGJlaW5nIHB1c2hlZCBmcm9tIGEgTmV0d29yayBFbGVt ZW50Lg0KDQoNCg0KRXJpYw0KDQoNCg0KPiBGcm9tOiBCZW4gQ2FtcGJlbGwsIE1heSAxNSwgMjAx NiAzOjE4IFBNDQoNCj4NCg0KPiBIaSBFcmljIGFuZCBTdWUsDQoNCj4NCg0KPiBUaGFua3MgZm9y IHRoZSBjaGFuZ2UsIGFuZCBJIHRoaW5rIGl0J3Mgb24gdGhlIHJpZ2h0IHRyYWNrLiBCdXQgSSBu b3RpY2UgbW9zdCBvZiB0aGUNCg0KPiBvdGhlciByZXF1aXJlbWVudHMsIGluIHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFuZCBpbiBvdGhlciBzZWN0aW9ucywNCg0KPiB1c2Ug MjExOSBrZXl3b3Jkcy4gSXMgdGhlcmUgYSByZWFzb24gbm90IHRvIGRvIHNvIGhlcmU/IFdvdWxk IGl0IGJlIHJlYXNvbmFibGUNCg0KPiB0byBzYXkgdGhhdCBhbnkgZW1ib2RpbWVudCBvZiB0aGVz ZSByZXF1aXJlbWVudHMgTVVTVCBzdXBwb3J0IGEgdHJhbnNwb3J0DQoNCj4gdGhhdCBwcm92aWRl cyBlbmNyeXB0aW9uIGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwgYW5kIHN1Y2ggYSB0cmFuc3Bv cnQgTVVTVCBiZQ0KDQo+IHVzZWQgd2hlbiBjYXJyeWluZyBwcml2YWN5LXNlbnNpdGl2ZSBpbmZv cm1hdGlvbj8NCg0KPg0KDQo+IFRoYW5rcyENCg0KPg0KDQo+IEJlbi4NCg0KPg0KDQo+DQoNCj4g T24gMTMgTWF5IDIwMTYsIGF0IDEwOjQ5LCBTdXNhbiBIYXJlcyB3cm90ZToNCg0KPg0KDQo+ID4g RXJpYzoNCg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+IFRoYW5rcyBmb3IganVtcGluZyBpbiBh bmQgcHV0dGluZyBvdXQgdGV4dCB0aGF0IHJlc29sdmVzIEJlbuKAmXMNCg0KPiA+IGNvbW1lbnRz LiAgVGhpcyB0ZXh0IHdvcmtzIGZvciBtZSB3aXRoIG9uZSBhZGRpdGlvbi4gIEFkZCByZWZlcmVu Y2UgdG8NCg0KPiA+IHRoZSBzZWN1cml0eSBlbnZpcm9ubWVudCBkcmFmdC4NCg0KPiA+DQoNCj4g Pg0KDQo+ID4NCg0KPiA+IFN1ZQ0KDQo+ID4NCg0KPiA+DQoNCj4gPg0KDQo+ID4gRnJvbTogRXJp YyBWb2l0IChldm9pdCkgW21haWx0bzpldm9pdEBjaXNjby5jb21dDQoNCj4gPiBTZW50OiBGcmlk YXksIE1heSAxMywgMjAxNiAxMToyNiBBTQ0KDQo+ID4gVG86IFN1c2FuIEhhcmVzOyBCZW4gQ2Ft cGJlbGw7IEFsaWEgQXRsYXMgKGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWls LmNvbT4pDQoNCj4gPiBDYzogVGhlIElFU0c7IGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0 Zi5vcmc+Ow0KDQo+ID4gZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc+ OyBpMnJzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aTJycy1jaGFpcnNAaWV0Zi5vcmc+DQoNCj4g PiBTdWJqZWN0OiBSRTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24NCg0KPiA+IGRy YWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0wNjogKHdpdGggRElTQ1VTUyBhbmQg Q09NTUVOVCkNCg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+IEhpIEJlbiwNCg0KPiA+DQoNCj4g Pg0KDQo+ID4NCg0KPiA+IEkgaGF2ZSBhZGRlZCB0aGUgdGV4dCBiZWxvdyBhcyB0aGUgbGVhZC1p biB0byBzZWN0aW9uIDQuMi41LiAgSQ0KDQo+ID4gYmVsaWV2ZSB0aGlzIG1lZXRzIHRoZSBpbnRl bnRzIG9mIHlvdXIgc3VnZ2VzdGlvbnMgYmVsb3cuDQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4g PiBIaSBTdXNhbiAmIEFsaWEsDQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4gPiBJIGhhdmUgdXBs b2FkZWQgdjA4IG9mDQoNCj4gPg0KDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLw0KDQo+ID4NCg0KPiA+IElm IEJlbiBjb25jdXJzIHdpdGggdGhlIHRleHQgYmVsb3csIEkgYW0gbm90IGF3YXJlIG9mIGFueSBy ZW1haW5pbmcNCg0KPiA+IGRpc2N1c3MgaXRlbXMuDQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4g PiBUaGFua3MgZXZlcnlvbmUgZm9yIHlvdXIgcmV2aWV3cywNCg0KPiA+DQoNCj4gPiBFcmljLCBB bGV4LCAmIEFsYmVydG8NCg0KPiA+DQoNCj4gPg0KDQo+ID4gNC4yLjUuICBTZWN1cml0eSBSZXF1 aXJlbWVudHMNCg0KPiA+DQoNCj4gPiAgICBTb21lIHVzZXMgb2YgdGhpcyBTdWJzY3JpcHRpb24g U2VydmljZSB3aWxsIHB1c2ggcHJpdmFjeS1zZW5zaXRpdmUNCg0KPiA+ICAgIHVwZGF0ZXMgYW5k IG1ldGFkYXRhLiAgR29vZCBkZXBsb3ltZW50IHByYWN0aWNlcyB3aWxsIGJpbmQgdGhpcw0KDQo+ ID4gICAgZ2VuZXJhdGVkIGluZm9ybWF0aW9uIHdpdGhpbiBzZWN1cmUsIGVuY3J5cHRlZCB0cmFu c3BvcnQgbGF5ZXINCg0KPiA+ICAgIG1lY2hhbmlzbXMuICBGb3IgZXhhbXBsZSBpZiBORVRDT05G IGlzIHVzZWQgYXMgdHJhbnNwb3J0LCB0aGVuDQoNCj4gPiAgICBbUkZDNTUzOV0gd291bGQgYmUg YSB2YWxpZCBvcHRpb24gdG8gc2VjdXJlIHRoZSB0cmFuc3BvcnRlZA0KDQo+ID4gICAgaW5mb3Jt YXRpb24uICBUaGUgU3Vic2NyaXB0aW9uIFNlcnZpY2UgY2FuIGFsc28gYmUgdXNlZCB3aXRoDQoN Cj4gPiBlbWVyZ2luZw0KDQo+ID4gICAgZGVwbG95bWVudCBjb250ZXh0cyBhcyB3ZWxsLiAgQXMg YW4gZXhhbXBsZSwgZGVwbG95bWVudHMgYmFzZWQgb24NCg0KPiA+ICAgIFtpMnJzLXVzZWNhc2Vd IGNhbiBhcHBseSB0aGVzZSByZXF1aXJlbWVudHMgaW4gY29uanVuY3Rpb24gd2l0aA0KDQo+ID4g dGhvc2UNCg0KPiA+ICAgIGRvY3VtZW50ZWQgd2l0aGluIFtpMnJzLXByb3RvY29sLXNlY3VyaXR5 XSB0byBzZWN1cmUgZXBoZW1lcmFsDQoNCj4gPiBzdGF0ZQ0KDQo+ID4gICAgaW5mb3JtYXRpb24g YmVpbmcgcHVzaGVkIGZyb20gYSBOZXR3b3JrIEVsZW1lbnQuDQoNCj4gPg0KDQo+ID4NCg0KPiA+ DQoNCj4gPg0KDQo+ID4gRnJvbTogU3VzYW4gSGFyZXMgW21haWx0bzpzaGFyZXNAbmR6aC5jb21d DQoNCj4gPiBTZW50OiBGcmlkYXksIE1heSAwNiwgMjAxNiA3OjA5IFBNDQoNCj4gPiBUbzogQmVu IENhbXBiZWxsDQoNCj4gPiBDYzogRXJpYyBWb2l0IChldm9pdCk7IFRoZSBJRVNHOyBpMnJzQGll dGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsNCg0KPiA+IGRyYWZ0LWlldGYtaTJycy1wdWIt c3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWIt cmVxdWlyZW1lbnRzQGlldGYub3JnPjsgaTJycy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmkycnMt Y2hhaXJzQGlldGYub3JnPg0KDQo+ID4gU3ViamVjdDogUmU6IFtpMnJzXSBCZW4gQ2FtcGJlbGwn cyBEaXNjdXNzIG9uDQoNCj4gPiBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMt MDY6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4g PiBCZW46DQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4gPiBUaGlzIGlzIHdpc2UgaWRlYS4gIEkg d2lsbCBzdWdnZXN0IHNvbWUgdGV4dCB0byBFcmljIGFuZCB5b3UgaW4gdGhlDQoNCj4gPiBtb3Ju aW5nLg0KDQo+ID4NCg0KPiA+DQoNCj4gPg0KDQo+ID4gU3VlDQoNCj4gPg0KDQo+ID4NCg0KPiA+ DQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4gPg0KDQo+ID4gU2VudCB2aWEgdGhlIFNhbXN1bmcg R2FsYXh5IE5vdGU1LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lDQoNCj4gPg0KDQo+ID4gLS0t LS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KDQo+ID4NCg0KPiA+IEZyb206IEJlbiBD YW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+Pg0KDQo+ID4N Cg0KPiA+IERhdGU6IDUvNi8yMDE2IDI6MzggUE0gKEdNVC0wNjowMCkNCg0KPiA+DQoNCj4gPiBU bzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4N Cg0KPiA+DQoNCj4gPiBDYzogRXJpYyBWb2l0IDxldm9pdEBjaXNjby5jb208bWFpbHRvOmV2b2l0 QGNpc2NvLmNvbT4+LCBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9y Zz4+LA0KDQo+ID4gaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4sIGRyYWZ0LWll dGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1p MnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnPiwNCg0KPiA+IGkycnMtY2hhaXJzQGll dGYub3JnPG1haWx0bzppMnJzLWNoYWlyc0BpZXRmLm9yZz4NCg0KPiA+DQoNCj4gPiBTdWJqZWN0 OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24NCg0KPiA+IGRyYWZ0LWlldGYt aTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0wNjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkN Cg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+IEhpIFN1c2FuLA0KDQo+ID4NCg0KPiA+IFRvIGJl IGNsZWFyLCBJIGRvIG5vdCBvYmplY3QgdG8gdGhlIHdpZGVyIGNvbnRleHQgcGVyIHNlLiBNeSBj b25jZXJuDQoNCj4gPiBpcw0KDQo+ID4gdGhhdCB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgcmVx dWlyZW1lbnRzIGFyZSBsZWZ0IGFzIGltcGxpY2l0LCBiYXNlZA0KDQo+ID4gb24gdGhlIG1vcmUg bmFycm93IGkycnMvbmV0Y29uZiBjb250ZXh0LiBJIG9ubHkgbWVudGlvbmVkIHRoZQ0KDQo+ID4g cG90ZW50aWFsDQoNCj4gPiBvZiByZXN0cmljdGluZyB0aGUgY29udGV4dGFzIG9uZSBwb3NzaWJs ZSB3YXkgZm9yd2FyZDsgSSBhbSBjZXJ0YWlubHkNCg0KPiA+IG5vdCB3ZWRkZWQgdG8gaXQuDQoN Cj4gPg0KDQo+ID4gTXkgc3VnZ2VzdGlvbiBmb3IgYSB3YXkgZm9yd2FyZCB3b3VsZCBiZSB0byBk b2N1bWVudCB0aGUgaGlnaCBsZXZlbA0KDQo+ID4gc2VjdXJpdHkgYW5kIHByaXZhY3kgcmVxdWly ZW1lbnRzIGluIHRoaXMgZG9jdW1lbnQuIElJVUMsIHRoZSBsYXJnZXINCg0KPiA+IGNvbnRleHQg aW5jbHVkZXMgcG90ZW50aWFsbHkgdW5rbm93biBjb250ZXh0cywgc28gc29tZSBvZiB0aGlzIG1h eQ0KDQo+ID4gbmVlZA0KDQo+ID4gdG8gYmUgY29uZGl0aW9uYWwuIEZvciBleGFtcGxlLCBsYW5n dWFnZSBsaWtlIHRoZSBmb2xsb3dpbmcgbWlnaHQgYmUNCg0KPiA+IGhlbHBmdWwgKHRoaXMgaXMg anVzdCBhbiBleGFtcGxlLS1JIGRvbid0IG1lYW4gdG8gc2F5IHRoYXQgaXQgaXMgdHJ1ZQ0KDQo+ ID4gb3INCg0KPiA+IGFwcGxpY2FibGUpOg0KDQo+ID4NCg0KPiA+ICAgIlNvbWUgdXNlcyBvZiB0 aGlzIG1lY2hhbmlzbSBtYXkgY2FycnkgcHJpdmFjeS1zZW5zaXRpdmUNCg0KPiA+IGluZm9ybWF0 aW9uLA0KDQo+ID4gb3IgZ2VuZXJhdGUgICAgcHJpdmFjeS1zZW5zaXRpdmUgbWV0YWRhdGEgdGhy b3VnaCB0aGUgc3Vic2NyaXB0aW9uDQoNCj4gPiBtZWNoYW5pc20uIEluIGNvbnRleHRzIHdoZXJl IHRoaXMgaXMgdHJ1ZSwgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHMNCg0KPiA+IGFwcGx5Li4u Ig0KDQo+ID4NCg0KPiA+IEl0IG1pZ2h0IGFsc28gYmUgcmVhc29uYWJsZSB0byBzYXkgdGhhdCwg Zm9yIHRoZSBjb250ZXh0IG9mIGkycnMsDQoNCj4gPiB0aGVzZQ0KDQo+ID4gcmVxdWlyZW1lbnRz IGFyZSBkb2N1bWVudGVkIGluIFtyZWZlcmVuY2VzXSBhbmQgYXJlIGV4cGVjdGVkIHRvIGJlDQoN Cj4gPiBmdWxmaWxsZWQgYnkgdGhlIFt0cmFuc3BvcnQgYW5kIG9yIHByb3RvY29sXQ0KDQo+ID4N Cg0KPiA+IEVyaWMncyBlbWFpbCBhbHNvIHN1Z2dlc3RlZCB0aGF0IHRoZSBhY3R1YWwgdHJhbnNw b3J0IG9mIGRhdGEgZnJvbSB0aGUNCg0KPiA+IFlhbmcgZGF0YXN0b3JlIG1heSBiZSBvdXQgb2Yg c2NvcGUgZm9yIHRoZXNlIHJlcXVpcmVtZW50cy4gSSBkb24ndA0KDQo+ID4gb2JqZWN0IHRvIHRo YXQsIGVpdGhlciwgYXMgbG9uZyBhcyBpdCBpcyBjbGVhciBhbmQgZXhwbGljaXQsIGFsdGhvdWdo DQoNCj4gPiBpdA0KDQo+ID4gd291bGQgYmUgZ29vZCB0byBwb2ludCB0byB3aGVyZSBpdCBpcyBf aW5fIHNjb3BlLg0KDQo+ID4NCg0KPiA+IFRoYW5rcyENCg0KPiA+DQoNCj4gPiBCZW4uDQoNCj4g Pg0KDQo+ID4gT24gNiBNYXkgMjAxNiwgYXQgMTowNiwgU3VzYW4gSGFyZXMgd3JvdGU6DQoNCj4g Pg0KDQo+ID4+IEJlbjoNCg0KPiA+Pg0KDQo+ID4+IFRoaXMgaXMgdGhlIGZpcnN0IG9mIHRoZSAi cmUtdXNlIiBtYW5hZ2VtZW50IHByb3RvY29scy4gIFRoZQ0KDQo+ID4+IHJlcXVpcmVtZW50cw0K DQo+ID4+IGFyZSBzZXQtdXAgc28gdGhhdCB3ZSBjYW4gc3VnZ2VzdCBhZGRpdGlvbnMgdG8gdGhl IE5FVENPTkYgYW5kDQoNCj4gPj4gUkVTVENPTkYgZm9yDQoNCj4gPj4gdGhpcyBmaXJzdCBvZiBJ MlJTLg0KDQo+ID4+DQoNCj4gPj4gVGhlIEkyUlMgZXBoZW1lcmFsIHdvcmssIHB1Yi9zdWIsIHRy YWNlYWJpbGl0eSwgYW5kIHNlY3VyaXR5IGFyZQ0KDQo+ID4+IHRhcmdldCBhdA0KDQo+ID4+IHRo ZSBJMlJTIHByb3RvY29sIGRlZmluaXRpb24gd2l0aCB0aGUgSTJSUyB1c2UgY2FzZS4gIEhvd2V2 ZXIsIHNpbmNlDQoNCj4gPj4gdGhlc2UNCg0KPiA+PiBhcmUgZ2VuZXJhbCBhZGRpdGlvbnMgdG8g TkVUQ09ORi9SRVNUQ09ORiwgdGhpcyB3b3JrIGNhbiBiZSB1c2VkDQoNCj4gPj4gZWxzZXdoZXJl Lg0KDQo+ID4+DQoNCj4gPj4gSSB0aGluayB0aGUgdGV4dCB5b3UgYXJlIGhpZ2hsaWdodGluZyBo YXMgdGhpcyBsYXJnZXIgY29udGV4dC4gICBOb3csDQoNCj4gPj4gb25lIG9mDQoNCj4gPj4gdGhl IHJlYWxseSBpbXBvcnRhbnQgdGhpbmdzIHRvIGNoYXQgd2l0aCBBbGlhIGFuZCBCZW5vaXQgaXMg aG93IGRvIHdlDQoNCj4gPj4gaGFuZGxlDQoNCj4gPj4gdGhlIHdpZGVyIHVzZSBjYXNlLiAgIERv IHdlIG1lbnRpb24gdGhlIHdpZGVyIGNvbnRleHQ/DQoNCj4gPj4NCg0KPiA+PiBUaGUgV0cgdGhv dWdodCBtZW50aW9uaW5nIGl0IHdhcyBpbXBvcnRhbnQuDQoNCj4gPj4NCg0KPiA+PiBTdWUNCg0K PiA+Pg0KDQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gPj4gRnJvbTogQmVu IENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXQ0KDQo+ID4+IFNlbnQ6IFRodXJzZGF5 LCBNYXkgMDUsIDIwMTYgNTozMSBQTQ0KDQo+ID4+IFRvOiBTdXNhbiBIYXJlcw0KDQo+ID4+IENj OiBFcmljIFZvaXQ7IFRoZSBJRVNHOyBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3Jn PjsNCg0KPiA+PiBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZz47IGky cnMtY2hhaXJzQGlldGYub3JnPG1haWx0bzppMnJzLWNoYWlyc0BpZXRmLm9yZz4NCg0KPiA+PiBT dWJqZWN0OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24NCg0KPiA+PiBkcmFm dC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDY6ICh3aXRoIERJU0NVU1MgYW5kIENP TU1FTlQpDQoNCj4gPj4NCg0KPiA+PiBPbiA1IE1heSAyMDE2LCBhdCA1OjE1LCBTdXNhbiBIYXJl cyB3cm90ZToNCg0KPiA+Pg0KDQo+ID4+PiBFcmljLCBCZW4gYW5kIElFU0cgbWVtYmVyczoNCg0K PiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4gVGhlIHB1Yi9zdWIgcmVxdWlyZW1lbnRz IGFyZSBwYXJ0IG9mIGEgNSBwYXJ0IHJlcXVpcmVtZW50cy4gICBNYXkgSQ0KDQo+ID4+PiBxdW90 ZQ0KDQo+ID4+PiBmcm9tIHRoZSBzaGVwaGVyZCdzIHJlcG9ydDoNCg0KPiA+Pj4NCg0KPiA+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4gPj4+DQoNCj4gPj4+IFRoZSByZXF1aXJlbWVudHMg Zm9yIHRoZSBmaXJzdCB2ZXJzaW9uIG9mIEkyUlMgYXJlOg0KDQo+ID4+Pg0KDQo+ID4+PiAxKSBt b2RlbCBkcml2ZW4gZXBoZW1lcmFsIHN0YXRlIC0gdGhhdCBpcyBkYXRhIG1vZGVscyB0aGF0IGRv IG5vdA0KDQo+ID4+PiBzdXJ2aXZlDQoNCj4gPj4+DQoNCj4gPj4+ICAgICBhIHNvZnR3YXJlIG9y IGhhcmR3YXJlIHJlYm9vdC4NCg0KPiA+Pj4NCg0KPiA+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS8NCg0KPiA+Pj4NCg0K PiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4gMikgYSBzZWN1cmUgcHJvdG9jb2wgLQ0KDQo+ID4+Pg0K DQo+ID4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMt cHJvdG9jb2wtc2VjdXJpdHktcmVxDQoNCj4gPj4+IHVpcmVtZQ0KDQo+ID4+PiBudHMvDQoNCj4g Pj4+DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IDMpIHRyYWNlYWJpbGl0eSAtIGFiaWxpdHkg dG8gcmVjb3JkIGludGVyYWN0aW9ucyBiZXR3ZWVuIEkyUlMNCg0KPiA+Pj4gZWxlbWVudHMNCg0K PiA+Pj4NCg0KPiA+Pj4gKENsaWVudCwgQWdlbnQsIFJvdXRpbmcgc3lzdGVtKQ0KDQo+ID4+Pg0K DQo+ID4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMt dHJhY2VhYmlsaXR5Lw0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+PiA0KSBub3Rp ZmljYXRpb24gcHVibGljYXRpb24gdmlhIHN1YnNjcmlwdGlvbg0KDQo+ID4+Pg0KDQo+ID4+PiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1y ZXF1aXJlbWVudHMvDQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IDUpIFByb3Rv Y29sIHRvIHBhc3MgRGF0YSBmb3IgQW5hbHl0aWNzDQoNCj4gPj4+DQoNCj4gPj4+IFRoZSBmaXJz dCB2ZXJzaW9uIG9mIHRoZXNlIHJlcXVpcmVtZW50cyBkb2VzIG5vdCBpbmNsdWRlIGENCg0KPiA+ Pj4NCg0KPiA+Pj4gc2VwYXJhdGUgYW5hbHl0aWNhbCBwcm90b2NvbCByZXF1aXJlbWVudHMgYXMg dGhlIHNpbXBsZSB1c2UgY2FzZXMNCg0KPiA+Pj4gbWF5DQoNCj4gPj4+DQoNCj4gPj4+IHBhc3Mg aW5mb3JtYXRpb24gdmlhIHF1ZXJ5L3BvbGwgb3IgdGhlIG5vdGlmaWNhdGlvbnMuDQoNCj4gPj4+ DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IFRoZSBJMlJTIHByb3RvY29sIGV4aXN0cyBpbiBh biBzZWN1cmUgZW52aXJvbm1lbnQgZGVzY3JpYmVkIGJ5Og0KDQo+ID4+Pg0KDQo+ID4+PiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtc2VjdXJpdHktZW52 aXJvbm1lbnQtDQoNCj4gPj4+IHJlcXMvDQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4g Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4N Cg0KPiA+Pj4gRXJpYyAtIFBlcmhhcHMgaXQgd291bGQgYmUgZ29vZCB0byBwb2ludCB0bzoNCg0K PiA+Pj4NCg0KPiA+Pj4gLiAgICAgICAgIGRyYWZ0LWlldGYtaTJycy1wcm90b2NvbC1zZWN1cml0 eS1yZXF1aXJlbWVudHMgYW5kDQoNCj4gPj4+DQoNCj4gPj4+IC4gICAgICAgICBkcmFmdC1pZXRm LWkycnMtc2VjdXJpdHktZW52aXJvbm1lbnQtcmVxcy8NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+ Pj4NCg0KPiA+Pj4gQmVuIC0gQ2FuIHlvdSB0ZWxsIG1lIGhvdyB0aGUgc2hlcGhlcmQgcmVwb3J0 IGNvdWxkIGhhdmUgYmVlbg0KDQo+ID4+PiBjbGVhcmVyPw0KDQo+ID4+PiAgVGhlDQoNCj4gPj4+ IEkycnMgcHJvdG9jb2wgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIHJlcXVpcmU6ICBjb25maWRlbnRp YWxpdHksDQoNCj4gPj4+IGVuY3J5cHRpb24sIHNlY3VyZSB0cmFuc3BvcnQsIHByb3RlY3Rpb24g YWdhaW5zdCByZXBsYXkgYXR0YWNrLA0KDQo+ID4+PiBwcm90ZWN0aW9uIGFnYWluc3QgRERvUyBh dHRhY2sgKGlmIHBvc3NpYmxlKS4NCg0KPiA+Pg0KDQo+ID4+IEkgdGhpbmsgbXkgY29uZnVzaW9u IGxpZXMgaW4gdGhlIGZhY3QgdGhhdCwgd2hpbGUgdGhlIHNoZXBoZXJkJ3MNCg0KPiA+PiB3cml0 ZXVwDQoNCj4gPj4gc3R5bGVzIHRoaXMgZHJhZnQgYXMgcGFydCBvZiB0aGUgSTJSUyBwcm90b2Nv bCByZXF1aXJlbWVudHMsIHRoZQ0KDQo+ID4+IGRyYWZ0DQoNCj4gPj4gaXRzZWxmIGNsYWltcyB0 byBkZXNjcmliZSByZXF1aXJlbWVudHMgZm9yIGEgZ2VuZXJhbGx5IHVzZWZ1bCBwdWItc3ViDQoN Cj4gPj4gaW50ZXJmYWNlIHRvIGEgeWFuZyBkYXRhc3RvcmUuIEl0J3Mgbm90IGNsZWFyIHRvIG1l IGhvdyBhbmQgd2hlbiB0aGUNCg0KPiA+PiBJMlJTDQoNCj4gPj4gcHJvdG9jb2wgc2VjdXJpdHkg cmVxdWlyZW1lbnRzIGFwcGx5IHRvIGl0LiBJZiB0aGUgZGVzY3JpYmVkDQoNCj4gPj4gaW50ZXJm YWNlDQoNCj4gPj4gaXMNCg0KPiA+PiBpbnRlbmRlZCB0byBiZSB1c2VmdWwgaW4gY29udGV4dHMg b3RoZXIgdGhhbiBJMlJTIChhbmQgdGhlIGRyYWZ0DQoNCj4gPj4gZXhwbGljaXRseQ0KDQo+ID4+ IHNldHMgdGhhdCBleHBlY3RhdGlvbiBpbiAyLjIpLCBpdCBuZWVkcyB0byB0YWxrIG1vcmUgZ2Vu ZXJhbGx5IGFib3V0DQoNCj4gPj4gc2VjdXJpdHkgYW5kIHByaXZhY3kuDQoNCj4gPj4NCg0KPiA+ PiBGb3IgZXhhbXBsZSwgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byBzYXkgdGhhdCBjZXJ0YWluIHNl Y3VyaXR5DQoNCj4gPj4gcmVxdWlyZW1lbnRzDQoNCj4gPj4gYXBwbHkgaW4gZW52aXJvbm1lbnRz IHdoZXJlIHRoZSBtZWNoYW5pc20gbWlnaHQgY2FycnkgcHJpdmFjeQ0KDQo+ID4+IHNlbnNpdGl2 ZQ0KDQo+ID4+IGRhdGEsIGFuZCB0aGVuIHBvaW50IHRvIHRoZSBpMnJzIHJlcXVpcmVtZW50cyBm b3Igd2hlbiB0aGUgbWVjaGFuaXNtDQoNCj4gPj4gaXMgdXNlZA0KDQo+ID4+IGluIGFuIEkyUlMg Y29udGV4dC4NCg0KPiA+Pg0KDQo+ID4+IEEgZGlmZmVyZW50IGFwcHJvYWNoIG1pZ2h0IGJlIHRv IG1vcmUgdGlnaHRseSBjb25zdHJhaW4gdGhpcyB0byBpMnJzDQoNCj4gPj4NCg0KPiA+Pj4NCg0K PiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4gQmVuIC0gT24gb3B0aW5nIGluLCBvbmNlIHRoZSByZWNl aXZlIGFjY2VwdHMgYSB0cmFuc3BvcnQgY29ubmVjdGlvbg0KDQo+ID4+PiBmcm9tIHRoZSBJMlJT IHNlcnZlciAtIGhvdyBpcyB0aGlzIG5vdCBhbiBvcHQtaW4gdG8gcmVjZWl2ZSBkYXRhPw0KDQo+ ID4+PiBXaGF0DQoNCj4gPj4+IGFyZSB5b3UgbG9va2luZyBmb3I/DQoNCj4gPj4NCg0KPiA+PiBJ IGd1ZXNzIHRoYXQgZGVwZW5kcyBvbiB0aGUgdHJhbnNwb3J0LiBUaGUgdHJhbnNwb3J0IHJlcXVp cmVtZW50cyBzYXkNCg0KPiA+PiB0aGUNCg0KPiA+PiBtZWNoYW5pc20gaGFzIHRvIHdvcmsgb3Zl ciBtdWx0aXBsZSB0cmFuc3BvcnRzLiBUaGUgbGFzdCBwYXJhZ3JhcGggaW4NCg0KPiA+PiA0LjIu NA0KDQo+ID4+IHNheXMgIkluIHRoZSBjYXNlIG9mIGNvbm5lY3Rpb24tb3JpZW50ZWQgdHJhbnNw b3J0cy4uLiIgd2hpY2gNCg0KPiA+PiBzdWdnZXN0cw0KDQo+ID4+IHRoYXQNCg0KPiA+PiBub24t Y29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3BvcnRzIGFyZSBwb3NzaWJsZS4NCg0KPiA+Pg0KDQo+ ID4+IEV2ZW4gd2l0aCBhIGNvbm5lY3Rpb24tb3JpZW50ZWQgdHJhbnNwb3J0LCB0aGlzIG1heSBk ZXBlbmQgb24gaG93DQoNCj4gPj4gY29ubmVjdGlvbi1tYW5hZ2VtZW50IGlzIGhhbmRsZWQsIGFu ZCB3aGV0aGVyIHRoZSByZWNlaXZlciBtaWdodCBiZQ0KDQo+ID4+IHJlY2VpdmluZyB0aGluZ3Mg aXQgX3dhbnRzXyB0byByZWNlaXZlIG9uIHRoZSBzYW1lIHRyYW5zcG9ydC4NCg0KPiA+Pg0KDQo+ ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+PiBTdWUgSGFyZXMNCg0KPiA+Pj4NCg0KPiA+ Pj4gKHNoZXBoZXJkKQ0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+ Pg0KDQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+ID4+PiBGcm9tOiBpMnJz IFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBWb2l0DQoN Cj4gPj4+IChldm9pdCkNCg0KPiA+Pj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMDQsIDIwMTYgNzoy NSBQTQ0KDQo+ID4+PiBUbzogQmVuIENhbXBiZWxsOyBUaGUgSUVTRw0KDQo+ID4+PiBDYzogaTJy c0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtaTJycy1wdWItc3Vi LXJlcXVpcmVtZW50c0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVx dWlyZW1lbnRzQGlldGYub3JnPjsNCg0KPiA+Pj4gaTJycy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRv OmkycnMtY2hhaXJzQGlldGYub3JnPjsgc2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6 aC5jb20+DQoNCj4gPj4+IFN1YmplY3Q6IFJlOiBbaTJyc10gQmVuIENhbXBiZWxsJ3MgRGlzY3Vz cyBvbg0KDQo+ID4+PiBkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDY6ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4g Pj4+IEhpIEJlbiwNCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4gVGhhbmtzIGZv ciB0aGUgY29tbWVudC4gICBJbi1saW5lLi4uLg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pg0K DQo+ID4+Pj4gRnJvbTogQmVuIENhbXBiZWxsLCBNYXkgMDQsIDIwMTYgMjo0OSBQTQ0KDQo+ID4+ Pg0KDQo+ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+ID4+Pg0KDQo+ID4+Pj4gRElTQ1VTUzoNCg0K PiA+Pj4NCg0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPiA+Pj4NCg0KPiA+Pj4+DQoNCj4gPj4+ DQoNCj4gPj4+PiBJIGhhdmUgYSBjb3VwbGUgb2YgcG9pbnRzIEkgd291bGQgbGlrZSB0byBkaXNj dXNzLiBIb3BlZnVsbHkgdGhleQ0KDQo+ID4+Pj4gY2FuDQoNCj4gPj4+DQoNCj4gPj4+PiBiZSBy ZXNvbHZlZA0KDQo+ID4+Pg0KDQo+ID4+Pj4gZWFzaWx5Og0KDQo+ID4+Pg0KDQo+ID4+Pj4NCg0K PiA+Pj4NCg0KPiA+Pj4+IEFyZSB0aGVyZSByZWFsbHkgbm8gcmVxdWlyZW1lbnRzIGZvciBwcml2 YWN5IG9yIGludGVncml0eQ0KDQo+ID4+Pj4gcHJvdGVjdGlvbj8NCg0KPiA+Pj4NCg0KPiA+Pj4+ IElzIHRoZXJlIGFuIGV4cGVjdGF0aW9uIHRoYXQgdGhpcyBtZWNoYW5pc20gd291bGQgZXZlciBj YXJyeQ0KDQo+ID4+Pj4gcHJpdmFjeQ0KDQo+ID4+Pg0KDQo+ID4+Pj4gc2Vuc2l0aXZlIG9yIG90 aGVyd2lzZSBzZW5zaXRpdmUgaW5mb3JtYXRpb24/DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+ DQoNCj4gPj4+IFtlcmljJ3MgY29tbWVudDoNCg0KPiA+Pj4NCg0KPiA+Pj4gV2hlbiB0aGUgc3Vi c2NyaXB0aW9uIGlzIGVzdGFibGlzaGVkIGR5bmFtaWNhbGx5IHZpYSBhbiBleGlzdGluZw0KDQo+ ID4+PiB0cmFuc3BvcnQNCg0KPiA+Pj4gc2Vzc2lvbiAod2hpY2ggaXMgZXhwZWN0ZWQgdG8gYmUg dGhlIGRvbWluYW50IGNhc2UpIHdlIGhhdmUgdGhlIHNhbWUNCg0KPiA+Pj4gZXhwZWN0YXRpb25z IGZvciBQcml2YWN5IGFuZCBpbnRlZ3JpdHkgYXMgd291bGQgYmUgcHJvdmlkZWQgdmlhIGENCg0K PiA+Pj4gIkdFVCINCg0KPiA+Pj4gaW5zdGVhZCBvZiBhICJQVVNIIiBvdmVyIHRoZSBzYW1lIHRy YW5zcG9ydC4gICBXZSBjb3VsZCBoYXZlDQoNCj4gPj4+IHJlcGxpY2F0ZWQgYWxsDQoNCj4gPj4+ IHRoZXNlIHJlcXVpcmVtZW50cywgYnV0IHRoYXQgd2FzIHNlZW4gYXMgdW5uZWNlc3NhcnkgYW5k IGxpa2VseSBsZXNzDQoNCj4gPj4+IHNlY3VyZQ0KDQo+ID4+PiB0aGFuIGFkb3B0aW5nIGV4aXN0 aW5nIG1lY2hhbmlzbXMuDQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IFdoZW4g dGhlIFN1YnNjcmliZXIgYW5kIFJlY2VpdmVyIGFyZSBkaWZmZXJlbnQsIHRoZW4gdGhlIHRyYW5z cG9ydA0KDQo+ID4+PiBjb25uZWN0aW9uIHdpbGwgaGF2ZSBjcmVkZW50aWFscyBwYXNzZWQgYXMg cGFydCBvZiB0aGUNCg0KPiA+Pj4gZXN0YWJsaXNobWVudC4NCg0KPiA+Pj4gVGhlc2UNCg0KPiA+ Pj4gY3JlZGVudGlhbHMgd2lsbCBiZSB1c2VkIGFzIGEgU2VjdXJpdHkgR3Jvb21pbmcgRmlsdGVy IGp1c3QgbGlrZSB0aGUNCg0KPiA+Pj4gYWJvdmUNCg0KPiA+Pj4gY2FzZSBzbyB0aGF0IHB1c2hl ZCBvYmplY3RzIHdpbGwgYmUgZXhjbHVkZWQgZnJvbSBhbiBVcGRhdGUNCg0KPiA+Pj4gTm90aWZp Y2F0aW9uIGFzDQoNCj4gPj4+IHBlciB0aGUgcGVybWlzc2lvbnMgb2YgdGhlIFJlY2VpdmVyLiAg IChJLmUuLCB0aGlzIGlzIGlkZW50aWNhbA0KDQo+ID4+PiBiZWhhdmlvciB0bw0KDQo+ID4+PiB0 aGUgYWJvdmUuKSAgICBBcyBzZXZlcmFsIHBlb3BsZSBoYXZlIGhhZCBxdWVzdGlvbnMgYWJvdXQg dGhpcywgdGhlDQoNCj4gPj4+IG5ldyB2MDcNCg0KPiA+Pj4gd2lsbCBtYWtlIHRoaXMgZXhwbGlj aXQgaW4gdGhlIFNlY3VyaXR5IHNlY3Rpb24uDQoNCj4gPj4+DQoNCj4gPj4+IEVuZCBvZiBlcmlj J3MgY29tbWVudF0NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4gU3VlOiBUaGUg dHJhbnNwb3J0IHByb3ZpZGVzIGZvciBwcml2YWN5LCBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4NCg0K PiA+Pj4gTW9zdA0KDQo+ID4+PiBjb25maWd1cmF0aW9uIGluIG5ldHdvcmsgYm94ZXMgd291bGQg bmVlZCBwcml2YWN5Lg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pj4gLSA0LjIu NSwgMm5kIHRvIGxhc3QgcGFyYWdyYXBoOg0KDQo+ID4+Pg0KDQo+ID4+Pj4gSSBhbSBzdXJwcmlz ZWQgdG8gZmluZCB0aGF0LCB3aGVuIHRoZSByZWNlaXZlciBpcyBub3QgdGhlDQoNCj4gPj4+PiBz dWJzY3JpYmVyLA0KDQo+ID4+Pg0KDQo+ID4+Pj4gdGhhdCB0aGUgcmVjZWl2ZXIgaXMgZXhwZWN0 ZWQgdG8gb3B0LW91dC4gSXQgc2VlbXMgbGlrZSBzb21lIGZvcm0NCg0KPiA+Pj4+IG9mDQoNCj4g Pj4+DQoNCj4gPj4+PiBvcHQtaW4gb3IgYWZmaXJtYXRpdmUgY29uc2VudCB3b3VsZCBiZSBuZWVk ZWQgaGVyZS4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4gVGhlIHF1ZXN0aW9u IHJlYWxseSB3YXMgaG93IGhlYXZ5LXdlaWdodCBzaG91bGQgdGhlIG1lY2hhbmlzbSBiZS4NCg0K PiA+Pj4gVHJhbnNwb3J0cyBiZWVuIGNvbnNpZGVyaW5nIGFyZSBhbGwgZW5jcnlwdGVkLiAgU28g dGhlcmUgaXMgYWxyZWFkeQ0KDQo+ID4+PiBhDQoNCj4gPj4+IGxldmVsDQoNCj4gPj4+IG9mIHRy dXN0IGJldHdlZW4gdGhlIHBlZXJzLiAgQW5kIGEgdGFyZ2V0IGNhbiBhbHdheXMgcHVsbCBkb3du IHRoZQ0KDQo+ID4+PiBjb25uZWN0aW9uIGlmIHRoZXJlIGFyZSBpc3N1ZXMuDQoNCj4gPj4+DQoN Cj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IEluIGFkZGl0aW9uLCBtdWx0aWNhc3QgdHJhbnNwb3J0 cyBhcmUgdmlhYmxlIGZvciBzb21lIGZ1dHVyZSBjYXNlcy4NCg0KPiA+Pj4gV2UNCg0KPiA+Pj4g ZGlkbid0IHdhbnQgbWVjaGFuaXNtcyB3aGljaCBjb21wbGljYXRlZCB0aGlzIHR5cGUgb2YgaW50 ZXJhY3Rpb24sDQoNCj4gPj4+IGVzcGVjaWFsbHkgaW4gYSB3b3JsZCB3aGVyZSBkdW1iIElvVCBk ZXZpY2VzIG1heSBiZSBpbnZvbHZlZC4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+ Pj4gU3VlOiBJZiB0aGUgcmVjZWl2ZXIgYWNjZXB0cyBhIHNlY3VyZSB0cmFuc3BvcnQgc2V0LXVw IGZyb20gdGhlDQoNCj4gPj4+IHNlcnZlciwgY2FuDQoNCj4gPj4+IHlvdSBwcm92aWRlIHRoZSBy ZWFzb24gd2h5IHRoaXMgaXMgbm90IGFuICJvcHQtaW4iIG9uY2UgaXQgcmVjZWl2ZXMNCg0KPiA+ Pj4gdGhlDQoNCj4gPj4+IGNvbm5lY3Rpb24gZnJvbSB0aGUgSTJSUyBhZ2VudD8NCg0KPiA+Pj4N Cg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KPiA+Pj4NCg0KPiA+Pj4+IENPTU1FTlQ6DQoNCj4gPj4+DQoNCj4gPj4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCj4gPj4+DQoNCj4gPj4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pj4gLSBHZW5lcmFsOiBJ IHN1cHBvcnQgU3RlcGhlbidzIERJU0NVU1MNCg0KPiA+Pj4NCg0KPiA+Pj4+DQoNCj4gPj4+DQoN Cj4gPj4+PiAtMi4yOiBXaGF0IGlzIHRoZSByZWFsIHNjb3BlIG9mIHRoaXMgd29yaz8gSXMgaXQg ZXhwZWN0ZWQgdG8NCg0KPiA+Pj4+IHN1cHBsYW50DQoNCj4gPj4+DQoNCj4gPj4+PiB0aGUgbWVu dGlvbmVkIG1lY2hhbmlzbXM/DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IE5v LiAgIEl0IGlzIGp1c3Qgc2hvd2luZyB0aGF0IG1hbnkgc3BlY2lhbGl6ZWQgUHVzaCBtZWNoYW5p c20gZXhpc3QuDQoNCj4gPj4+IFRoaXMNCg0KPiA+Pj4gaXMgbm90IGludGVuZGVkIHRvIHN1cHBs YW50IGV4aXN0aW5nIG1lY2hhbmlzbXMsIGFsdGhvdWdoIHBlcmhhcHMgaXQNCg0KPiA+Pj4gY2Fu DQoNCj4gPj4+IGhlbHAgYXZvaWQgZnV0dXJlIGRlZGljYXRlZCBzb2x1dGlvbnMuDQoNCj4gPj4+ DQoNCj4gPj4+PiAtIDIuMzogIldlIG5lZWQgYSBuZXcgcHViLXN1Yg0KDQo+ID4+Pg0KDQo+ID4+ Pj4gICAgdGVjaG5vbG9neSINCg0KPiA+Pj4NCg0KPiA+Pj4+IFRoZSBzaGVwaGVyZCB3cml0ZSB1 cCBtZW50aW9uZWQgYSBnb2FsIHRvIHVzZSBleGlzdGluZw0KDQo+ID4+Pj4gdGVjaG5vbG9naWVz Lg0KDQo+ID4+Pg0KDQo+ID4+Pj4gSXMgdGhlIHBvaW50IG9mIHRoaXMgc2VudGVuY2UgdG8gc3Vn Z2VzdCB0aGF0IGlzIG5vdCBmZWFzaWJsZT8NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0K PiA+Pj4gRXhpc3RpbmcgdGVjaG5vbG9naWVzIGNhbm5vdCBtZWV0IGFsbCB0aGUgcmVxdWlyZW1l bnRzIHNwZWNpZmllZC4NCg0KPiA+Pj4gVGhlcmUgYXJlDQoNCj4gPj4+IHRlY2hub2xvZ3kgZHJh ZnRzIHByb2dyZXNzaW5nIGluIE5FVENPTkYgd2hpY2ggY2FuLg0KDQo+ID4+Pg0KDQo+ID4+Pg0K DQo+ID4+Pg0KDQo+ID4+Pj4gLSA0LjEsIDR0aCBwYXJhZ3JhcGg6DQoNCj4gPj4+DQoNCj4gPj4+ PiBUaGUgTUFZIGRvZXNuJ3Qgc2VlbSByaWdodC0taXMgdGhpcyBhIHN0YXRlbWVudCBvZiBmYWN0 IHRoYXQgdGhlDQoNCj4gPj4+DQoNCj4gPj4+PiBzdWJzY3JpYmVyIG1heSBoYXZlIHRvIHJlc3Vi c2NyaWJlLCBvciBhIHJlcXVpcmVtZW50IG9mIHRoZSBmb3JtDQoNCj4gPj4+PiB0aGF0DQoNCj4g Pj4+DQoNCj4gPj4+PiB0aGUgc2VydmljZSBNQVkgZm9yY2UgdGhlIHN1YnNjcmliZXIgdG8gcmVz dWJzY3JpYmU/IChCZSBjYXJlZnVsDQoNCj4gPj4+PiB3aXRoDQoNCj4gPj4+DQoNCj4gPj4+PiBN QVlzIGluIHJlcXVpcmVtZW50cyBsYW5ndWFnZS0tdGhleSBpbXBseSB1bmV4cGVjdGVkIHRoaW5n cy4gRm9yDQoNCj4gPj4+DQoNCj4gPj4+PiBleGFtcGxlLCBzZXZlcmFsIHJlcXVpcmVtZW50cyBz YXkgYSBTVUJTQ1JJQkUgTUFZIGRvIHNvbWV0aGluZy0tZG8NCg0KPiA+Pj4NCg0KPiA+Pj4+IHRo b3NlIGltcGx5IHRoYXQgdGhlIHNlcnZpY2UgTVVTVCBhbGxvdyB0aGUgc3Vic2NyaWJlciB0byBk byBpdCA/KQ0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+PiBHb29kIHBvaW50LiAg IFJld29yZGVkIGluIHYwNy4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4+IC0t IDQuMi4yLCB0aGlyZCBidWxsZXQ6IFRoZSBwcmV2aW91cyBzZWN0aW9uIHNhaWQgZGFtcGVuaW5n IHBlcmlvZHMNCg0KPiA+Pj4NCg0KPiA+Pj4+IE1VU1QgYmUgc3VwcG9ydGVkLg0KDQo+ID4+Pg0K DQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+PiBZZXMsIGJ1dCBkYW1wZW5pbmcgaXMgbmV2ZXIgZm9y IHBlcmlvZGljIHN1YnNjcmlwdGlvbnMuDQoNCj4gPj4+DQoNCj4gPj4+PiAtIDQuMi4xLCB0aGly ZCBwYXJhZ3JhcGg6IFRoaXMgaXMgYSBiaXQgYW1iaWd1b3VzLiBJIHRoaW5rIGl0IG1lYW5zDQoN Cj4gPj4+PiB0bw0KDQo+ID4+Pg0KDQo+ID4+Pj4gY2hhbmdlIHRoZSB3aGF0IHN1YnRyZWVzIHRo ZSBzdWJzY3JpcHRpb24gYXBwbGllcyB0bywgYnV0IGNvdWxkIGJlDQoNCj4gPj4+DQoNCj4gPj4+ PiBpbnRlcnByZXRlZCB0byBjaGFuZ2UgdGhlIHN1YnRyZWVzIHRoZW1zZWx2ZXMuDQoNCj4gPj4+ DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IEZpeGVkDQoNCj4gPj4+DQoNCj4gPj4+PiAtIDQu Mi42LjQ6IFdvdWxkIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dlZCBvdXQtb2Ytb3JkZXIgZGVsaXZl cnkgYnV0DQoNCj4gPj4+DQoNCj4gPj4+PiBnYXZlIHRoZSBzdWJzY3JpYmVyIGEgd2F5IHRvIHJl Y29uc3RydWN0IHRoZSBvcmRlciBmdWxmaWxsIHRoaXMNCg0KPiA+Pj4gcmVxdWlyZW1lbnQ/DQoN Cj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IFllcywgdGhlIHRpbWVzdGFtcCB3aXRo aW4gYW4gdXBkYXRlLiAgQnV0IHRoaXMgcmVxdWlyZW1lbnQgdGFyZ2V0cyBhDQoNCj4gPj4+IHNw ZWNpZmljIG9iamVjdCBpbiBhIHNwZWNpZmljIHN1YnNjcmlwdGlvbi4gIFNvIHRoZXJlIHNob3Vs ZCBiZSBubw0KDQo+ID4+PiBpc3N1ZXMuDQoNCj4gPj4+DQoNCj4gPj4+PiBOaXRzOg0KDQo+ID4+ Pg0KDQo+ID4+Pj4gLSBUaGUgc2hlcGhlcmQgd3JpdGUgdXAgc3VnZ2VzdHMgdGhpcyBpcyBzdGFu ZGFyZHMgdHJhY2suIFRoZSBkcmFmdA0KDQo+ID4+Pg0KDQo+ID4+Pj4gYW5kIHRyYWNrZXIgYm90 aCBzYXkgaW5mb3JtYXRpb25hbC4gUGxlYXNlIHVwZGF0ZSB0aGUgc2hlcGhlcmQgd3JpdA0KDQo+ ID4+Pj4gdXAuDQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IEZpeGVkDQoNCj4g Pj4+DQoNCj4gPj4+PiAtMywgbGFzdCBwYXJhZ3JhcGg6IFdoYXQncyB0aGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIGEgIlB1c2giIGFuZCBhbg0KDQo+ID4+PiAiVXBkYXRlIj8NCg0KPiA+Pj4NCg0KPiA+ Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4gUmV3b3JkZWQNCg0KPiA+Pj4NCg0KPiA+Pj4+IC00LjE6IEEg Zm9yd2FyZCByZWZlcmVuY2UgdG8gdGhlIHN1YnNjcmlwdGlvbiBRb1Mgc2VjdGlvbiB3b3VsZCBi ZQ0KDQo+ID4+PiBoZWxwZnVsLg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+PiBN b3ZlZCB0aGUgcmVxdWlyZW1lbnQgaW4gcXVlc3Rpb24gdG8gNC4yLjYuDQoNCj4gPj4+DQoNCj4g Pj4+PiAtLSBMYXN0IHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZTogU2VudGVuY2UgZG9lc24ndCBw YXJzZS4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4NCg0KPiA+Pj4gRml4ZWQNCg0KPiA+Pj4N Cg0KPiA+Pj4+DQoNCj4gPj4+DQoNCj4gPj4+PiAtIDQuMi44LCB0aGlyZCBwYXJhZ3JhcGg6IEkg ZG9uJ3QgdGhpbmsgdGhhdCBzaG91bGQgYmUgYSAyMTE5IE1BWQ0KDQo+ID4+Pg0KDQo+ID4+Pg0K DQo+ID4+Pg0KDQo+ID4+PiBGaXhlZA0KDQo+ID4+Pg0KDQo+ID4+PiBUaGFua3MgYWdhaW4gZm9y IHRoZSByZXZpZXchDQoNCj4gPj4+DQoNCj4gPj4+IEVyaWMNCg0KPiA+Pj4NCg0KPiA+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPiA+Pj4NCg0K PiA+Pj4gaTJycyBtYWlsaW5nIGxpc3QNCg0KPiA+Pj4NCg0KPiA+Pj4gIDxtYWlsdG86aTJyc0Bp ZXRmLm9yZz4gaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NCg0KPiA+Pj4NCg0K PiA+Pj4gIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM+DQoNCj4g Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0K --_000_167d2323d3264287a30c36c1950984b5XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRp di5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEyOS43NXB0IDEuMGluIDEyOS43cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSBCZW4sPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoZXJlIGlzIG5vIGlzc3VlIHdpdGggcmV3b3JkaW5nIHRvIGEgcmVxdWly ZW1lbnQgcmF0aGVyIHRoYW4gYW4gaW50cm8uJm5ic3A7IFRoZSBzZWNvbmQgc2VudGVuY2UgYmVs b3cgaGFzIGJlZW4gY2hhbmdlZCB0byBtZWV0IDIxMTkuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlNvbWUgdXNlcyBvZiB0aGlzIFN1YnNjcmlwdGlvbiBTZXJ2aWNlIHdpbGwgcHVzaCBw cml2YWN5LXNlbnNpdGl2ZSB1cGRhdGVzIGFuZCBtZXRhZGF0YS4mbmJzcDsNCjxzcGFuIHN0eWxl PSJjb2xvcjojMDBCMDUwIj5Gb3IgcHJpdmFjeS1zZW5zaXRpdmUgZGVwbG95bWVudHMsIHN1YnNj cmlwdGlvbiBpbmZvcm1hdGlvbiBNVVNUIGJlIGJvdW5kIHdpdGhpbiBzZWN1cmUsDQo8L3NwYW4+ ZW5jcnlwdGVkIHRyYW5zcG9ydCBsYXllciBtZWNoYW5pc21zLiZuYnNwOyBGb3IgZXhhbXBsZSBp ZiBORVRDT05GIGlzIHVzZWQgYXMgdHJhbnNwb3J0LCB0aGVuIFtSRkM1NTM5XSB3b3VsZCBiZSBh IHZhbGlkIG9wdGlvbiB0byBzZWN1cmUgdGhlIHRyYW5zcG9ydGVkIGluZm9ybWF0aW9uLiZuYnNw OyBUaGUgU3Vic2NyaXB0aW9uIFNlcnZpY2UgY2FuIGFsc28gYmUgdXNlZCB3aXRoIGVtZXJnaW5n DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+cHJpdmFjeS1zZW5zaXRpdmUgPC9zcGFuPmRl cGxveW1lbnQgY29udGV4dHMgYXMgd2VsbC4mbmJzcDsgQXMgYW4gZXhhbXBsZSwgZGVwbG95bWVu dHMgYmFzZWQgb24gW2kycnMtdXNlY2FzZV0NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj53 b3VsZCA8L3NwYW4+YXBwbHkgdGhlc2UgcmVxdWlyZW1lbnRzIGluIGNvbmp1bmN0aW9uIHdpdGgg dGhvc2UgZG9jdW1lbnRlZCB3aXRoaW4gW2kycnMtZW52aXJvbm1lbnQtc2VjdXJpdHldIGFuZCBb aTJycy1wcm90b2NvbC1zZWN1cml0eV0gdG8gc2VjdXJlIGVwaGVtZXJhbCBzdGF0ZSBpbmZvcm1h dGlvbiBiZWluZyBwdXNoZWQgZnJvbSBhIE5ldHdvcmsgRWxlbWVudC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+RXJpYzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEZy b206IEJlbiBDYW1wYmVsbCwgTWF5IDE1LCAyMDE2IDM6MTggUE08L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IEhpIEVyaWMgYW5kIFN1ZSw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhhbmtzIGZvciB0aGUgY2hh bmdlLCBhbmQgSSB0aGluayBpdCdzIG9uIHRoZSByaWdodCB0cmFjay4gQnV0IEkgbm90aWNlIG1v c3Qgb2YgdGhlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBvdGhlciByZXF1aXJl bWVudHMsIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFuZCBpbiBvdGhl ciBzZWN0aW9ucyw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHVzZSAyMTE5IGtl eXdvcmRzLiBJcyB0aGVyZSBhIHJlYXNvbiBub3QgdG8gZG8gc28gaGVyZT8gV291bGQgaXQgYmUg cmVhc29uYWJsZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdG8gc2F5IHRoYXQg YW55IGVtYm9kaW1lbnQgb2YgdGhlc2UgcmVxdWlyZW1lbnRzIE1VU1Qgc3VwcG9ydCBhIHRyYW5z cG9ydDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhhdCBwcm92aWRlcyBlbmNy eXB0aW9uIGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwgYW5kIHN1Y2ggYSB0cmFuc3BvcnQgTVVT VCBiZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdXNlZCB3aGVuIGNhcnJ5aW5n IHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uPzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGFua3MhPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IEJlbi48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBPbiAxMyBNYXkgMjAxNiwgYXQgMTA6NDksIFN1c2FuIEhhcmVzIHdyb3RlOjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7IEVyaWM6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFRo YW5rcyBmb3IganVtcGluZyBpbiBhbmQgcHV0dGluZyBvdXQgdGV4dCB0aGF0IHJlc29sdmVzIEJl buKAmXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgY29tbWVudHMuJm5i c3A7IFRoaXMgdGV4dCB3b3JrcyBmb3IgbWUgd2l0aCBvbmUgYWRkaXRpb24uJm5ic3A7IEFkZCBy ZWZlcmVuY2UgdG88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgdGhlIHNl Y3VyaXR5IGVudmlyb25tZW50IGRyYWZ0LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyBTdWU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg RnJvbTogRXJpYyBWb2l0IChldm9pdCkgWzxhIGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWls dG86ZXZvaXRAY2lzY28uY29tPC9zcGFuPjwvYT5dPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7IFNlbnQ6IEZyaWRheSwgTWF5IDEzLCAyMDE2IDExOjI2IEFNPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFRvOiBTdXNhbiBIYXJlczsgQmVuIENhbXBi ZWxsOyBBbGlhIEF0bGFzICg8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5ha2F0bGFzQGdt YWlsLmNvbTwvc3Bhbj48L2E+KTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyBDYzogVGhlIElFU0c7IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aTJyc0BpZXRmLm9yZzwv c3Bhbj48L2E+OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyA8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFm dC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjsNCjxh IGhyZWY9Im1haWx0bzppMnJzLWNoYWlyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnMtY2hhaXJzQGlldGYub3JnPC9zcGFu PjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgU3ViamVjdDogUkU6 IFtpMnJzXSBCZW4gQ2FtcGJlbGwncyBEaXNjdXNzIG9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7IGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0wNjog KHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgSGkgQmVuLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyBJIGhhdmUgYWRkZWQgdGhlIHRleHQgYmVsb3cgYXMgdGhlIGxlYWQtaW4gdG8gc2VjdGlv biA0LjIuNS4mbmJzcDsgSTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBi ZWxpZXZlIHRoaXMgbWVldHMgdGhlIGludGVudHMgb2YgeW91ciBzdWdnZXN0aW9ucyBiZWxvdy48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgSGkgU3VzYW4gJmFtcDsg QWxpYSw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgSSBoYXZlIHVw bG9hZGVkIHYwOCBvZjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMv Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1y ZXF1aXJlbWVudHMvPC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgSWYgQmVuIGNvbmN1 cnMgd2l0aCB0aGUgdGV4dCBiZWxvdywgSSBhbSBub3QgYXdhcmUgb2YgYW55IHJlbWFpbmluZzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBkaXNjdXNzIGl0ZW1zLjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBUaGFua3MgZXZlcnlvbmUgZm9y IHlvdXIgcmV2aWV3cyw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgRXJpYywgQWxleCwgJmFtcDsgQWxi ZXJ0bzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyA0LjIuNS4mbmJzcDsgU2VjdXJpdHkgUmVxdWlyZW1lbnRzPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNvbWUgdXNlcyBvZiB0aGlzIFN1YnNjcmlwdGlvbiBT ZXJ2aWNlIHdpbGwgcHVzaCBwcml2YWN5LXNlbnNpdGl2ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB1cGRhdGVzIGFuZCBtZXRhZGF0YS4m bmJzcDsgR29vZCBkZXBsb3ltZW50IHByYWN0aWNlcyB3aWxsIGJpbmQgdGhpczwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBnZW5lcmF0ZWQg aW5mb3JtYXRpb24gd2l0aGluIHNlY3VyZSwgZW5jcnlwdGVkIHRyYW5zcG9ydCBsYXllcjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBtZWNo YW5pc21zLiZuYnNwOyBGb3IgZXhhbXBsZSBpZiBORVRDT05GIGlzIHVzZWQgYXMgdHJhbnNwb3J0 LCB0aGVuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFtSRkM1NTM5XSB3b3VsZCBiZSBhIHZhbGlkIG9wdGlvbiB0byBzZWN1cmUgdGhlIHRy YW5zcG9ydGVkPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGluZm9ybWF0aW9uLiZuYnNwOyBUaGUgU3Vic2NyaXB0aW9uIFNlcnZpY2UgY2Fu IGFsc28gYmUgdXNlZCB3aXRoPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 IGVtZXJnaW5nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRlcGxveW1lbnQgY29udGV4dHMgYXMgd2VsbC4mbmJzcDsgQXMgYW4gZXhhbXBs ZSwgZGVwbG95bWVudHMgYmFzZWQgb248L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgW2kycnMtdXNlY2FzZV0gY2FuIGFwcGx5IHRoZXNlIHJl cXVpcmVtZW50cyBpbiBjb25qdW5jdGlvbiB3aXRoPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7IHRob3NlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvY3VtZW50ZWQgd2l0aGluIFtpMnJzLXByb3RvY29sLXNlY3Vy aXR5XSB0byBzZWN1cmUgZXBoZW1lcmFsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7IHN0YXRlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIGJlaW5nIHB1c2hlZCBmcm9tIGEgTmV0d29yayBFbGVt ZW50LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBGcm9tOiBTdXNhbiBIYXJlcyBbPGEgaHJlZj0i bWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpzaGFyZXNAbmR6aC5jb208L3NwYW4+PC9hPl08L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgU2VudDogRnJpZGF5LCBNYXkgMDYs IDIwMTYgNzowOSBQTTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBUbzog QmVuIENhbXBiZWxsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IENjOiBF cmljIFZvaXQgKGV2b2l0KTsgVGhlIElFU0c7IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3Jn Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5p MnJzQGlldGYub3JnPC9zcGFuPjwvYT47PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVu dHNAaWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50c0BpZXRmLm9yZzwv c3Bhbj48L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmkycnMtY2hhaXJzQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aTJycy1jaGFpcnNA aWV0Zi5vcmc8L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyBTdWJqZWN0OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb248L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVx dWlyZW1lbnRzLTA2OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBCZW46PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7IFRoaXMgaXMgd2lzZSBpZGVhLiZuYnNwOyBJIHdpbGwgc3VnZ2VzdCBz b21lIHRleHQgdG8gRXJpYyBhbmQgeW91IGluIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyBtb3JuaW5nLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyBTdWU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgU2VudCB2aWEgdGhlIFNhbXN1 bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7IEZyb206IEJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBub3N0 cnVtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmJlbkBub3N0cnVtLmNvbTwvc3Bhbj48L2E+Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBE YXRlOiA1LzYvMjAxNiAyOjM4IFBNIChHTVQtMDY6MDApPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFRv OiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnNoYXJlc0BuZHpo LmNvbTwvc3Bhbj48L2E+Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBDYzogRXJpYyBWb2l0ICZs dDs8YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZXZvaXRAY2lzY28uY29tPC9zcGFuPjwvYT4m Z3Q7LCBUaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pZXNnQGlldGYub3Jn PC9zcGFuPjwvYT4mZ3Q7LDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyA8 YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnNAaWV0Zi5vcmc8L3NwYW4+PC9hPiwNCjxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFm dC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc8L3NwYW4+PC9hPiw8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOmkycnMt Y2hhaXJzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+aTJycy1jaGFpcnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyBTdWJqZWN0OiBSZTogW2kycnNdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb248L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgZHJhZnQtaWV0Zi1pMnJzLXB1Yi1z dWItcmVxdWlyZW1lbnRzLTA2OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBIaSBTdXNhbiw8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgVG8gYmUgY2xlYXIsIEkgZG8gbm90IG9iamVjdCB0byB0aGUgd2lkZXIgY29udGV4dCBw ZXIgc2UuIE15IGNvbmNlcm48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg aXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgdGhhdCB0aGUgc2VjdXJp dHkgYW5kIHByaXZhY3kgcmVxdWlyZW1lbnRzIGFyZSBsZWZ0IGFzIGltcGxpY2l0LCBiYXNlZDwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBvbiB0aGUgbW9yZSBuYXJyb3cg aTJycy9uZXRjb25mIGNvbnRleHQuIEkgb25seSBtZW50aW9uZWQgdGhlPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHBvdGVudGlhbDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyBvZiByZXN0cmljdGluZyB0aGUgY29udGV4dGFzIG9uZSBwb3NzaWJs ZSB3YXkgZm9yd2FyZDsgSSBhbSBjZXJ0YWlubHk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgbm90IHdlZGRlZCB0byBpdC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgTXkgc3Vn Z2VzdGlvbiBmb3IgYSB3YXkgZm9yd2FyZCB3b3VsZCBiZSB0byBkb2N1bWVudCB0aGUgaGlnaCBs ZXZlbDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBzZWN1cml0eSBhbmQg cHJpdmFjeSByZXF1aXJlbWVudHMgaW4gdGhpcyBkb2N1bWVudC4gSUlVQywgdGhlIGxhcmdlcjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBjb250ZXh0IGluY2x1ZGVzIHBv dGVudGlhbGx5IHVua25vd24gY29udGV4dHMsIHNvIHNvbWUgb2YgdGhpcyBtYXk8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgbmVlZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyB0byBiZSBjb25kaXRpb25hbC4gRm9yIGV4YW1wbGUsIGxhbmd1YWdl IGxpa2UgdGhlIGZvbGxvd2luZyBtaWdodCBiZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyBoZWxwZnVsICh0aGlzIGlzIGp1c3QgYW4gZXhhbXBsZS0tSSBkb24ndCBtZWFu IHRvIHNheSB0aGF0IGl0IGlzIHRydWU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgb3I8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgYXBwbGljYWJs ZSk6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7ICZxdW90O1NvbWUgdXNlcyBvZiB0 aGlzIG1lY2hhbmlzbSBtYXkgY2FycnkgcHJpdmFjeS1zZW5zaXRpdmU8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgaW5mb3JtYXRpb24sPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7IG9yIGdlbmVyYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7IHByaXZhY3kt c2Vuc2l0aXZlIG1ldGFkYXRhIHRocm91Z2ggdGhlIHN1YnNjcmlwdGlvbjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBtZWNoYW5pc20uIEluIGNvbnRleHRzIHdoZXJlIHRo aXMgaXMgdHJ1ZSwgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHM8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgYXBwbHkuLi4mcXVvdDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg SXQgbWlnaHQgYWxzbyBiZSByZWFzb25hYmxlIHRvIHNheSB0aGF0LCBmb3IgdGhlIGNvbnRleHQg b2YgaTJycyw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgdGhlc2U8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgcmVxdWlyZW1lbnRzIGFyZSBkb2N1 bWVudGVkIGluIFtyZWZlcmVuY2VzXSBhbmQgYXJlIGV4cGVjdGVkIHRvIGJlPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGZ1bGZpbGxlZCBieSB0aGUgW3RyYW5zcG9ydCBh bmQgb3IgcHJvdG9jb2xdPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEVyaWMncyBlbWFpbCBhbHNvIHN1 Z2dlc3RlZCB0aGF0IHRoZSBhY3R1YWwgdHJhbnNwb3J0IG9mIGRhdGEgZnJvbSB0aGU8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgWWFuZyBkYXRhc3RvcmUgbWF5IGJlIG91 dCBvZiBzY29wZSBmb3IgdGhlc2UgcmVxdWlyZW1lbnRzLiBJIGRvbid0PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IG9iamVjdCB0byB0aGF0LCBlaXRoZXIsIGFzIGxvbmcg YXMgaXQgaXMgY2xlYXIgYW5kIGV4cGxpY2l0LCBhbHRob3VnaDwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyBpdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyB3b3VsZCBiZSBnb29kIHRvIHBvaW50IHRvIHdoZXJlIGl0IGlzIF9pbl8gc2NvcGUuPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7IFRoYW5rcyE8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgQmVuLjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyBPbiA2IE1heSAyMDE2LCBhdCAxOjA2LCBTdXNhbiBIYXJlcyB3cm90 ZTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IEJlbjo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyBUaGlzIGlzIHRoZSBmaXJzdCBvZiB0aGUgJnF1b3Q7cmUtdXNlJnF1b3Q7IG1hbmFnZW1l bnQgcHJvdG9jb2xzLiZuYnNwOyBUaGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7IHJlcXVpcmVtZW50czwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsgYXJlIHNldC11cCBzbyB0aGF0IHdlIGNhbiBzdWdnZXN0IGFkZGl0aW9ucyB0byB0 aGUgTkVUQ09ORiBhbmQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 IFJFU1RDT05GIGZvcjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsg dGhpcyBmaXJzdCBvZiBJMlJTLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IFRoZSBJMlJT IGVwaGVtZXJhbCB3b3JrLCBwdWIvc3ViLCB0cmFjZWFiaWxpdHksIGFuZCBzZWN1cml0eSBhcmU8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHRhcmdldCBhdDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgdGhlIEkyUlMgcHJvdG9jb2wg ZGVmaW5pdGlvbiB3aXRoIHRoZSBJMlJTIHVzZSBjYXNlLiZuYnNwOyBIb3dldmVyLCBzaW5jZTwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgdGhlc2U8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGFyZSBnZW5lcmFsIGFkZGl0aW9ucyB0 byBORVRDT05GL1JFU1RDT05GLCB0aGlzIHdvcmsgY2FuIGJlIHVzZWQ8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGVsc2V3aGVyZS48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyBJIHRoaW5rIHRoZSB0ZXh0IHlvdSBhcmUgaGlnaGxpZ2h0aW5nIGhhcyB0aGlz IGxhcmdlciBjb250ZXh0LiZuYnNwOyZuYnNwOyBOb3csPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBvbmUgb2Y8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IHRoZSByZWFsbHkgaW1wb3J0YW50IHRoaW5ncyB0byBjaGF0IHdpdGggQWxp YSBhbmQgQmVub2l0IGlzIGhvdyBkbyB3ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsgaGFuZGxlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyB0aGUgd2lkZXIgdXNlIGNhc2UuJm5ic3A7Jm5ic3A7IERvIHdlIG1lbnRpb24gdGhlIHdp ZGVyIGNvbnRleHQ/PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgVGhlIFdHIHRob3VnaHQg bWVudGlvbmluZyBpdCB3YXMgaW1wb3J0YW50LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 IFN1ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBCZW4g Q2FtcGJlbGwgWzxhIGhyZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86YmVuQG5vc3RydW0u Y29tPC9zcGFuPjwvYT5dPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyBTZW50OiBUaHVyc2RheSwgTWF5IDA1LCAyMDE2IDU6MzEgUE08L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IFRvOiBTdXNhbiBIYXJlczwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgQ2M6IEVyaWMgVm9pdDsgVGhlIElFU0c7IDxhIGhy ZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lIj5pMnJzQGlldGYub3JnPC9zcGFuPjwvYT47PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzQGlldGYub3JnIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWkycnMtcHVi LXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjsNCjxhIGhyZWY9Im1haWx0bzpp MnJzLWNoYWlyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmkycnMtY2hhaXJzQGlldGYub3JnPC9zcGFuPjwvYT48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbaTJyc10gQmVu IENhbXBiZWxsJ3MgRGlzY3VzcyBvbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsgZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2OiAod2l0aCBE SVNDVVNTIGFuZCBDT01NRU5UKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IE9uIDUgTWF5 IDIwMTYsIGF0IDU6MTUsIFN1c2FuIEhhcmVzIHdyb3RlOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OyBFcmljLCBCZW4gYW5kIElFU0cgbWVtYmVyczo8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBU aGUgcHViL3N1YiByZXF1aXJlbWVudHMgYXJlIHBhcnQgb2YgYSA1IHBhcnQgcmVxdWlyZW1lbnRz LiZuYnNwOyZuYnNwOyBNYXkgSTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsmZ3Q7IHF1b3RlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgZnJvbSB0aGUgc2hlcGhlcmQncyByZXBvcnQ6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS08L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7IFRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBmaXJzdCB2ZXJzaW9uIG9m IEkyUlMgYXJlOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgMSkgbW9kZWwg ZHJpdmVuIGVwaGVtZXJhbCBzdGF0ZSAtIHRoYXQgaXMgZGF0YSBtb2RlbHMgdGhhdCBkbyBub3Q8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBzdXJ2aXZlPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBhIHNvZnR3YXJlIG9yIGhhcmR3YXJlIHJlYm9vdC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUvIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLzwvc3Bhbj48L2E+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDsgMikgYSBzZWN1cmUgcHJvdG9jb2wgLTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcTwvc3Bhbj48L2E+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgdWlyZW1lPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgbnRzLzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsmZ3Q7IDMpIHRyYWNlYWJpbGl0eSAtIGFiaWxpdHkgdG8gcmVjb3JkIGludGVyYWN0aW9u cyBiZXR3ZWVuIEkyUlM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jmd0OyBlbGVtZW50czwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgKENsaWVu dCwgQWdlbnQsIFJvdXRpbmcgc3lzdGVtKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1pMnJzLXRyYWNlYWJpbGl0eS8iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtaTJycy10cmFjZWFiaWxpdHkvPC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyA0KSBu b3RpZmljYXRpb24gcHVibGljYXRpb24gdmlhIHN1YnNjcmlwdGlvbjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLyI+DQo8c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLzwv c3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgNSkgUHJvdG9jb2wgdG8gcGFzcyBEYXRhIGZvciBB bmFseXRpY3M8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IFRoZSBmaXJzdCB2 ZXJzaW9uIG9mIHRoZXNlIHJlcXVpcmVtZW50cyBkb2VzIG5vdCBpbmNsdWRlIGE8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IHNlcGFyYXRlIGFuYWx5dGljYWwgcHJvdG9jb2wg cmVxdWlyZW1lbnRzIGFzIHRoZSBzaW1wbGUgdXNlIGNhc2VzPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgbWF5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OyBwYXNzIGluZm9ybWF0aW9uIHZpYSBxdWVyeS9wb2xsIG9yIHRoZSBub3RpZmlj YXRpb25zLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IFRoZSBJMlJTIHByb3RvY29sIGV4aXN0cyBpbiBhbiBz ZWN1cmUgZW52aXJvbm1lbnQgZGVzY3JpYmVkIGJ5OjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pMnJzLXNlY3VyaXR5LWVudmlyb25tZW50LSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXNlY3VyaXR5LWVudmlyb25tZW50LTwvc3Bhbj48L2E+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgcmVxcy88L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsg RXJpYyAtIFBlcmhhcHMgaXQgd291bGQgYmUgZ29vZCB0byBwb2ludCB0bzo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVp cmVtZW50cyBhbmQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IC4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1pMnJz LXNlY3VyaXR5LWVudmlyb25tZW50LXJlcXMvPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgQmVuIC0gQ2FuIHlv dSB0ZWxsIG1lIGhvdyB0aGUgc2hlcGhlcmQgcmVwb3J0IGNvdWxkIGhhdmUgYmVlbjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IGNsZWFyZXI/PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgVGhlPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSTJycyBwcm90b2NvbCBzZWN1 cml0eSByZXF1aXJlbWVudHMgcmVxdWlyZTombmJzcDsgY29uZmlkZW50aWFsaXR5LDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IGVuY3J5cHRpb24sIHNlY3Vy ZSB0cmFuc3BvcnQsIHByb3RlY3Rpb24gYWdhaW5zdCByZXBsYXkgYXR0YWNrLDwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IHByb3RlY3Rpb24gYWdhaW5zdCBE RG9TIGF0dGFjayAoaWYgcG9zc2libGUpLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IEkg dGhpbmsgbXkgY29uZnVzaW9uIGxpZXMgaW4gdGhlIGZhY3QgdGhhdCwgd2hpbGUgdGhlIHNoZXBo ZXJkJ3M8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHdyaXRldXA8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHN0eWxlcyB0aGlzIGRy YWZ0IGFzIHBhcnQgb2YgdGhlIEkyUlMgcHJvdG9jb2wgcmVxdWlyZW1lbnRzLCB0aGU8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGRyYWZ0PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBpdHNlbGYgY2xhaW1zIHRvIGRlc2NyaWJlIHJl cXVpcmVtZW50cyBmb3IgYSBnZW5lcmFsbHkgdXNlZnVsIHB1Yi1zdWI8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGludGVyZmFjZSB0byBhIHlhbmcgZGF0YXN0b3Jl LiBJdCdzIG5vdCBjbGVhciB0byBtZSBob3cgYW5kIHdoZW4gdGhlPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBJMlJTPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyBwcm90b2NvbCBzZWN1cml0eSByZXF1aXJlbWVudHMgYXBwbHkgdG8g aXQuIElmIHRoZSBkZXNjcmliZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7IGludGVyZmFjZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsgaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGludGVuZGVk IHRvIGJlIHVzZWZ1bCBpbiBjb250ZXh0cyBvdGhlciB0aGFuIEkyUlMgKGFuZCB0aGUgZHJhZnQ8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGV4cGxpY2l0bHk8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHNldHMgdGhhdCBleHBlY3Rh dGlvbiBpbiAyLjIpLCBpdCBuZWVkcyB0byB0YWxrIG1vcmUgZ2VuZXJhbGx5IGFib3V0PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBzZWN1cml0eSBhbmQgcHJpdmFj eS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBGb3IgZXhhbXBsZSwgaXQgbWlnaHQgbWFr ZSBzZW5zZSB0byBzYXkgdGhhdCBjZXJ0YWluIHNlY3VyaXR5PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyByZXF1aXJlbWVudHM8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGFwcGx5IGluIGVudmlyb25tZW50cyB3aGVyZSB0aGUgbWVj aGFuaXNtIG1pZ2h0IGNhcnJ5IHByaXZhY3k8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IHNlbnNpdGl2ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsgZGF0YSwgYW5kIHRoZW4gcG9pbnQgdG8gdGhlIGkycnMgcmVxdWlyZW1lbnRzIGZv ciB3aGVuIHRoZSBtZWNoYW5pc208L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7IGlzIHVzZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 IGluIGFuIEkyUlMgY29udGV4dC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBBIGRpZmZl cmVudCBhcHByb2FjaCBtaWdodCBiZSB0byBtb3JlIHRpZ2h0bHkgY29uc3RyYWluIHRoaXMgdG8g aTJyczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7Jmd0OyBCZW4gLSBPbiBvcHRpbmcgaW4sIG9uY2UgdGhlIHJlY2VpdmUgYWNjZXB0cyBhIHRy YW5zcG9ydCBjb25uZWN0aW9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDsgZnJvbSB0aGUgSTJSUyBzZXJ2ZXIgLSBob3cgaXMgdGhpcyBub3QgYW4gb3B0LWlu IHRvIHJlY2VpdmUgZGF0YT88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7Jmd0OyBXaGF0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZn dDsgYXJlIHlvdSBsb29raW5nIGZvcj88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBJIGd1 ZXNzIHRoYXQgZGVwZW5kcyBvbiB0aGUgdHJhbnNwb3J0LiBUaGUgdHJhbnNwb3J0IHJlcXVpcmVt ZW50cyBzYXk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHRoZTwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgbWVjaGFuaXNtIGhhcyB0 byB3b3JrIG92ZXIgbXVsdGlwbGUgdHJhbnNwb3J0cy4gVGhlIGxhc3QgcGFyYWdyYXBoIGluPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyA0LjIuNDwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgc2F5cyAmcXVvdDtJbiB0aGUgY2FzZSBv ZiBjb25uZWN0aW9uLW9yaWVudGVkIHRyYW5zcG9ydHMuLi4mcXVvdDsgd2hpY2g8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHN1Z2dlc3RzPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyB0aGF0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBub24tY29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3BvcnRzIGFy ZSBwb3NzaWJsZS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBFdmVuIHdpdGggYSBjb25u ZWN0aW9uLW9yaWVudGVkIHRyYW5zcG9ydCwgdGhpcyBtYXkgZGVwZW5kIG9uIGhvdzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgY29ubmVjdGlvbi1tYW5hZ2VtZW50 IGlzIGhhbmRsZWQsIGFuZCB3aGV0aGVyIHRoZSByZWNlaXZlciBtaWdodCBiZTwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgcmVjZWl2aW5nIHRoaW5ncyBpdCBfd2Fu dHNfIHRvIHJlY2VpdmUgb24gdGhlIHNhbWUgdHJhbnNwb3J0LjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWUgSGFyZXM8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IChzaGVwaGVyZCk8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBG cm9tOiBpMnJzIFs8YSBocmVmPSJtYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmkycnMt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSBPbiBCZWhhbGYgT2YgRXJpYyBWb2l0PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgKGV2b2l0KTwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwg TWF5IDA0LCAyMDE2IDc6MjUgUE08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OyBUbzogQmVuIENhbXBiZWxsOyBUaGUgSUVTRzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PmkycnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWky cnMtcHViLXN1Yi1yZXF1aXJlbWVudHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1 aXJlbWVudHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86aTJycy1jaGFpcnNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pMnJz LWNoYWlyc0BpZXRmLm9yZzwvc3Bhbj48L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpo LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PnNoYXJlc0BuZHpoLmNvbTwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtpMnJzXSBCZW4gQ2FtcGJlbGwncyBEaXNj dXNzIG9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgZHJh ZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2OiAod2l0aCBESVNDVVNTIGFuZCBD T01NRU5UKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IEhpIEJlbiw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGFua3Mg Zm9yIHRoZSBjb21tZW50LiZuYnNwOyZuYnNwOyBJbi1saW5lLi4uLjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBGcm9tOiBCZW4gQ2FtcGJlbGwsIE1heSAwNCwgMjAxNiAyOjQ5IFBNPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IERJU0NVU1M6PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgSSBoYXZlIGEgY291cGxlIG9mIHBvaW50cyBJIHdvdWxkIGxpa2UgdG8gZGlzY3Vzcy4gSG9w ZWZ1bGx5IHRoZXk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgY2FuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYmUgcmVz b2x2ZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBlYXNpbHk6PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBBcmUgdGhlcmUgcmVhbGx5IG5vIHJlcXVpcmVtZW50cyBm b3IgcHJpdmFjeSBvciBpbnRlZ3JpdHk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgcHJvdGVjdGlvbj88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBJcyB0aGVyZSBhbiBleHBlY3RhdGlvbiB0aGF0IHRoaXMgbWVjaGFuaXNt IHdvdWxkIGV2ZXIgY2Fycnk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgcHJpdmFjeTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IHNlbnNpdGl2ZSBvciBvdGhlcndpc2Ugc2Vuc2l0aXZlIGluZm9ybWF0aW9uPzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsmZ3Q7IFtlcmljJ3MgY29tbWVudDo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7IFdoZW4gdGhlIHN1YnNjcmlwdGlvbiBpcyBlc3RhYmxpc2hlZCBkeW5hbWljYWxseSB2 aWEgYW4gZXhpc3Rpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jmd0OyB0cmFuc3BvcnQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jmd0OyBzZXNzaW9uICh3aGljaCBpcyBleHBlY3RlZCB0byBiZSB0aGUgZG9taW5hbnQgY2FzZSkg d2UgaGF2ZSB0aGUgc2FtZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7IGV4cGVjdGF0aW9ucyBmb3IgUHJpdmFjeSBhbmQgaW50ZWdyaXR5IGFzIHdvdWxkIGJl IHByb3ZpZGVkIHZpYSBhPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgJnF1b3Q7R0VUJnF1b3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyZndDsgaW5zdGVhZCBvZiBhICZxdW90O1BVU0gmcXVvdDsgb3ZlciB0aGUgc2FtZSB0 cmFuc3BvcnQuJm5ic3A7Jm5ic3A7IFdlIGNvdWxkIGhhdmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyByZXBsaWNhdGVkIGFsbDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IHRoZXNlIHJlcXVpcmVtZW50cywgYnV0IHRo YXQgd2FzIHNlZW4gYXMgdW5uZWNlc3NhcnkgYW5kIGxpa2VseSBsZXNzPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgc2VjdXJlPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgdGhhbiBhZG9wdGluZyBleGlzdGluZyBtZWNo YW5pc21zLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IFdoZW4gdGhlIFN1YnNjcmliZXIgYW5kIFJlY2VpdmVy IGFyZSBkaWZmZXJlbnQsIHRoZW4gdGhlIHRyYW5zcG9ydDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IGNvbm5lY3Rpb24gd2lsbCBoYXZlIGNyZWRlbnRpYWxz IHBhc3NlZCBhcyBwYXJ0IG9mIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsmZ3Q7IGVzdGFibGlzaG1lbnQuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhlc2U8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OyBjcmVkZW50aWFscyB3aWxsIGJlIHVzZWQgYXMgYSBTZWN1cml0eSBHcm9v bWluZyBGaWx0ZXIganVzdCBsaWtlIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7IGFib3ZlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyZndDsgY2FzZSBzbyB0aGF0IHB1c2hlZCBvYmplY3RzIHdpbGwgYmUgZXhjbHVkZWQg ZnJvbSBhbiBVcGRhdGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jmd0OyBOb3RpZmljYXRpb24gYXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OyBwZXIgdGhlIHBlcm1pc3Npb25zIG9mIHRoZSBSZWNlaXZlci4mbmJzcDsmbmJz cDsgKEkuZS4sIHRoaXMgaXMgaWRlbnRpY2FsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jmd0OyZndDsgYmVoYXZpb3IgdG88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGUgYWJvdmUuKSZuYnNwOyZuYnNwOyZuYnNwOyBBcyBzZXZl cmFsIHBlb3BsZSBoYXZlIGhhZCBxdWVzdGlvbnMgYWJvdXQgdGhpcywgdGhlPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgbmV3IHYwNzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IHdpbGwgbWFrZSB0aGlzIGV4cGxpY2l0 IGluIHRoZSBTZWN1cml0eSBzZWN0aW9uLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgRW5kIG9mIGVyaWMncyBjb21tZW50XTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IFN1ZTogVGhlIHRy YW5zcG9ydCBwcm92aWRlcyBmb3IgcHJpdmFjeSwgaW50ZWdyaXR5IHByb3RlY3Rpb24uPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgTW9zdDwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IGNvbmZpZ3VyYXRpb24gaW4gbmV0 d29yayBib3hlcyB3b3VsZCBuZWVkIHByaXZhY3kuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IC0gNC4y LjUsIDJuZCB0byBsYXN0IHBhcmFncmFwaDo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBJIGFtIHN1cnByaXNlZCB0byBmaW5kIHRoYXQsIHdoZW4gdGhlIHJlY2VpdmVy IGlzIG5vdCB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgc3Vic2NyaWJlciw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyB0aGF0IHRoZSByZWNlaXZlciBpcyBleHBlY3RlZCB0byBvcHQtb3V0LiBJdCBzZWVtcyBsaWtl IHNvbWUgZm9ybTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBvZjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG9wdC1pbiBv ciBhZmZpcm1hdGl2ZSBjb25zZW50IHdvdWxkIGJlIG5lZWRlZCBoZXJlLjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsm Z3Q7IFRoZSBxdWVzdGlvbiByZWFsbHkgd2FzIGhvdyBoZWF2eS13ZWlnaHQgc2hvdWxkIHRoZSBt ZWNoYW5pc20gYmUuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZn dDsgVHJhbnNwb3J0cyBiZWVuIGNvbnNpZGVyaW5nIGFyZSBhbGwgZW5jcnlwdGVkLiZuYnNwOyBT byB0aGVyZSBpcyBhbHJlYWR5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDsgYTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7 IGxldmVsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgb2Yg dHJ1c3QgYmV0d2VlbiB0aGUgcGVlcnMuJm5ic3A7IEFuZCBhIHRhcmdldCBjYW4gYWx3YXlzIHB1 bGwgZG93biB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0 OyBjb25uZWN0aW9uIGlmIHRoZXJlIGFyZSBpc3N1ZXMuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSW4gYWRk aXRpb24sIG11bHRpY2FzdCB0cmFuc3BvcnRzIGFyZSB2aWFibGUgZm9yIHNvbWUgZnV0dXJlIGNh c2VzLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IFdlPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgZGlkbid0IHdhbnQg bWVjaGFuaXNtcyB3aGljaCBjb21wbGljYXRlZCB0aGlzIHR5cGUgb2YgaW50ZXJhY3Rpb24sPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgZXNwZWNpYWxseSBp biBhIHdvcmxkIHdoZXJlIGR1bWIgSW9UIGRldmljZXMgbWF5IGJlIGludm9sdmVkLjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsmZ3Q7IFN1ZTogSWYgdGhlIHJlY2VpdmVyIGFjY2VwdHMgYSBzZWN1cmUgdHJhbnNwb3J0 IHNldC11cCBmcm9tIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7IHNlcnZlciwgY2FuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDsgeW91IHByb3ZpZGUgdGhlIHJlYXNvbiB3aHkgdGhpcyBpcyBub3QgYW4gJnF1b3Q7 b3B0LWluJnF1b3Q7IG9uY2UgaXQgcmVjZWl2ZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OyBjb25uZWN0aW9uIGZyb20gdGhlIEkyUlMgYWdlbnQ/PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgQ09NTUVOVDo8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyAtIEdlbmVyYWw6IEkgc3VwcG9ydCBTdGVwaGVuJ3MgRElTQ1VT UzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLTIuMjogV2hhdCBpcyB0aGUgcmVhbCBzY29wZSBv ZiB0aGlzIHdvcms/IElzIGl0IGV4cGVjdGVkIHRvPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHN1cHBsYW50PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgdGhlIG1lbnRpb25lZCBtZWNoYW5pc21zPzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsm Z3Q7IE5vLiZuYnNwOyZuYnNwOyBJdCBpcyBqdXN0IHNob3dpbmcgdGhhdCBtYW55IHNwZWNpYWxp emVkIFB1c2ggbWVjaGFuaXNtIGV4aXN0LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7IFRoaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OyBpcyBub3QgaW50ZW5kZWQgdG8gc3VwcGxhbnQgZXhpc3RpbmcgbWVjaGFuaXNt cywgYWx0aG91Z2ggcGVyaGFwcyBpdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsmZ3Q7IGNhbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7IGhlbHAgYXZvaWQgZnV0dXJlIGRlZGljYXRlZCBzb2x1dGlvbnMuPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLSAyLjM6ICZxdW90O1dlIG5lZWQgYSBuZXcg cHViLXN1YjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRlY2hub2xvZ3kmcXVvdDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBUaGUgc2hlcGhlcmQgd3JpdGUgdXAgbWVudGlvbmVkIGEgZ29hbCB0byB1c2Ug ZXhpc3Rpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgdGVjaG5vbG9naWVzLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IElzIHRoZSBwb2ludCBvZiB0aGlzIHNlbnRlbmNlIHRvIHN1Z2dlc3QgdGhhdCBpcyBub3QgZmVh c2libGU/PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgRXhpc3RpbmcgdGVjaG5vbG9naWVzIGNhbm5vdCBtZWV0 IGFsbCB0aGUgcmVxdWlyZW1lbnRzIHNwZWNpZmllZC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGVyZSBhcmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyB0ZWNobm9sb2d5IGRyYWZ0cyBwcm9ncmVzc2luZyBpbiBO RVRDT05GIHdoaWNoIGNhbi48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLSA0LjEsIDR0aCBwYXJhZ3Jh cGg6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhlIE1BWSBkb2Vz bid0IHNlZW0gcmlnaHQtLWlzIHRoaXMgYSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0IHRoZTwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHN1YnNjcmliZXIgbWF5IGhhdmUg dG8gcmVzdWJzY3JpYmUsIG9yIGEgcmVxdWlyZW1lbnQgb2YgdGhlIGZvcm08L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhhdDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBzZXJ2aWNlIE1BWSBmb3JjZSB0aGUgc3Vi c2NyaWJlciB0byByZXN1YnNjcmliZT8gKEJlIGNhcmVmdWw8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgd2l0aDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE1BWXMgaW4gcmVxdWlyZW1lbnRzIGxhbmd1YWdlLS10aGV5IGlt cGx5IHVuZXhwZWN0ZWQgdGhpbmdzLiBGb3I8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBleGFtcGxlLCBzZXZlcmFsIHJlcXVpcmVtZW50cyBzYXkgYSBTVUJTQ1JJQkUg TUFZIGRvIHNvbWV0aGluZy0tZG88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyB0aG9zZSBpbXBseSB0aGF0IHRoZSBzZXJ2aWNlIE1VU1QgYWxsb3cgdGhlIHN1YnNjcmli ZXIgdG8gZG8gaXQgPyk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBHb29kIHBvaW50LiZuYnNwOyZuYnNwOyBS ZXdvcmRlZCBpbiB2MDcuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IC0tIDQuMi4yLCB0aGlyZCBidWxs ZXQ6IFRoZSBwcmV2aW91cyBzZWN0aW9uIHNhaWQgZGFtcGVuaW5nIHBlcmlvZHM8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBNVVNUIGJlIHN1cHBvcnRlZC48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OyBZZXMsIGJ1dCBkYW1wZW5pbmcgaXMgbmV2ZXIgZm9yIHBlcmlvZGljIHN1YnNj cmlwdGlvbnMuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLSA0LjIu MSwgdGhpcmQgcGFyYWdyYXBoOiBUaGlzIGlzIGEgYml0IGFtYmlndW91cy4gSSB0aGluayBpdCBt ZWFuczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0 bzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNoYW5nZSB0aGUgd2hh dCBzdWJ0cmVlcyB0aGUgc3Vic2NyaXB0aW9uIGFwcGxpZXMgdG8sIGJ1dCBjb3VsZCBiZTwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVycHJldGVkIHRvIGNoYW5n ZSB0aGUgc3VidHJlZXMgdGhlbXNlbHZlcy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBGaXhlZDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IC0gNC4yLjYuNDogV291bGQgYSBtZWNo YW5pc20gdGhhdCBhbGxvd2VkIG91dC1vZi1vcmRlciBkZWxpdmVyeSBidXQ8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBnYXZlIHRoZSBzdWJzY3JpYmVyIGEgd2F5IHRv IHJlY29uc3RydWN0IHRoZSBvcmRlciBmdWxmaWxsIHRoaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyByZXF1aXJlbWVudD88L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBZ ZXMsIHRoZSB0aW1lc3RhbXAgd2l0aGluIGFuIHVwZGF0ZS4mbmJzcDsgQnV0IHRoaXMgcmVxdWly ZW1lbnQgdGFyZ2V0cyBhPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgc3BlY2lmaWMgb2JqZWN0IGluIGEgc3BlY2lmaWMgc3Vic2NyaXB0aW9uLiZuYnNwOyBT byB0aGVyZSBzaG91bGQgYmUgbm88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OyBpc3N1ZXMuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgTml0czo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAtIFRoZSBz aGVwaGVyZCB3cml0ZSB1cCBzdWdnZXN0cyB0aGlzIGlzIHN0YW5kYXJkcyB0cmFjay4gVGhlIGRy YWZ0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYW5kIHRyYWNrZXIg Ym90aCBzYXkgaW5mb3JtYXRpb25hbC4gUGxlYXNlIHVwZGF0ZSB0aGUgc2hlcGhlcmQgd3JpdDwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB1cC48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OyBGaXhlZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IC0zLCBsYXN0IHBhcmFncmFwaDogV2hhdCdzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSAm cXVvdDtQdXNoJnF1b3Q7IGFuZCBhbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsmZ3Q7ICZxdW90O1VwZGF0ZSZxdW90Oz88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBSZXdvcmRl ZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IC00LjE6IEEgZm9yd2Fy ZCByZWZlcmVuY2UgdG8gdGhlIHN1YnNjcmlwdGlvbiBRb1Mgc2VjdGlvbiB3b3VsZCBiZTwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IGhlbHBmdWwuPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyZndDsgTW92ZWQgdGhlIHJlcXVpcmVtZW50IGluIHF1ZXN0aW9uIHRvIDQuMi42Ljwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IC0tIExhc3QgcGFyYWdyYXBo LCBsYXN0IHNlbnRlbmNlOiBTZW50ZW5jZSBkb2Vzbid0IHBhcnNlLjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7 IEZpeGVkPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAtIDQuMi44LCB0aGlyZCBwYXJhZ3JhcGg6 IEkgZG9uJ3QgdGhpbmsgdGhhdCBzaG91bGQgYmUgYSAyMTE5IE1BWTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7 IEZpeGVkPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGFua3MgYWdhaW4g Zm9yIHRoZSByZXZpZXchPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBFcmlj PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDsgaTJycyBtYWlsaW5nIGxpc3Q8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzppMnJzQGll dGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQo8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmkycnNAaWV0 Zi5vcmc8L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmbmJz cDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy cyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczwvc3Bhbj48L2E+Jmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycyI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPC9zcGFuPjwvYT48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_167d2323d3264287a30c36c1950984b5XCHRTP013ciscocom_-- From nobody Mon May 16 08:06:48 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F1312D0F2 for ; Mon, 16 May 2016 08:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCc-GpwuGsAx for ; Mon, 16 May 2016 08:06:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8C0F312D197 for ; Mon, 16 May 2016 08:06:43 -0700 (PDT) Received: from [172.20.10.3] (mobile-166-170-033-119.mycingular.net [166.170.33.119] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4GF6crK039845 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 16 May 2016 10:06:39 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-170-033-119.mycingular.net [166.170.33.119] (may be forged) claimed to be [172.20.10.3] From: "Ben Campbell" To: "Eric Voit" Date: Mon, 16 May 2016 11:06:31 -0400 Message-ID: In-Reply-To: <167d2323d3264287a30c36c1950984b5@XCH-RTP-013.cisco.com> References: <9e9692bd22a041ba91e39a9f7dce8c9e@XCH-RTP-013.cisco.com> <00a901d1ad2e$f8a21e10$e9e65a30$@ndzh.com> <167d2323d3264287a30c36c1950984b5@XCH-RTP-013.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "i2rs@ietf.org" , "i2rs-chairs@ietf.org" , Alia Atlas , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , The IESG , Susan Hares Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 15:06:47 -0000 That works for me. I will clear the DISCUSS. Thanks! Ben. On 16 May 2016, at 9:46, Eric Voit (evoit) wrote: > Hi Ben, > > > > There is no issue with rewording to a requirement rather than an = > intro. The second sentence below has been changed to meet 2119. > > > > Some uses of this Subscription Service will push privacy-sensitive = > updates and metadata. For privacy-sensitive deployments, subscription = > information MUST be bound within secure, encrypted transport layer = > mechanisms. For example if NETCONF is used as transport, then = > [RFC5539] would be a valid option to secure the transported = > information. The Subscription Service can also be used with emerging = > privacy-sensitive deployment contexts as well. As an example, = > deployments based on [i2rs-usecase] would apply these requirements in = > conjunction with those documented within [i2rs-environment-security] = > and [i2rs-protocol-security] to secure ephemeral state information = > being pushed from a Network Element. > > > > Eric > > > >> From: Ben Campbell, May 15, 2016 3:18 PM > >> > >> Hi Eric and Sue, > >> > >> Thanks for the change, and I think it's on the right track. But I = >> notice most of the > >> other requirements, in the security considerations section and in = >> other sections, > >> use 2119 keywords. Is there a reason not to do so here? Would it be = >> reasonable > >> to say that any embodiment of these requirements MUST support a = >> transport > >> that provides encryption and integrity protection, and such a = >> transport MUST be > >> used when carrying privacy-sensitive information? > >> > >> Thanks! > >> > >> Ben. > >> > >> > >> On 13 May 2016, at 10:49, Susan Hares wrote: > >> > >>> Eric: > >>> > >>> > >>> > >>> Thanks for jumping in and putting out text that resolves Ben=E2=80=99= s > >>> comments. This text works for me with one addition. Add reference = >>> to > >>> the security environment draft. > >>> > >>> > >>> > >>> Sue > >>> > >>> > >>> > >>> From: Eric Voit (evoit) [mailto:evoit@cisco.com] > >>> Sent: Friday, May 13, 2016 11:26 AM > >>> To: Susan Hares; Ben Campbell; Alia Atlas = >>> (akatlas@gmail.com) > >>> Cc: The IESG; i2rs@ietf.org; > >>> draft-ietf-i2rs-pub-sub-requirements@ietf.org; = >>> i2rs-chairs@ietf.org > >>> Subject: RE: [i2rs] Ben Campbell's Discuss on > >>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > >>> > >>> > >>> > >>> Hi Ben, > >>> > >>> > >>> > >>> I have added the text below as the lead-in to section 4.2.5. I > >>> believe this meets the intents of your suggestions below. > >>> > >>> > >>> > >>> Hi Susan & Alia, > >>> > >>> > >>> > >>> I have uploaded v08 of > >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements= / > >>> > >>> If Ben concurs with the text below, I am not aware of any remaining > >>> discuss items. > >>> > >>> > >>> > >>> Thanks everyone for your reviews, > >>> > >>> Eric, Alex, & Alberto > >>> > >>> > >>> 4.2.5. Security Requirements > >>> > >>> Some uses of this Subscription Service will push = >>> privacy-sensitive > >>> updates and metadata. Good deployment practices will bind this > >>> generated information within secure, encrypted transport layer > >>> mechanisms. For example if NETCONF is used as transport, then > >>> [RFC5539] would be a valid option to secure the transported > >>> information. The Subscription Service can also be used with > >>> emerging > >>> deployment contexts as well. As an example, deployments based on > >>> [i2rs-usecase] can apply these requirements in conjunction with > >>> those > >>> documented within [i2rs-protocol-security] to secure ephemeral > >>> state > >>> information being pushed from a Network Element. > >>> > >>> > >>> > >>> > >>> From: Susan Hares [mailto:shares@ndzh.com] > >>> Sent: Friday, May 06, 2016 7:09 PM > >>> To: Ben Campbell > >>> Cc: Eric Voit (evoit); The IESG; = >>> i2rs@ietf.org; > >>> draft-ietf-i2rs-pub-sub-requirements@ietf.org; = >>> i2rs-chairs@ietf.org > >>> Subject: Re: [i2rs] Ben Campbell's Discuss on > >>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > >>> > >>> > >>> > >>> Ben: > >>> > >>> > >>> > >>> This is wise idea. I will suggest some text to Eric and you in the > >>> morning. > >>> > >>> > >>> > >>> Sue > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > >>> > >>> -------- Original message -------- > >>> > >>> From: Ben Campbell > > >>> > >>> Date: 5/6/2016 2:38 PM (GMT-06:00) > >>> > >>> To: Susan Hares > > >>> > >>> Cc: Eric Voit >, The IESG = >>> >, > >>> i2rs@ietf.org, = >>> draft-ietf-i2rs-pub-sub-requirements@ietf.org, > >>> i2rs-chairs@ietf.org > >>> > >>> Subject: Re: [i2rs] Ben Campbell's Discuss on > >>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > >>> > >>> > >>> > >>> Hi Susan, > >>> > >>> To be clear, I do not object to the wider context per se. My concern > >>> is > >>> that the security and privacy requirements are left as implicit, = >>> based > >>> on the more narrow i2rs/netconf context. I only mentioned the > >>> potential > >>> of restricting the contextas one possible way forward; I am = >>> certainly > >>> not wedded to it. > >>> > >>> My suggestion for a way forward would be to document the high level > >>> security and privacy requirements in this document. IIUC, the larger > >>> context includes potentially unknown contexts, so some of this may > >>> need > >>> to be conditional. For example, language like the following might be > >>> helpful (this is just an example--I don't mean to say that it is = >>> true > >>> or > >>> applicable): > >>> > >>> "Some uses of this mechanism may carry privacy-sensitive > >>> information, > >>> or generate privacy-sensitive metadata through the subscription > >>> mechanism. In contexts where this is true, the following = >>> requirements > >>> apply..." > >>> > >>> It might also be reasonable to say that, for the context of i2rs, > >>> these > >>> requirements are documented in [references] and are expected to be > >>> fulfilled by the [transport and or protocol] > >>> > >>> Eric's email also suggested that the actual transport of data from = >>> the > >>> Yang datastore may be out of scope for these requirements. I don't > >>> object to that, either, as long as it is clear and explicit, = >>> although > >>> it > >>> would be good to point to where it is _in_ scope. > >>> > >>> Thanks! > >>> > >>> Ben. > >>> > >>> On 6 May 2016, at 1:06, Susan Hares wrote: > >>> > >>>> Ben: > >>>> > >>>> This is the first of the "re-use" management protocols. The > >>>> requirements > >>>> are set-up so that we can suggest additions to the NETCONF and > >>>> RESTCONF for > >>>> this first of I2RS. > >>>> > >>>> The I2RS ephemeral work, pub/sub, traceability, and security are > >>>> target at > >>>> the I2RS protocol definition with the I2RS use case. However, = >>>> since > >>>> these > >>>> are general additions to NETCONF/RESTCONF, this work can be used > >>>> elsewhere. > >>>> > >>>> I think the text you are highlighting has this larger context. = >>>> Now, > >>>> one of > >>>> the really important things to chat with Alia and Benoit is how do = >>>> we > >>>> handle > >>>> the wider use case. Do we mention the wider context? > >>>> > >>>> The WG thought mentioning it was important. > >>>> > >>>> Sue > >>>> > >>>> -----Original Message----- > >>>> From: Ben Campbell [mailto:ben@nostrum.com] > >>>> Sent: Thursday, May 05, 2016 5:31 PM > >>>> To: Susan Hares > >>>> Cc: Eric Voit; The IESG; i2rs@ietf.org; > >>>> draft-ietf-i2rs-pub-sub-requirements@ietf.org; = >>>> i2rs-chairs@ietf.org > >>>> Subject: Re: [i2rs] Ben Campbell's Discuss on > >>>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) > >>>> > >>>> On 5 May 2016, at 5:15, Susan Hares wrote: > >>>> > >>>>> Eric, Ben and IESG members: > >>>>> > >>>>> > >>>>> > >>>>> The pub/sub requirements are part of a 5 part requirements. May = >>>>> I > >>>>> quote > >>>>> from the shepherd's report: > >>>>> > >>>>> --------------------- > >>>>> > >>>>> The requirements for the first version of I2RS are: > >>>>> > >>>>> 1) model driven ephemeral state - that is data models that do not > >>>>> survive > >>>>> > >>>>> a software or hardware reboot. > >>>>> > >>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > >>>>> > >>>>> > >>>>> > >>>>> 2) a secure protocol - > >>>>> > >>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-= req > >>>>> uireme > >>>>> nts/ > >>>>> > >>>>> > >>>>> > >>>>> 3) traceability - ability to record interactions between I2RS > >>>>> elements > >>>>> > >>>>> (Client, Agent, Routing system) > >>>>> > >>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ > >>>>> > >>>>> > >>>>> > >>>>> 4) notification publication via subscription > >>>>> > >>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requiremen= ts/ > >>>>> > >>>>> > >>>>> > >>>>> 5) Protocol to pass Data for Analytics > >>>>> > >>>>> The first version of these requirements does not include a > >>>>> > >>>>> separate analytical protocol requirements as the simple use cases > >>>>> may > >>>>> > >>>>> pass information via query/poll or the notifications. > >>>>> > >>>>> > >>>>> > >>>>> The I2RS protocol exists in an secure environment described by: > >>>>> > >>>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environme= nt- > >>>>> reqs/ > >>>>> > >>>>> > >>>>> > >>>>> ------------------------- > >>>>> > >>>>> > >>>>> > >>>>> Eric - Perhaps it would be good to point to: > >>>>> > >>>>> . draft-ietf-i2rs-protocol-security-requirements and > >>>>> > >>>>> . draft-ietf-i2rs-security-environment-reqs/ > >>>>> > >>>>> > >>>>> > >>>>> Ben - Can you tell me how the shepherd report could have been > >>>>> clearer? > >>>>> The > >>>>> I2rs protocol security requirements require: confidentiality, > >>>>> encryption, secure transport, protection against replay attack, > >>>>> protection against DDoS attack (if possible). > >>>> > >>>> I think my confusion lies in the fact that, while the shepherd's > >>>> writeup > >>>> styles this draft as part of the I2RS protocol requirements, the > >>>> draft > >>>> itself claims to describe requirements for a generally useful = >>>> pub-sub > >>>> interface to a yang datastore. It's not clear to me how and when = >>>> the > >>>> I2RS > >>>> protocol security requirements apply to it. If the described > >>>> interface > >>>> is > >>>> intended to be useful in contexts other than I2RS (and the draft > >>>> explicitly > >>>> sets that expectation in 2.2), it needs to talk more generally = >>>> about > >>>> security and privacy. > >>>> > >>>> For example, it might make sense to say that certain security > >>>> requirements > >>>> apply in environments where the mechanism might carry privacy > >>>> sensitive > >>>> data, and then point to the i2rs requirements for when the = >>>> mechanism > >>>> is used > >>>> in an I2RS context. > >>>> > >>>> A different approach might be to more tightly constrain this to = >>>> i2rs > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Ben - On opting in, once the receive accepts a transport = >>>>> connection > >>>>> from the I2RS server - how is this not an opt-in to receive data? > >>>>> What > >>>>> are you looking for? > >>>> > >>>> I guess that depends on the transport. The transport requirements = >>>> say > >>>> the > >>>> mechanism has to work over multiple transports. The last paragraph = >>>> in > >>>> 4.2.4 > >>>> says "In the case of connection-oriented transports..." which > >>>> suggests > >>>> that > >>>> non-connection-oriented transports are possible. > >>>> > >>>> Even with a connection-oriented transport, this may depend on how > >>>> connection-management is handled, and whether the receiver might be > >>>> receiving things it _wants_ to receive on the same transport. > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Sue Hares > >>>>> > >>>>> (shepherd) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit > >>>>> (evoit) > >>>>> Sent: Wednesday, May 04, 2016 7:25 PM > >>>>> To: Ben Campbell; The IESG > >>>>> Cc: i2rs@ietf.org; = >>>>> draft-ietf-i2rs-pub-sub-requirements@ietf.org; > >>>>> i2rs-chairs@ietf.org; = >>>>> shares@ndzh.com > >>>>> Subject: Re: [i2rs] Ben Campbell's Discuss on > >>>>> draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and = >>>>> COMMENT) > >>>>> > >>>>> > >>>>> > >>>>> Hi Ben, > >>>>> > >>>>> > >>>>> > >>>>> Thanks for the comment. In-line.... > >>>>> > >>>>> > >>>>> > >>>>>> From: Ben Campbell, May 04, 2016 2:49 PM > >>>>> > >>>>>> ------------------------------------------------------------------= ---- > >>>>> > >>>>>> DISCUSS: > >>>>> > >>>>>> ------------------------------------------------------------------= ---- > >>>>> > >>>>>> > >>>>> > >>>>>> I have a couple of points I would like to discuss. Hopefully they > >>>>>> can > >>>>> > >>>>>> be resolved > >>>>> > >>>>>> easily: > >>>>> > >>>>>> > >>>>> > >>>>>> Are there really no requirements for privacy or integrity > >>>>>> protection? > >>>>> > >>>>>> Is there an expectation that this mechanism would ever carry > >>>>>> privacy > >>>>> > >>>>>> sensitive or otherwise sensitive information? > >>>>> > >>>>> > >>>>> > >>>>> [eric's comment: > >>>>> > >>>>> When the subscription is established dynamically via an existing > >>>>> transport > >>>>> session (which is expected to be the dominant case) we have the = >>>>> same > >>>>> expectations for Privacy and integrity as would be provided via a > >>>>> "GET" > >>>>> instead of a "PUSH" over the same transport. We could have > >>>>> replicated all > >>>>> these requirements, but that was seen as unnecessary and likely = >>>>> less > >>>>> secure > >>>>> than adopting existing mechanisms. > >>>>> > >>>>> > >>>>> > >>>>> When the Subscriber and Receiver are different, then the transport > >>>>> connection will have credentials passed as part of the > >>>>> establishment. > >>>>> These > >>>>> credentials will be used as a Security Grooming Filter just like = >>>>> the > >>>>> above > >>>>> case so that pushed objects will be excluded from an Update > >>>>> Notification as > >>>>> per the permissions of the Receiver. (I.e., this is identical > >>>>> behavior to > >>>>> the above.) As several people have had questions about this, = >>>>> the > >>>>> new v07 > >>>>> will make this explicit in the Security section. > >>>>> > >>>>> End of eric's comment] > >>>>> > >>>>> > >>>>> > >>>>> Sue: The transport provides for privacy, integrity protection. > >>>>> Most > >>>>> configuration in network boxes would need privacy. > >>>>> > >>>>> > >>>>> > >>>>>> - 4.2.5, 2nd to last paragraph: > >>>>> > >>>>>> I am surprised to find that, when the receiver is not the > >>>>>> subscriber, > >>>>> > >>>>>> that the receiver is expected to opt-out. It seems like some form > >>>>>> of > >>>>> > >>>>>> opt-in or affirmative consent would be needed here. > >>>>> > >>>>> > >>>>> > >>>>> The question really was how heavy-weight should the mechanism be. > >>>>> Transports been considering are all encrypted. So there is = >>>>> already > >>>>> a > >>>>> level > >>>>> of trust between the peers. And a target can always pull down the > >>>>> connection if there are issues. > >>>>> > >>>>> > >>>>> > >>>>> In addition, multicast transports are viable for some future = >>>>> cases. > >>>>> We > >>>>> didn't want mechanisms which complicated this type of interaction, > >>>>> especially in a world where dumb IoT devices may be involved. > >>>>> > >>>>> > >>>>> > >>>>> Sue: If the receiver accepts a secure transport set-up from the > >>>>> server, can > >>>>> you provide the reason why this is not an "opt-in" once it = >>>>> receives > >>>>> the > >>>>> connection from the I2RS agent? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> ------------------------------------------------------------------= ---- > >>>>> > >>>>>> COMMENT: > >>>>> > >>>>>> ------------------------------------------------------------------= ---- > >>>>> > >>>>>> > >>>>> > >>>>>> - General: I support Stephen's DISCUSS > >>>>> > >>>>>> > >>>>> > >>>>>> -2.2: What is the real scope of this work? Is it expected to > >>>>>> supplant > >>>>> > >>>>>> the mentioned mechanisms? > >>>>> > >>>>> > >>>>> > >>>>> No. It is just showing that many specialized Push mechanism = >>>>> exist. > >>>>> This > >>>>> is not intended to supplant existing mechanisms, although perhaps = >>>>> it > >>>>> can > >>>>> help avoid future dedicated solutions. > >>>>> > >>>>>> - 2.3: "We need a new pub-sub > >>>>> > >>>>>> technology" > >>>>> > >>>>>> The shepherd write up mentioned a goal to use existing > >>>>>> technologies. > >>>>> > >>>>>> Is the point of this sentence to suggest that is not feasible? > >>>>> > >>>>> > >>>>> > >>>>> Existing technologies cannot meet all the requirements specified. > >>>>> There are > >>>>> technology drafts progressing in NETCONF which can. > >>>>> > >>>>> > >>>>> > >>>>>> - 4.1, 4th paragraph: > >>>>> > >>>>>> The MAY doesn't seem right--is this a statement of fact that the > >>>>> > >>>>>> subscriber may have to resubscribe, or a requirement of the form > >>>>>> that > >>>>> > >>>>>> the service MAY force the subscriber to resubscribe? (Be careful > >>>>>> with > >>>>> > >>>>>> MAYs in requirements language--they imply unexpected things. For > >>>>> > >>>>>> example, several requirements say a SUBSCRIBE MAY do = >>>>>> something--do > >>>>> > >>>>>> those imply that the service MUST allow the subscriber to do it = >>>>>> ?) > >>>>> > >>>>> > >>>>> > >>>>> Good point. Reworded in v07. > >>>>> > >>>>> > >>>>> > >>>>>> -- 4.2.2, third bullet: The previous section said dampening = >>>>>> periods > >>>>> > >>>>>> MUST be supported. > >>>>> > >>>>> > >>>>> > >>>>> Yes, but dampening is never for periodic subscriptions. > >>>>> > >>>>>> - 4.2.1, third paragraph: This is a bit ambiguous. I think it = >>>>>> means > >>>>>> to > >>>>> > >>>>>> change the what subtrees the subscription applies to, but could = >>>>>> be > >>>>> > >>>>>> interpreted to change the subtrees themselves. > >>>>> > >>>>> > >>>>> > >>>>> Fixed > >>>>> > >>>>>> - 4.2.6.4: Would a mechanism that allowed out-of-order delivery = >>>>>> but > >>>>> > >>>>>> gave the subscriber a way to reconstruct the order fulfill this > >>>>> requirement? > >>>>> > >>>>> > >>>>> > >>>>> Yes, the timestamp within an update. But this requirement targets = >>>>> a > >>>>> specific object in a specific subscription. So there should be no > >>>>> issues. > >>>>> > >>>>>> Nits: > >>>>> > >>>>>> - The shepherd write up suggests this is standards track. The = >>>>>> draft > >>>>> > >>>>>> and tracker both say informational. Please update the shepherd = >>>>>> writ > >>>>>> up. > >>>>> > >>>>> > >>>>> > >>>>> Fixed > >>>>> > >>>>>> -3, last paragraph: What's the difference between a "Push" and an > >>>>> "Update"? > >>>>> > >>>>> > >>>>> > >>>>> Reworded > >>>>> > >>>>>> -4.1: A forward reference to the subscription QoS section would = >>>>>> be > >>>>> helpful. > >>>>> > >>>>> > >>>>> > >>>>> Moved the requirement in question to 4.2.6. > >>>>> > >>>>>> -- Last paragraph, last sentence: Sentence doesn't parse. > >>>>> > >>>>> > >>>>> > >>>>> Fixed > >>>>> > >>>>>> > >>>>> > >>>>>> - 4.2.8, third paragraph: I don't think that should be a 2119 MAY > >>>>> > >>>>> > >>>>> > >>>>> Fixed > >>>>> > >>>>> Thanks again for the review! > >>>>> > >>>>> Eric > >>>>> > >>>>> _______________________________________________ > >>>>> > >>>>> i2rs mailing list > >>>>> > >>>>> i2rs@ietf.org > >>>>> > >>>>> > >>>>> https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon May 16 08:09:55 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B6A12D0B1; Mon, 16 May 2016 08:09:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160516150953.16725.92691.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 08:09:53 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-pub-sub-requirements-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 15:09:53 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2rs-pub-sub-requirements-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS points. The comments below are from my initial ballot. I think you've probably addressed most of them, but I am leaving them for reference: - General: I support Stephen's DISCUSS -2.2: What is the real scope of this work? Is it expected to supplant the mentioned mechanisms? - 2.3: "We need a new pub-sub technology" The shepherd write up mentioned a goal to use existing technologies. Is the point of this sentence to suggest that is not feasible? - 4.1, 4th paragraph: The MAY doesn't seem right--is this a statement of fact that the subscriber may have to resubscribe, or a requirement of the form that the service MAY force the subscriber to resubscribe? (Be careful with MAYs in requirements language--they imply unexpected things. For example, several requirements say a SUBSCRIBE MAY do something--do those imply that the service MUST allow the subscriber to do it ?) -- 4.2.2, third bullet: The previous section said dampening periods MUST be supported. - 4.2.1, third paragraph: This is a bit ambiguous. I think it means to change the what subtrees the subscription applies to, but could be interpreted to change the subtrees themselves. - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but gave the subscriber a way to reconstruct the order fulfill this requirement? Nits: - The shepherd write up suggests this is standards track. The draft and tracker both say informational. Please update the shepherd writ up. -3, last paragraph: What's the difference between a "Push" and an "Update"? -4.1: A forward reference to the subscription QoS section would be helpful. -- Last paragraph, last sentence: Sentence doesn't parse. - 4.2.8, third paragraph: I don't think that should be a 2119 MAY From nobody Tue May 17 00:12:08 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E3512B05C; Tue, 17 May 2016 00:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-iw8x2qpkw1; Tue, 17 May 2016 00:12:02 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860CF12D09C; Tue, 17 May 2016 00:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7582; q=dns/txt; s=iport; t=1463469122; x=1464678722; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jpmPW3Ct0ykNElmxg8plB3dPxgsxJkHyOwFMrJZh4CM=; b=EUU+s6BWIqv0i0ENYFFD3/38W+j9tMfHJHrORQLvFF2dbNuLpGJ8wt6N MVaH0QhMXlkfP6adYxFXDLnZdd7DinUs7NAfoTQhjss8K8I7alLi6r8gO Y22quynrfTdPRKVViXZdnefnntcLW06jweNKUWYY5V+Hd282BqquG1X93 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiAgAmwzpX/5FdJa1UCYM3VX4GuWoBD?= =?us-ascii?q?YF2IoVvAoEyOBQBAQEBAQEBZSeEQgEBAQQ6PwwEAgEIEQEDAQEBHhAyFwYIAgQ?= =?us-ascii?q?BDQUIiCcOwiwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYlhE2EEQcKAYV1BZgoA?= =?us-ascii?q?Y4WgXCET4hhj0ABHgEBQoNsbgGGUDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="273712276" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2016 07:12:01 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4H7C1D3005779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 07:12:01 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 02:12:00 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Tue, 17 May 2016 02:12:00 -0500 From: "Les Ginsberg (ginsberg)" To: "Joe Clarke (jclarke)" , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQBnClYAAieCg0AALuo+AAACzD3QAAvztwAARQFW8AARa8OAAK0WXnA= Date: Tue, 17 May 2016 07:12:00 +0000 Message-ID: References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> <30733d2a0880449dbd5cf930c48ad6be@XCH-ALN-001.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.97.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 07:12:04 -0000 Thanx Joe - looks good. Les > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Friday, May 13, 2016 8:36 AM > To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.or= g > Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >=20 > On 5/13/16 08:17, Les Ginsberg (ginsberg) wrote: > > Joe - > > > > Something like the attached file perhaps? >=20 > Thanks. We have posted rev -10 of this draft that should address all of = your > comments. >=20 > Joe >=20 > > > > Les > > > > > >> -----Original Message----- > >> From: Joe Clarke (jclarke) > >> Sent: Wednesday, May 11, 2016 3:21 PM > >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >> i2rs@ietf.org > >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >> > >> On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: > >>> Joe - > >>> > >>> Yes - this looks better to me. > >>> > >>> What about the "shadow boxes" for Applications/Clients? > >> > >> Do you have an example draft I could look at for that? > >> > >> Joe > >> > >>> > >>> Les > >>> > >>> > >>>> -----Original Message----- > >>>> From: Joe Clarke (jclarke) > >>>> Sent: Wednesday, May 11, 2016 8:19 AM > >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >>>> i2rs@ietf.org > >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >>>> > >>>> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: > >>>>> Joe - > >>>>> > >>>>> Apologies for the delayed response. I am a victim of my own email > >>>>> infilters. :-( Inline. > >>>> > >>>> Thanks, Les. Have a look at > >>>> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- > >>>> 10.diff.html > >>>> . I added a new line to show the flow in both directions. > >>>> > >>>> Joe > >>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Joe Clarke (jclarke) > >>>>>> Sent: Friday, April 29, 2016 10:44 AM > >>>>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >>>>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >>>>>> i2rs@ietf.org > >>>>>> Subject: Re: [i2rs] RtgDir review: > >>>>>> draft-ietf-i2rs-traceability-08 > >>>>>> > >>>>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: > >>>>>>> Summary: This document is a well written document - easy to > >>>> understand. > >>>>>>> My compliments to the authors. I believe there is one minor > >>>>>>> issue which I would like to see addressed before publication. > >>>>>> > >>>>>> Thanks for your comments and feedback, Les. Please see below for > >>>>>> some replies and questions. > >>>>>> > >>>>>>> In Section 5.2 there is a definition of the information which is > >>>>>>> required to be kept by an I2RS Agent for each I2RS interaction. > >>>>>>> I would like to see the addition of "Request State" into this lis= t. > >>>>>>> Operationally each request could be in one of the following state= s: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> * Enqueued (or pending if you prefer) > >>>>>>> > >>>>>>> * In process > >>>>>>> > >>>>>>> * Completed > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The lack of such a state seems to imply that both the queue time > >>>>>>> and the processing time are insignificant. While I think this > >>>>>>> may be the case for many requests, it will not always be the > >>>>>>> case. In queue time may be lengthy due to other load on the > >>>>>>> Agent. Also, some requests - particularly destructive requests > >>>>>>> which involve cleanup of resources - may take a significant > >>>>>>> amount of time to > >> complete. > >>>>>> > >>>>>> Good observation. Traceability was aimed mainly at the > >>>>>> termination of the request, but I like the idea of tracing the sta= te > machine. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Along with this an additional timestamp - Processing Initiated - > >>>>>>> would be useful to indicate when processing of the request > >>>>>>> actually > >>>> began. > >>>>>> > >>>>>> I don't know we need a new timestamp. Perhaps we just need to > >>>> rename > >>>>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" > >> and > >>>>>> "End Timestamp" to denote the time within the current state. > >>>>>> What do you think? > >>>>> > >>>>> [Les:] My intent was to log the time at which the request began > >>>>> processing > >>>> so that you can see whether a long delay in completion was due to > >>>> enqueue delay or actual lengthy processing time. I am not adamant > >>>> about this so if you want to stay with the two timestamps that is OK= . > >>>>> > >>>>>> > >>>>>>> s/Some notable elements on the architecture/ Some notable > >> elements > >>>>>>> of the architecture > >>>>>> > >>>>>> Fixed. Thanks! > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Figure 1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Not clear to me why Application IDs start at 0 but Client IDs sta= rt at > 1. > >>>>>> > >>>>>> Ah. The numbers there are not IDs. They are the number of > >>>>>> actual things in the boxes above. For Applications, there may be > >>>>>> 0 to N for a given client. For Clients, you need at least 1. > >>>>>> Does that make > >> sense? > >>>>>> > >>>>> [Les:] Maybe you want to use "shadows" on the boxes to indicate > >>>>> there > >>>> can be multiple Application boxes and multiple Client boxes? > >>>>> What you say makes sense but I do not intuit that when I look at > >>>>> the ASSCII > >>>> art. > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Figure 1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Is the text "Op Data V" between I2RS Agent box and Routing > >>>>>>> System box intentional? > >>>>>> > >>>>>> Yes. The 'V' is meant to be an arrow head pointed down. The > >>>>>> request and data go from Client to Agent whereas the Response > >>>>>> goes from Agent to Client. > >>>>>> > >>>>>> We are open to suggestions on how to make this clearer. > >>>>> > >>>>> [Les:] I think it would be clearer if you had two lines - one > >>>>> flowing down > >>>> associated with the Op Data and one flowing up with the result. > >>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Section 5.2 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Secondary Identity > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> This is defined to be "opaque" yet if not provided the agent is > >>>>>>> supposed to insert "an UNAVAILABLE value". This seems to be a > >>>>>>> contradiction unless we have a publicly defined value that > >>>>>>> clients are prohibited from using. Absent that you would need a > >>>>>>> "Secondary > >>>> Identity Valid" indicator. > >>>>>> > >>>>>> Good observation. I think it's fine to say that this field must > >>>>>> be logged. If there is no application, then the field will be > >>>>>> logged as empty. If there is an application, then whatever value > >>>>>> is provided will be logged. > >>>>>> > >>>>>> Do you feel strongly that we need a field to indicate Application > >> Present? > >>>>>> > >>>>> [Les:] I am fine w your changes. > >>>>> > >>>>> Les > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Section 7.4 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> s/establish an vendor-agnostic/establish a vendor-agnostic > >>>>>> > >>>>>> Fixed. Thanks! > >>>>>> > >>>>>> Joe > >>> > > From nobody Tue May 17 09:21:38 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E64412D98F for ; Tue, 17 May 2016 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWp-eR_MwJZp for ; Tue, 17 May 2016 09:21:29 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6FA12D6AD for ; Tue, 17 May 2016 09:21:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7225A1E335; Tue, 17 May 2016 12:26:35 -0400 (EDT) Date: Tue, 17 May 2016 12:26:35 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20160517162635.GB17462@pfrc.org> References: <20160506055901.26792.54292.idtracker@ietfa.amsl.com> <20160506073445.GA42286@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160506073445.GA42286@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 16:21:37 -0000 Jürgen, On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder wrote: > I have a hard time with this document. Section 3 is labelled > requirements but it actually details solution and I disagree with a > significant number of the solution elements. If you were to restrict your comments to the requirements labeled variously: Ephemeral-REQ-XX PubSub-REQ-X do you consider the items sufficiently well described to be a requirements document? As Sue mentioned, we can migrate solution-space discussion wholly into the strawman document. -- Jeff From nobody Tue May 17 10:46:01 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBFE12D7E3; Tue, 17 May 2016 10:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOXjYTEBSItl; Tue, 17 May 2016 10:45:52 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4450112D7F2; Tue, 17 May 2016 10:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4626; q=dns/txt; s=iport; t=1463507152; x=1464716752; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S1CPWmtugailJ0Ze82tIJ7PUkSop0bOJGHZJ2S1XI8g=; b=B+iE296avHmd5RewSCX09oKMfJjcm92z0fnvFzCm0FZ1epZTbZlAKUmL wRyuZ9c00VbwFlbmcFd6YpWh3ejuYzD+pTlHomFJqfGTQ9h+AJdVYZdy7 MwsoIgWoLaWfZI6gqF0aHaQsOafHNUQCi+z3P1mnMoI+laeS2vaMs8i7x g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAgBdWDtX/4YNJK1cgzdVLlAGuXEBD?= =?us-ascii?q?YF1FwuFbwKBOzgUAQEBAQEBAWUnhEIBAQEDAQEBATc0CwULAgEIJREFCycLJQI?= =?us-ascii?q?EAQ0FCIgfCA7DYwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiWETYQREQFOhScFh?= =?us-ascii?q?36QKwGFfogZgXCET4hhj0EBHgEBQoIGHBaBNW4BhlA2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="274685481" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2016 17:45:51 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4HHjpjs015262 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 17:45:51 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 13:45:50 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Tue, 17 May 2016 13:45:50 -0400 From: "Eric Voit (evoit)" To: Stephen Farrell , The IESG Thread-Topic: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRpZsnp1NFjC4UtkSYNrqGomVop5+9atUQ Date: Tue, 17 May 2016 17:45:50 +0000 Message-ID: <21c7d7142c1a4a0091df164c1bd201e9@XCH-RTP-013.cisco.com> References: <20160504002307.8276.60759.idtracker@ietfa.amsl.com> In-Reply-To: <20160504002307.8276.60759.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 17:45:59 -0000 Hi Stephen, > Stephen Farrell, May 03, 2016 8:23 PM >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-i2rs-pub-sub-requirements-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > I have what I hope are two very easily sorted things that I'd like to cha= t about: >=20 > (1) 4.2.5, para2: Hang on - this is 2016 isn't it? :-) Why would we ever = have a > pub/sub service whose subscribers can pretend to be the service? I am not sure I understand. The Subscription Service is located on the Pub= lisher. Having the Publisher and Subscriber mutually authenticate each oth= er makes sense. If you mean something else and you are wondering if whether a Subscriber ca= n also be a Publisher for the information it receives, yes it can. Having = a collector/controller as a middle-man is a very valid implementation. But= there is nothing which binds such independent subscriptions together. =20 > (2) Don't you need a statement somewhere that commensurate security needs > to be provided for pushed notifications as was used for the original subs= cription? > That might be a little hard to phrase correctly but I hope we agree that = the > notifications ought not be significantly less secure than the subscriptio= n. We had some interactions with Ben Campbell on this topic. In general we = are doing our best to decouple the subscription establishment and maintenan= ce from the underlying transport options. This is because there are implem= entations (for example wholly within an MSDC) which don't require payload e= ncryption. Still most implementations should have transport encryption. S= o after several interactions with Ben, the text leading off Section 4.2.5 n= ow reads: Some uses of this Subscription Service will push privacy-sensitive updates and metadata. Good deployment practices will bind this generated information within secure, encrypted transport layer mechanisms. For example if NETCONF is used as transport, then [RFC5539] would be a valid option to secure the transported information. The Subscription Service can also be used with emerging deployment contexts as well. As an example, deployments based on [i2rs-usecase] can apply these requirements in conjunction with those documented within [i2rs-protocol-security] to secure ephemeral state information being pushed from a Network Element. Does this hit your objective?=20 Eric >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - I wondered if this was maybe of interest to more than just i2rs, and if= so, > whether any effort had been made to try figure out if these requirements = work > for folks who don't care about i2rs? It'd seem a shame to work on this bu= t stop > one step short of being appropriately general. > (But you probably already checked that I guess.) >=20 > - 4.2.2, last para: The MUST here seems like it may be quite onerous, in = general. > Did someone think all of that through? For example, what if the reason fo= r > declining is that the Subscriber doesn't have sufficient privilege? > Saying what privilege is needed would be a breach of least-privilege. Tra= nsient > errors may also make this very hard to do well. I'd suggest s/MUST/MAY/ a= nd to > also turn the information returned into a hint and not a promise. >=20 > - 4.2.5, para 1: saying there "MUST be mutual authentication" is odd - th= e usual > terms would be "MUST implement" or "MUST use" which of those does "MUST > be" > mean? >=20 > - 4.2.8: when you say fetch... by whom? Is there an implicit requirement = in the > title of the subsection? >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 17 11:20:45 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE3A12D72D for ; Tue, 17 May 2016 11:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay31DqwI4LIE for ; Tue, 17 May 2016 11:20:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 392DF12D798 for ; Tue, 17 May 2016 11:20:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6D7881E335; Tue, 17 May 2016 14:25:30 -0400 (EDT) Date: Tue, 17 May 2016 14:25:30 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20160517182530.GC17462@pfrc.org> References: <57040667.10401@cisco.com> <00a001d18f7c$8142a440$83c7ecc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a001d18f7c$8142a440$83c7ecc0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org, 'Joe Clarke' Subject: Re: [i2rs] Comments on last-write-wins (strawman) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:20:44 -0000 Sue, On Tue, Apr 05, 2016 at 04:48:25PM -0400, Susan Hares wrote: > > This requirement that implementations provide "last write" and the ability > to "ephemeral" wins (by setting a configuration flag) is a good addition. > > I hope others will comment on this point. I believe what this implies is the behavior of the agent to have either two panes of glass (local + ephemeral) or one pane, where local and ephemeral co-exist. I believe a prior concern from Andy was that in such a single-pane model, a restart of the system may result in an invalid static (local) configuration. If this is a valid interpretation, perhaps we should always be going for the two pane of glass model? -- Jeff From nobody Tue May 17 11:24:09 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE7E12D783 for ; Tue, 17 May 2016 11:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRcvQu2gIRuq for ; Tue, 17 May 2016 11:24:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AF412D72D for ; Tue, 17 May 2016 11:24:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5EE3B8EE; Tue, 17 May 2016 20:24:03 +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 51Za51pLKXSj; Tue, 17 May 2016 20:23:54 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 17 May 2016 20:24:02 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 619E920055; Tue, 17 May 2016 20:24:02 +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 xz0zaEsmUVX2; Tue, 17 May 2016 20:24:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 126E020056; Tue, 17 May 2016 20:24:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ECB783AD7776; Tue, 17 May 2016 20:23:59 +0200 (CEST) Date: Tue, 17 May 2016 20:23:59 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20160517182359.GA4821@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org References: <20160506055901.26792.54292.idtracker@ietfa.amsl.com> <20160506073445.GA42286@elstar.local> <20160517162635.GB17462@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <20160517162635.GB17462@pfrc.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:24:07 -0000 On Tue, May 17, 2016 at 12:26:35PM -0400, Jeffrey Haas wrote: > Jürgen, > > On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder wrote: > > I have a hard time with this document. Section 3 is labelled > > requirements but it actually details solution and I disagree with a > > significant number of the solution elements. > > If you were to restrict your comments to the requirements labeled variously: > Ephemeral-REQ-XX > PubSub-REQ-X > > do you consider the items sufficiently well described to be a requirements > document? Mostly: - I do not understand what Ephemeral-REQ-05 is trying to say. - I disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds like solution attempts (to which I do not agree). - I disagree with Ephemeral-REQ-07 and all of section 3.5 and subsections; this is not a requirement but an attempt to describe a solution. - I disagree with Ephemeral-REQ-08 and all of section 3.5 and subsections; this is not a requirement but an attempt to describe a solution. - Has Ephemeral-REQ-09 (the first one) not been stated elsewhere already? - Ephemeral-REQ-xx with xx >= 09 and xx <= 13 seem repetitions from requirements already stated elsewhere? - I did not understand section 3.7.3 and I am unsure what Ephemeral-REQ-13 or more specifically whether it is different from what is already stated in the requirements. I have trouble parsing some of the sentences, e.g. [...] I2RS notes multiple operations in one or more messages handling can handle errors within the set of operations in many ways. - I do not understand PubSub-REQ-1; what is the difference between synchronous and asynchronous push? - I may disagree with PubSub-REQ-2 but then I do not know what 'real time for notifications' means. - I may disagree with PubSub-REQ-3. - I do not understand what PubSub-REQ-4 means; what is a 'critical node event'? How do I decide this requirement has been met? - PubSub-REQ-5 seems to mix up different issues. I do not know what a hierarchy of filters of XPATHs is. - PubSub-REQ-6 is likely underspecified. Overall, I do not understand why we need these additional requirements given that we have draft-ietf-i2rs-pub-sub-requirements-08.txt. > As Sue mentioned, we can migrate solution-space discussion wholly into the > strawman document. In general, it would help me if you make an effort to reduce the number of documents and if you make an effort to avoid document overlaps. Sometimes less is more. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 17 11:24:36 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC8012DC24; Tue, 17 May 2016 11:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOvZpnkSr427; Tue, 17 May 2016 11:24:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E46B12D783; Tue, 17 May 2016 11:24:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D5361BE2F; Tue, 17 May 2016 19:24:25 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_G4GDBC_Su4; Tue, 17 May 2016 19:24:24 +0100 (IST) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8D805BE2C; Tue, 17 May 2016 19:24:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463509464; bh=OvS1K4ATPAkFTt9S6jhO2vg5uI/r/Z3k6LCvTNA6Nhw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=LatG43xTUlwJEU6wQIF3Zlzo+0+5wVA6vrXPhvyvXDU41tNA2JAqNyUG02tJM3r+z Ycjrqp0M6+ZElsZetsw5JMRxzYPzpxb547OFpurN7LewrUjMxWnHVFpo/P7ZdGWlpW +t3hlYVgJyNZQ4xEXqE0/Yb/lLbpTOCa4FPz/Iwc= To: "Eric Voit (evoit)" , The IESG References: <20160504002307.8276.60759.idtracker@ietfa.amsl.com> <21c7d7142c1a4a0091df164c1bd201e9@XCH-RTP-013.cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573B61D7.606@cs.tcd.ie> Date: Tue, 17 May 2016 19:24:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <21c7d7142c1a4a0091df164c1bd201e9@XCH-RTP-013.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020702080802070505030001" Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:24:30 -0000 This is a cryptographically signed message in MIME format. --------------ms020702080802070505030001 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 17/05/16 18:45, Eric Voit (evoit) wrote: > Hi Stephen, >=20 >> Stephen Farrell, May 03, 2016 8:23 PM >>=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-i2rs-pub-sub-requirements-06: Discuss >>=20 >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >>=20 >>=20 >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here:=20 >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/= >> >> >> >> >>=20 ---------------------------------------------------------------------- >> DISCUSS:=20 >> ----------------------------------------------------------------------= >> >> >> >>=20 I have what I hope are two very easily sorted things that I'd like to chat about: >>=20 >> (1) 4.2.5, para2:=20 It's para 3 now. Not sure if that changed in this rev or if I goofed. If the latter, apologies;-) >> Hang on - this is 2016 isn't it? :-) Why would we >> ever have a pub/sub service whose subscribers can pretend to be the >> service? >=20 > I am not sure I understand. The Subscription Service is located on > the Publisher. Having the Publisher and Subscriber mutually > authenticate each other makes sense. >=20 > If you mean something else and you are wondering if whether a > Subscriber can also be a Publisher for the information it receives, > yes it can. Having a collector/controller as a middle-man is a very > valid implementation. But there is nothing which binds such > independent subscriptions together. The problem is that the text says "it SHOULD be possible to provide cryptographic authentication in such a way that no Subscriber can pose as the original Subscription Service" I see no reason for that SHOULD. The implication I take from it is that someone wants to use purely symmetric keying which seems pretty odd. I'd say better text would be to say that "Subscribers MUST NOT be able to pose as the original Subscription Service" maybe. >=20 >> (2) Don't you need a statement somewhere that commensurate security >> needs to be provided for pushed notifications as was used for the >> original subscription? That might be a little hard to phrase >> correctly but I hope we agree that the notifications ought not be >> significantly less secure than the subscription. >=20 > We had some interactions with Ben Campbell on this topic. In > general we are doing our best to decouple the subscription > establishment and maintenance from the underlying transport options. > This is because there are implementations (for example wholly within > an MSDC) which don't require payload encryption. Still most > implementations should have transport encryption. So after several > interactions with Ben, the text leading off Section 4.2.5 now reads: >=20 > Some uses of this Subscription Service will push privacy-sensitive=20 > updates and metadata. Good deployment practices will bind this=20 > generated information within secure, encrypted transport layer=20 > mechanisms. For example if NETCONF is used as transport, then=20 > [RFC5539] would be a valid option to secure the transported=20 > information. The Subscription Service can also be used with > emerging deployment contexts as well. As an example, deployments > based on [i2rs-usecase] can apply these requirements in conjunction > with those documented within [i2rs-protocol-security] to secure > ephemeral state information being pushed from a Network Element. >=20 > Does this hit your objective? Not quite, though it is related. If you added "Commensurate strength security mechanisms MUST be defined (and SHOULD be used) for all of the stages of the pub/sub process, for example using the same algorithms and endpoints for keying for both subscription and publication stages would seem advisable." The thing to avoid is e.g. using some really strong mechanism for the subscription but something much weaker or with worse endpoints for the publication (or vice versa). Sorry if that wording is a bit vague, I didn't re-read the entire doc to get the context right. Cheers, S. >=20 > Eric >=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 - I wondered if this was maybe of interest to more than just i2rs, and if so, >> whether any effort had been made to try figure out if these >> requirements work for folks who don't care about i2rs? It'd seem a >> shame to work on this but stop one step short of being >> appropriately general. (But you probably already checked that I >> guess.) >>=20 >> - 4.2.2, last para: The MUST here seems like it may be quite >> onerous, in general. Did someone think all of that through? For >> example, what if the reason for declining is that the Subscriber >> doesn't have sufficient privilege? Saying what privilege is needed >> would be a breach of least-privilege. Transient errors may also >> make this very hard to do well. I'd suggest s/MUST/MAY/ and to also >> turn the information returned into a hint and not a promise. >>=20 >> - 4.2.5, para 1: saying there "MUST be mutual authentication" is >> odd - the usual terms would be "MUST implement" or "MUST use" which >> of those does "MUST be" mean? >>=20 >> - 4.2.8: when you say fetch... by whom? Is there an implicit >> requirement in the title of the subsection? >>=20 >>=20 >> _______________________________________________ i2rs mailing list=20 >> i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --------------ms020702080802070505030001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTcx ODI0MjNaMC8GCSqGSIb3DQEJBDEiBCCvrRL6Il09YD8DjhveUKQMMbMLmavAL0E3iOJeRaEI gzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBPzVEZBq7QW9GcDwHvqgbbsJERXsVi7sWOlkBRqLn0QvuJGTP7a4bX N1GYUmyv3BMeJfrXQ0YjWDfpS87RovNSjEPimqBCscLms7mDchZNndNYhmFUdMbVl4okf4lq WFGv//+wAQlPBOU+V/HWhDsOdszMeAnpYqofnAkGP0700bBHSxl97tZz+uOJw+p0Y0mauN0u zUvRUyy4vGI7kba5u7Nsn7zkR5OavDnjDBeBrX4tq1O7ZOXBNuyRl6ljdpNS/+EIB0OtQO4H IkIn4IwbvPmEoe5I1rSCh7fIqksB4Rh0SXEu0pyP5RsZlQa2caY3+GtfFx7K67eMDrB31NLX AAAAAAAA --------------ms020702080802070505030001-- From nobody Tue May 17 11:32:32 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A62B12D89A; Tue, 17 May 2016 11:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkUjaUwQNLLb; Tue, 17 May 2016 11:32:29 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A3B12D89B; Tue, 17 May 2016 11:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6008; q=dns/txt; s=iport; t=1463509948; x=1464719548; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=XGPtA37rNatm//8Zt1aeSraVZhJydl8oyQIpUMJMcJU=; b=bYMgJrLsuZU4TFTgym1HKblzQPfi/ZorITItEsr8J87v+9eHj+RSjx93 xPgyi6kOUMFBfYX1LEkCOxSTbOHASQHDMZizmFSQJcOgKZ/LkEPzgdwWT ugqGNjIuBmSp9LiWrn0gpa6CRKV6SVIsXNhYHk+fshwz4i0PvdDFCeuZU g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAgBMYjtX/5xdJa1cgzdVLlAGuXEBD?= =?us-ascii?q?YF1FwuFb4E+OBQBAQEBAQEBZSeEQgEBAQMBAQEBNzQLBQsCAQgVEBEFCycLJQI?= =?us-ascii?q?EAQ0FCIgfCA7DPwEBAQEBAQEBAQEBAQEBAQEBGwWGJYRNhBERAU6FJwWHfpArA?= =?us-ascii?q?YV+iBmBcIRPiGGPQQEeAQFCggYcFoE1bgGGUDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="274747320" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2016 18:32:27 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4HIWRqp018789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 18:32:27 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 14:32:26 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Tue, 17 May 2016 14:32:26 -0400 From: "Eric Voit (evoit)" To: Stephen Farrell , The IESG Thread-Topic: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRpZsnp1NFjC4UtkSYNrqGomVop5+9atUQgAAXqsA= Date: Tue, 17 May 2016 18:32:26 +0000 Message-ID: <0b45fbbe5c4f452bbc19ccbb9ede28c1@XCH-RTP-013.cisco.com> References: <20160504002307.8276.60759.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:32:31 -0000 Hi Stephen, And some thoughts on your comments too... > From: Eric Voit, May 17, 2016 1:46 PM >=20 > Hi Stephen, >=20 > > Stephen Farrell, May 03, 2016 8:23 PM > > > > Stephen Farrell has entered the following ballot position for > > draft-ietf-i2rs-pub-sub-requirements-06: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > > > I have what I hope are two very easily sorted things that I'd like to c= hat about: > > > > (1) 4.2.5, para2: Hang on - this is 2016 isn't it? :-) Why would we > > ever have a pub/sub service whose subscribers can pretend to be the ser= vice? >=20 > I am not sure I understand. The Subscription Service is located on the P= ublisher. > Having the Publisher and Subscriber mutually authenticate each other make= s > sense. >=20 > If you mean something else and you are wondering if whether a Subscriber = can > also be a Publisher for the information it receives, yes it can. Having = a > collector/controller as a middle-man is a very valid implementation. But= there is > nothing which binds such independent subscriptions together. >=20 > > (2) Don't you need a statement somewhere that commensurate security > > needs to be provided for pushed notifications as was used for the origi= nal > subscription? > > That might be a little hard to phrase correctly but I hope we agree > > that the notifications ought not be significantly less secure than the > subscription. >=20 > We had some interactions with Ben Campbell on this topic. In general w= e are > doing our best to decouple the subscription establishment and maintenance > from the underlying transport options. This is because there are > implementations (for example wholly within an MSDC) which don't require > payload encryption. Still most implementations should have transport > encryption. So after several interactions with Ben, the text leading off= Section > 4.2.5 now reads: >=20 > Some uses of this Subscription Service will push privacy-sensitive > updates and metadata. Good deployment practices will bind this > generated information within secure, encrypted transport layer > mechanisms. For example if NETCONF is used as transport, then > [RFC5539] would be a valid option to secure the transported > information. The Subscription Service can also be used with emerging > deployment contexts as well. As an example, deployments based on > [i2rs-usecase] can apply these requirements in conjunction with those > documented within [i2rs-protocol-security] to secure ephemeral state > information being pushed from a Network Element. >=20 > Does this hit your objective? >=20 > Eric >=20 > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > - I wondered if this was maybe of interest to more than just i2rs, and > > if so, whether any effort had been made to try figure out if these > > requirements work for folks who don't care about i2rs? It'd seem a > > shame to work on this but stop one step short of being appropriately ge= neral. > > (But you probably already checked that I guess.) Yes, we have attempted to aggregate requirements from other sources. At t= he beginning there were discussions across I2RS, NETCONF, NETMOD WGs and Op= s and Routing ADs to arrange for general applicability. > > - 4.2.2, last para: The MUST here seems like it may be quite onerous, i= n > general. > > Did someone think all of that through? For example, what if the reason > > for declining is that the Subscriber doesn't have sufficient privilege? > > Saying what privilege is needed would be a breach of least-privilege. > > Transient errors may also make this very hard to do well. I'd suggest > > s/MUST/MAY/ and to also turn the information returned into a hint and n= ot a > promise. Thanks, you make good points... (1) Changing text to explicitly show that these are hints. =20 (2) Changing text to SHOULD. (3) If the subscriber doesn't have privilege, then the target YANG path wou= ld not exist (or be found). Which would be a normal error, not a constrai= ned resource error. And this requirement was aimed at resource constraints= . Which means the text needs to be tweaked.=20 To meet these 3 points, how about the text: "In cases where a Subscription = Request cannot be fulfilled due to insufficient platform resources, the Sub= scription Service SHOULD include within its decline hints on criteria that = would have been acceptable when the Subscription Request was made." > > - 4.2.5, para 1: saying there "MUST be mutual authentication" is odd - > > the usual terms would be "MUST implement" or "MUST use" which of those > > does "MUST be" > > mean? MUST use. Will change text. =20 > > - 4.2.8: when you say fetch... by whom? Is there an implicit > > requirement in the title of the subsection? What is implicit is that some mechanism to meet operational requirements of= this section should exist. The entity doing the fetching could be an NMS= . Thanks, Eric > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 17 11:35:02 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412CD12DD16; Tue, 17 May 2016 11:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBYdoaoaE_FI; Tue, 17 May 2016 11:34:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B951912DD0C; Tue, 17 May 2016 11:34:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9BF4ABE2C; Tue, 17 May 2016 19:34:55 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_eYUikvrypn; Tue, 17 May 2016 19:34:53 +0100 (IST) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6129FBDF9; Tue, 17 May 2016 19:34:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463510093; bh=hjcRa4QehihVms5uPlTd6OvZzMxPr+IvBg3ADMnaOCo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ZhTt8P64ttGSwOPDHWZIAtXk33tNr0mz2qygtx7o5KXoTldLHmiltuiA4QcFcgXHo zKsOh1WW+iGhdB3B9KNE5zI14EXCQBheqNeMQK91WwFC4SGJLlAtzpbL4KusOsLibo KyJBs9NgQYmXjPaFob+eQOT4PK794WRvrVbgOh0g= To: "Eric Voit (evoit)" , The IESG References: <20160504002307.8276.60759.idtracker@ietfa.amsl.com> <0b45fbbe5c4f452bbc19ccbb9ede28c1@XCH-RTP-013.cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573B644D.6030201@cs.tcd.ie> Date: Tue, 17 May 2016 19:34:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <0b45fbbe5c4f452bbc19ccbb9ede28c1@XCH-RTP-013.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020309030707060901020201" Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:34:58 -0000 This is a cryptographically signed message in MIME format. --------------ms020309030707060901020201 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/05/16 19:32, Eric Voit (evoit) wrote: > Hi Stephen, >=20 > And some thoughts on your comments too... Those're all good. Cheers, S >=20 >> From: Eric Voit, May 17, 2016 1:46 PM >> >> Hi Stephen, >> >>> Stephen Farrell, May 03, 2016 8:23 PM >>> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-i2rs-pub-sub-requirements-06: Discuss >>> >>> When responding, please keep the subject line intact and reply to all= >>> email addresses included in the To and CC lines. (Feel free to cut >>> this introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements= / >>> >>> >>> >>> ---------------------------------------------------------------------= - >>> DISCUSS: >>> ---------------------------------------------------------------------= - >>> >>> >>> I have what I hope are two very easily sorted things that I'd like to= chat about: >>> >>> (1) 4.2.5, para2: Hang on - this is 2016 isn't it? :-) Why would we >>> ever have a pub/sub service whose subscribers can pretend to be the s= ervice? >> >> I am not sure I understand. The Subscription Service is located on th= e Publisher. >> Having the Publisher and Subscriber mutually authenticate each other m= akes >> sense. >> >> If you mean something else and you are wondering if whether a Subscrib= er can >> also be a Publisher for the information it receives, yes it can. Havi= ng a >> collector/controller as a middle-man is a very valid implementation. = But there is >> nothing which binds such independent subscriptions together. >> >>> (2) Don't you need a statement somewhere that commensurate security >>> needs to be provided for pushed notifications as was used for the ori= ginal >> subscription? >>> That might be a little hard to phrase correctly but I hope we agree >>> that the notifications ought not be significantly less secure than th= e >> subscription. >> >> We had some interactions with Ben Campbell on this topic. In genera= l we are >> doing our best to decouple the subscription establishment and maintena= nce >> from the underlying transport options. This is because there are >> implementations (for example wholly within an MSDC) which don't requir= e >> payload encryption. Still most implementations should have transport >> encryption. So after several interactions with Ben, the text leading = off Section >> 4.2.5 now reads: >> >> Some uses of this Subscription Service will push privacy-sensitive >> updates and metadata. Good deployment practices will bind this >> generated information within secure, encrypted transport layer >> mechanisms. For example if NETCONF is used as transport, then >> [RFC5539] would be a valid option to secure the transported >> information. The Subscription Service can also be used with emergi= ng >> deployment contexts as well. As an example, deployments based on >> [i2rs-usecase] can apply these requirements in conjunction with tho= se >> documented within [i2rs-protocol-security] to secure ephemeral stat= e >> information being pushed from a Network Element. >> >> Does this hit your objective? >> >> Eric >> >>> >>> ---------------------------------------------------------------------= - >>> COMMENT: >>> ---------------------------------------------------------------------= - >>> >>> >>> - I wondered if this was maybe of interest to more than just i2rs, an= d >>> if so, whether any effort had been made to try figure out if these >>> requirements work for folks who don't care about i2rs? It'd seem a >>> shame to work on this but stop one step short of being appropriately = general. >>> (But you probably already checked that I guess.) >=20 > Yes, we have attempted to aggregate requirements from other sources. = At the beginning there were discussions across I2RS, NETCONF, NETMOD WGs = and Ops and Routing ADs to arrange for general applicability. >=20 >>> - 4.2.2, last para: The MUST here seems like it may be quite onerous,= in >> general. >>> Did someone think all of that through? For example, what if the reaso= n >>> for declining is that the Subscriber doesn't have sufficient privileg= e? >>> Saying what privilege is needed would be a breach of least-privilege.= >>> Transient errors may also make this very hard to do well. I'd suggest= >>> s/MUST/MAY/ and to also turn the information returned into a hint and= not a >> promise. >=20 > Thanks, you make good points... >=20 > (1) Changing text to explicitly show that these are hints. =20 > (2) Changing text to SHOULD. > (3) If the subscriber doesn't have privilege, then the target YANG path= would not exist (or be found). Which would be a normal error, not a co= nstrained resource error. And this requirement was aimed at resource con= straints. Which means the text needs to be tweaked.=20 >=20 > To meet these 3 points, how about the text: "In cases where a Subscript= ion Request cannot be fulfilled due to insufficient platform resources, t= he Subscription Service SHOULD include within its decline hints on criter= ia that would have been acceptable when the Subscription Request was made= =2E" >=20 >>> - 4.2.5, para 1: saying there "MUST be mutual authentication" is odd = - >>> the usual terms would be "MUST implement" or "MUST use" which of thos= e >>> does "MUST be" >>> mean? >=20 > MUST use. Will change text. =20 >=20 >>> - 4.2.8: when you say fetch... by whom? Is there an implicit >>> requirement in the title of the subsection? >=20 > What is implicit is that some mechanism to meet operational requirement= s of this section should exist. The entity doing the fetching could be = an NMS. >=20 > Thanks, > Eric >=20 >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >=20 --------------ms020309030707060901020201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTcx ODM0NTNaMC8GCSqGSIb3DQEJBDEiBCDDUAyoVT+Q/KlBpY/GVaajB/Ixh38fGtmJsCpXf0sj PDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQC0wqlYW0/ly/FANfYKWFXRw35i2sVpG/Uttiz6Jvh58g8TBLv9iKG2 GqYqTe3Vo/xVPtjGi/CXXvBGxaS+3/3XDd94O33x9Wh+45duEWedfV4gv9tuweCYy8K8//RC AkuF/nyT/NqWIQ5jdhYMZ+eH/88o+NStuzjxeAfLiEMSS8ukymeQzLMWMrjCvfFTZa7CXnW+ T3MTJcKcNlWwTHeJyw/kmG+oFS6DtwIsidALo+HlQ5Kula54vUCGpZT5P0whwj1LzWyMvd3x BEYlI/lGspEw7QGEw6Xf9B42kQzKu/wkXy/WFsym9g2tZ5OZBBKS3p41zGfLoxozhhK5Tkj9 AAAAAAAA --------------ms020309030707060901020201-- From nobody Tue May 17 11:37:39 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5687112D8A9; Tue, 17 May 2016 11:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F2eLZZKOJmO; Tue, 17 May 2016 11:37:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8612D8E7; Tue, 17 May 2016 11:37:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 82E4C1E335; Tue, 17 May 2016 14:42:45 -0400 (EDT) Date: Tue, 17 May 2016 14:42:45 -0400 From: Jeffrey Haas To: Susan Hares , i2rs@ietf.org, netconf@ietf.org Message-ID: <20160517184245.GD17462@pfrc.org> References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> <20160506074418.GB42286@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160506074418.GB42286@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [i2rs] [Netconf] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:37:35 -0000 Jürgen, On Fri, May 06, 2016 at 09:44:18AM +0200, Juergen Schoenwaelder wrote: > I disagree with many things in the document. For example, a data model > must not detail things like > > o encoding [XML | JSON] > > o protocol [RESTCONF | NETCONF] > > o protocol-transport [ssh, tls, tcp] > > o transport-ports [ports] I believe the strawman document may be too general with regard to these items. These keywords may be appropriate for subscription/notification type model entries, especially when the subscription is intended to be directed to an end-point different than the transport connect the subscription is being requested from. The strawman should be updated to cover an example to clarify this point. > because of layering and modularity concerns and of deployment > flexibility. There are many more of these. Overall, it would help if > there were fewer documents and not so many overlapping documents. I agree that there are too many documents. The number of them has been somewhat driven by different parties pushing for analysis of requirements from different angles. As we converge on content, we should be centralizing the content. -- Jeff From nobody Tue May 17 11:42:39 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AAC12D781 for ; Tue, 17 May 2016 11:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prO4dF78kgUm for ; Tue, 17 May 2016 11:42:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6055912DC9F for ; Tue, 17 May 2016 11:42:32 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 031AD1E335; Tue, 17 May 2016 14:47:43 -0400 (EDT) Date: Tue, 17 May 2016 14:47:43 -0400 From: Jeffrey Haas To: i2rs@ietf.org, iesg-secretariat@ietf.org Message-ID: <20160517184743.GE17462@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [i2rs] CANCELED I2RS virtual interim meeting May 18, 2016 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:42:38 -0000 Working Group, After discussing the status of the ephemeral state and strawman drafts with Sue, we determined we should cancel tomorrow's virtual interim session. We will continue iterating with discussion of content on the mailing list. -- Jeff From nobody Tue May 17 12:10:44 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12BA12D513; Tue, 17 May 2016 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TgHSFbpj4gg; Tue, 17 May 2016 12:10:40 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9389E12D50E; Tue, 17 May 2016 12:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9058; q=dns/txt; s=iport; t=1463512240; x=1464721840; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kIRuVNfO7CWiavIiPxpnJ+Slzve0hQEQiz+NfZt+0Lg=; b=dd59sWnmCSlGs1SVOcBUdjVHy2mtiqqWesDFrVtQVhUoFv/klLH26vP0 uuDpLoObx4J4Y11PH8B4QWtLxKoV/4EczdXx9PsMgzlvMfixni9yciZU0 I3B6nZvEwyBh10XkLCmpWoRWlJyw0LEAkSb377EI4KNNI9+vmjxAySRpl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAgDgaztX/4gNJK1dgzdVLlAGuXMBD?= =?us-ascii?q?YF1FwuFbwIcgSA4FAEBAQEBAQFlJ4RCAQEBAwEBAQEgEToGBQULAgEIFQMCAgk?= =?us-ascii?q?MAggHAgICJQsVEAIEAQ0FCIgfCA6xQ5FtAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wWBAYUkg0qBA4QREQEzOgyCI4JZBYd+kCsBhX6IGYFwhE+DKoU3hi6JEwEeAQF?= =?us-ascii?q?CggYcFoE1bgGGUDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="274761899" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2016 19:10:39 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4HJAd2P023158 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 19:10:39 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 15:10:38 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Tue, 17 May 2016 15:10:38 -0400 From: "Eric Voit (evoit)" To: Stephen Farrell , The IESG Thread-Topic: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRpZsnp1NFjC4UtkSYNrqGomVop5+9atUQgABfroD//79B0A== Date: Tue, 17 May 2016 19:10:38 +0000 Message-ID: References: <20160504002307.8276.60759.idtracker@ietfa.amsl.com> <21c7d7142c1a4a0091df164c1bd201e9@XCH-RTP-013.cisco.com> <573B61D7.606@cs.tcd.ie> In-Reply-To: <573B61D7.606@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:10:43 -0000 KyBtb3JlDQoNCj4gRnJvbTogU3RlcGhlbiBGYXJyZWxsLCBNYXkgMTcsIDIwMTYgMjoyNCBQTQ0K PiANCj4gDQo+IEhpeWEsDQo+IA0KPiBPbiAxNy8wNS8xNiAxODo0NSwgRXJpYyBWb2l0IChldm9p dCkgd3JvdGU6DQo+ID4gSGkgU3RlcGhlbiwNCj4gPg0KPiA+PiBTdGVwaGVuIEZhcnJlbGwsIE1h eSAwMywgMjAxNiA4OjIzIFBNDQo+ID4+DQo+ID4+IFN0ZXBoZW4gRmFycmVsbCBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPj4gZHJhZnQtaWV0Zi1pMnJz LXB1Yi1zdWItcmVxdWlyZW1lbnRzLTA2OiBEaXNjdXNzDQo+ID4+DQo+ID4+IFdoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvDQo+ ID4+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4g KEZlZWwgZnJlZSB0bw0KPiA+PiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dl dmVyLikNCj4gPj4NCj4gPj4NCj4gPj4gUGxlYXNlIHJlZmVyIHRvDQo+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCBmb3IgbW9yZQ0K PiA+PiBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Lg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90 IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kDQo+ID4+IGhlcmU6DQo+ID4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy8N Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiBESVND VVNTOg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+IEkgaGF2 ZSB3aGF0IEkgaG9wZSBhcmUgdHdvIHZlcnkgZWFzaWx5IHNvcnRlZCB0aGluZ3MgdGhhdCBJJ2Qg bGlrZSB0bw0KPiBjaGF0IGFib3V0Og0KPiA+Pg0KPiA+PiAoMSkgNC4yLjUsIHBhcmEyOg0KPiAN Cj4gSXQncyBwYXJhIDMgbm93LiBOb3Qgc3VyZSBpZiB0aGF0IGNoYW5nZWQgaW4gdGhpcyByZXYg b3IgaWYNCj4gSSBnb29mZWQuIElmIHRoZSBsYXR0ZXIsIGFwb2xvZ2llczstKQ0KDQpZZXMuICAg VGhhdCBpcyB3aGF0IGNhdWdodCBtZSB0b28uICAgSSB3YXMgYW5zd2VyaW5nIGZvciBQYXJhZ3Jh cGggMi4NCiANCj4gPj4gSGFuZyBvbiAtIHRoaXMgaXMgMjAxNiBpc24ndCBpdD8gOi0pIFdoeSB3 b3VsZCB3ZQ0KPiA+PiBldmVyIGhhdmUgYSBwdWIvc3ViIHNlcnZpY2Ugd2hvc2Ugc3Vic2NyaWJl cnMgY2FuIHByZXRlbmQgdG8gYmUgdGhlDQo+ID4+IHNlcnZpY2U/DQo+ID4NCj4gPiBJIGFtIG5v dCBzdXJlIEkgdW5kZXJzdGFuZC4gIFRoZSBTdWJzY3JpcHRpb24gU2VydmljZSBpcyBsb2NhdGVk IG9uDQo+ID4gdGhlIFB1Ymxpc2hlci4gIEhhdmluZyB0aGUgUHVibGlzaGVyIGFuZCBTdWJzY3Jp YmVyIG11dHVhbGx5DQo+ID4gYXV0aGVudGljYXRlIGVhY2ggb3RoZXIgbWFrZXMgc2Vuc2UuDQo+ ID4NCj4gPiBJZiB5b3UgbWVhbiBzb21ldGhpbmcgZWxzZSBhbmQgeW91IGFyZSB3b25kZXJpbmcg aWYgd2hldGhlciBhDQo+ID4gU3Vic2NyaWJlciBjYW4gYWxzbyBiZSBhIFB1Ymxpc2hlciBmb3Ig dGhlIGluZm9ybWF0aW9uIGl0IHJlY2VpdmVzLA0KPiA+IHllcyBpdCBjYW4uICBIYXZpbmcgYSBj b2xsZWN0b3IvY29udHJvbGxlciBhcyBhIG1pZGRsZS1tYW4gaXMgYSB2ZXJ5DQo+ID4gdmFsaWQg aW1wbGVtZW50YXRpb24uICBCdXQgdGhlcmUgaXMgbm90aGluZyB3aGljaCBiaW5kcyBzdWNoDQo+ ID4gaW5kZXBlbmRlbnQgc3Vic2NyaXB0aW9ucyB0b2dldGhlci4NCj4gDQo+IFRoZSBwcm9ibGVt IGlzIHRoYXQgdGhlIHRleHQgc2F5cyAiaXQgU0hPVUxEIGJlIHBvc3NpYmxlIHRvIHByb3ZpZGUN Cj4gICAgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlvbiBpbiBzdWNoIGEgd2F5IHRoYXQgbm8g U3Vic2NyaWJlciBjYW4NCj4gICAgcG9zZSBhcyB0aGUgb3JpZ2luYWwgU3Vic2NyaXB0aW9uIFNl cnZpY2UiDQo+IA0KPiBJIHNlZSBubyByZWFzb24gZm9yIHRoYXQgU0hPVUxELiBUaGUgaW1wbGlj YXRpb24gSSB0YWtlIGZyb20gaXQNCj4gaXMgdGhhdCBzb21lb25lIHdhbnRzIHRvIHVzZSBwdXJl bHkgc3ltbWV0cmljIGtleWluZyB3aGljaCBzZWVtcw0KPiBwcmV0dHkgb2RkLiBJJ2Qgc2F5IGJl dHRlciB0ZXh0IHdvdWxkIGJlIHRvIHNheSB0aGF0ICJTdWJzY3JpYmVycw0KPiBNVVNUIE5PVCBi ZSBhYmxlIHRvIHBvc2UgYXMgdGhlIG9yaWdpbmFsIFN1YnNjcmlwdGlvbiBTZXJ2aWNlIg0KPiBt YXliZS4NCg0KWW91ciB0ZXh0IGlzIGJldHRlci4gICBDaGFuZ2VkLg0KDQo+ID4NCj4gPj4gKDIp IERvbid0IHlvdSBuZWVkIGEgc3RhdGVtZW50IHNvbWV3aGVyZSB0aGF0IGNvbW1lbnN1cmF0ZSBz ZWN1cml0eQ0KPiA+PiBuZWVkcyB0byBiZSBwcm92aWRlZCBmb3IgcHVzaGVkIG5vdGlmaWNhdGlv bnMgYXMgd2FzIHVzZWQgZm9yIHRoZQ0KPiA+PiBvcmlnaW5hbCBzdWJzY3JpcHRpb24/IFRoYXQg bWlnaHQgYmUgYSBsaXR0bGUgaGFyZCB0byBwaHJhc2UNCj4gPj4gY29ycmVjdGx5IGJ1dCBJIGhv cGUgd2UgYWdyZWUgdGhhdCB0aGUgbm90aWZpY2F0aW9ucyBvdWdodCBub3QgYmUNCj4gPj4gc2ln bmlmaWNhbnRseSBsZXNzIHNlY3VyZSB0aGFuIHRoZSBzdWJzY3JpcHRpb24uDQo+ID4NCj4gPiBX ZSBoYWQgc29tZSBpbnRlcmFjdGlvbnMgd2l0aCBCZW4gQ2FtcGJlbGwgb24gdGhpcyB0b3BpYy4g ICAgSW4NCj4gPiBnZW5lcmFsIHdlIGFyZSBkb2luZyBvdXIgYmVzdCB0byBkZWNvdXBsZSB0aGUg c3Vic2NyaXB0aW9uDQo+ID4gZXN0YWJsaXNobWVudCBhbmQgbWFpbnRlbmFuY2UgZnJvbSB0aGUg dW5kZXJseWluZyB0cmFuc3BvcnQgb3B0aW9ucy4NCj4gPiBUaGlzIGlzIGJlY2F1c2UgdGhlcmUg YXJlIGltcGxlbWVudGF0aW9ucyAoZm9yIGV4YW1wbGUgd2hvbGx5IHdpdGhpbg0KPiA+IGFuIE1T REMpIHdoaWNoIGRvbid0IHJlcXVpcmUgcGF5bG9hZCBlbmNyeXB0aW9uLiAgU3RpbGwgbW9zdA0K PiA+IGltcGxlbWVudGF0aW9ucyBzaG91bGQgaGF2ZSB0cmFuc3BvcnQgZW5jcnlwdGlvbi4gIFNv IGFmdGVyIHNldmVyYWwNCj4gPiBpbnRlcmFjdGlvbnMgd2l0aCBCZW4sIHRoZSB0ZXh0IGxlYWRp bmcgb2ZmIFNlY3Rpb24gNC4yLjUgbm93IHJlYWRzOg0KPiA+DQo+ID4gU29tZSB1c2VzIG9mIHRo aXMgU3Vic2NyaXB0aW9uIFNlcnZpY2Ugd2lsbCBwdXNoIHByaXZhY3ktc2Vuc2l0aXZlDQo+ID4g dXBkYXRlcyBhbmQgbWV0YWRhdGEuICBHb29kIGRlcGxveW1lbnQgcHJhY3RpY2VzIHdpbGwgYmlu ZCB0aGlzDQo+ID4gZ2VuZXJhdGVkIGluZm9ybWF0aW9uIHdpdGhpbiBzZWN1cmUsIGVuY3J5cHRl ZCB0cmFuc3BvcnQgbGF5ZXINCj4gPiBtZWNoYW5pc21zLiAgRm9yIGV4YW1wbGUgaWYgTkVUQ09O RiBpcyB1c2VkIGFzIHRyYW5zcG9ydCwgdGhlbg0KPiA+IFtSRkM1NTM5XSB3b3VsZCBiZSBhIHZh bGlkIG9wdGlvbiB0byBzZWN1cmUgdGhlIHRyYW5zcG9ydGVkDQo+ID4gaW5mb3JtYXRpb24uICBU aGUgU3Vic2NyaXB0aW9uIFNlcnZpY2UgY2FuIGFsc28gYmUgdXNlZCB3aXRoDQo+ID4gZW1lcmdp bmcgZGVwbG95bWVudCBjb250ZXh0cyBhcyB3ZWxsLiAgQXMgYW4gZXhhbXBsZSwgZGVwbG95bWVu dHMNCj4gPiBiYXNlZCBvbiBbaTJycy11c2VjYXNlXSBjYW4gYXBwbHkgdGhlc2UgcmVxdWlyZW1l bnRzIGluIGNvbmp1bmN0aW9uDQo+ID4gd2l0aCB0aG9zZSBkb2N1bWVudGVkIHdpdGhpbiBbaTJy cy1wcm90b2NvbC1zZWN1cml0eV0gdG8gc2VjdXJlDQo+ID4gZXBoZW1lcmFsIHN0YXRlIGluZm9y bWF0aW9uIGJlaW5nIHB1c2hlZCBmcm9tIGEgTmV0d29yayBFbGVtZW50Lg0KPiA+DQo+ID4gRG9l cyB0aGlzIGhpdCB5b3VyIG9iamVjdGl2ZT8NCj4gDQo+IE5vdCBxdWl0ZSwgdGhvdWdoIGl0IGlz IHJlbGF0ZWQuDQo+IA0KPiBJZiB5b3UgYWRkZWQgIkNvbW1lbnN1cmF0ZSBzdHJlbmd0aCBzZWN1 cml0eSBtZWNoYW5pc21zIE1VU1QNCj4gYmUgZGVmaW5lZCAoYW5kIFNIT1VMRCBiZSB1c2VkKSBm b3IgYWxsIG9mIHRoZSBzdGFnZXMgb2YNCj4gdGhlIHB1Yi9zdWIgcHJvY2VzcywgZm9yIGV4YW1w bGUgdXNpbmcgdGhlIHNhbWUgYWxnb3JpdGhtcw0KPiBhbmQgZW5kcG9pbnRzIGZvciBrZXlpbmcg Zm9yIGJvdGggc3Vic2NyaXB0aW9uIGFuZCBwdWJsaWNhdGlvbg0KPiBzdGFnZXMgd291bGQgc2Vl bSBhZHZpc2FibGUuIg0KPiANCj4gVGhlIHRoaW5nIHRvIGF2b2lkIGlzIGUuZy4gdXNpbmcgc29t ZSByZWFsbHkgc3Ryb25nIG1lY2hhbmlzbQ0KPiBmb3IgdGhlIHN1YnNjcmlwdGlvbiBidXQgc29t ZXRoaW5nIG11Y2ggd2Vha2VyIG9yIHdpdGggd29yc2UNCj4gZW5kcG9pbnRzIGZvciB0aGUgcHVi bGljYXRpb24gKG9yIHZpY2UgdmVyc2EpLg0KPiANCj4gU29ycnkgaWYgdGhhdCB3b3JkaW5nIGlz IGEgYml0IHZhZ3VlLCBJIGRpZG4ndCByZS1yZWFkIHRoZQ0KPiBlbnRpcmUgZG9jIHRvIGdldCB0 aGUgY29udGV4dCByaWdodC4NCg0KSSBzZWUgd2hhdCB5b3UgYXJlIGdldHRpbmcgYXQgbm93LiAg IEhvdyBhYm91dCB0aGUgcmVxdWlyZW1lbnQgdGV4dDoNCg0KIkZvciBhbnkgZW5jcnlwdGVkIGlu Zm9ybWF0aW9uIGV4Y2hhbmdlcywgY29tbWVuc3VyYXRlIHN0cmVuZ3RoIHNlY3VyaXR5IG1lY2hh bmlzbXMgTVVTVCBiZSBhdmFpbGFibGUgYW5kIFNIT1VMRCBiZSB1c2VkLiAgVGhpcyBpbmNsdWRl cyBhbGwgc3RhZ2VzIG9mIHRoZSBTdWJzY3JpcHRpb24gYW5kIHVwZGF0ZSBwdXNoIHByb2Nlc3Mu Ig0KDQpUaGFua3MsDQpFcmljDQoNCg0KIA0KPiBDaGVlcnMsDQo+IFMuDQo+IA0KPiA+DQo+ID4g RXJpYw0KPiA+DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPj4NCj4gQ09NTUVO VDoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiAtIEkgd29u ZGVyZWQgaWYgdGhpcyB3YXMgbWF5YmUgb2YgaW50ZXJlc3QgdG8gbW9yZSB0aGFuIGp1c3QgaTJy cywgYW5kDQo+IGlmIHNvLA0KPiA+PiB3aGV0aGVyIGFueSBlZmZvcnQgaGFkIGJlZW4gbWFkZSB0 byB0cnkgZmlndXJlIG91dCBpZiB0aGVzZQ0KPiA+PiByZXF1aXJlbWVudHMgd29yayBmb3IgZm9s a3Mgd2hvIGRvbid0IGNhcmUgYWJvdXQgaTJycz8gSXQnZCBzZWVtIGENCj4gPj4gc2hhbWUgdG8g d29yayBvbiB0aGlzIGJ1dCBzdG9wIG9uZSBzdGVwIHNob3J0IG9mIGJlaW5nDQo+ID4+IGFwcHJv cHJpYXRlbHkgZ2VuZXJhbC4gKEJ1dCB5b3UgcHJvYmFibHkgYWxyZWFkeSBjaGVja2VkIHRoYXQg SQ0KPiA+PiBndWVzcy4pDQo+ID4+DQo+ID4+IC0gNC4yLjIsIGxhc3QgcGFyYTogVGhlIE1VU1Qg aGVyZSBzZWVtcyBsaWtlIGl0IG1heSBiZSBxdWl0ZQ0KPiA+PiBvbmVyb3VzLCBpbiBnZW5lcmFs LiBEaWQgc29tZW9uZSB0aGluayBhbGwgb2YgdGhhdCB0aHJvdWdoPyBGb3INCj4gPj4gZXhhbXBs ZSwgd2hhdCBpZiB0aGUgcmVhc29uIGZvciBkZWNsaW5pbmcgaXMgdGhhdCB0aGUgU3Vic2NyaWJl cg0KPiA+PiBkb2Vzbid0IGhhdmUgc3VmZmljaWVudCBwcml2aWxlZ2U/IFNheWluZyB3aGF0IHBy aXZpbGVnZSBpcyBuZWVkZWQNCj4gPj4gd291bGQgYmUgYSBicmVhY2ggb2YgbGVhc3QtcHJpdmls ZWdlLiBUcmFuc2llbnQgZXJyb3JzIG1heSBhbHNvDQo+ID4+IG1ha2UgdGhpcyB2ZXJ5IGhhcmQg dG8gZG8gd2VsbC4gSSdkIHN1Z2dlc3Qgcy9NVVNUL01BWS8gYW5kIHRvIGFsc28NCj4gPj4gdHVy biB0aGUgaW5mb3JtYXRpb24gcmV0dXJuZWQgaW50byBhIGhpbnQgYW5kIG5vdCBhIHByb21pc2Uu DQo+ID4+DQo+ID4+IC0gNC4yLjUsIHBhcmEgMTogc2F5aW5nIHRoZXJlICJNVVNUIGJlIG11dHVh bCBhdXRoZW50aWNhdGlvbiIgaXMNCj4gPj4gb2RkIC0gdGhlIHVzdWFsIHRlcm1zIHdvdWxkIGJl ICJNVVNUIGltcGxlbWVudCIgb3IgIk1VU1QgdXNlIiB3aGljaA0KPiA+PiBvZiB0aG9zZSBkb2Vz ICJNVVNUIGJlIiBtZWFuPw0KPiA+Pg0KPiA+PiAtIDQuMi44OiB3aGVuIHlvdSBzYXkgZmV0Y2gu Li4gYnkgd2hvbT8gSXMgdGhlcmUgYW4gaW1wbGljaXQNCj4gPj4gcmVxdWlyZW1lbnQgaW4gdGhl IHRpdGxlIG9mIHRoZSBzdWJzZWN0aW9uPw0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBpMnJzIG1haWxpbmcgbGlzdA0KPiA+ PiBpMnJzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy cw0KDQo= From nobody Tue May 17 12:22:14 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FEC12D836; Tue, 17 May 2016 12:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DX8gY8Y_yrA; Tue, 17 May 2016 12:22:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EDC12D50F; Tue, 17 May 2016 12:22:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D1C78BE2D; Tue, 17 May 2016 20:22:09 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od2iNQXAghMc; Tue, 17 May 2016 20:22:08 +0100 (IST) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6994EBE2C; Tue, 17 May 2016 20:22:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463512928; bh=lfKa4o6nD34/TMI8sPJDc3cB3lV30kfYG9UBzc4ngrE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=rGaQVTkkL79G7fqAK2jvdNHPOM9jaIiDFfCCs1S8kKX+Q6y3lffU73i/3hL42zpIX VlqhdkagbrLRBxCymh50igz7aUc1yV40WGncX3mKsiDGlK9DSUtHhK0DSUTn9DwmIE I73r26GsFrL8jjYwmWTWaseRB/dNF79+gbfBN7s8= To: "Eric Voit (evoit)" , The IESG References: <20160504002307.8276.60759.idtracker@ietfa.amsl.com> <21c7d7142c1a4a0091df164c1bd201e9@XCH-RTP-013.cisco.com> <573B61D7.606@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573B6F5F.4080908@cs.tcd.ie> Date: Tue, 17 May 2016 20:22:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090305060209090700030207" Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:22:13 -0000 This is a cryptographically signed message in MIME format. --------------ms090305060209090700030207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 17/05/16 20:10, Eric Voit (evoit) wrote: > + more Looks like we're sorted. Just shoot out a rev with those changes and I'll clear, Thanks, S. >=20 >> From: Stephen Farrell, May 17, 2016 2:24 PM >> >> >> Hiya, >> >> On 17/05/16 18:45, Eric Voit (evoit) wrote: >>> Hi Stephen, >>> >>>> Stephen Farrell, May 03, 2016 8:23 PM >>>> >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-i2rs-pub-sub-requirements-06: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to >>>> all email addresses included in the To and CC lines. (Feel free to >>>> cut this introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >>>> information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found >>>> here: >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/ >>>> >>>> >>>> >>>> >>>> >> ----------------------------------------------------------------------= >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> >>>> >> I have what I hope are two very easily sorted things that I'd like to >> chat about: >>>> >>>> (1) 4.2.5, para2: >> >> It's para 3 now. Not sure if that changed in this rev or if >> I goofed. If the latter, apologies;-) >=20 > Yes. That is what caught me too. I was answering for Paragraph 2. > =20 >>>> Hang on - this is 2016 isn't it? :-) Why would we >>>> ever have a pub/sub service whose subscribers can pretend to be the >>>> service? >>> >>> I am not sure I understand. The Subscription Service is located on >>> the Publisher. Having the Publisher and Subscriber mutually >>> authenticate each other makes sense. >>> >>> If you mean something else and you are wondering if whether a >>> Subscriber can also be a Publisher for the information it receives, >>> yes it can. Having a collector/controller as a middle-man is a very >>> valid implementation. But there is nothing which binds such >>> independent subscriptions together. >> >> The problem is that the text says "it SHOULD be possible to provide >> cryptographic authentication in such a way that no Subscriber can >> pose as the original Subscription Service" >> >> I see no reason for that SHOULD. The implication I take from it >> is that someone wants to use purely symmetric keying which seems >> pretty odd. I'd say better text would be to say that "Subscribers >> MUST NOT be able to pose as the original Subscription Service" >> maybe. >=20 > Your text is better. Changed. >=20 >>> >>>> (2) Don't you need a statement somewhere that commensurate security >>>> needs to be provided for pushed notifications as was used for the >>>> original subscription? That might be a little hard to phrase >>>> correctly but I hope we agree that the notifications ought not be >>>> significantly less secure than the subscription. >>> >>> We had some interactions with Ben Campbell on this topic. In >>> general we are doing our best to decouple the subscription >>> establishment and maintenance from the underlying transport options. >>> This is because there are implementations (for example wholly within >>> an MSDC) which don't require payload encryption. Still most >>> implementations should have transport encryption. So after several >>> interactions with Ben, the text leading off Section 4.2.5 now reads: >>> >>> Some uses of this Subscription Service will push privacy-sensitive >>> updates and metadata. Good deployment practices will bind this >>> generated information within secure, encrypted transport layer >>> mechanisms. For example if NETCONF is used as transport, then >>> [RFC5539] would be a valid option to secure the transported >>> information. The Subscription Service can also be used with >>> emerging deployment contexts as well. As an example, deployments >>> based on [i2rs-usecase] can apply these requirements in conjunction >>> with those documented within [i2rs-protocol-security] to secure >>> ephemeral state information being pushed from a Network Element. >>> >>> Does this hit your objective? >> >> Not quite, though it is related. >> >> If you added "Commensurate strength security mechanisms MUST >> be defined (and SHOULD be used) for all of the stages of >> the pub/sub process, for example using the same algorithms >> and endpoints for keying for both subscription and publication >> stages would seem advisable." >> >> The thing to avoid is e.g. using some really strong mechanism >> for the subscription but something much weaker or with worse >> endpoints for the publication (or vice versa). >> >> Sorry if that wording is a bit vague, I didn't re-read the >> entire doc to get the context right. >=20 > I see what you are getting at now. How about the requirement text: >=20 > "For any encrypted information exchanges, commensurate strength securit= y mechanisms MUST be available and SHOULD be used. This includes all sta= ges of the Subscription and update push process." >=20 > Thanks, > Eric >=20 >=20 > =20 >> Cheers, >> S. >> >>> >>> Eric >>> >>>> >>>> --------------------------------------------------------------------= -- >>>> >>>> >> COMMENT: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> >>>> >> - I wondered if this was maybe of interest to more than just i2rs, and= >> if so, >>>> whether any effort had been made to try figure out if these >>>> requirements work for folks who don't care about i2rs? It'd seem a >>>> shame to work on this but stop one step short of being >>>> appropriately general. (But you probably already checked that I >>>> guess.) >>>> >>>> - 4.2.2, last para: The MUST here seems like it may be quite >>>> onerous, in general. Did someone think all of that through? For >>>> example, what if the reason for declining is that the Subscriber >>>> doesn't have sufficient privilege? Saying what privilege is needed >>>> would be a breach of least-privilege. Transient errors may also >>>> make this very hard to do well. I'd suggest s/MUST/MAY/ and to also >>>> turn the information returned into a hint and not a promise. >>>> >>>> - 4.2.5, para 1: saying there "MUST be mutual authentication" is >>>> odd - the usual terms would be "MUST implement" or "MUST use" which >>>> of those does "MUST be" mean? >>>> >>>> - 4.2.8: when you say fetch... by whom? Is there an implicit >>>> requirement in the title of the subsection? >>>> >>>> >>>> _______________________________________________ i2rs mailing list >>>> i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs >=20 --------------ms090305060209090700030207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTcx OTIyMDdaMC8GCSqGSIb3DQEJBDEiBCD8oW43nlyZ+47BLrOUN/WlOIEyecMQXaKRqr5FlVcw VTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAJSQN5JhfiyTHJN9lTq6fe4PamXPz7pN63dHRaBv/jtsmBdC9bNZdR 7jo19ZxRKjiOnHd+j3LjuGxomwWGf5ffwwPj6b7k6Izwk7AUyTu9rJ6xY4caBzrprMxoKi35 WC/O9HaxEC2elLiqIwcy/kq3zHn/D+QcXPlDYKfrqxb8gAF+CuJDf7LieRXMq8UgKg22UnAk 4etw9hzf4L750si6CYRgGeMPqn2GNLkfdNXyx5a07lblI0x4WAON7MYrY/BOVGbDfLl4gsQ/ PMAjB6x9YcJTnHCSXUfvSs/nVuX+C0el19dWP7J1Rw/0ko+qkO4i9+/CZn3Ln8V74d9V0C5g AAAAAAAA --------------ms090305060209090700030207-- From nobody Tue May 17 12:27:56 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACEC12DD59; Tue, 17 May 2016 12:27:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160517192752.24848.24471.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 12:27:52 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-pub-sub-requirements-09.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:27:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : Requirements for Subscription to YANG Datastores Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Filename : draft-ietf-i2rs-pub-sub-requirements-09.txt Pages : 17 Date : 2016-05-17 Abstract: This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Netconf and Restconf). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-pub-sub-requirements-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 17 12:30:27 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EBC12DD6C; Tue, 17 May 2016 12:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZcGGcv38h1d; Tue, 17 May 2016 12:30:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F31512DD74; Tue, 17 May 2016 12:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10080; q=dns/txt; s=iport; t=1463513418; x=1464723018; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UOQmTQDHjCXAXZcDAc+HYkrvsqjiTosrBdxg8oR21XU=; b=Jaz327v5yp6F31BilNzcCijHp45fYg7q31Q+CpGNqD4pXqLwJg+X1KRT ikoLivIjS1kluc75cbzybEzORLI0N8lJm/lFRqM/vGQinul82XbrQAHJg furIUttuWIlUKYPz37qw2Z9pHfid1SeffwY+ur+mCoQ26mLipVZv9gHQJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAgAbcDtX/4MNJK1dgzdVLlAGuXUBD?= =?us-ascii?q?YF1FwuFbwIcgSA4FAEBAQEBAQFlJ4RCAQEBAwEBAQEgEToGBQULAgEIFQMCAgk?= =?us-ascii?q?WBwICAiULFRACBAENBQiIHwgOsUiRZwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFg?= =?us-ascii?q?QGFJINKgQOEEREBM4JpglkFh36QKwGFfogZgXCET4MqhTeGLokTAR4BAUKCBhw?= =?us-ascii?q?WgTVuAYZQNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="108171736" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2016 19:30:17 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4HJUGIP027174 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 19:30:17 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 15:30:16 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Tue, 17 May 2016 15:30:16 -0400 From: "Eric Voit (evoit)" To: Stephen Farrell , The IESG Thread-Topic: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) Thread-Index: AQHRpZsnp1NFjC4UtkSYNrqGomVop5+9atUQgABfroD//79B0IAAUOGA//++nHA= Date: Tue, 17 May 2016 19:30:16 +0000 Message-ID: <357e717398274bd99e0555f975f73410@XCH-RTP-013.cisco.com> References: <20160504002307.8276.60759.idtracker@ietfa.amsl.com> <21c7d7142c1a4a0091df164c1bd201e9@XCH-RTP-013.cisco.com> <573B61D7.606@cs.tcd.ie> <573B6F5F.4080908@cs.tcd.ie> In-Reply-To: <573B6F5F.4080908@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:30:20 -0000 djA5IHBvc3RlZA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1p MnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLw0KDQpUaGlzIHZlcnNpb24gc2hvdWxkIGhhdmUgYWxs IGRpc2N1c3NlZCBjaGFuZ2VzIGFjcm9zcyBhbGwgcmV2aWV3ZXJzLg0KDQpFcmljDQoNCj4gSGl5 YSwNCj4gDQo+IE9uIDE3LzA1LzE2IDIwOjEwLCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZToNCj4g PiArIG1vcmUNCj4gDQo+IExvb2tzIGxpa2Ugd2UncmUgc29ydGVkLiBKdXN0IHNob290IG91dCBh IHJldiB3aXRoIHRob3NlDQo+IGNoYW5nZXMgYW5kIEknbGwgY2xlYXIsDQo+IA0KPiBUaGFua3Ms DQo+IFMuDQo+IA0KPiA+DQo+ID4+IEZyb206IFN0ZXBoZW4gRmFycmVsbCwgTWF5IDE3LCAyMDE2 IDI6MjQgUE0NCj4gPj4NCj4gPj4NCj4gPj4gSGl5YSwNCj4gPj4NCj4gPj4gT24gMTcvMDUvMTYg MTg6NDUsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOg0KPiA+Pj4gSGkgU3RlcGhlbiwNCj4gPj4+ DQo+ID4+Pj4gU3RlcGhlbiBGYXJyZWxsLCBNYXkgMDMsIDIwMTYgODoyMyBQTQ0KPiA+Pj4+DQo+ ID4+Pj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KPiA+Pj4+IGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0w NjogRGlzY3Vzcw0KPiA+Pj4+DQo+ID4+Pj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0 aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8NCj4gPj4+PiBhbGwgZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8NCj4g Pj4+PiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPj4+Pg0K PiA+Pj4+DQo+ID4+Pj4gUGxlYXNlIHJlZmVyIHRvDQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIGZvciBtb3JlDQo+ID4+Pj4g aW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4g Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZA0KPiA+Pj4+IGhlcmU6DQo+ID4+Pj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1l bnRzLw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+Pj4+IERJU0NVU1M6DQo+ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+DQo+ ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+IEkgaGF2ZSB3aGF0IEkgaG9wZSBhcmUgdHdvIHZl cnkgZWFzaWx5IHNvcnRlZCB0aGluZ3MgdGhhdCBJJ2QgbGlrZSB0bw0KPiA+PiBjaGF0IGFib3V0 Og0KPiA+Pj4+DQo+ID4+Pj4gKDEpIDQuMi41LCBwYXJhMjoNCj4gPj4NCj4gPj4gSXQncyBwYXJh IDMgbm93LiBOb3Qgc3VyZSBpZiB0aGF0IGNoYW5nZWQgaW4gdGhpcyByZXYgb3IgaWYNCj4gPj4g SSBnb29mZWQuIElmIHRoZSBsYXR0ZXIsIGFwb2xvZ2llczstKQ0KPiA+DQo+ID4gWWVzLiAgIFRo YXQgaXMgd2hhdCBjYXVnaHQgbWUgdG9vLiAgIEkgd2FzIGFuc3dlcmluZyBmb3IgUGFyYWdyYXBo IDIuDQo+ID4NCj4gPj4+PiBIYW5nIG9uIC0gdGhpcyBpcyAyMDE2IGlzbid0IGl0PyA6LSkgV2h5 IHdvdWxkIHdlDQo+ID4+Pj4gZXZlciBoYXZlIGEgcHViL3N1YiBzZXJ2aWNlIHdob3NlIHN1YnNj cmliZXJzIGNhbiBwcmV0ZW5kIHRvIGJlIHRoZQ0KPiA+Pj4+IHNlcnZpY2U/DQo+ID4+Pg0KPiA+ Pj4gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQuICBUaGUgU3Vic2NyaXB0aW9uIFNlcnZpY2Ug aXMgbG9jYXRlZCBvbg0KPiA+Pj4gdGhlIFB1Ymxpc2hlci4gIEhhdmluZyB0aGUgUHVibGlzaGVy IGFuZCBTdWJzY3JpYmVyIG11dHVhbGx5DQo+ID4+PiBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciBt YWtlcyBzZW5zZS4NCj4gPj4+DQo+ID4+PiBJZiB5b3UgbWVhbiBzb21ldGhpbmcgZWxzZSBhbmQg eW91IGFyZSB3b25kZXJpbmcgaWYgd2hldGhlciBhDQo+ID4+PiBTdWJzY3JpYmVyIGNhbiBhbHNv IGJlIGEgUHVibGlzaGVyIGZvciB0aGUgaW5mb3JtYXRpb24gaXQgcmVjZWl2ZXMsDQo+ID4+PiB5 ZXMgaXQgY2FuLiAgSGF2aW5nIGEgY29sbGVjdG9yL2NvbnRyb2xsZXIgYXMgYSBtaWRkbGUtbWFu IGlzIGEgdmVyeQ0KPiA+Pj4gdmFsaWQgaW1wbGVtZW50YXRpb24uICBCdXQgdGhlcmUgaXMgbm90 aGluZyB3aGljaCBiaW5kcyBzdWNoDQo+ID4+PiBpbmRlcGVuZGVudCBzdWJzY3JpcHRpb25zIHRv Z2V0aGVyLg0KPiA+Pg0KPiA+PiBUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSB0ZXh0IHNheXMgIml0 IFNIT1VMRCBiZSBwb3NzaWJsZSB0byBwcm92aWRlDQo+ID4+ICAgIGNyeXB0b2dyYXBoaWMgYXV0 aGVudGljYXRpb24gaW4gc3VjaCBhIHdheSB0aGF0IG5vIFN1YnNjcmliZXIgY2FuDQo+ID4+ICAg IHBvc2UgYXMgdGhlIG9yaWdpbmFsIFN1YnNjcmlwdGlvbiBTZXJ2aWNlIg0KPiA+Pg0KPiA+PiBJ IHNlZSBubyByZWFzb24gZm9yIHRoYXQgU0hPVUxELiBUaGUgaW1wbGljYXRpb24gSSB0YWtlIGZy b20gaXQNCj4gPj4gaXMgdGhhdCBzb21lb25lIHdhbnRzIHRvIHVzZSBwdXJlbHkgc3ltbWV0cmlj IGtleWluZyB3aGljaCBzZWVtcw0KPiA+PiBwcmV0dHkgb2RkLiBJJ2Qgc2F5IGJldHRlciB0ZXh0 IHdvdWxkIGJlIHRvIHNheSB0aGF0ICJTdWJzY3JpYmVycw0KPiA+PiBNVVNUIE5PVCBiZSBhYmxl IHRvIHBvc2UgYXMgdGhlIG9yaWdpbmFsIFN1YnNjcmlwdGlvbiBTZXJ2aWNlIg0KPiA+PiBtYXli ZS4NCj4gPg0KPiA+IFlvdXIgdGV4dCBpcyBiZXR0ZXIuICAgQ2hhbmdlZC4NCj4gPg0KPiA+Pj4N Cj4gPj4+PiAoMikgRG9uJ3QgeW91IG5lZWQgYSBzdGF0ZW1lbnQgc29tZXdoZXJlIHRoYXQgY29t bWVuc3VyYXRlIHNlY3VyaXR5DQo+ID4+Pj4gbmVlZHMgdG8gYmUgcHJvdmlkZWQgZm9yIHB1c2hl ZCBub3RpZmljYXRpb25zIGFzIHdhcyB1c2VkIGZvciB0aGUNCj4gPj4+PiBvcmlnaW5hbCBzdWJz Y3JpcHRpb24/IFRoYXQgbWlnaHQgYmUgYSBsaXR0bGUgaGFyZCB0byBwaHJhc2UNCj4gPj4+PiBj b3JyZWN0bHkgYnV0IEkgaG9wZSB3ZSBhZ3JlZSB0aGF0IHRoZSBub3RpZmljYXRpb25zIG91Z2h0 IG5vdCBiZQ0KPiA+Pj4+IHNpZ25pZmljYW50bHkgbGVzcyBzZWN1cmUgdGhhbiB0aGUgc3Vic2Ny aXB0aW9uLg0KPiA+Pj4NCj4gPj4+IFdlIGhhZCBzb21lIGludGVyYWN0aW9ucyB3aXRoIEJlbiBD YW1wYmVsbCBvbiB0aGlzIHRvcGljLiAgICBJbg0KPiA+Pj4gZ2VuZXJhbCB3ZSBhcmUgZG9pbmcg b3VyIGJlc3QgdG8gZGVjb3VwbGUgdGhlIHN1YnNjcmlwdGlvbg0KPiA+Pj4gZXN0YWJsaXNobWVu dCBhbmQgbWFpbnRlbmFuY2UgZnJvbSB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQgb3B0aW9ucy4N Cj4gPj4+IFRoaXMgaXMgYmVjYXVzZSB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIChmb3IgZXhh bXBsZSB3aG9sbHkgd2l0aGluDQo+ID4+PiBhbiBNU0RDKSB3aGljaCBkb24ndCByZXF1aXJlIHBh eWxvYWQgZW5jcnlwdGlvbi4gIFN0aWxsIG1vc3QNCj4gPj4+IGltcGxlbWVudGF0aW9ucyBzaG91 bGQgaGF2ZSB0cmFuc3BvcnQgZW5jcnlwdGlvbi4gIFNvIGFmdGVyIHNldmVyYWwNCj4gPj4+IGlu dGVyYWN0aW9ucyB3aXRoIEJlbiwgdGhlIHRleHQgbGVhZGluZyBvZmYgU2VjdGlvbiA0LjIuNSBu b3cgcmVhZHM6DQo+ID4+Pg0KPiA+Pj4gU29tZSB1c2VzIG9mIHRoaXMgU3Vic2NyaXB0aW9uIFNl cnZpY2Ugd2lsbCBwdXNoIHByaXZhY3ktc2Vuc2l0aXZlDQo+ID4+PiB1cGRhdGVzIGFuZCBtZXRh ZGF0YS4gIEdvb2QgZGVwbG95bWVudCBwcmFjdGljZXMgd2lsbCBiaW5kIHRoaXMNCj4gPj4+IGdl bmVyYXRlZCBpbmZvcm1hdGlvbiB3aXRoaW4gc2VjdXJlLCBlbmNyeXB0ZWQgdHJhbnNwb3J0IGxh eWVyDQo+ID4+PiBtZWNoYW5pc21zLiAgRm9yIGV4YW1wbGUgaWYgTkVUQ09ORiBpcyB1c2VkIGFz IHRyYW5zcG9ydCwgdGhlbg0KPiA+Pj4gW1JGQzU1MzldIHdvdWxkIGJlIGEgdmFsaWQgb3B0aW9u IHRvIHNlY3VyZSB0aGUgdHJhbnNwb3J0ZWQNCj4gPj4+IGluZm9ybWF0aW9uLiAgVGhlIFN1YnNj cmlwdGlvbiBTZXJ2aWNlIGNhbiBhbHNvIGJlIHVzZWQgd2l0aA0KPiA+Pj4gZW1lcmdpbmcgZGVw bG95bWVudCBjb250ZXh0cyBhcyB3ZWxsLiAgQXMgYW4gZXhhbXBsZSwgZGVwbG95bWVudHMNCj4g Pj4+IGJhc2VkIG9uIFtpMnJzLXVzZWNhc2VdIGNhbiBhcHBseSB0aGVzZSByZXF1aXJlbWVudHMg aW4gY29uanVuY3Rpb24NCj4gPj4+IHdpdGggdGhvc2UgZG9jdW1lbnRlZCB3aXRoaW4gW2kycnMt cHJvdG9jb2wtc2VjdXJpdHldIHRvIHNlY3VyZQ0KPiA+Pj4gZXBoZW1lcmFsIHN0YXRlIGluZm9y bWF0aW9uIGJlaW5nIHB1c2hlZCBmcm9tIGEgTmV0d29yayBFbGVtZW50Lg0KPiA+Pj4NCj4gPj4+ IERvZXMgdGhpcyBoaXQgeW91ciBvYmplY3RpdmU/DQo+ID4+DQo+ID4+IE5vdCBxdWl0ZSwgdGhv dWdoIGl0IGlzIHJlbGF0ZWQuDQo+ID4+DQo+ID4+IElmIHlvdSBhZGRlZCAiQ29tbWVuc3VyYXRl IHN0cmVuZ3RoIHNlY3VyaXR5IG1lY2hhbmlzbXMgTVVTVA0KPiA+PiBiZSBkZWZpbmVkIChhbmQg U0hPVUxEIGJlIHVzZWQpIGZvciBhbGwgb2YgdGhlIHN0YWdlcyBvZg0KPiA+PiB0aGUgcHViL3N1 YiBwcm9jZXNzLCBmb3IgZXhhbXBsZSB1c2luZyB0aGUgc2FtZSBhbGdvcml0aG1zDQo+ID4+IGFu ZCBlbmRwb2ludHMgZm9yIGtleWluZyBmb3IgYm90aCBzdWJzY3JpcHRpb24gYW5kIHB1YmxpY2F0 aW9uDQo+ID4+IHN0YWdlcyB3b3VsZCBzZWVtIGFkdmlzYWJsZS4iDQo+ID4+DQo+ID4+IFRoZSB0 aGluZyB0byBhdm9pZCBpcyBlLmcuIHVzaW5nIHNvbWUgcmVhbGx5IHN0cm9uZyBtZWNoYW5pc20N Cj4gPj4gZm9yIHRoZSBzdWJzY3JpcHRpb24gYnV0IHNvbWV0aGluZyBtdWNoIHdlYWtlciBvciB3 aXRoIHdvcnNlDQo+ID4+IGVuZHBvaW50cyBmb3IgdGhlIHB1YmxpY2F0aW9uIChvciB2aWNlIHZl cnNhKS4NCj4gPj4NCj4gPj4gU29ycnkgaWYgdGhhdCB3b3JkaW5nIGlzIGEgYml0IHZhZ3VlLCBJ IGRpZG4ndCByZS1yZWFkIHRoZQ0KPiA+PiBlbnRpcmUgZG9jIHRvIGdldCB0aGUgY29udGV4dCBy aWdodC4NCj4gPg0KPiA+IEkgc2VlIHdoYXQgeW91IGFyZSBnZXR0aW5nIGF0IG5vdy4gICBIb3cg YWJvdXQgdGhlIHJlcXVpcmVtZW50IHRleHQ6DQo+ID4NCj4gPiAiRm9yIGFueSBlbmNyeXB0ZWQg aW5mb3JtYXRpb24gZXhjaGFuZ2VzLCBjb21tZW5zdXJhdGUgc3RyZW5ndGggc2VjdXJpdHkNCj4g bWVjaGFuaXNtcyBNVVNUIGJlIGF2YWlsYWJsZSBhbmQgU0hPVUxEIGJlIHVzZWQuICBUaGlzIGlu Y2x1ZGVzIGFsbCBzdGFnZXMgb2YNCj4gdGhlIFN1YnNjcmlwdGlvbiBhbmQgdXBkYXRlIHB1c2gg cHJvY2Vzcy4iDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gRXJpYw0KPiA+DQo+ID4NCj4gPg0KPiA+ PiBDaGVlcnMsDQo+ID4+IFMuDQo+ID4+DQo+ID4+Pg0KPiA+Pj4gRXJpYw0KPiA+Pj4NCj4gPj4+ Pg0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+IENPTU1FTlQ6DQo+ ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+ IC0gSSB3b25kZXJlZCBpZiB0aGlzIHdhcyBtYXliZSBvZiBpbnRlcmVzdCB0byBtb3JlIHRoYW4g anVzdCBpMnJzLCBhbmQNCj4gPj4gaWYgc28sDQo+ID4+Pj4gd2hldGhlciBhbnkgZWZmb3J0IGhh ZCBiZWVuIG1hZGUgdG8gdHJ5IGZpZ3VyZSBvdXQgaWYgdGhlc2UNCj4gPj4+PiByZXF1aXJlbWVu dHMgd29yayBmb3IgZm9sa3Mgd2hvIGRvbid0IGNhcmUgYWJvdXQgaTJycz8gSXQnZCBzZWVtIGEN Cj4gPj4+PiBzaGFtZSB0byB3b3JrIG9uIHRoaXMgYnV0IHN0b3Agb25lIHN0ZXAgc2hvcnQgb2Yg YmVpbmcNCj4gPj4+PiBhcHByb3ByaWF0ZWx5IGdlbmVyYWwuIChCdXQgeW91IHByb2JhYmx5IGFs cmVhZHkgY2hlY2tlZCB0aGF0IEkNCj4gPj4+PiBndWVzcy4pDQo+ID4+Pj4NCj4gPj4+PiAtIDQu Mi4yLCBsYXN0IHBhcmE6IFRoZSBNVVNUIGhlcmUgc2VlbXMgbGlrZSBpdCBtYXkgYmUgcXVpdGUN Cj4gPj4+PiBvbmVyb3VzLCBpbiBnZW5lcmFsLiBEaWQgc29tZW9uZSB0aGluayBhbGwgb2YgdGhh dCB0aHJvdWdoPyBGb3INCj4gPj4+PiBleGFtcGxlLCB3aGF0IGlmIHRoZSByZWFzb24gZm9yIGRl Y2xpbmluZyBpcyB0aGF0IHRoZSBTdWJzY3JpYmVyDQo+ID4+Pj4gZG9lc24ndCBoYXZlIHN1ZmZp Y2llbnQgcHJpdmlsZWdlPyBTYXlpbmcgd2hhdCBwcml2aWxlZ2UgaXMgbmVlZGVkDQo+ID4+Pj4g d291bGQgYmUgYSBicmVhY2ggb2YgbGVhc3QtcHJpdmlsZWdlLiBUcmFuc2llbnQgZXJyb3JzIG1h eSBhbHNvDQo+ID4+Pj4gbWFrZSB0aGlzIHZlcnkgaGFyZCB0byBkbyB3ZWxsLiBJJ2Qgc3VnZ2Vz dCBzL01VU1QvTUFZLyBhbmQgdG8gYWxzbw0KPiA+Pj4+IHR1cm4gdGhlIGluZm9ybWF0aW9uIHJl dHVybmVkIGludG8gYSBoaW50IGFuZCBub3QgYSBwcm9taXNlLg0KPiA+Pj4+DQo+ID4+Pj4gLSA0 LjIuNSwgcGFyYSAxOiBzYXlpbmcgdGhlcmUgIk1VU1QgYmUgbXV0dWFsIGF1dGhlbnRpY2F0aW9u IiBpcw0KPiA+Pj4+IG9kZCAtIHRoZSB1c3VhbCB0ZXJtcyB3b3VsZCBiZSAiTVVTVCBpbXBsZW1l bnQiIG9yICJNVVNUIHVzZSIgd2hpY2gNCj4gPj4+PiBvZiB0aG9zZSBkb2VzICJNVVNUIGJlIiBt ZWFuPw0KPiA+Pj4+DQo+ID4+Pj4gLSA0LjIuODogd2hlbiB5b3Ugc2F5IGZldGNoLi4uIGJ5IHdo b20/IElzIHRoZXJlIGFuIGltcGxpY2l0DQo+ID4+Pj4gcmVxdWlyZW1lbnQgaW4gdGhlIHRpdGxl IG9mIHRoZSBzdWJzZWN0aW9uPw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBpMnJzIG1haWxpbmcgbGlzdA0KPiA+ Pj4+IGkycnNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p MnJzDQo+ID4NCg0K From nobody Tue May 17 12:31:13 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB2412D9E5; Tue, 17 May 2016 12:31:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160517193110.24776.60161.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 12:31:10 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-pub-sub-requirements-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:31:12 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-pub-sub-requirements-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the discussion! From nobody Tue May 17 16:41:32 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB50F12D10F; Tue, 17 May 2016 16:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.999, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsptP1sAZaBE; Tue, 17 May 2016 16:41:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C8D1812D0DF; Tue, 17 May 2016 16:41:20 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 889481E335; Tue, 17 May 2016 19:46:32 -0400 (EDT) Date: Tue, 17 May 2016 19:46:32 -0400 From: Jeffrey Haas To: draft-ietf-i2rs-security-environment-reqs@ietf.org, i2rs@ietf.org Message-ID: <20160517234632.GG17462@pfrc.org> References: <20160404200101.15723.87315.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20160404200101.15723.87315.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-security-environment-reqs-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 23:41:28 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Authors, Upon review of the environment security requirements, I found a number of items to comment upon. Since the majority of these were spelling or grammar, I chose to simply provide you a diff. https://github.com/jhaas-pfrc/i2rs-2016/blob/jhaas/draft-ietf-i2rs-security-environment-reqs-01-comments/draft-ietf-i2rs-security-environment-reqs/draft-ietf-i2rs-security-environment-reqs.xml The above github link will take you to a repository containing your draft with edits. The "master" branch contains the IETF sourced .xml and .txt files. Thus, you can clone this repository and get access to the diff. Please note I have flagged some issues within the .xml as XXX JMH and that these issues require separate attention. I am also attaching a rfcdiff showing the suggested edits. -- Jeff On Mon, Apr 04, 2016 at 01:01:01PM -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System of the IETF. > > Title : I2RS Environment Security Requirements > Authors : Daniel Migault > Joel Halpern > Susan Hares > Filename : draft-ietf-i2rs-security-environment-reqs-01.txt > Pages : 19 > Date : 2016-04-04 > > Abstract: > This document provides environment security requirements for the I2RS > architecture. Environment security requirements are independent of > the protocol used for I2RS. As a result, the requirements provided > in this document are intended to provide good security practise so > I2RS can be securely deployed and operated. > > These security requirements are designated as environment security > requirements as opposed to the protocol security requirements. The > reason to have separate document is that protocol security > requirements are intended to help the design of the I2RS protocol > whether the environment requirements are rather intended for > deployment or implementations. --M9NhX3UHpAaciwkO Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-i2rs-security-environment-reqs-from--01.diff.html" Diff: draft-ietf-i2rs-security-environment-reqs-01.txt - draft-ietf-i2rs-security-environment-reqs.txt
 draft-ietf-i2rs-security-environment-reqs-01.txt   draft-ietf-i2rs-security-environment-reqs.txt 
I2RS WG D. Migault, Ed. I2RS WG D. Migault, Ed.
Internet-Draft J. Halpern Internet-Draft J. Halpern
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: October 6, 2016 S. Hares Expires: November 18, 2016 S. Hares
Huawei Huawei
April 4, 2016 May 17, 2016
I2RS Environment Security Requirements I2RS Environment Security Requirements
draft-ietf-i2rs-security-environment-reqs-01 draft-ietf-i2rs-security-environment-reqs-02
Abstract Abstract
This document provides environment security requirements for the I2RS This document provides environment security requirements for the I2RS
architecture. Environment security requirements are independent of architecture. The environment security requirements are independent
the protocol used for I2RS. As a result, the requirements provided of the protocol used for I2RS and are intended to document the
in this document are intended to provide good security practise so deployment and operational environment of I2RS.
I2RS can be securely deployed and operated.
These security requirements are designated as environment security
requirements as opposed to the protocol security requirements. The
reason to have separate document is that protocol security
requirements are intended to help the design of the I2RS protocol
whether the environment requirements are rather intended for
deployment or implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2016. This Internet-Draft will expire on November 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4
4. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4 4. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4
4.1. I2RS plane and management plane . . . . . . . . . . . . . 4 4.1. I2RS Plane and management plane . . . . . . . . . . . . . 4
4.2. I2RS plane and forwarding plane . . . . . . . . . . . . . 5 4.2. I2RS Plane and forwarding plane . . . . . . . . . . . . . 5
4.3. I2RS plane and Control plane . . . . . . . . . . . . . . 6 4.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 6
4.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 6 4.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 6
5. I2RS Access Control for routing system resources . . . . . . 8 5. I2RS Access Control for routing system resources . . . . . . 8
5.1. I2RS Access Control architecture . . . . . . . . . . . . 8 5.1. I2RS Access Control architecture . . . . . . . . . . . . 8
5.2. I2RS Agent Access Control policies . . . . . . . . . . . 13 5.2. I2RS Agent Access Control policies . . . . . . . . . . . 13
5.3. I2RS Client Access Control policies . . . . . . . . . . . 14 5.3. I2RS Client Access Control policies . . . . . . . . . . . 14
5.4. Application and Access Control policies . . . . . . . . . 15 5.4. Application and Access Control policies . . . . . . . . . 15
6. I2RS Application Isolation . . . . . . . . . . . . . . . . . 16 6. I2RS Application Isolation . . . . . . . . . . . . . . . . . 15
6.1. Robustness toward programmability . . . . . . . . . . . . 16 6.1. Robustness Toward Programmability . . . . . . . . . . . . 16
6.2. Application Isolation . . . . . . . . . . . . . . . . . . 17 6.2. Application Isolation . . . . . . . . . . . . . . . . . . 17
6.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.2. Application Control . . . . . . . . . . . . . . . . . 17 6.2.2. Application Control . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 10 skipping to change at page 2, line 47
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document provides environment security requirements for the I2RS This document provides environment security requirements for the I2RS
architecture. Environment security requirements are independent of architecture. Environment security requirements are independent of
the protocol used for I2RS. As a result, the requirements provided the protocol used for I2RS. As a result, the requirements provided
in this document are intended to provide good security practise so in this document are intended to provide good security practice so
I2RS can be securely deployed and operated. I2RS can be securely deployed and operated.
These security requirements are designated as environment security These security requirements are designated as environment security
requirements as opposed to the protocol security requirements requirements as opposed to the protocol security requirements
described in [I-D.ietf-i2rs-protocol-security-requirements]. The described in [I-D.ietf-i2rs-protocol-security-requirements]. The
reason to have separate document is that protocol security reason to have separate document is that protocol security
requirements are intended to help the design of the I2RS protocol requirements are intended to help the design of the I2RS protocol
whether the environment requirements are rather intended for whether the environment requirements are rather intended for
deployment or implementations. deployment or implementations.
Even though I2RS is mostly concerned by the interface between the Even though I2RS is mostly concerned with the interface between the
I2RS Client and the I2RS Agent, the security recommendations must I2RS Client and the I2RS Agent, the security recommendations must
consider the entire I2RS architecture, specifying where security consider the entire I2RS architecture, specifying where security
functions may be hosted, and what should be met so to address any new functions may be hosted, and what should be met so to address any new
attack vectors exposed by deploying this architecture. In other attack vectors exposed by deploying this architecture. In other
words, security has to be considered globally over the complete I2RS words, security has to be considered globally over the complete I2RS
architecture and not only on the interfaces. architecture and not only on its interfaces.
I2RS architecture depicted in [I-D.ietf-i2rs-architecture] describes The I2RS architecture depicted in [I-D.ietf-i2rs-architecture]
the I2RS components and their interactions to provide a programmatic describes the I2RS components and their interactions to provide a
interface for the routing system. I2RS components as well as their programmatic interface for the routing system. I2RS components, as
interactions have not yet been considered in conventional routing well as their interactions, have not yet been considered in
systems. As such it introduces a need to interface with the routing conventional routing systems. As such, it introduces a need to
system designated as I2RS plane in this document. interface with the routing system designated as the I2RS Plane in
this document.
This document is built as follows. Section 4 describes how the I2RS This document is structured as follows:
plane can be contained or isolated from existing management plane,
control plane and forwarding plane. The remaining sections of the o Section 4 describes how the I2RS Plane can be contained or
document focuses on the security within the I2RS plane. Section 5 isolated from existing management plane, control plane and
analyzes how the I2RS Access Control policies can be deployed forwarding plane. The remaining sections of the document focuses
throughout the I2RS plane in order to only grant access to the on the security within the I2RS Plane.
routing system resources to authorized components with the authorized
privileges. This also includes providing a robust communication o Section 5 analyzes how the I2RS Access Control policies can be
system between the components. Then, Section 6 details how I2RS deployed throughout the I2RS Plane in order to only grant access
keeps applications isolated one from another and do not affect the to the routing system resources to authorized components with the
I2RS components. Applications may be independent, with different authorized privileges. This also includes providing a robust
scopes, owned by different tenants. In addition, they modify the communication system between the components.
routing system that may be in an automatic way.
o Section 6 details how I2RS keeps applications isolated one from
another and do not affect the I2RS components. Applications may
be independent, with different scopes, owned by different tenants.
In addition, they modify the routing system that may be in an
automatic way.
The reader is expected to be familiar with the The reader is expected to be familiar with the
[I-D.ietf-i2rs-architecture]. The document provides a list of [I-D.ietf-i2rs-architecture]. The document provides a list of
environment security requirements. Motivations are placed before the environment security requirements. Motivations are placed before the
requirements are announced. related requirements.
3. Terminology and Acronyms 3. Terminology and Acronyms
- Environment Security Requirements : I2RS Plane: The environment the I2RS architecture is running on. It
includes the Applications, the I2RS Clients and the I2RS Agent.
- I2RS plane : The environment the I2RS process is running on. It
includes the Applications, the I2RS Client and the I2RS Agent.
- I2RS user : The user of the I2RS client software or system. I2RS User: The user of the I2RS client software or system.
- I2RS Access Control policies: policies controlling access of the I2RS Access Control policies: Policies controlling access of the
routing resources by Applications. These policies are divided routing resources by Applications. These policies are divided
into policies applied by the I2RS Client regarding Applications into policies applied by the I2RS Client regarding Applications
and policies applied by the I2RS Agent regarding I2RS Clients. and policies applied by the I2RS Agent regarding I2RS Clients.
- I2RS Client Access Control policies : The Access Control policies I2RS Client Access Control policies: The Access Control policies
processed by the I2RS Client. processed by the I2RS Client.
- I2RS Agent Access Control policies : The Access Control policies I2RS Agent Access Control policies: The Access Control policies
processed by the I2RS Agent. processed by the I2RS Agent.
4. I2RS Plane Isolation 4. I2RS Plane Isolation
Isolating the I2RS plane from other network plane, such as the Isolating the I2RS Plane from other network planes, such as the
control plane, is foundational to the security of the I2RS control plane, is foundational to the security of the I2RS
environment. Clearly differentiating I2RS components from the rest environment. Clearly differentiating I2RS components from the rest
of the network protects the I2RS components from vulnerabilities in of the network protects the I2RS components from vulnerabilities in
other parts of the network, and protect other systems vital to the other parts of the network, and protect other systems vital to the
health of the network from vulnerabilities in the I2RS plane. health of the network from vulnerabilities in the I2RS Plane.
Separating the I2RS plane from other network control and forwarding Separating the I2RS Plane from other network control and forwarding
planes is similar to the best common practice of containerizing planes is similar to the best common practice of containerizing
software into modules, and defense in depth in the larger world of software into modules, and defense in depth in the larger world of
network security. network security.
That said the I2RS plane cannot be considered as completely isolated That said, the I2RS Plane cannot be considered as being completely
from other planes, and interactions should be identified and isolated from other planes, and interactions should be identified and
controlled. Follows a brief description on how the I2RS plane controlled. The following sections provide brief descriptions on how
positions itself in regard to the other planes. The description is the I2RS Plane positions itself with regard to the other planes.
indicative, and may not be exhaustive.
4.1. I2RS plane and management plane 4.1. I2RS Plane and management plane
The I2RS plane purpose is to provide a standard programmatic The purpose of the I2RS Plane is to provide a standard programmatic
interface of the routing system resources to network oriented interface to the routing system resources for network-oriented
applications. Control plane and forwarding planes are related to applications. Control and forwarding planes are related to routing
routing protocols, and I2RS is based on top of those. The management protocols, and I2RS is based on top of those. The management plane
plane is usually vendor specific, provides a broader control over the is usually vendor specific, and provides broader control over the
networking equipment such as system service. Given its associated networking equipment such as system services. Given its associated
privileges it is expected to be reserved to highly trusted users like privileges, it is expected to be reserved for highly trusted users
network administrators. such as network administrators.
The I2RS plane and the management plane both interact with several The I2RS Plane and the management plane both interact with several
common elements on forwarding and packet processing devices. common elements on forwarding and packet processing devices.
[I-D.ietf-i2rs-architecture] describes several of these interaction [I-D.ietf-i2rs-architecture] describes several of these interaction
points such as the local configuration, the static system state, points such as local configuration, static system state, routing, and
routing, and signalling. Because of this potential overlaps, a signaling. Because of these potential overlaps, a routing resource
routing resource may be accessed by different means (APIs, may be accessed by different means (e.g., APIs and applications) and
applications) and different planes. To keep these overlaps under different planes. To keep these overlaps under control, one could
control, one could either control the access to these resources with control access to these resources with northbound APIs, for example.
northbound APIs for example. Northbound APIs are provided to limit Northbound APIs are provided to limit the scope of the applications
the scope of the applications toward the routing resources. In our toward the routing resources. In our case, the northbound API may be
case, the northbound API may be provided for the I2RS applications by provided for the I2RS applications by the I2RS Client as well as to
the I2RS Client as well as to the management plane. In case the management plane. When conflicting overlaps cannot be avoided,
conflicting overlaps cannot be avoided, and routing resource can be and routing resource can be accessed by both the management plane and
accessed by both the management plane and the I2RS plane, then, they the I2RS Plane, they should be resolved in a deterministic way.
should be resolved in a deterministic way.
On the northbound side, there must be clear protections against the On the northbound side, there must be clear protections against the
I2RS system "infecting" the management system with bad information, I2RS system "infecting" the management system with bad information,
or the management system "infecting" the I2RS system with bad or vice-versa. The primary protection in this space is going to need
information. The primary protection in this space is going to need
to be validation rules on the speed of information flow, value limits to be validation rules on the speed of information flow, value limits
on the data presented, and other protections of this type. on the data presented, and other protections of this type.
On the conflicting side/issues, there should be clear rules about On the conflicting side/issues, there should be clear rules about
which plan's commands win in the case of conflict in order to prevent which plan's commands win in the case of conflict in order to prevent
attacks where the two systems can be forced to deadlock. attacks where the two systems can be forced to deadlock.
4.2. I2RS plane and forwarding plane 4.2. I2RS Plane and forwarding plane
Applications hosted on I2RS Client belongs to the I2RS plane. These Applications hosted on I2RS Client belong to the I2RS Plane. These
Applications are hard to remain constrained into the I2RS plane, or Applications are hard to remain constrained into the I2RS Plane, or
even to limit their scope within the I2RS plane. even to limit their scope within the I2RS Plane.
Applications using I2RS are part of the I2RS plane but may also Applications using I2RS are part of the I2RS Plane but may also
interact with other components outside the I2RS plane. A common interact with other components outside the I2RS Plane. A common
example may be an application uses I2RS to configure the network example may be an application that uses I2RS to configure the network
according to security or monitored events. As these events are according to security or monitored events. Since these events are
monitored on the forwarding plane and not the I2RS plane, the monitored on the forwarding plane and not in the I2RS Plane, the
application breaks plane isolation. application breaks plane isolation.
In addition, applications may communicate with multiple I2RS Clients; In addition, applications may communicate with multiple I2RS Clients.
as such, any given application may have a broader view of the current Thus any given application may have a broader view of the current and
and potential states of the network and the I2RS plane itself. potential states of the network and the I2RS Plane itself. Because
of this, any individual application could be an effective attack
Because of this, any individual application could be an effective vector against the operation of the network, the I2RS Plane, or any
attack vector against the operation of the network, the I2RS plane, plane with which the I2RS Plane interacts. There is little the I2RS
or any plane with which the I2RS plane interacts. There is little Plane can do to validate applications with which it interacts, other
the I2RS plane can do to validate applications with which it than to provide some general validation against common
interacts, other than to provide some broad general validations misconfigurations or errors. As with the separation between the
against common misconfigurations or errors. As with the separation management plane and the I2RS Plane, this should minimally take the
between the management plane and the I2RS plane, this should form of limits on information accepted, limits on the rate at which
minimally take the form of limits on information accepted, limits on information is accepted, and rudimentary checks against intentionally
the rate at which information is accepted, and rudimentary checks formed routing loops or injecting information that would cause the
against intentionally formed routing loops or injecting information control plane to fail to converge. Other forms of protection may be
that would cause the control plane to fail to converge. Other forms necessary.
of protection may be necessary.
4.3. I2RS plane and Control plane 4.3. I2RS Plane and Control Plane
The network control plane consists of the processes and protocols The network control plane consists of the processes and protocols
that discover topology, advertise reachability, and determine the that discover topology, advertise reachability, and determine the
shortest path between any location on the network and any path between any location on the network and any destination. It is
destination. It is not anticipated there will be any interactions not anticipated there will be any interactions between the on-the-
between the on-the-wire signalling used by the control plane. wire signaling used by the control plane and the I2RS Plane.
However, in some situations the I2RS system could modify information However, in some situations the I2RS system could modify information
in the local databases of the control plane. This is not normally in the local databases of the control plane. This is not normally
recommended, as it can bypass the normal loop free, loop free recommended, as it can bypass the normal loop free, loop free
alternate, and convergence properties of the control plane. However, alternate, and convergence properties of the control plane. However,
if the I2RS system does directly inject information into these if the I2RS system does directly inject information into these
tables, the I2RS system should ensure that loop free routing is tables, the I2RS system should ensure that loop free routing is
preserved, including loop free alternates, tunnelled interfaces, preserved, including loop free alternates, tunneled interfaces,
virtual overlays, and other such constructions. Any information virtual overlays, and other such constructions. Any information
injected into the control plane directly could cause the control injected into the control plane directly could cause the control
plane to fail to converge, resulting in a complete network outage. plane to fail to converge, resulting in a complete network outage.
4.4. Recommendations 4.4. Recommendations
To isolate I2RS transactions from other planes, it is recommended To isolate I2RS transactions from other planes, it is recommended
that: that:
REQ 1: Application-to-routing system resources communications should REQ 1: Application-to-routing system resources communications should
use an isolated communication channel. Various level of use an isolated communication channel. Various levels of
isolation can be considered. The highest level of isolation isolation can be considered. The highest level of isolation
may be provided by using a physically isolated network. could be provided by using a physically isolated network.
Alternatives may also consider logical isolation; for example Alternatives may also include logical isolation; for example
by using vLAN. Eventually, in virtual environment that by using vLANs. In virtual environments that share a common
shares a common infrastructure, encryption, for example by infrastructure, encryption - for example, TLS or IPsec - may
using TLS or IPsec, may also be used as a way to enforce also be used as a way to enforce isolation.
isolation.
REQ 2: The interface (like the IP address) used by the routing REQ 2: The IP interface used by the routing element to receive I2RS
element to receive I2RS transactions should be a dedicated transactions should be a dedicated physical or logical
physical or logical interface. As previously, mentioned a interface. As previously mentioned, a dedicated physical
dedicated physical interface may contribute to a higher interface may contribute to higher isolation. However,
isolation, however logical isolation be also be considered logical isolation be also be considered - for example, by
for example by using a dedicated IP address or a dedicated using a dedicated IP address or a dedicated port.
port.
When the I2RS Agent performs an action on a routing element, the When the I2RS Agent performs an action on a routing element, the
action is performed via process(es) associated to a system user . In action is performed via process(es) associated to a system user . In
a typical UNIX system, the user is designated with a user id (uid) a typical UNIX system, the user is designated with a user id (uid)
and belong to groups designated by group ids (gid). These users are and belong to groups designated by group ids (gid). These users are
dependent of the routing element's operation system and are dependent of the routing element's operating system and are
designated I2RS System Users. Some implementation may use a I2RS designated I2RS System Users. Some implementation may use a single
System User for the I2RS Agent that proxies the different I2RS I2RS System User for the I2RS Agent that proxies the different I2RS
Client, other implementations may use I2RS System User for each Clients, other implementations may use distinct I2RS System Users for
different I2RS Clients. each I2RS Client.
REQ 3: I2RS Agent should have permissions separate from any other REQ 3: I2RS Agents should have permissions separate from any other
entity (for example any internal system management processes entity; for example, any internal system management or CLI
or CLI processes). processes.
I2RS resource may be shared with the management plane and the control I2RS resources may be shared with the management plane and the
plane. It is hardly possible to prevent interactions between the control plane. It is hardly possible to prevent interactions between
planes. I2RS routing system resource management is limited to the the planes. I2RS routing system resource management is limited to
I2RS plane. As such, update of I2RS routing system outside of the the I2RS Plane. As such, updates to an I2RS-enabled routing system
I2RS plane may be remain unnoticed unless explicitly notified to the outside of the I2RS Plane may remain unnoticed unless the I2RS Plane
I2RS plane. Such notification is expected to trigger synchronization is explicitly notified. Such notification is expected to trigger
of the I2RS resource state within each I2RS component. This synchronization of the I2RS resource state within each I2RS
guarantees that I2RS resource are maintained in a coherent state component. This guarantees that I2RS resource are maintained in a
among the I2RS plane. In addition, depending on the I2RS resource coherent state within the I2RS Plane. In addition, depending on the
that is updated as well as the origin of the modification performed, I2RS resource that is updated as well as the origin of the
the I2RS Access Control policies may be impacted. More especially, a modification performed, the I2RS Access Control policies may be
I2RS Client is more likely to update an I2RS resources that has been impacted. For example, an I2RS Client is more likely to update an
updated by itself, then by the management plane for example. I2RS resources that has been updated by itself than by the management
plane.
REQ 4: I2RS plane should be informed when a routing system resource REQ 4: The I2RS Plane should be informed when a routing system
is modified by a user outside the I2RS plane access. The resource used by that plane is externally modified. The
notification is not expected to flood the I2RS plane. notification is not expected to flood the I2RS Plane.
Instead, notification is expected to be provided to the I2RS Instead, the notification is expected to be provided to the
components interacting, configuring or monitoring the routing I2RS components interacting, configuring or monitoring the
system resource. The notification is at least provided by routing system resource. The notification is at least
the I2RS Agent to the various I2RS Client, but additional provided by the I2RS Agent to the various I2RS Client, but
mechanisms might eventually be required so I2RS Client can additional mechanisms might eventually be required so I2RS
relay the notification to the I2RS applications. This is Client can relay the notification to the I2RS applications.
designated as "I2RS resource modified out of I2RS plane". This is designated as "I2RS resource modified out of I2RS
This requirements is also described in section 7.6 of Plane". This requirements is also described in section 7.6
[I-D.ietf-i2rs-architecture] for the I2RS Client. This of [I-D.ietf-i2rs-architecture] for the I2RS Client. This
document extends the requirement to the I2RS plane, in case document extends the requirement to the I2RS Plane, in case
future evolution of the I2RS plane. future evolution of the I2RS Plane.
REQ 5: I2RS plane should define an "I2RS plane overwrite policy". REQ 5: The I2RS Plane should define an "I2RS Plane overwrite
Such policy defines how an I2RS is able to update and policy". Such policy defines how an I2RS is able to update
overwrite a resource set by a user outside the I2RS plane. and overwrite a resource set by a user outside the I2RS
Such hierarchy has been described in section 6.3 and 7.8 of Plane. Such hierarchy has been described in section 6.3 and
[I-D.ietf-i2rs-architecture] 7.8 of [I-D.ietf-i2rs-architecture]
5. I2RS Access Control for routing system resources 5. I2RS Access Control for routing system resources
This section provides recommendations on how I2RS Access Control This section provides recommendations on how I2RS Access Control
policies associated to the routing system resources. These policies policies are associated to the routing system resources. These
only apply within the I2RS plane. More especially, the policies are policies only apply within the I2RS Plane. More especially, the
associated to the Applications, the I2RS Clients and the I2RS Agents, policies are associated to the Applications, the I2RS Clients, and
with their associated identity and roles. the I2RS Agents with their associated identity and roles.
Note that the deployment of Applications, I2RS Client and I2RS Agent Note that the deployment of Applications, I2RS Client, and I2RS Agent
in a closed environment, should not be considered by default as a in a closed environment should not be considered by default as a
secure environment. Even for closed environment access control secure environment. Even for closed environment access control
policies should be carefully defined to be able to, in the future to policies should be carefully defined to be able to, in the future,
carefully extend the I2RS plane to remote Applications or remote I2RS carefully extend the I2RS Plane to remote Applications or remote I2RS
Clients. As a result, this section always consider the case Clients. As a result, this section always consider the case where
Applications and I2RS Client can be located locally, in a closed Applications and I2RS Client can be located locally, in a closed
environment or distributed over open networks. environment, or distributed over open networks.
Although [I-D.ietf-i2rs-protocol-security-requirements] provides Although [I-D.ietf-i2rs-protocol-security-requirements] provides
security requirements of the transport and protocol between the I2RS security requirements for the transport and protocol between the I2RS
Client and the I2RS Agent, this section is mostly focused on access Client and the I2RS Agent, this section is mostly focused on access
control. control.
5.1. I2RS Access Control architecture 5.1. I2RS Access Control architecture
Applications access to routing system resource via numerous Application access to routing system resources via numerous
intermediaries nodes. The application communicates with an I2RS intermediaries nodes. The application communicates with an I2RS
Client. In some cases, the I2RS Client is only associated to a Client. In some cases, the I2RS Client is only associated to a
single application, but the I2RS Client may also act as a broker. single application, but the I2RS Client may also act as a broker.
The I2RS Client, then, communicates with the I2RS Agent that may The I2RS Client communicates with the I2RS Agent that may eventually
eventually access the resource. access the resource.
The I2RS Client broker approach provides scalability to the I2RS The I2RS Client broker approach provides scalability to the I2RS
architecture as it avoids that each Application be registered to the architecture since it avoids requiring each Application be registered
I2RS Agent. Similarly, the I2RS Access Control should be able to with the I2RS Agent. Similarly, I2RS Access Control should be able
scale numerous applications. to scale numerous applications.
REQ 6: I2RS Access Control should be performed through the whole REQ 6: I2RS Access Control should be performed throughout the I2RS
I2RS plane. It should not be enforced by the I2RS Agent only Plane. It should not be enforced by the I2RS Agent only
within the routing element. Instead, the I2RS Client should within the routing element. Instead, the I2RS Client should
enforce the I2RS Client Access Control against Applications enforce the I2RS Client Access Control against Applications
and the I2RS Agent should enforce the I2RS Agent Access and the I2RS Agent should enforce the I2RS Agent Access
Control against the I2RS Clients. Note that I2RS Client Control against the I2RS Clients. Note that I2RS Client
Access Control is not in the scope of the I2RS architecture Access Control is not in the scope of the I2RS architecture
[I-D.ietf-i2rs-architecture], which exclusively focuses on [I-D.ietf-i2rs-architecture], which exclusively focuses on
the I2RS Agent Access Control. the I2RS Agent Access Control.
This results in a layered and hierarchical or multi-party I2RS Access This results in a layered and hierarchical or multi-party I2RS Access
Control. An application will be able to access a routing system Control. An application will then be able to access a routing system
resource only if both the I2RS Client is granted access by the I2RS resource only if both the I2RS Client is granted access by the I2RS
Agent and the application is granted access by the I2RS Client. Agent and the application is granted access by the I2RS Client.
REQ 7: When an access request to a routing resource is refused by REQ 7: When an access request to a routing resource is refused by
one party (the I2RS Client or the I2RS Agent), the initiator one party (the I2RS Client or the I2RS Agent), the initiator
of the request (e.g the Application) as well as all of the request (e.g., the Application) as well as all
intermediaries should indicate the reason the access has not intermediaries should indicate the reason the access has not
been granted as well as the entity that has rejected the been granted, as well as the entity that has rejected the
request. request.
REQ 8: In order to provide coherent Access Control policies enforced REQ 8: In order to provide coherent Access Control policies enforced
by multiple parties (e.g. the I2RS Client or the I2RS Agent), by multiple parties (e.g., the I2RS Client or the I2RS
theses parties should trust each others, and communication Agent), these parties should trust each other, and
between them should also be trusted, - that is should not communication between them should also be trusted; that is
introduce additional vector of attacks. they should not introduce additional vectors of attack.
In case the I2RS Client Access Control or the I2RS Agent Access In case the I2RS Client Access Control or the I2RS Agent Access
Control does not grant access to a routing system resource, the Control does not grant access to a routing system resource, the
Application should be able to determine whether its request has been Application should be able to determine whether its request has been
rejected by the I2RS Client or the I2RS Agent as well as the reason rejected by the I2RS Client or the I2RS Agent as well as the reason
that caused the reject. More specifically, the I2RS Agent may reject that caused the rejection. More specifically, the I2RS Agent may
the request because, for example, the I2RS Client is not an reject the request because, for example, the I2RS Client is not an
authorized I2RS Client, or because the I2RS Client does not not have authorized I2RS Client, or because the I2RS Client does not not have
enough privileges. The I2RS Client should be notified of the reason enough privileges. The I2RS Client should be notified of the reason
that caused the reject by the I2RS Agent, and The I2RS Client should that caused the rejection by the I2RS Agent, and The I2RS Client
return a message to the Application, indicating the I2RS Client is should return a message to the Application, indicating the I2RS
not authorized or does not have enough privileges. Similarly, if the Client is not authorized or does not have enough privileges.
I2RS Client does not grant the access to the Application, the I2RS Similarly, if the I2RS Client does not grant access to the
Client should also inform the Application. The error message Application, the I2RS Client should also inform the Application.
returned should be for example: "Read failure: you do not have the
read permission", "Write failure: you do not have write permission" For example, the error message returned could be: "Read failure: you
or "Write failure: resource accessed by someone else". This do not have read permission", "Write failure: you do not have write
requirement has been written in a generic manner as it concerns permission", or "Write failure: resource accessed by someone else".
This requirement has been written in a generic manner as it concerns
various interactions: interactions between the application and the various interactions: interactions between the application and the
I2RS Client, interactions between the I2RS Client and the I2RS Agent. I2RS Client, interactions between the I2RS Client and the I2RS Agent.
In the latest case, the requirement is part of the protocol security In the latest case, the requirement is part of the protocol security
requirements addressed by requirements addressed by
[I-D.ietf-i2rs-protocol-security-requirements]. [I-D.ietf-i2rs-protocol-security-requirements].
Although [I-D.ietf-i2rs-protocol-security-requirements] is focused on Although [I-D.ietf-i2rs-protocol-security-requirements] is focused on
transport security requirements between the I2RS Client and the I2RS transport security requirements between the I2RS Client and the I2RS
Agent, the similar requirements may apply between the Application and Agent, similar requirements may apply between the Application and the
the I2RS Client for a remote Application. I2RS Client for a remote Application.
REQ 9: I2RS Client or I2RS Agent SHOULD also be able to refuse a REQ 9: An I2RS Client or I2RS Agent SHOULD also be able to refuse
communication with an Application or an I2RS Client when the communication with an Application or an I2RS Client when the
communication channel does not fulfill enough security communication channel does not fulfill enough security
requirements. For example, the it should be able to reject requirements. For example, it should be able to reject
messages over a communication channel that can be easily messages over a communication channel that can be easily
hijacked, like a clear text UDP channel. hijacked, such as a clear text UDP channel.
In order to limit the number of access request that result in an In order to limit the number of access request that result in an
error, each Application or I2RS Client may be able to retrieve the error, each Application or I2RS Client may be able to retrieve the
I2RS Access Control policies that applies to it. This subset of I2RS Access Control policies that apply to it. This subset of rules
rules is designated as the "Individual I2RS Access Control policies". is designated as the "Individual I2RS Access Control policies". As
As these policies are subject to changes, a dynamic synchronization these policies are subject to changes, a dynamic synchronization
mechanism should be provided. However, such mechanism may be mechanism should be provided. However, such mechanism may be
implemented with different level of completeness and dynamicity of implemented with different levels of completeness and dynamicity of
the Individual I2RS Access Control policies. Caching requests that the Individual I2RS Access Control policies. Caching requests that
have been rejected may be one such variant. It remains relatively have been rejected may be one such variant. It remains relatively
easy to implement and may avoid the complete disclosure of the Access easy to implement and may avoid the complete disclosure of the Access
Control policies of the I2RS Agent. In fact the relative disclosure Control policies of the I2RS Agent. In fact the relative disclosure
of Access Control policies may leak confidential information in case of Access Control policies may leak confidential information in case
of misconfiguration and should be balanced with the level of trust of of misconfiguration and should be balanced with the level of trust of
the I2RS Client and the necessity of distributing the enforcement of the I2RS Client and the necessity of distributing the enforcement of
the Access Control policies. the Access Control policies.
REQ 10: The I2RS Client may be able to request for its I2RS Access REQ 10: The I2RS Client may be able to request its I2RS Access
Control subset policies to the I2RS Agent or cache requests Control subset policies from the I2RS Agent, or cache
that have been rejected by the I2RS Agent to limit forwarding requests that have been rejected by the I2RS Agent to limit
unnecessary queries to the I2RS Agent. forwarding unnecessary queries to that I2RS Agent.
REQ 11: The I2RS Client may be able to be notified when its I2RS REQ 11: An I2RS Client should be able to be notified when its I2RS
Access Control subset policies have been updated by the I2RS Access Control subset policies have been updated by the I2RS
Agent. Agent.
Similarly, for the Applications Similarly, for the Applications:
REQ 12: The Applications may be able to request for its I2RS Access REQ 12: Applications may be able to request its I2RS Access Control
Control subset policies, so to limit forwarding unnecessary subset policies, in order to limit forwarding unnecessary
queries to the I2RS Client. queries to the I2RS Client.
REQ 13: The Applications may be able to subscribe a service that REQ 13: Applications may be able to subscribe to a service that
provides notification when its I2RS Access Control subset provides notification when its I2RS Access Control subset
policies have been updated. policies have been updated.
I2RS Access Control should be appropriately be balanced between the I2RS Access Control should be appropriately be balanced between the
I2RS Client and the I2RS Agent. I2RS Access Control should not I2RS Client and the I2RS Agent. I2RS Access Control should not
solely rely only on the I2RS Client or the I2RS Agent as illustrated solely rely only on the I2RS Client or the I2RS Agent as illustrated
below: below:
- 1) I2RS Clients are dedicated to a single Application: In this 1. I2RS Clients are dedicated to a single Application: In this
case, it is likely that I2RS Access Control is enforced only by case, it is likely that I2RS Access Control is enforced only by
the I2RS Agent, as the I2RS Client is likely to accept all the I2RS Agent, as the I2RS Client is likely to accept all access
access request of the application. However, it is recommended request of the application. However, it is recommended that even
that even in this case, I2RS Client Access Control is not based in this case, I2RS Client Access Control is not based on an
on an "Allow anything from application" policy, but instead the "Allow anything from application" policy, but instead the I2RS
I2RS Client specifies accesses that are enabled. In addition, Client specifies accesses that are enabled. In addition, the
the I2RS Client may sync its associated I2RS Access Control I2RS Client may sync its associated I2RS Access Control policies
policies with the I2RS Agent to limit the number of refused with the I2RS Agent to limit the number of refused access
access requests being sent to the I2RS Agent. The I2RS Client requests being sent to the I2RS Agent. The I2RS Client is
is expected to balance pro and cons between sync its access expected to balance pro and cons between sync its access control
control policies with the I2RS Agent and simply guessing the policies with the I2RS Agent and simply guessing the access
access request to the I2RS Agent. request to the I2RS Agent.
- 2) A single I2RS Client acts as a broker for all Applications: In 2. A single I2RS Client acts as a broker for all Applications: In
the case the I2RS Agent has a single I2RS Client. Such the case the I2RS Agent has a single I2RS Client. This
architecture results in I2RS Client with high privileges, as it architecture results in an I2RS Client with high privileges, as
sums the privileges of all applications. As end-to-end it provides the union of the privileges of all applications.
authentication is not provided between the Application and the Since end-to-end authentication is not provided between the
I2RS Agent, if the I2RS Client becomes corrupted, it is Application and the I2RS Agent, if the I2RS Client becomes
possible for the malicious application escalates its privileges compromised, it is possible for the malicious applications to
and make the I2RS Client perform some action on behalf of the escalate its privileges and make the I2RS Client perform some
application with more privileges. This would not have been action on behalf of the application with more privileges. This
possible with end-to-end authentication. In order to mitigate would not have been possible with end-to-end authentication. In
such attack, the I2RS Client that acts as a broker is expected order to mitigate such attack, the I2RS Client that acts as a
to host application with an equivalent level of privileges. broker is expected to host application with an equivalent level
of privileges.
REQ 14: The I2RS Access Control should explicitly specify accesses REQ 14: I2RS Access Control should explicitly specify accesses that
that are granted. More specifically, anything not explicitly are granted. More specifically, anything not explicitly
granted -- the default rule-- should be denied. granted - the default rule - should be denied.
In addition to distribute the I2RS Access Control policies between In addition to distribute the I2RS Access Control policies between
I2RS Clients and I2RS Agents, I2RS Access Control policies can also I2RS Clients and I2RS Agents, I2RS Access Control policies can also
be distributed within a set of I2RS Clients or a set of I2RS Agents. be distributed within a set of I2RS Clients or a set of I2RS Agents.
REQ 15: I2RS Clients should be distributed and act as brokers for REQ 15: I2RS Clients should be distributed and act as brokers for
Applications that share roughly similar permissions. This Applications that share roughly similar permissions. This
avoids ending with over privileges I2RS Client compared to avoids ending with over privileges I2RS Client compared to
hosted applications and thus discourages applications to hosted applications and thus discourages applications to
perform privilege escalation within an I2RS Client. perform privilege escalation within an I2RS Client.
skipping to change at page 12, line 14 skipping to change at page 12, line 8
that are only provided read access to the routing system that are only provided read access to the routing system
resources does not need to perform any write access, and so resources does not need to perform any write access, and so
should not be provided these accesses. Suppose an I2RS should not be provided these accesses. Suppose an I2RS
Client requires write access to the resources. It is not Client requires write access to the resources. It is not
recommended to grant the I2RS Agent the write access in order recommended to grant the I2RS Agent the write access in order
to satisfy a unique I2RS Client. Instead, the I2RS Client to satisfy a unique I2RS Client. Instead, the I2RS Client
that requires write access should be connected to a I2RS that requires write access should be connected to a I2RS
Agent that is already shared by I2RS Client that requires a Agent that is already shared by I2RS Client that requires a
write access. write access.
Access Control policies enforcement should be monitored in order to Access Control policy enforcement should be monitored in order to
detect violation of the policies or detect an attack. Access Control detect violation of the policies or detect an attack. Access Control
policies enforcement may not be performed by the I2RS Client or the policy enforcement may not be performed by the I2RS Client or the
I2RS Agent as violation may require a more global view of the I2RS I2RS Agent since violation may require a more global view of the I2RS
Access Control policies. As a result, consistency check and Access Control policies. As a result, consistency checks and
mitigation may instead be performed by the management plane. mitigation may instead be performed by the management plane.
However, I2RS Clients and I2RS Agents play a central role. However, I2RS Clients and I2RS Agents play a central role.
REQ 17: I2RS Client and I2RS Agent should be able to log the various REQ 17: I2RS Clients and I2RS Agents should be able to log the
transaction they perform, as well as suspicious activities. various transactions they perform, as well as suspicious
These logs should be collected regularly and analyzed by activities. These logs should be collected regularly and
functions that may be out of the I2RS plane. analyzed by functions that may be out of the I2RS Plane.
Access Control policies should be implemented so that they remain Access Control policies should be implemented so that they remain
manageable in short and longer term. This means the way they are manageable in the short and longer term. This means the way they are
managed today should be address future deployment and use of I2RS. managed today should address future deployment and use of I2RS.
REQ 18: Access Control should be managed in an automated way, that is REQ 18: Access Control should be managed in an automated way, that is
granting or revoking an Application should not involve manual granting or revoking an Application should not involve manual
configuration over the I2RS plane - like all the I2RS configuration over the I2RS Plane, such as all the I2RS
Clients. Clients.
REQ 19: Access Control should be scalable when the number of REQ 19: Access Control should be scalable when the number of
Application grows as well as when the number of I2RS Client Applications grow, as well as when the number of I2RS Clients
increases. A typical implementation of a local I2RS Client increase. A typical implementation of a local I2RS Client
Access Control policies may result in creating manually a Access Control policy may result in manually creating a
system user associated to each Application. Such an approach system user associated with each Application. Such an
is likely not to scale when the number of Applications approach is likely not to scale when the number of
increases or the number of I2RS Client increases. Applications increase or the number of I2RS Clients increase.
REQ 20: Access Control should be dynamically managed and easy to be REQ 20: Access Control should be dynamically managed and easy to be
updated. Although the number of I2RS Clients is expected to updated. Although the number of I2RS Clients is expected to
be lower than the number of Application, as I2RS Agent be lower than the number of Application, as I2RS Agent
provide access to the routing resource, it is of primary provides access to the routing resource. It is of primary
importance that an access can be granted or revoke in an importance that access can be granted or revoked in an
efficient way. efficient way.
REQ 21: I2RS Clients and I2RS Agents should be uniquely identified in REQ 21: I2RS Clients and I2RS Agents should be uniquely identified in
the network to enable centralized management of the I2RS the network to enable centralized management of the I2RS
Access Control policies. Access Control policies.
5.2. I2RS Agent Access Control policies 5.2. I2RS Agent Access Control policies
The I2RS Agent Access Control restricts the routing system resource The I2RS Agent Access Control restricts the routing system resource
access to authorized identities - possible access policies may be access to authorized identities. Possible access policies may be
none, read or write. The initiator of an access request to a routing none, read or write. The initiator of an access request to a routing
resource is always an Application. However, it remains challenging resource is always an Application. However, it remains challenging
for the I2RS Agent to establish its access control policies based on for the I2RS Agent to establish its access control policies based on
the application that initiates the request. First, when an I2RS the application that initiates the request. First, when an I2RS
Client acts as a broker, the I2RS Agent may not be able to Client acts as a broker, the I2RS Agent may not be able to
authenticate the Application. In that sense, the I2RS Agent relies authenticate the Application. In that sense, the I2RS Agent relies
on the capability of the I2RS Client to authenticate the Applications on the capability of the I2RS Client to authenticate the Applications
and apply the appropriated I2RS Client Access Control. Then, an I2RS and apply the appropriated I2RS Client Access Control. Then, an I2RS
Agent may not uniquely identify a piece of software implementing an Agent may not uniquely identify a piece of software implementing an
I2RS Client. In fact, an I2RS Client may be provided multiple I2RS Client. In fact, an I2RS Client may be provided multiple
identities which can be associated to different roles or privileges. identities which can be associated to different roles or privileges.
The I2RS Client is left responsible for using them appropriately The I2RS Client is left responsible for using them appropriately
according to the Application. Finally, each I2RS Client may contact according to the Application. Finally, each I2RS Client may contact
various I2RS Agent with different privileges and Access Control various I2RS Agent with different privileges and Access Control
policies. policies.
This section provides recommendations on the I2RS Agent Access This section provides recommendations for the I2RS Agent Access
Control policies to keep I2RS Access Control coherent within the I2RS Control policies to keep I2RS Access Control coherent within the I2RS
plane. Plane.
REQ 22: I2RS Agent Access Control policies should be primarily based REQ 22: I2RS Agent Access Control policies should be primarily based
on the I2RS Clients as described in on the I2RS Clients as described in
[I-D.ietf-i2rs-architecture]. [I-D.ietf-i2rs-architecture].
REQ 23: I2RS Agent Access Control policies may be based on the REQ 23: I2RS Agent Access Control policies may be based on the
Application. In this case the identity of the Application Application. In this case the identity of the Application
MUST be authenticated by the I2RS Agent, and the secondary MUST be authenticated by the I2RS Agent, and the secondary
identity used to tag the application as defined in identity used to tag the application as defined in
[I-D.ietf-i2rs-architecture] should be considered cautiously. [I-D.ietf-i2rs-architecture] should be considered cautiously.
The tag may be used associated only to an authenticated I2RS The tag may be used associated only to an authenticated I2RS
Client that is known to authenticate its Application. Client that is known to authenticate its Application.
The I2RS Agent Access Control policies may evolve over time as The I2RS Agent Access Control policies may evolve over time as
resource may also be updated outside the I2RS plane. Similarly, a resources may also be updated outside the I2RS Plane. Similarly, a
given resource may be accessed by multiple I2RS users within the I2RS given resource may be accessed by multiple I2RS users within the I2RS
plane. Although this is considered as an error, depending on the Plane. Although this is considered as an error, depending on the
I2RS Client that performed the update, the I2RS may accept or refuse I2RS Client that performed the update, the I2RS may accept or refuse
to overwrite the routing system resource. to overwrite the routing system resource.
REQ 24: The I2RS Agent should know which identity (most likely system REQ 24: The I2RS Agent should know which identity (most likely system
user) performed the latest update of the routing resource. user) performed the latest update of the routing resource.
This is true for an identity inside and outside the I2RS This is true for an identity inside and outside the I2RS
plane, so the I2RS Agent can appropriately perform an update Plane, so the I2RS Agent can appropriately perform an update
according to the priorities associated to the requesting according to the priorities associated to the requesting
identity and the identity that last updated the resource. On identity and the identity that last updated the resource. On
an environment perspective, the I2RS Agent MUST be aware when an environment perspective, the I2RS Agent MUST be aware when
the resource has been modified outside the I2RS plane, as the resource has been modified outside the I2RS Plane, as
well as its priority associated towards the I2RS plane. well as its priority associated towards the I2RS Plane.
Similar requirements exist for identities within the I2RS Similar requirements exist for identities within the I2RS
plane, but belongs to the protocol security requirements. Plane, but belongs to the protocol security requirements.
REQ 25: the I2RS Agent should have a "I2RS Agent overwrite Policy" REQ 25: the I2RS Agent should have a "I2RS Agent overwrite Policy"
that indicates how identities can be prioritized. This that indicates how identities can be prioritized. This
requirements is also described in section 7.6 of requirements is also described in section 7.6 of
[I-D.ietf-i2rs-architecture]. Similar requirements exist for [I-D.ietf-i2rs-architecture]. Similar requirements exist for
components within the I2RS plane, but belongs to the protocol components within the I2RS Plane, but belongs to the protocol
security requirements. security requirements.
5.3. I2RS Client Access Control policies 5.3. I2RS Client Access Control policies
The I2RS Client Access Control policies are responsible for The I2RS Client Access Control policies are responsible for
authenticating the application managing the privileges for the authenticating the application managing the privileges for the
applications, and enforcing access control to resources by the applications, and enforcing access control to resources by the
applications. As a result, applications. As a result,
REQ 26: I2RS Client should authenticate its applications. If the REQ 26: An I2RS Client should authenticate its applications. If the
I2RS Client acts as a broker and supports multiple I2RS Client acts as a broker and supports multiple
Applications, it should authenticate each of them. Applications, it should authenticate each of them.
Authentication of the application may used GSSAPI, Secure RPC Authentication of the application may used GSSAPI, Secure RPC
mechanisms. mechanisms.
REQ 27: I2RS Client should define Access Control policies associated REQ 27: An I2RS Client should define Access Control policies
to each applications. An access to a routing resource by an associated to each application. Access to a routing resource
Application should not be forwarded by the I2RS Client based by an Application should not be forwarded by the I2RS Client
on the I2RS Agent Access Control policies. The I2RS Client based on the I2RS Agent Access Control policies. The I2RS
should first check whether the Application has sufficient Client should first check whether the Application has
privileges, and if so send an access request to the I2RS sufficient privileges, and if so send an access request to
Agent. When an I2RS Client has multiple identities that are the I2RS Agent. When an I2RS Client has multiple identities
associated with different privileges. The I2RS Client Access that are associated with different privileges, the I2RS
Control policies should specify the associated I2RS Client's Client Access Control policies should specify the associated
identities, especially, when the I2RS Agent Access Control I2RS Client's identity, especially when the I2RS Agent Access
policies are changed for a given I2RS Client's identity. Control policies are changed for a given I2RS Client's
identity.
In case, no authentication mechanisms have being provided between the In case, no authentication mechanisms have being provided between the
I2RS Client and the application, then I2RS Client may not act as I2RS Client and the application, then I2RS Client may not act as
broker, and be instead dedicated to a single application. By doing broker, and be instead dedicated to a single application. By doing
so, application authentication may rely on the I2RS authentication so, application authentication may rely on the I2RS authentication
mechanisms between the I2RS Client and the I2RS Agent. On the other mechanisms between the I2RS Client and the I2RS Agent. On the other
hand, although this is not recommended, the I2RS Access Control hand, although this is not recommended, the I2RS Access Control
policies is only enforced by the I2RS Agent. policies is only enforced by the I2RS Agent.
5.4. Application and Access Control policies 5.4. Application and Access Control policies
Application does not enforce access control policies. Instead these Applications do not enforce access control policies. Instead, these
are enforced by the I2RS Clients and the I2RS Agents. This section are enforced by the I2RS Clients and the I2RS Agents. This section
provides recommendations for Applications in order to ease I2RS provides recommendations for Applications in order to ease I2RS
Access Control by the I2RS Client and the I2RS Agent. Access Control by the I2RS Client and the I2RS Agent.
As multiple ways may be used for an Application to communicate with Since multiple ways may be used by an Application to communicate with
its associated I2RS Client, it is not expected that all Applications its associated I2RS Client, it is not expected that all Applications
use the same conventional identifier format across the I2RS plane. use the same conventional identifier format across the I2RS Plane.
However, if all Applications are running on a dedicated system However, if all Applications are running on a dedicated system
sharing an I2RS Client, it is expected each Application may uniquely sharing an I2RS Client, it is expected each Application may uniquely
identified, for example using different system users. identified, for example using different system users.
REQ 28: Applications SHOULD be uniquely identified by their REQ 28: Applications SHOULD be uniquely identified by their
associated I2RS Clients associated I2RS Clients
The I2RS Client provides access to resource on its behalf and this The I2RS Client provides access to resource on its behalf and this
access should only be granted for trusted applications, or access should only be granted for trusted applications, or
Applications with an similar level of trust. On the other hand, this Applications with an similar level of trust. On the other hand, this
does not prevent an I2RS Client to host a large number of does not prevent an I2RS Client from hosting a large number of
Applications. Similarly, an Application may also require to access Applications. Similarly, an Application may also require access to
multiple I2RS Clients depending on the resource to be accessed. As multiple I2RS Clients depending on the resource to be accessed.
I2RS Client are restricted for a subset of Applications, Since I2RS Clients are restricted to a subset of Applications:
REQ 29: Each Application SHOULD be associated to a restricted number REQ 29: Each Application SHOULD be associated to a restricted number
of I2RS Client of I2RS Clients.
REQ 30: Application SHOULD be provided means and methods to contact REQ 30: Applications SHOULD be provided the means and methods to
their associated I2RS Client. If the I2RS Client belongs to contact their associated I2RS Client. If an I2RS Client
the Application (as a module or a library for example), or belongs to the Application (as a module or a library for
when the Application runs into a dedicated system (like a example), or when the Application runs in a dedicated system
container) with a I2RS Client, it is obvious which I2RS (like a container) with a I2RS Client, it is obvious which
Client the Application is associated to. On the other hand, I2RS Client the Application is associated to. On the other
Applications may also remotely access the I2RS Client. In hand, Applications may also remotely access an I2RS Client.
this case, the Application is expected to be provided some In this case, the Application is expected to be provided some
means to be able to retrieve the necessary information to means to be able to retrieve the necessary information to
contact its associated I2RS Client. The IP address may not contact its associated I2RS Client. The IP address may not
be appropriated in case renumbering occurs within the network be appropriated in case renumbering occurs within the network
or in case the traffic from Applications should be shared or in case the traffic from Applications should be shared
between multiple instances of a given I2RS Client. In this between multiple instances of a given I2RS Client. In this
case a FQDN may be preferred. case a FQDN may be preferred.
6. I2RS Application Isolation 6. I2RS Application Isolation
A key aspect of the I2RS architecture is the network oriented A key aspect of the I2RS architecture is the network oriented
application. As these application are supposed to be independent, application. These application are controlled by independent and
controlled by independent and various tenants. In addition to various tenants. In addition to independent logic, these
independent logic, these applications may be malicious. Then, these applications may be malicious. These applications also introduce
applications introduce also programmability which results in fast programmability which results in fast network settings.
network settings.
The I2RS architecture should remain robust to these applications and The I2RS architecture should remain robust for these applications and
make sure an application does not impact the other applications. make sure an application does not impact the other applications.
This section discusses both security aspects related to This section discusses both security aspects related to
programmability as well as application isolation in the I2RS programmability as well as application isolation in the I2RS
architecture. architecture.
6.1. Robustness toward programmability 6.1. Robustness Toward Programmability
I2RS provides a programmatic interface in and out of the Internet I2RS provides a programmatic interface into and out of the Internet
routing system. This feature, in addition to the global network view routing system. This feature, in addition to the global network view
provided by the centralized architecture comes with a few advantages provided by the centralized architecture, comes with a few advantages
in term of security. in terms of security.
The use of automation reduces configuration errors. In addition, The use of automation reduces configuration errors. In addition,
this interface enables fast network reconfiguration. Agility this interface enables fast network reconfiguration. Agility
provides a key advantage in term of deployment as side effect provides a key advantage in term of deployment as side effect
configuration may be easily addressed. Finally, it also provides configuration may be easily addressed. Finally, it also provides
facilities to monitor and mitigate an attack when the network is facilities to monitor and mitigate an attack when the network is
under attack. under attack.
On the other hand programmability also comes with a few drawbacks. On the other hand, programmability also comes with a few drawbacks:
First, applications can belong to multiple tenants with different Applications can belong to multiple tenants with different
objectives. This absence of coordination may result in unstable objectives. This absence of coordination may result in unstable
routing configurations such as oscillations between network routing configurations such as oscillations between network
configurations, and creation of loops for example. A typical example configurations, and creation of loops. A typical example would be an
would be an application monitoring a state and changing its state. application monitoring and changing some state. If another
If another application performs the reverse operation, the routing application performs the reverse operation, the routing system may
system may become unstable. Data and application isolation is become unstable. Data and application isolation is expected to
expected to prevent such situations to happen, however, to guarantee prevent such situations from happening. However, to guarantee
the network stability, constant monitoring and error detection are network stability, constant monitoring and error detection are
recommended to be activated. recommended.
REQ 31: The I2RS Agents should monitor constantly parts of the system REQ 31: I2RS Agents should constantly monitor the parts of the system
for which I2RS Clients or Applications have provided that I2RS Clients or Applications have provided requests. It
requests. It should also be able to detect I2RS Clients or should also be able to detect I2RS Clients or Applications
Applications that lead the routing system in an unstable that make the routing system unstable. Minimally, monitoring
state. Monitoring consists at least in logging events and consists of logging events and eventually providing
eventually provide notifications or alerts to the management notifications or alerts to the management plane when
plane in case, something has been detected. The management something has been detected. The management plane is in
plane is in charge of collecting the logs, the notifications charge of collecting the logs, the notifications, and
and eventually to consider the appropriated actions. A eventually the consideration of appropriate actions. For
typical action may be the update of I2RS Access Control example, a typical action may be the update of I2RS Access
policies for example or re-configuring routing elements. Control policies or re-configuring routing elements.
6.2. Application Isolation 6.2. Application Isolation
6.2.1. DoS 6.2.1. DoS
Requirements for robustness to Dos Attacks have been addressed in the Requirements for robustness to DoS Attacks have been addressed in the
Communication channel section [I-D.ietf-i2rs-architecture]. Communication channel section [I-D.ietf-i2rs-architecture].
The I2RS interface is used by application to interact with the The I2RS interface is used by applications to interact with the
routing states. As the I2RS Agent is shared between multiple routing states. Since the I2RS Agent is shared between multiple
applications, one application can prevent an application by applications, one application can prevent an application from
performing DoS or DDoS attacks on the I2RS Agent or on the network. performing DoS or DDoS attacks on the I2RS Agent or on the network.
DoS attack targeting the I2RS Agent would consist in providing DoS attacks targeting the I2RS Agent would consist of providing
requests that keep the I2RS Agent busy for a long time. This may requests that keep the I2RS Agent busy for a long time. This may
involve heavy computation by the I2RS Agent for example to blocking involve heavy computation by the I2RS Agent, for example, to blocking
operations like disk access. In addition, DoS attacks targeting the operations like disk access. In addition, DoS attacks targeting the
network may use specific commands like monitoring stream over the network may use specific commands like monitoring stream over the
network. Then, DoS attack may be also targeting the application network. Then, DoS attack may be also targeting the application
directly by performing reflection attacks. Such an attack could be directly by performing reflection attacks. Such an attack could be
performed by indicating the target application as the target for some performed by indicating the target application as the target for some
information like the listing of the RIB. Reflection may be performed information like the listing of the RIB. Reflection may be performed
at various levels and can be based on the use of UDP or at the at various levels and can be based on the use of UDP or at the
service level like redirection of information to a specific service level like redirection of information to a specific
repository. repository.
REQ 32: In order to prevent DoS, it is recommended the I2RS Agent REQ 32: In order to prevent DoS, it is recommended the I2RS Agent
controls the resources allocated to each I2RS Clients. I2RS controls the resources allocated to each I2RS Client. I2RS
Client that acts as broker may not be protected as Clients that act as brokers may not be protected as
efficiently against these attacks unless they perform efficiently against these attacks unless they perform
resource controls themselves of their hosted applications. resource controls themselves of their hosted applications.
REQ 33: I2RS Agent does not make response redirection possible unless REQ 33: An I2RS Agent does not make response redirection possible
the redirection is previously validated and agreed by the unless the redirection is previously validated and agreed by
destination. the destination.
REQ 34: avoid the use of underlying protocols that are not robust to REQ 34: Avoid the use of underlying protocols that are not robust to
reflection attacks. reflection attacks.
6.2.2. Application Control 6.2.2. Application Control
Requirements for Application Control have been addressed in the I2RS Requirements for Application Control have been addressed in the I2RS
plane isolation as well as in the trusted Communication Channel Plane isolation as well as in the trusted Communication Channel
sections. sections.
Applications use the I2RS interface in order to update the routing Applications use the I2RS interface in order to update the routing
system. These updates may be driven by behavior on the forwarding system. These updates may be driven by behavior on the forwarding
plane or any external behaviors. In this case, correlating plane or any external behaviors. In this case, correlating
observation to the I2RS traffic may enable to derive the application observation to the I2RS traffic may enable to derive the application
logic. Once the application logic has been derived, a malicious logic. Once the application logic has been derived, a malicious
application may generate traffic or any event in the network in order application may generate traffic or any event in the network in order
to activate the alternate application. to activate the alternate application.
skipping to change at page 18, line 35 skipping to change at page 18, line 29
8. Privacy Considerations 8. Privacy Considerations
9. IANA Considerations 9. IANA Considerations
10. Acknowledgments 10. Acknowledgments
A number of people provided a significant amount of helping comments A number of people provided a significant amount of helping comments
and reviews. Among them the authors would like to thank Russ White, and reviews. Among them the authors would like to thank Russ White,
Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas,
Alia Atlas, Linda Dunbar Alia Atlas, Linda Dunbar.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, March 1997.
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-09 (work in System", draft-ietf-i2rs-architecture-09 (work in
progress), March 2015. progress), March 2015.
[I-D.ietf-i2rs-protocol-security-requirements] [I-D.ietf-i2rs-protocol-security-requirements]
Hares, S., Migault, D., and J. Halpern, "I2RS Security Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", draft-ietf-i2rs-protocol-security- Related Requirements", draft-ietf-i2rs-protocol-security-
requirements-01 (work in progress), September 2015. requirements-02 (work in progress), December 2015.
Authors' Addresses Authors' Addresses
Daniel Migault (editor) Daniel Migault (editor)
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
Phone: +1 514-452-2160 Phone: +1 514-452-2160
 End of changes. 115 change blocks. 
355 lines changed or deleted 346 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--M9NhX3UHpAaciwkO-- From nobody Tue May 17 16:55:48 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4EE12D172 for ; Tue, 17 May 2016 16:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XZ_wLBxy0Xm for ; Tue, 17 May 2016 16:55:44 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F5812B054 for ; Tue, 17 May 2016 16:55:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9FED6266996; Tue, 17 May 2016 16:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463529344; bh=OrY87Ys/NUfWuhQXCzertZNYWpgp+NDYR1FdlZ7pOHg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QsmeR3s09VPKZPOP2jm3HT9eT8u3jaaZvcFAKLQpQWBtHo+VaHkDoqQAWyKidY2Ty W2qwjEYED27a82vEYgCXdNN2vHI2Dd0ilVGRUg4dudlB08uL1f0dUn+SqYlD3F38vL Kwo8kOUnFB6Me19Afkho7xZydFAeArtZN8nS3Exo= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 2B526266994; Tue, 17 May 2016 16:55:44 -0700 (PDT) To: Jeffrey Haas , i2rs@ietf.org References: <20160404200101.15723.87315.idtracker@ietfa.amsl.com> <20160517234632.GG17462@pfrc.org> From: "Joel M. Halpern" Message-ID: <4540adf1-5087-853c-b043-b3eb37614ebc@joelhalpern.com> Date: Tue, 17 May 2016 19:55:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160517234632.GG17462@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-security-environment-reqs-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 23:55:47 -0000 Jeff, thanks for the thorough review. On the editorial matters, the edit to the definition of I2RS Plane seems somewhat off. I understand why you did not like referring to it as the environment for the "process", particularly since there are multiple "processes" involved. But one does not run an "architecture" in an environment either. How about defining it as "The environment the I2RS components" are running on."? Or maybe "The connected set of I2RS components" since the I2RS Plane is really that communication, not the underlay. It is a bit awkward for either the authors or the WG to review the other notes, as apparently they are in the git but not in the diff (since they are only in the XML.) Yours, Joel On 5/17/16 7:46 PM, Jeffrey Haas wrote: > Authors, > > Upon review of the environment security requirements, I found a number of > items to comment upon. Since the majority of these were spelling or > grammar, I chose to simply provide you a diff. > > https://github.com/jhaas-pfrc/i2rs-2016/blob/jhaas/draft-ietf-i2rs-security-environment-reqs-01-comments/draft-ietf-i2rs-security-environment-reqs/draft-ietf-i2rs-security-environment-reqs.xml > > The above github link will take you to a repository containing your draft > with edits. The "master" branch contains the IETF sourced .xml and .txt > files. Thus, you can clone this repository and get access to the diff. > > Please note I have flagged some issues within the .xml as XXX JMH and that > these issues require separate attention. > > I am also attaching a rfcdiff showing the suggested edits. > > -- Jeff > > > > On Mon, Apr 04, 2016 at 01:01:01PM -0700, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Interface to the Routing System of the IETF. >> >> Title : I2RS Environment Security Requirements >> Authors : Daniel Migault >> Joel Halpern >> Susan Hares >> Filename : draft-ietf-i2rs-security-environment-reqs-01.txt >> Pages : 19 >> Date : 2016-04-04 >> >> Abstract: >> This document provides environment security requirements for the I2RS >> architecture. Environment security requirements are independent of >> the protocol used for I2RS. As a result, the requirements provided >> in this document are intended to provide good security practise so >> I2RS can be securely deployed and operated. >> >> These security requirements are designated as environment security >> requirements as opposed to the protocol security requirements. The >> reason to have separate document is that protocol security >> requirements are intended to help the design of the I2RS protocol >> whether the environment requirements are rather intended for >> deployment or implementations. >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 17 17:10:34 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456E712D094 for ; Tue, 17 May 2016 17:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.999, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDy9G5yAFNnw for ; Tue, 17 May 2016 17:10:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EDAC012D544 for ; Tue, 17 May 2016 17:10:25 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CD51E1E335; Tue, 17 May 2016 20:15:36 -0400 (EDT) Date: Tue, 17 May 2016 20:15:36 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20160518001535.GH17462@pfrc.org> References: <20160404200101.15723.87315.idtracker@ietfa.amsl.com> <20160517234632.GG17462@pfrc.org> <4540adf1-5087-853c-b043-b3eb37614ebc@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline In-Reply-To: <4540adf1-5087-853c-b043-b3eb37614ebc@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-security-environment-reqs-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 00:10:32 -0000 --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joel, On Tue, May 17, 2016 at 07:55:55PM -0400, Joel M. Halpern wrote: > On the editorial matters, the edit to the definition of I2RS Plane > seems somewhat off. I understand why you did not like referring to > it as the environment for the "process", particularly since there > are multiple "processes" involved. But one does not run an > "architecture" in an environment either. How about defining it as > "The environment the I2RS components" are running on."? Or maybe > "The connected set of I2RS components" since the I2RS Plane is > really that communication, not the underlay. I must admit to not having the best set of suggested wording here. The main thing that seemed wrong was the use of processes in the context of UNIX and there's no guarantee that such an ecosystem is used to instantiate I2RS. One suggestion may be to simply scrub the "flavor of UNIX" from the text and simply continue to use "processes", perhaps being a bit more careful to define what that means in context. > It is a bit awkward for either the authors or the WG to review the > other notes, as apparently they are in the git but not in the diff > (since they are only in the XML.) Fair point. I am attaching the .xml. I am also attaching a form of the rfcdiff wherein the XXX comments have been exposed. I am not pushing that altered .xml in order to let you authors have a clean bit of xml to use for your edits. (Note that I encourage the authors to work from the git repository. It makes further rounds of edits easier.) -- Jeff --CdrF4e02JqNVZeln Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-i2rs-security-environment-reqs-from--01.diff.html" Diff: draft-ietf-i2rs-security-environment-reqs-01.txt - draft-ietf-i2rs-security-environment-reqs.txt
 draft-ietf-i2rs-security-environment-reqs-01.txt   draft-ietf-i2rs-security-environment-reqs.txt 
I2RS WG D. Migault, Ed. I2RS WG D. Migault, Ed.
Internet-Draft J. Halpern Internet-Draft J. Halpern
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: October 6, 2016 S. Hares Expires: November 18, 2016 S. Hares
Huawei Huawei
April 4, 2016 May 17, 2016
I2RS Environment Security Requirements I2RS Environment Security Requirements
draft-ietf-i2rs-security-environment-reqs-01 draft-ietf-i2rs-security-environment-reqs-02
Abstract Abstract
This document provides environment security requirements for the I2RS This document provides environment security requirements for the I2RS
architecture. Environment security requirements are independent of architecture. The environment security requirements are independent
the protocol used for I2RS. As a result, the requirements provided of the protocol used for I2RS and are intended to document the
in this document are intended to provide good security practise so deployment and operational environment of I2RS.
I2RS can be securely deployed and operated.
These security requirements are designated as environment security
requirements as opposed to the protocol security requirements. The
reason to have separate document is that protocol security
requirements are intended to help the design of the I2RS protocol
whether the environment requirements are rather intended for
deployment or implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2016. This Internet-Draft will expire on November 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4
4. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4 4. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4
4.1. I2RS plane and management plane . . . . . . . . . . . . . 4 4.1. I2RS Plane and management plane . . . . . . . . . . . . . 4
4.2. I2RS plane and forwarding plane . . . . . . . . . . . . . 5 4.2. I2RS Plane and forwarding plane . . . . . . . . . . . . . 5
4.3. I2RS plane and Control plane . . . . . . . . . . . . . . 6 4.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 6
4.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 6 4.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 6
5. I2RS Access Control for routing system resources . . . . . . 8 5. I2RS Access Control for routing system resources . . . . . . 8
5.1. I2RS Access Control architecture . . . . . . . . . . . . 8 5.1. I2RS Access Control architecture . . . . . . . . . . . . 8
5.2. I2RS Agent Access Control policies . . . . . . . . . . . 13 5.2. I2RS Agent Access Control policies . . . . . . . . . . . 13
5.3. I2RS Client Access Control policies . . . . . . . . . . . 14 5.3. I2RS Client Access Control policies . . . . . . . . . . . 14
5.4. Application and Access Control policies . . . . . . . . . 15 5.4. Application and Access Control policies . . . . . . . . . 15
6. I2RS Application Isolation . . . . . . . . . . . . . . . . . 16 6. I2RS Application Isolation . . . . . . . . . . . . . . . . . 16
6.1. Robustness toward programmability . . . . . . . . . . . . 16 6.1. Robustness Toward Programmability . . . . . . . . . . . . 16
6.2. Application Isolation . . . . . . . . . . . . . . . . . . 17 6.2. Application Isolation . . . . . . . . . . . . . . . . . . 17
6.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.2. Application Control . . . . . . . . . . . . . . . . . 17 6.2.2. Application Control . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document provides environment security requirements for the I2RS This document provides environment security requirements for the I2RS
architecture. Environment security requirements are independent of architecture. Environment security requirements are independent of
the protocol used for I2RS. As a result, the requirements provided the protocol used for I2RS. As a result, the requirements provided
in this document are intended to provide good security practise so in this document are intended to provide good security practice so
I2RS can be securely deployed and operated. I2RS can be securely deployed and operated.
These security requirements are designated as environment security These security requirements are designated as environment security
requirements as opposed to the protocol security requirements requirements as opposed to the protocol security requirements
described in [I-D.ietf-i2rs-protocol-security-requirements]. The described in [I-D.ietf-i2rs-protocol-security-requirements]. The
reason to have separate document is that protocol security reason to have separate document is that protocol security
requirements are intended to help the design of the I2RS protocol requirements are intended to help the design of the I2RS protocol
whether the environment requirements are rather intended for whether the environment requirements are rather intended for
deployment or implementations. deployment or implementations.
Even though I2RS is mostly concerned by the interface between the Even though I2RS is mostly concerned with the interface between the
I2RS Client and the I2RS Agent, the security recommendations must I2RS Client and the I2RS Agent, the security recommendations must
consider the entire I2RS architecture, specifying where security consider the entire I2RS architecture, specifying where security
functions may be hosted, and what should be met so to address any new functions may be hosted, and what should be met so to address any new
attack vectors exposed by deploying this architecture. In other attack vectors exposed by deploying this architecture. In other
words, security has to be considered globally over the complete I2RS words, security has to be considered globally over the complete I2RS
architecture and not only on the interfaces. architecture and not only on its interfaces.
I2RS architecture depicted in [I-D.ietf-i2rs-architecture] describes The I2RS architecture depicted in [I-D.ietf-i2rs-architecture]
the I2RS components and their interactions to provide a programmatic describes the I2RS components and their interactions to provide a
interface for the routing system. I2RS components as well as their programmatic interface for the routing system. I2RS components, as
interactions have not yet been considered in conventional routing well as their interactions, have not yet been considered in
systems. As such it introduces a need to interface with the routing conventional routing systems. As such, it introduces a need to
system designated as I2RS plane in this document. interface with the routing system designated as the I2RS Plane in
this document.
This document is built as follows. Section 4 describes how the I2RS This document is structured as follows:
plane can be contained or isolated from existing management plane,
control plane and forwarding plane. The remaining sections of the o Section 4 describes how the I2RS Plane can be contained or
document focuses on the security within the I2RS plane. Section 5 isolated from existing management plane, control plane and
analyzes how the I2RS Access Control policies can be deployed forwarding plane. The remaining sections of the document focuses
throughout the I2RS plane in order to only grant access to the on the security within the I2RS Plane.
routing system resources to authorized components with the authorized
privileges. This also includes providing a robust communication o Section 5 analyzes how the I2RS Access Control policies can be
system between the components. Then, Section 6 details how I2RS deployed throughout the I2RS Plane in order to only grant access
keeps applications isolated one from another and do not affect the to the routing system resources to authorized components with the
I2RS components. Applications may be independent, with different authorized privileges. This also includes providing a robust
scopes, owned by different tenants. In addition, they modify the communication system between the components.
routing system that may be in an automatic way.
o Section 6 details how I2RS keeps applications isolated one from
another and do not affect the I2RS components. Applications may
be independent, with different scopes, owned by different tenants.
In addition, they modify the routing system that may be in an
automatic way.
The reader is expected to be familiar with the The reader is expected to be familiar with the
[I-D.ietf-i2rs-architecture]. The document provides a list of [I-D.ietf-i2rs-architecture]. The document provides a list of
environment security requirements. Motivations are placed before the environment security requirements. Motivations are placed before the
requirements are announced. related requirements.
3. Terminology and Acronyms 3. Terminology and Acronyms
- Environment Security Requirements : I2RS Plane: The environment the I2RS architecture is running on. It
includes the Applications, the I2RS Clients and the I2RS Agent.
- I2RS plane : The environment the I2RS process is running on. It
includes the Applications, the I2RS Client and the I2RS Agent.
- I2RS user : The user of the I2RS client software or system. I2RS User: The user of the I2RS client software or system.
- I2RS Access Control policies: policies controlling access of the I2RS Access Control policies: Policies controlling access of the
routing resources by Applications. These policies are divided routing resources by Applications. These policies are divided
into policies applied by the I2RS Client regarding Applications into policies applied by the I2RS Client regarding Applications
and policies applied by the I2RS Agent regarding I2RS Clients. and policies applied by the I2RS Agent regarding I2RS Clients.
- I2RS Client Access Control policies : The Access Control policies I2RS Client Access Control policies: The Access Control policies
processed by the I2RS Client. processed by the I2RS Client.
- I2RS Agent Access Control policies : The Access Control policies I2RS Agent Access Control policies: The Access Control policies
processed by the I2RS Agent. processed by the I2RS Agent.
4. I2RS Plane Isolation 4. I2RS Plane Isolation
Isolating the I2RS plane from other network plane, such as the Isolating the I2RS Plane from other network planes, such as the
control plane, is foundational to the security of the I2RS control plane, is foundational to the security of the I2RS
environment. Clearly differentiating I2RS components from the rest environment. Clearly differentiating I2RS components from the rest
of the network protects the I2RS components from vulnerabilities in of the network protects the I2RS components from vulnerabilities in
other parts of the network, and protect other systems vital to the other parts of the network, and protect other systems vital to the
health of the network from vulnerabilities in the I2RS plane. health of the network from vulnerabilities in the I2RS Plane.
Separating the I2RS plane from other network control and forwarding Separating the I2RS Plane from other network control and forwarding
planes is similar to the best common practice of containerizing planes is similar to the best common practice of containerizing
software into modules, and defense in depth in the larger world of software into modules, and defense in depth in the larger world of
network security. network security.
That said the I2RS plane cannot be considered as completely isolated That said, the I2RS Plane cannot be considered as being completely
from other planes, and interactions should be identified and isolated from other planes, and interactions should be identified and
controlled. Follows a brief description on how the I2RS plane controlled. The following sections provide brief descriptions on how
positions itself in regard to the other planes. The description is the I2RS Plane positions itself with regard to the other planes.
indicative, and may not be exhaustive.
4.1. I2RS plane and management plane 4.1. I2RS Plane and management plane
The I2RS plane purpose is to provide a standard programmatic The purpose of the I2RS Plane is to provide a standard programmatic
interface of the routing system resources to network oriented interface to the routing system resources for network-oriented
applications. Control plane and forwarding planes are related to applications. Control and forwarding planes are related to routing
routing protocols, and I2RS is based on top of those. The management protocols, and I2RS is based on top of those. The management plane
plane is usually vendor specific, provides a broader control over the is usually vendor specific, and provides broader control over the
networking equipment such as system service. Given its associated networking equipment such as system services. Given its associated
privileges it is expected to be reserved to highly trusted users like privileges, it is expected to be reserved for highly trusted users
network administrators. such as network administrators.
The I2RS plane and the management plane both interact with several The I2RS Plane and the management plane both interact with several
common elements on forwarding and packet processing devices. common elements on forwarding and packet processing devices.
[I-D.ietf-i2rs-architecture] describes several of these interaction [I-D.ietf-i2rs-architecture] describes several of these interaction
points such as the local configuration, the static system state, points such as local configuration, static system state, routing, and
routing, and signalling. Because of this potential overlaps, a signaling. Because of these potential overlaps, a routing resource
routing resource may be accessed by different means (APIs, may be accessed by different means (e.g., APIs and applications) and
applications) and different planes. To keep these overlaps under different planes. To keep these overlaps under control, one could
control, one could either control the access to these resources with control access to these resources with northbound APIs, for example.
northbound APIs for example. Northbound APIs are provided to limit Northbound APIs are provided to limit the scope of the applications
the scope of the applications toward the routing resources. In our toward the routing resources. In our case, the northbound API may be
case, the northbound API may be provided for the I2RS applications by provided for the I2RS applications by the I2RS Client as well as to
the I2RS Client as well as to the management plane. In case the management plane. When conflicting overlaps cannot be avoided,
conflicting overlaps cannot be avoided, and routing resource can be and routing resource can be accessed by both the management plane and
accessed by both the management plane and the I2RS plane, then, they the I2RS Plane, they should be resolved in a deterministic way.
should be resolved in a deterministic way.
On the northbound side, there must be clear protections against the On the northbound side, there must be clear protections against the
I2RS system "infecting" the management system with bad information, I2RS system "infecting" the management system with bad information,
or the management system "infecting" the I2RS system with bad or vice-versa. The primary protection in this space is going to need
information. The primary protection in this space is going to need
to be validation rules on the speed of information flow, value limits to be validation rules on the speed of information flow, value limits
on the data presented, and other protections of this type. on the data presented, and other protections of this type.
XXX JMH the sentence at the end of the last paragraph doesn't parse.
On the conflicting side/issues, there should be clear rules about On the conflicting side/issues, there should be clear rules about
which plan's commands win in the case of conflict in order to prevent which plan's commands win in the case of conflict in order to prevent
attacks where the two systems can be forced to deadlock. attacks where the two systems can be forced to deadlock.
4.2. I2RS plane and forwarding plane XXX JMH the previous section also does not parse. Also, how does
this overlap with the protocol behavior in terms of priority w.r.t
local configuration vs. ephemeral?
Applications hosted on I2RS Client belongs to the I2RS plane. These 4.2. I2RS Plane and forwarding plane
Applications are hard to remain constrained into the I2RS plane, or
even to limit their scope within the I2RS plane.
Applications using I2RS are part of the I2RS plane but may also Applications hosted on I2RS Client belong to the I2RS Plane. These
interact with other components outside the I2RS plane. A common Applications are hard to remain constrained into the I2RS Plane, or
example may be an application uses I2RS to configure the network even to limit their scope within the I2RS Plane.
according to security or monitored events. As these events are
monitored on the forwarding plane and not the I2RS plane, the XXX JMH It is unclear what the last sentence of the prior section is
intended to say
Applications using I2RS are part of the I2RS Plane but may also
interact with other components outside the I2RS Plane. A common
example may be an application that uses I2RS to configure the network
according to security or monitored events. Since these events are
monitored on the forwarding plane and not in the I2RS Plane, the
application breaks plane isolation. application breaks plane isolation.
In addition, applications may communicate with multiple I2RS Clients; XXX JMH - the second sentence of the above section is unclear and
as such, any given application may have a broader view of the current doesn't parse.
and potential states of the network and the I2RS plane itself.
Because of this, any individual application could be an effective In addition, applications may communicate with multiple I2RS Clients.
attack vector against the operation of the network, the I2RS plane, Thus any given application may have a broader view of the current and
or any plane with which the I2RS plane interacts. There is little potential states of the network and the I2RS Plane itself. Because
the I2RS plane can do to validate applications with which it of this, any individual application could be an effective attack
interacts, other than to provide some broad general validations vector against the operation of the network, the I2RS Plane, or any
against common misconfigurations or errors. As with the separation plane with which the I2RS Plane interacts. There is little the I2RS
between the management plane and the I2RS plane, this should Plane can do to validate applications with which it interacts, other
minimally take the form of limits on information accepted, limits on than to provide some general validation against common
the rate at which information is accepted, and rudimentary checks misconfigurations or errors. As with the separation between the
against intentionally formed routing loops or injecting information management plane and the I2RS Plane, this should minimally take the
that would cause the control plane to fail to converge. Other forms form of limits on information accepted, limits on the rate at which
of protection may be necessary. information is accepted, and rudimentary checks against intentionally
formed routing loops or injecting information that would cause the
control plane to fail to converge. Other forms of protection may be
necessary.
4.3. I2RS plane and Control plane 4.3. I2RS Plane and Control Plane
The network control plane consists of the processes and protocols The network control plane consists of the processes and protocols
that discover topology, advertise reachability, and determine the that discover topology, advertise reachability, and determine the
shortest path between any location on the network and any path between any location on the network and any destination. It is
destination. It is not anticipated there will be any interactions not anticipated there will be any interactions between the on-the-
between the on-the-wire signalling used by the control plane. wire signaling used by the control plane and the I2RS Plane.
However, in some situations the I2RS system could modify information However, in some situations the I2RS system could modify information
in the local databases of the control plane. This is not normally in the local databases of the control plane. This is not normally
recommended, as it can bypass the normal loop free, loop free recommended, as it can bypass the normal loop free, loop free
alternate, and convergence properties of the control plane. However, alternate, and convergence properties of the control plane. However,
if the I2RS system does directly inject information into these if the I2RS system does directly inject information into these
tables, the I2RS system should ensure that loop free routing is tables, the I2RS system should ensure that loop free routing is
preserved, including loop free alternates, tunnelled interfaces, preserved, including loop free alternates, tunneled interfaces,
virtual overlays, and other such constructions. Any information virtual overlays, and other such constructions. Any information
injected into the control plane directly could cause the control injected into the control plane directly could cause the control
plane to fail to converge, resulting in a complete network outage. plane to fail to converge, resulting in a complete network outage.
4.4. Recommendations 4.4. Recommendations
To isolate I2RS transactions from other planes, it is recommended To isolate I2RS transactions from other planes, it is recommended
that: that:
REQ 1: Application-to-routing system resources communications should REQ 1: Application-to-routing system resources communications should
use an isolated communication channel. Various level of use an isolated communication channel. Various levels of
isolation can be considered. The highest level of isolation isolation can be considered. The highest level of isolation
may be provided by using a physically isolated network. could be provided by using a physically isolated network.
Alternatives may also consider logical isolation; for example Alternatives may also include logical isolation; for example
by using vLAN. Eventually, in virtual environment that by using vLANs. In virtual environments that share a common
shares a common infrastructure, encryption, for example by infrastructure, encryption - for example, TLS or IPsec - may
using TLS or IPsec, may also be used as a way to enforce also be used as a way to enforce isolation.
isolation.
REQ 2: The interface (like the IP address) used by the routing REQ 2: The IP interface used by the routing element to receive I2RS
element to receive I2RS transactions should be a dedicated transactions should be a dedicated physical or logical
physical or logical interface. As previously, mentioned a interface. As previously mentioned, a dedicated physical
dedicated physical interface may contribute to a higher interface may contribute to higher isolation. However,
isolation, however logical isolation be also be considered logical isolation be also be considered - for example, by
for example by using a dedicated IP address or a dedicated using a dedicated IP address or a dedicated port.
port.
When the I2RS Agent performs an action on a routing element, the When the I2RS Agent performs an action on a routing element, the
action is performed via process(es) associated to a system user . In action is performed via process(es) associated to a system user . In
a typical UNIX system, the user is designated with a user id (uid) a typical UNIX system, the user is designated with a user id (uid)
and belong to groups designated by group ids (gid). These users are and belong to groups designated by group ids (gid). These users are
dependent of the routing element's operation system and are dependent of the routing element's operating system and are
designated I2RS System Users. Some implementation may use a I2RS designated I2RS System Users. Some implementation may use a single
System User for the I2RS Agent that proxies the different I2RS I2RS System User for the I2RS Agent that proxies the different I2RS
Client, other implementations may use I2RS System User for each Clients, other implementations may use distinct I2RS System Users for
different I2RS Clients. each I2RS Client. ( XXX JMH - this section covered an implementation
detail that presumes underlying UNIX. )
REQ 3: I2RS Agent should have permissions separate from any other REQ 3: I2RS Agents should have permissions separate from any other
entity (for example any internal system management processes entity; for example, any internal system management or CLI
or CLI processes). processes.
I2RS resource may be shared with the management plane and the control I2RS resources may be shared with the management plane and the
plane. It is hardly possible to prevent interactions between the control plane. It is hardly possible to prevent interactions between
planes. I2RS routing system resource management is limited to the the planes. I2RS routing system resource management is limited to
I2RS plane. As such, update of I2RS routing system outside of the the I2RS Plane. As such, updates to an I2RS-enabled routing system
I2RS plane may be remain unnoticed unless explicitly notified to the outside of the I2RS Plane may remain unnoticed unless the I2RS Plane
I2RS plane. Such notification is expected to trigger synchronization is explicitly notified. Such notification is expected to trigger
of the I2RS resource state within each I2RS component. This synchronization of the I2RS resource state within each I2RS
guarantees that I2RS resource are maintained in a coherent state component. This guarantees that I2RS resource are maintained in a
among the I2RS plane. In addition, depending on the I2RS resource coherent state within the I2RS Plane. In addition, depending on the
that is updated as well as the origin of the modification performed, I2RS resource that is updated as well as the origin of the
the I2RS Access Control policies may be impacted. More especially, a modification performed, the I2RS Access Control policies may be
I2RS Client is more likely to update an I2RS resources that has been impacted. For example, an I2RS Client is more likely to update an
updated by itself, then by the management plane for example. I2RS resources that has been updated by itself than by the management
plane.
REQ 4: I2RS plane should be informed when a routing system resource REQ 4: The I2RS Plane should be informed when a routing system
is modified by a user outside the I2RS plane access. The resource used by that plane is externally modified. The
notification is not expected to flood the I2RS plane. notification is not expected to flood the I2RS Plane.
Instead, notification is expected to be provided to the I2RS Instead, the notification is expected to be provided to the
components interacting, configuring or monitoring the routing I2RS components interacting, configuring or monitoring the
system resource. The notification is at least provided by routing system resource. The notification is at least
the I2RS Agent to the various I2RS Client, but additional provided by the I2RS Agent to the various I2RS Client, but
mechanisms might eventually be required so I2RS Client can additional mechanisms might eventually be required so I2RS
relay the notification to the I2RS applications. This is Client can relay the notification to the I2RS applications.
designated as "I2RS resource modified out of I2RS plane". This is designated as "I2RS resource modified out of I2RS
This requirements is also described in section 7.6 of Plane". This requirements is also described in section 7.6
[I-D.ietf-i2rs-architecture] for the I2RS Client. This of [I-D.ietf-i2rs-architecture] for the I2RS Client. This
document extends the requirement to the I2RS plane, in case document extends the requirement to the I2RS Plane, in case
future evolution of the I2RS plane. future evolution of the I2RS Plane.
REQ 5: I2RS plane should define an "I2RS plane overwrite policy". REQ 5: The I2RS Plane should define an "I2RS Plane overwrite
Such policy defines how an I2RS is able to update and policy". Such policy defines how an I2RS is able to update
overwrite a resource set by a user outside the I2RS plane. and overwrite a resource set by a user outside the I2RS
Such hierarchy has been described in section 6.3 and 7.8 of Plane. Such hierarchy has been described in section 6.3 and
[I-D.ietf-i2rs-architecture] 7.8 of [I-D.ietf-i2rs-architecture]
5. I2RS Access Control for routing system resources 5. I2RS Access Control for routing system resources
This section provides recommendations on how I2RS Access Control This section provides recommendations on how I2RS Access Control
policies associated to the routing system resources. These policies policies are associated to the routing system resources. These
only apply within the I2RS plane. More especially, the policies are policies only apply within the I2RS Plane. More especially, the
associated to the Applications, the I2RS Clients and the I2RS Agents, policies are associated to the Applications, the I2RS Clients, and
with their associated identity and roles. the I2RS Agents with their associated identity and roles.
Note that the deployment of Applications, I2RS Client and I2RS Agent Note that the deployment of Applications, I2RS Client, and I2RS Agent
in a closed environment, should not be considered by default as a in a closed environment should not be considered by default as a
secure environment. Even for closed environment access control secure environment. Even for closed environment access control
policies should be carefully defined to be able to, in the future to policies should be carefully defined to be able to, in the future,
carefully extend the I2RS plane to remote Applications or remote I2RS carefully extend the I2RS Plane to remote Applications or remote I2RS
Clients. As a result, this section always consider the case Clients. As a result, this section always consider the case where
Applications and I2RS Client can be located locally, in a closed Applications and I2RS Client can be located locally, in a closed
environment or distributed over open networks. environment, or distributed over open networks.
Although [I-D.ietf-i2rs-protocol-security-requirements] provides Although [I-D.ietf-i2rs-protocol-security-requirements] provides
security requirements of the transport and protocol between the I2RS security requirements for the transport and protocol between the I2RS
Client and the I2RS Agent, this section is mostly focused on access Client and the I2RS Agent, this section is mostly focused on access
control. control.
5.1. I2RS Access Control architecture 5.1. I2RS Access Control architecture
Applications access to routing system resource via numerous Application access to routing system resources via numerous
intermediaries nodes. The application communicates with an I2RS intermediaries nodes. The application communicates with an I2RS
Client. In some cases, the I2RS Client is only associated to a Client. In some cases, the I2RS Client is only associated to a
single application, but the I2RS Client may also act as a broker. single application, but the I2RS Client may also act as a broker.
The I2RS Client, then, communicates with the I2RS Agent that may The I2RS Client communicates with the I2RS Agent that may eventually
eventually access the resource. access the resource.
The I2RS Client broker approach provides scalability to the I2RS The I2RS Client broker approach provides scalability to the I2RS
architecture as it avoids that each Application be registered to the architecture since it avoids requiring each Application be registered
I2RS Agent. Similarly, the I2RS Access Control should be able to with the I2RS Agent. Similarly, I2RS Access Control should be able
scale numerous applications. to scale numerous applications.
REQ 6: I2RS Access Control should be performed through the whole REQ 6: I2RS Access Control should be performed throughout the I2RS
I2RS plane. It should not be enforced by the I2RS Agent only Plane. It should not be enforced by the I2RS Agent only
within the routing element. Instead, the I2RS Client should within the routing element. Instead, the I2RS Client should
enforce the I2RS Client Access Control against Applications enforce the I2RS Client Access Control against Applications
and the I2RS Agent should enforce the I2RS Agent Access and the I2RS Agent should enforce the I2RS Agent Access
Control against the I2RS Clients. Note that I2RS Client Control against the I2RS Clients. Note that I2RS Client
Access Control is not in the scope of the I2RS architecture Access Control is not in the scope of the I2RS architecture
[I-D.ietf-i2rs-architecture], which exclusively focuses on [I-D.ietf-i2rs-architecture], which exclusively focuses on
the I2RS Agent Access Control. the I2RS Agent Access Control.
This results in a layered and hierarchical or multi-party I2RS Access This results in a layered and hierarchical or multi-party I2RS Access
Control. An application will be able to access a routing system Control. An application will then be able to access a routing system
resource only if both the I2RS Client is granted access by the I2RS resource only if both the I2RS Client is granted access by the I2RS
Agent and the application is granted access by the I2RS Client. Agent and the application is granted access by the I2RS Client.
REQ 7: When an access request to a routing resource is refused by REQ 7: When an access request to a routing resource is refused by
one party (the I2RS Client or the I2RS Agent), the initiator one party (the I2RS Client or the I2RS Agent), the initiator
of the request (e.g the Application) as well as all of the request (e.g., the Application) as well as all
intermediaries should indicate the reason the access has not intermediaries should indicate the reason the access has not
been granted as well as the entity that has rejected the been granted, as well as the entity that has rejected the
request. request.
REQ 8: In order to provide coherent Access Control policies enforced REQ 8: In order to provide coherent Access Control policies enforced
by multiple parties (e.g. the I2RS Client or the I2RS Agent), by multiple parties (e.g., the I2RS Client or the I2RS
theses parties should trust each others, and communication Agent), these parties should trust each other, and
between them should also be trusted, - that is should not communication between them should also be trusted; that is
introduce additional vector of attacks. they should not introduce additional vectors of attack.
In case the I2RS Client Access Control or the I2RS Agent Access In case the I2RS Client Access Control or the I2RS Agent Access
Control does not grant access to a routing system resource, the Control does not grant access to a routing system resource, the
Application should be able to determine whether its request has been Application should be able to determine whether its request has been
rejected by the I2RS Client or the I2RS Agent as well as the reason rejected by the I2RS Client or the I2RS Agent as well as the reason
that caused the reject. More specifically, the I2RS Agent may reject that caused the rejection. More specifically, the I2RS Agent may
the request because, for example, the I2RS Client is not an reject the request because, for example, the I2RS Client is not an
authorized I2RS Client, or because the I2RS Client does not not have authorized I2RS Client, or because the I2RS Client does not not have
enough privileges. The I2RS Client should be notified of the reason enough privileges. The I2RS Client should be notified of the reason
that caused the reject by the I2RS Agent, and The I2RS Client should that caused the rejection by the I2RS Agent, and The I2RS Client
return a message to the Application, indicating the I2RS Client is should return a message to the Application, indicating the I2RS
not authorized or does not have enough privileges. Similarly, if the Client is not authorized or does not have enough privileges.
I2RS Client does not grant the access to the Application, the I2RS Similarly, if the I2RS Client does not grant access to the
Client should also inform the Application. The error message Application, the I2RS Client should also inform the Application.
returned should be for example: "Read failure: you do not have the
read permission", "Write failure: you do not have write permission" For example, the error message returned could be: "Read failure: you
or "Write failure: resource accessed by someone else". This do not have read permission", "Write failure: you do not have write
requirement has been written in a generic manner as it concerns permission", or "Write failure: resource accessed by someone else".
This requirement has been written in a generic manner as it concerns
various interactions: interactions between the application and the various interactions: interactions between the application and the
I2RS Client, interactions between the I2RS Client and the I2RS Agent. I2RS Client, interactions between the I2RS Client and the I2RS Agent.
In the latest case, the requirement is part of the protocol security In the latest case, the requirement is part of the protocol security
requirements addressed by requirements addressed by
[I-D.ietf-i2rs-protocol-security-requirements]. [I-D.ietf-i2rs-protocol-security-requirements].
Although [I-D.ietf-i2rs-protocol-security-requirements] is focused on Although [I-D.ietf-i2rs-protocol-security-requirements] is focused on
transport security requirements between the I2RS Client and the I2RS transport security requirements between the I2RS Client and the I2RS
Agent, the similar requirements may apply between the Application and Agent, similar requirements may apply between the Application and the
the I2RS Client for a remote Application. I2RS Client for a remote Application.
REQ 9: I2RS Client or I2RS Agent SHOULD also be able to refuse a REQ 9: An I2RS Client or I2RS Agent SHOULD also be able to refuse
communication with an Application or an I2RS Client when the communication with an Application or an I2RS Client when the
communication channel does not fulfill enough security communication channel does not fulfill enough security
requirements. For example, the it should be able to reject requirements. For example, it should be able to reject
messages over a communication channel that can be easily messages over a communication channel that can be easily
hijacked, like a clear text UDP channel. hijacked, such as a clear text UDP channel.
In order to limit the number of access request that result in an In order to limit the number of access request that result in an
error, each Application or I2RS Client may be able to retrieve the error, each Application or I2RS Client may be able to retrieve the
I2RS Access Control policies that applies to it. This subset of I2RS Access Control policies that apply to it. This subset of rules
rules is designated as the "Individual I2RS Access Control policies". is designated as the "Individual I2RS Access Control policies". As
As these policies are subject to changes, a dynamic synchronization these policies are subject to changes, a dynamic synchronization
mechanism should be provided. However, such mechanism may be mechanism should be provided. However, such mechanism may be
implemented with different level of completeness and dynamicity of implemented with different levels of completeness and dynamicity of
the Individual I2RS Access Control policies. Caching requests that the Individual I2RS Access Control policies. Caching requests that
have been rejected may be one such variant. It remains relatively have been rejected may be one such variant. It remains relatively
easy to implement and may avoid the complete disclosure of the Access easy to implement and may avoid the complete disclosure of the Access
Control policies of the I2RS Agent. In fact the relative disclosure Control policies of the I2RS Agent. In fact the relative disclosure
of Access Control policies may leak confidential information in case of Access Control policies may leak confidential information in case
of misconfiguration and should be balanced with the level of trust of of misconfiguration and should be balanced with the level of trust of
the I2RS Client and the necessity of distributing the enforcement of the I2RS Client and the necessity of distributing the enforcement of
the Access Control policies. the Access Control policies.
REQ 10: The I2RS Client may be able to request for its I2RS Access REQ 10: The I2RS Client may be able to request its I2RS Access
Control subset policies to the I2RS Agent or cache requests Control subset policies from the I2RS Agent, or cache
that have been rejected by the I2RS Agent to limit forwarding requests that have been rejected by the I2RS Agent to limit
unnecessary queries to the I2RS Agent. forwarding unnecessary queries to that I2RS Agent.
REQ 11: The I2RS Client may be able to be notified when its I2RS REQ 11: An I2RS Client should be able to be notified when its I2RS
Access Control subset policies have been updated by the I2RS Access Control subset policies have been updated by the I2RS
Agent. Agent.
Similarly, for the Applications Similarly, for the Applications:
REQ 12: The Applications may be able to request for its I2RS Access REQ 12: Applications may be able to request its I2RS Access Control
Control subset policies, so to limit forwarding unnecessary subset policies, in order to limit forwarding unnecessary
queries to the I2RS Client. queries to the I2RS Client.
REQ 13: The Applications may be able to subscribe a service that REQ 13: Applications may be able to subscribe to a service that
provides notification when its I2RS Access Control subset provides notification when its I2RS Access Control subset
policies have been updated. policies have been updated.
I2RS Access Control should be appropriately be balanced between the I2RS Access Control should be appropriately be balanced between the
I2RS Client and the I2RS Agent. I2RS Access Control should not I2RS Client and the I2RS Agent. I2RS Access Control should not
solely rely only on the I2RS Client or the I2RS Agent as illustrated solely rely only on the I2RS Client or the I2RS Agent as illustrated
below: below:
- 1) I2RS Clients are dedicated to a single Application: In this 1. I2RS Clients are dedicated to a single Application: In this
case, it is likely that I2RS Access Control is enforced only by case, it is likely that I2RS Access Control is enforced only by
the I2RS Agent, as the I2RS Client is likely to accept all the I2RS Agent, as the I2RS Client is likely to accept all access
access request of the application. However, it is recommended request of the application. However, it is recommended that even
that even in this case, I2RS Client Access Control is not based in this case, I2RS Client Access Control is not based on an
on an "Allow anything from application" policy, but instead the "Allow anything from application" policy, but instead the I2RS
I2RS Client specifies accesses that are enabled. In addition, Client specifies accesses that are enabled. In addition, the
the I2RS Client may sync its associated I2RS Access Control I2RS Client may sync its associated I2RS Access Control policies
policies with the I2RS Agent to limit the number of refused with the I2RS Agent to limit the number of refused access
access requests being sent to the I2RS Agent. The I2RS Client requests being sent to the I2RS Agent. The I2RS Client is
is expected to balance pro and cons between sync its access expected to balance pro and cons between sync its access control
control policies with the I2RS Agent and simply guessing the policies with the I2RS Agent and simply guessing the access
access request to the I2RS Agent. request to the I2RS Agent.
- 2) A single I2RS Client acts as a broker for all Applications: In 2. A single I2RS Client acts as a broker for all Applications: In
the case the I2RS Agent has a single I2RS Client. Such the case the I2RS Agent has a single I2RS Client. This
architecture results in I2RS Client with high privileges, as it architecture results in an I2RS Client with high privileges, as
sums the privileges of all applications. As end-to-end it provides the union of the privileges of all applications.
authentication is not provided between the Application and the Since end-to-end authentication is not provided between the
I2RS Agent, if the I2RS Client becomes corrupted, it is Application and the I2RS Agent, if the I2RS Client becomes
possible for the malicious application escalates its privileges compromised, it is possible for the malicious applications to
and make the I2RS Client perform some action on behalf of the escalate its privileges and make the I2RS Client perform some
application with more privileges. This would not have been action on behalf of the application with more privileges. This
possible with end-to-end authentication. In order to mitigate would not have been possible with end-to-end authentication. In
such attack, the I2RS Client that acts as a broker is expected order to mitigate such attack, the I2RS Client that acts as a
to host application with an equivalent level of privileges. broker is expected to host application with an equivalent level
of privileges.
REQ 14: The I2RS Access Control should explicitly specify accesses REQ 14: I2RS Access Control should explicitly specify accesses that
that are granted. More specifically, anything not explicitly are granted. More specifically, anything not explicitly
granted -- the default rule-- should be denied. granted - the default rule - should be denied.
In addition to distribute the I2RS Access Control policies between In addition to distribute the I2RS Access Control policies between
I2RS Clients and I2RS Agents, I2RS Access Control policies can also I2RS Clients and I2RS Agents, I2RS Access Control policies can also
be distributed within a set of I2RS Clients or a set of I2RS Agents. be distributed within a set of I2RS Clients or a set of I2RS Agents.
REQ 15: I2RS Clients should be distributed and act as brokers for REQ 15: I2RS Clients should be distributed and act as brokers for
Applications that share roughly similar permissions. This Applications that share roughly similar permissions. This
avoids ending with over privileges I2RS Client compared to avoids ending with over privileges I2RS Client compared to
hosted applications and thus discourages applications to hosted applications and thus discourages applications to
perform privilege escalation within an I2RS Client. perform privilege escalation within an I2RS Client.
REQ 16: I2RS Agents should be avoided being granted over privileges REQ 16: XXX JMH awkward - needs to be repharased
REQ 17: I2RS Agents should be avoided being granted over privileges
regarding to their authorized I2RS Client. I2RS Agent should regarding to their authorized I2RS Client. I2RS Agent should
be shared by I2RS Client with roughly similar permissions. be shared by I2RS Client with roughly similar permissions.
More explicitly, an I2RS Agent shared between I2RS Clients More explicitly, an I2RS Agent shared between I2RS Clients
that are only provided read access to the routing system that are only provided read access to the routing system
resources does not need to perform any write access, and so resources does not need to perform any write access, and so
should not be provided these accesses. Suppose an I2RS should not be provided these accesses. Suppose an I2RS
Client requires write access to the resources. It is not Client requires write access to the resources. It is not
recommended to grant the I2RS Agent the write access in order recommended to grant the I2RS Agent the write access in order
to satisfy a unique I2RS Client. Instead, the I2RS Client to satisfy a unique I2RS Client. Instead, the I2RS Client
that requires write access should be connected to a I2RS that requires write access should be connected to a I2RS
Agent that is already shared by I2RS Client that requires a Agent that is already shared by I2RS Client that requires a
write access. write access.
Access Control policies enforcement should be monitored in order to REQ 18: XXX JMH - similarly awkward, please rephrase
Access Control policy enforcement should be monitored in order to
detect violation of the policies or detect an attack. Access Control detect violation of the policies or detect an attack. Access Control
policies enforcement may not be performed by the I2RS Client or the policy enforcement may not be performed by the I2RS Client or the
I2RS Agent as violation may require a more global view of the I2RS I2RS Agent since violation may require a more global view of the I2RS
Access Control policies. As a result, consistency check and Access Control policies. As a result, consistency checks and
mitigation may instead be performed by the management plane. mitigation may instead be performed by the management plane.
However, I2RS Clients and I2RS Agents play a central role. However, I2RS Clients and I2RS Agents play a central role.
REQ 17: I2RS Client and I2RS Agent should be able to log the various REQ 19: I2RS Clients and I2RS Agents should be able to log the
transaction they perform, as well as suspicious activities. various transactions they perform, as well as suspicious
These logs should be collected regularly and analyzed by activities. These logs should be collected regularly and
functions that may be out of the I2RS plane. analyzed by functions that may be out of the I2RS Plane.
Access Control policies should be implemented so that they remain Access Control policies should be implemented so that they remain
manageable in short and longer term. This means the way they are manageable in the short and longer term. This means the way they are
managed today should be address future deployment and use of I2RS. managed today should address future deployment and use of I2RS.
REQ 18: Access Control should be managed in an automated way, that is REQ 20: Access Control should be managed in an automated way, that is
granting or revoking an Application should not involve manual granting or revoking an Application should not involve manual
configuration over the I2RS plane - like all the I2RS configuration over the I2RS Plane, such as all the I2RS
Clients. Clients.
REQ 19: Access Control should be scalable when the number of REQ 21: Access Control should be scalable when the number of
Application grows as well as when the number of I2RS Client Applications grow, as well as when the number of I2RS Clients
increases. A typical implementation of a local I2RS Client increase. A typical implementation of a local I2RS Client
Access Control policies may result in creating manually a Access Control policy may result in manually creating a
system user associated to each Application. Such an approach system user associated with each Application. Such an
is likely not to scale when the number of Applications approach is likely not to scale when the number of
increases or the number of I2RS Client increases. Applications increase or the number of I2RS Clients increase.
REQ 20: Access Control should be dynamically managed and easy to be REQ 22: Access Control should be dynamically managed and easy to be
updated. Although the number of I2RS Clients is expected to updated. Although the number of I2RS Clients is expected to
be lower than the number of Application, as I2RS Agent be lower than the number of Application, as I2RS Agent
provide access to the routing resource, it is of primary provides access to the routing resource. It is of primary
importance that an access can be granted or revoke in an importance that access can be granted or revoked in an
efficient way. efficient way.
REQ 21: I2RS Clients and I2RS Agents should be uniquely identified in REQ 23: I2RS Clients and I2RS Agents should be uniquely identified in
the network to enable centralized management of the I2RS the network to enable centralized management of the I2RS
Access Control policies. Access Control policies.
5.2. I2RS Agent Access Control policies 5.2. I2RS Agent Access Control policies
The I2RS Agent Access Control restricts the routing system resource The I2RS Agent Access Control restricts the routing system resource
access to authorized identities - possible access policies may be access to authorized identities. Possible access policies may be
none, read or write. The initiator of an access request to a routing none, read or write. The initiator of an access request to a routing
resource is always an Application. However, it remains challenging resource is always an Application. However, it remains challenging
for the I2RS Agent to establish its access control policies based on for the I2RS Agent to establish its access control policies based on
the application that initiates the request. First, when an I2RS the application that initiates the request. First, when an I2RS
Client acts as a broker, the I2RS Agent may not be able to Client acts as a broker, the I2RS Agent may not be able to
authenticate the Application. In that sense, the I2RS Agent relies authenticate the Application. In that sense, the I2RS Agent relies
on the capability of the I2RS Client to authenticate the Applications on the capability of the I2RS Client to authenticate the Applications
and apply the appropriated I2RS Client Access Control. Then, an I2RS and apply the appropriated I2RS Client Access Control. Then, an I2RS
Agent may not uniquely identify a piece of software implementing an Agent may not uniquely identify a piece of software implementing an
I2RS Client. In fact, an I2RS Client may be provided multiple I2RS Client. In fact, an I2RS Client may be provided multiple
identities which can be associated to different roles or privileges. identities which can be associated to different roles or privileges.
The I2RS Client is left responsible for using them appropriately The I2RS Client is left responsible for using them appropriately
according to the Application. Finally, each I2RS Client may contact according to the Application. Finally, each I2RS Client may contact
various I2RS Agent with different privileges and Access Control various I2RS Agent with different privileges and Access Control
policies. policies.
This section provides recommendations on the I2RS Agent Access This section provides recommendations for the I2RS Agent Access
Control policies to keep I2RS Access Control coherent within the I2RS Control policies to keep I2RS Access Control coherent within the I2RS
plane. Plane.
REQ 22: I2RS Agent Access Control policies should be primarily based REQ 24: I2RS Agent Access Control policies should be primarily based
on the I2RS Clients as described in on the I2RS Clients as described in
[I-D.ietf-i2rs-architecture]. [I-D.ietf-i2rs-architecture].
REQ 23: I2RS Agent Access Control policies may be based on the REQ 25: XXX JMH - it is unlcear what the previous sentence is
requiring
REQ 26: I2RS Agent Access Control policies may be based on the
Application. In this case the identity of the Application Application. In this case the identity of the Application
MUST be authenticated by the I2RS Agent, and the secondary MUST be authenticated by the I2RS Agent, and the secondary
identity used to tag the application as defined in identity used to tag the application as defined in
[I-D.ietf-i2rs-architecture] should be considered cautiously. [I-D.ietf-i2rs-architecture] should be considered cautiously.
The tag may be used associated only to an authenticated I2RS The tag may be used associated only to an authenticated I2RS
Client that is known to authenticate its Application. Client that is known to authenticate its Application.
The I2RS Agent Access Control policies may evolve over time as The I2RS Agent Access Control policies may evolve over time as
resource may also be updated outside the I2RS plane. Similarly, a resources may also be updated outside the I2RS Plane. Similarly, a
given resource may be accessed by multiple I2RS users within the I2RS given resource may be accessed by multiple I2RS users within the I2RS
plane. Although this is considered as an error, depending on the Plane. Although this is considered as an error, depending on the
I2RS Client that performed the update, the I2RS may accept or refuse I2RS Client that performed the update, the I2RS may accept or refuse
to overwrite the routing system resource. to overwrite the routing system resource.
REQ 24: The I2RS Agent should know which identity (most likely system REQ 27: The I2RS Agent should know which identity (most likely system
user) performed the latest update of the routing resource. user) performed the latest update of the routing resource.
This is true for an identity inside and outside the I2RS This is true for an identity inside and outside the I2RS
plane, so the I2RS Agent can appropriately perform an update Plane, so the I2RS Agent can appropriately perform an update
according to the priorities associated to the requesting according to the priorities associated to the requesting
identity and the identity that last updated the resource. On identity and the identity that last updated the resource. On
an environment perspective, the I2RS Agent MUST be aware when an environment perspective, the I2RS Agent MUST be aware when
the resource has been modified outside the I2RS plane, as the resource has been modified outside the I2RS Plane, as
well as its priority associated towards the I2RS plane. well as its priority associated towards the I2RS Plane.
Similar requirements exist for identities within the I2RS Similar requirements exist for identities within the I2RS
plane, but belongs to the protocol security requirements. Plane, but belongs to the protocol security requirements.
REQ 25: the I2RS Agent should have a "I2RS Agent overwrite Policy" REQ 28: the I2RS Agent should have a "I2RS Agent overwrite Policy"
that indicates how identities can be prioritized. This that indicates how identities can be prioritized. This
requirements is also described in section 7.6 of requirements is also described in section 7.6 of
[I-D.ietf-i2rs-architecture]. Similar requirements exist for [I-D.ietf-i2rs-architecture]. Similar requirements exist for
components within the I2RS plane, but belongs to the protocol components within the I2RS Plane, but belongs to the protocol
security requirements. security requirements.
5.3. I2RS Client Access Control policies 5.3. I2RS Client Access Control policies
The I2RS Client Access Control policies are responsible for The I2RS Client Access Control policies are responsible for
authenticating the application managing the privileges for the authenticating the application managing the privileges for the
applications, and enforcing access control to resources by the applications, and enforcing access control to resources by the
applications. As a result, applications. As a result,
REQ 26: I2RS Client should authenticate its applications. If the REQ 29: An I2RS Client should authenticate its applications. If the
I2RS Client acts as a broker and supports multiple I2RS Client acts as a broker and supports multiple
Applications, it should authenticate each of them. Applications, it should authenticate each of them.
Authentication of the application may used GSSAPI, Secure RPC Authentication of the application may used GSSAPI, Secure RPC
mechanisms. mechanisms.
REQ 27: I2RS Client should define Access Control policies associated REQ 30: An I2RS Client should define Access Control policies
to each applications. An access to a routing resource by an associated to each application. Access to a routing resource
Application should not be forwarded by the I2RS Client based by an Application should not be forwarded by the I2RS Client
on the I2RS Agent Access Control policies. The I2RS Client based on the I2RS Agent Access Control policies. The I2RS
should first check whether the Application has sufficient Client should first check whether the Application has
privileges, and if so send an access request to the I2RS sufficient privileges, and if so send an access request to
Agent. When an I2RS Client has multiple identities that are the I2RS Agent. When an I2RS Client has multiple identities
associated with different privileges. The I2RS Client Access that are associated with different privileges, the I2RS
Control policies should specify the associated I2RS Client's Client Access Control policies should specify the associated
identities, especially, when the I2RS Agent Access Control I2RS Client's identity, especially when the I2RS Agent Access
policies are changed for a given I2RS Client's identity. Control policies are changed for a given I2RS Client's
identity.
In case, no authentication mechanisms have being provided between the In case, no authentication mechanisms have being provided between the
I2RS Client and the application, then I2RS Client may not act as I2RS Client and the application, then I2RS Client may not act as
broker, and be instead dedicated to a single application. By doing broker, and be instead dedicated to a single application. By doing
so, application authentication may rely on the I2RS authentication so, application authentication may rely on the I2RS authentication
mechanisms between the I2RS Client and the I2RS Agent. On the other mechanisms between the I2RS Client and the I2RS Agent. On the other
hand, although this is not recommended, the I2RS Access Control hand, although this is not recommended, the I2RS Access Control
policies is only enforced by the I2RS Agent. policies is only enforced by the I2RS Agent.
5.4. Application and Access Control policies 5.4. Application and Access Control policies
Application does not enforce access control policies. Instead these Applications do not enforce access control policies. Instead, these
are enforced by the I2RS Clients and the I2RS Agents. This section are enforced by the I2RS Clients and the I2RS Agents. This section
provides recommendations for Applications in order to ease I2RS provides recommendations for Applications in order to ease I2RS
Access Control by the I2RS Client and the I2RS Agent. Access Control by the I2RS Client and the I2RS Agent.
As multiple ways may be used for an Application to communicate with Since multiple ways may be used by an Application to communicate with
its associated I2RS Client, it is not expected that all Applications its associated I2RS Client, it is not expected that all Applications
use the same conventional identifier format across the I2RS plane. use the same conventional identifier format across the I2RS Plane.
However, if all Applications are running on a dedicated system However, if all Applications are running on a dedicated system
sharing an I2RS Client, it is expected each Application may uniquely sharing an I2RS Client, it is expected each Application may uniquely
identified, for example using different system users. identified, for example using different system users.
REQ 28: Applications SHOULD be uniquely identified by their REQ 31: Applications SHOULD be uniquely identified by their
associated I2RS Clients associated I2RS Clients
The I2RS Client provides access to resource on its behalf and this The I2RS Client provides access to resource on its behalf and this
access should only be granted for trusted applications, or access should only be granted for trusted applications, or
Applications with an similar level of trust. On the other hand, this Applications with an similar level of trust. On the other hand, this
does not prevent an I2RS Client to host a large number of does not prevent an I2RS Client from hosting a large number of
Applications. Similarly, an Application may also require to access Applications. Similarly, an Application may also require access to
multiple I2RS Clients depending on the resource to be accessed. As multiple I2RS Clients depending on the resource to be accessed.
I2RS Client are restricted for a subset of Applications, Since I2RS Clients are restricted to a subset of Applications:
REQ 29: Each Application SHOULD be associated to a restricted number REQ 32: Each Application SHOULD be associated to a restricted number
of I2RS Client of I2RS Clients.
REQ 30: Application SHOULD be provided means and methods to contact REQ 33: Applications SHOULD be provided the means and methods to
their associated I2RS Client. If the I2RS Client belongs to contact their associated I2RS Client. If an I2RS Client
the Application (as a module or a library for example), or belongs to the Application (as a module or a library for
when the Application runs into a dedicated system (like a example), or when the Application runs in a dedicated system
container) with a I2RS Client, it is obvious which I2RS (like a container) with a I2RS Client, it is obvious which
Client the Application is associated to. On the other hand, I2RS Client the Application is associated to. On the other
Applications may also remotely access the I2RS Client. In hand, Applications may also remotely access an I2RS Client.
this case, the Application is expected to be provided some In this case, the Application is expected to be provided some
means to be able to retrieve the necessary information to means to be able to retrieve the necessary information to
contact its associated I2RS Client. The IP address may not contact its associated I2RS Client. The IP address may not
be appropriated in case renumbering occurs within the network be appropriated in case renumbering occurs within the network
or in case the traffic from Applications should be shared or in case the traffic from Applications should be shared
between multiple instances of a given I2RS Client. In this between multiple instances of a given I2RS Client. In this
case a FQDN may be preferred. case a FQDN may be preferred.
6. I2RS Application Isolation 6. I2RS Application Isolation
A key aspect of the I2RS architecture is the network oriented A key aspect of the I2RS architecture is the network oriented
application. As these application are supposed to be independent, application. These application are controlled by independent and
controlled by independent and various tenants. In addition to various tenants. In addition to independent logic, these
independent logic, these applications may be malicious. Then, these applications may be malicious. These applications also introduce
applications introduce also programmability which results in fast programmability which results in fast network settings.
network settings.
The I2RS architecture should remain robust to these applications and The I2RS architecture should remain robust for these applications and
make sure an application does not impact the other applications. make sure an application does not impact the other applications.
This section discusses both security aspects related to This section discusses both security aspects related to
programmability as well as application isolation in the I2RS programmability as well as application isolation in the I2RS
architecture. architecture.
6.1. Robustness toward programmability 6.1. Robustness Toward Programmability
I2RS provides a programmatic interface in and out of the Internet I2RS provides a programmatic interface into and out of the Internet
routing system. This feature, in addition to the global network view routing system. This feature, in addition to the global network view
provided by the centralized architecture comes with a few advantages provided by the centralized architecture, comes with a few advantages
in term of security. in terms of security.
The use of automation reduces configuration errors. In addition, The use of automation reduces configuration errors. In addition,
this interface enables fast network reconfiguration. Agility this interface enables fast network reconfiguration. Agility
provides a key advantage in term of deployment as side effect provides a key advantage in term of deployment as side effect
configuration may be easily addressed. Finally, it also provides configuration may be easily addressed. Finally, it also provides
facilities to monitor and mitigate an attack when the network is facilities to monitor and mitigate an attack when the network is
under attack. under attack.
On the other hand programmability also comes with a few drawbacks. On the other hand, programmability also comes with a few drawbacks:
First, applications can belong to multiple tenants with different Applications can belong to multiple tenants with different
objectives. This absence of coordination may result in unstable objectives. This absence of coordination may result in unstable
routing configurations such as oscillations between network routing configurations such as oscillations between network
configurations, and creation of loops for example. A typical example configurations, and creation of loops. A typical example would be an
would be an application monitoring a state and changing its state. application monitoring and changing some state. If another
If another application performs the reverse operation, the routing application performs the reverse operation, the routing system may
system may become unstable. Data and application isolation is become unstable. Data and application isolation is expected to
expected to prevent such situations to happen, however, to guarantee prevent such situations from happening. However, to guarantee
the network stability, constant monitoring and error detection are network stability, constant monitoring and error detection are
recommended to be activated. recommended.
REQ 31: The I2RS Agents should monitor constantly parts of the system REQ 34: I2RS Agents should constantly monitor the parts of the system
for which I2RS Clients or Applications have provided that I2RS Clients or Applications have provided requests. It
requests. It should also be able to detect I2RS Clients or should also be able to detect I2RS Clients or Applications
Applications that lead the routing system in an unstable that make the routing system unstable. Minimally, monitoring
state. Monitoring consists at least in logging events and consists of logging events and eventually providing
eventually provide notifications or alerts to the management notifications or alerts to the management plane when
plane in case, something has been detected. The management something has been detected. The management plane is in
plane is in charge of collecting the logs, the notifications charge of collecting the logs, the notifications, and
and eventually to consider the appropriated actions. A eventually the consideration of appropriate actions. For
typical action may be the update of I2RS Access Control example, a typical action may be the update of I2RS Access
policies for example or re-configuring routing elements. Control policies or re-configuring routing elements.
6.2. Application Isolation 6.2. Application Isolation
6.2.1. DoS 6.2.1. DoS
Requirements for robustness to Dos Attacks have been addressed in the Requirements for robustness to DoS Attacks have been addressed in the
Communication channel section [I-D.ietf-i2rs-architecture]. Communication channel section [I-D.ietf-i2rs-architecture].
The I2RS interface is used by application to interact with the The I2RS interface is used by applications to interact with the
routing states. As the I2RS Agent is shared between multiple routing states. Since the I2RS Agent is shared between multiple
applications, one application can prevent an application by applications, one application can prevent an application from
performing DoS or DDoS attacks on the I2RS Agent or on the network. performing DoS or DDoS attacks on the I2RS Agent or on the network.
DoS attack targeting the I2RS Agent would consist in providing DoS attacks targeting the I2RS Agent would consist of providing
requests that keep the I2RS Agent busy for a long time. This may requests that keep the I2RS Agent busy for a long time. This may
involve heavy computation by the I2RS Agent for example to blocking involve heavy computation by the I2RS Agent, for example, to blocking
operations like disk access. In addition, DoS attacks targeting the operations like disk access. In addition, DoS attacks targeting the
network may use specific commands like monitoring stream over the network may use specific commands like monitoring stream over the
network. Then, DoS attack may be also targeting the application network. Then, DoS attack may be also targeting the application
directly by performing reflection attacks. Such an attack could be directly by performing reflection attacks. Such an attack could be
performed by indicating the target application as the target for some performed by indicating the target application as the target for some
information like the listing of the RIB. Reflection may be performed information like the listing of the RIB. Reflection may be performed
at various levels and can be based on the use of UDP or at the at various levels and can be based on the use of UDP or at the
service level like redirection of information to a specific service level like redirection of information to a specific
repository. repository.
REQ 32: In order to prevent DoS, it is recommended the I2RS Agent REQ 35: In order to prevent DoS, it is recommended the I2RS Agent
controls the resources allocated to each I2RS Clients. I2RS controls the resources allocated to each I2RS Client. I2RS
Client that acts as broker may not be protected as Clients that act as brokers may not be protected as
efficiently against these attacks unless they perform efficiently against these attacks unless they perform
resource controls themselves of their hosted applications. resource controls themselves of their hosted applications.
REQ 33: I2RS Agent does not make response redirection possible unless REQ 36: An I2RS Agent does not make response redirection possible
the redirection is previously validated and agreed by the unless the redirection is previously validated and agreed by
destination. the destination.
REQ 34: avoid the use of underlying protocols that are not robust to REQ 37: Avoid the use of underlying protocols that are not robust to
reflection attacks. reflection attacks.
6.2.2. Application Control 6.2.2. Application Control
Requirements for Application Control have been addressed in the I2RS Requirements for Application Control have been addressed in the I2RS
plane isolation as well as in the trusted Communication Channel Plane isolation as well as in the trusted Communication Channel
sections. sections.
Applications use the I2RS interface in order to update the routing Applications use the I2RS interface in order to update the routing
system. These updates may be driven by behavior on the forwarding system. These updates may be driven by behavior on the forwarding
plane or any external behaviors. In this case, correlating plane or any external behaviors. In this case, correlating
observation to the I2RS traffic may enable to derive the application observation to the I2RS traffic may enable to derive the application
logic. Once the application logic has been derived, a malicious logic. Once the application logic has been derived, a malicious
application may generate traffic or any event in the network in order application may generate traffic or any event in the network in order
to activate the alternate application. to activate the alternate application.
REQ 35: Application logic should remain opaque to external listeners. REQ 38: Application logic should remain opaque to external listeners.
Application logic may be partly hidden by encrypting the Application logic may be partly hidden by encrypting the
communication between the I2RS Client and the I2RS Agent. communication between the I2RS Client and the I2RS Agent.
Additional ways to obfuscate the communications may involve Additional ways to obfuscate the communications may involve
sending random messages of various sizes. Such strategies sending random messages of various sizes. Such strategies
have to be balanced with network load. Note that I2RS Client have to be balanced with network load. Note that I2RS Client
broker are more likely to hide the application logic compared broker are more likely to hide the application logic compared
to I2RS Client associated to a single application. to I2RS Client associated to a single application.
7. Security Considerations 7. Security Considerations
skipping to change at page 18, line 35 skipping to change at page 18, line 48
8. Privacy Considerations 8. Privacy Considerations
9. IANA Considerations 9. IANA Considerations
10. Acknowledgments 10. Acknowledgments
A number of people provided a significant amount of helping comments A number of people provided a significant amount of helping comments
and reviews. Among them the authors would like to thank Russ White, and reviews. Among them the authors would like to thank Russ White,
Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas,
Alia Atlas, Linda Dunbar Alia Atlas, Linda Dunbar.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, March 1997.
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-09 (work in System", draft-ietf-i2rs-architecture-09 (work in
progress), March 2015. progress), March 2015.
[I-D.ietf-i2rs-protocol-security-requirements] [I-D.ietf-i2rs-protocol-security-requirements]
Hares, S., Migault, D., and J. Halpern, "I2RS Security Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", draft-ietf-i2rs-protocol-security- Related Requirements", draft-ietf-i2rs-protocol-security-
requirements-01 (work in progress), September 2015. requirements-02 (work in progress), December 2015.
Authors' Addresses Authors' Addresses
Daniel Migault (editor) Daniel Migault (editor)
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
Phone: +1 514-452-2160 Phone: +1 514-452-2160
 End of changes. 130 change blocks. 
370 lines changed or deleted 382 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--CdrF4e02JqNVZeln Content-Type: application/xml Content-Disposition: attachment; filename="draft-ietf-i2rs-security-environment-reqs.xml" Content-Transfer-Encoding: quoted-printable =0A= =0A =0A =0A]>=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A =0A I2RS Environment Security Requirements=0A= =0A =0A Ericsson =0A =
=0A =0A 8400 boulevard Decarie = =0A Montreal, QC =0A H4P 2N= 2 =0A Canada =0A =0A = +1 514-452-2160 =0A daniel.migault@eric= sson.com =0A
=0A =0A=0A =0A Ericsson=0A
=0A Joel.Halp= ern@ericsson.com=0A
=0A =0A =0A Huawei=0A
=0A =0A = 7453 Hickory Hill=0A Saline=0A = MI=0A 48176=0A USA=0A =0A shares@ndzh.com=0A =0A <= /address>=0A =0A=0A =0A Routing Area =0A I2RS WG =0A=0A =0A This = document provides environment security requirements for the I2RS architectu= re. The environment security requirements are independent of the protocol u= sed for I2RS and are intended to document the deployment and operational en= vironment of I2RS. =0A =0A=0A =0A =0A= =0A
=0A The key w= ords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOUL= D NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be int= erpreted as described in .=0A =0A=0A=0A
=0A = This document provides environment security requirements for the I2RS ar= chitecture. Environment security requirements are independent of the protoc= ol used for I2RS. As a result, the requirements provided in this document a= re intended to provide good security practice so I2RS can be securely deplo= yed and operated. =0A These security requirements are designated = as environment security requirements as opposed to the protocol security re= quirements described in . The reason to have separate document is that protocol securi= ty requirements are intended to help the design of the I2RS protocol whethe= r the environment requirements are rather intended for deployment or implem= entations.=0A=0A=0A Even though I2RS is most= ly concerned with the interface between the I2RS Client and the I2RS Agent,= the security recommendations must consider the entire I2RS architecture, s= pecifying where security functions may be hosted, and what should be met s= o to address any new attack vectors exposed by deploying this architecture.= In other words, security has to be considered globally over the complete I= 2RS architecture and not only on its interfaces.=0A=0A The I2RS= architecture depicted in des= cribes the I2RS components and their interactions to provide a programmatic= interface for the routing system. I2RS components, as well as their intera= ctions, have not yet been considered in conventional routing systems. As su= ch, it introduces a need to interface with the routing system designated as= the I2RS Plane in this document. =0A=0A=0A This document is st= ructured as follows:=0A =0A = describes how the I2RS Plane ca= n be contained or isolated from existing management plane, control plane an= d forwarding plane. The remaining sections of the document focuses on the s= ecurity within the I2RS Plane.=0A analyzes how the I2RS Access Control policies can be deployed througho= ut the I2RS Plane in order to only grant access to the routing system resou= rces to authorized components with the authorized privileges. This also inc= ludes providing a robust communication system between the components.= =0A details how= I2RS keeps applications isolated one from another and do not affect the I2= RS components. Applications may be independent, with different scopes, owne= d by different tenants. In addition, they modify the routing system that ma= y be in an automatic way.=0A =0A=0A =0A The r= eader is expected to be familiar with the . The document provides a list of environment security requirem= ents. Motivations are placed before the related requirements.=0A=0A =
=0A=0A
=0A = =0A =0A The environment the I2RS architecture is running on. It= includes the Applications, the I2RS Clients and the I2RS Agent. =0A = The user of the I2RS client software or= system. =0A Policies= controlling access of the routing resources by Applications. These policie= s are divided into policies applied by the I2RS Client regarding Applicatio= ns and policies applied by the I2RS Agent regarding I2RS Clients.=0A = The Access Control p= olicies processed by the I2RS Client.=0A The Access Control policies processed by the I2RS= Agent.=0A =0A =0A
=0A=0A=0A =0A= =0AIsolating the I2RS Plane from other network planes, such as the contr= ol plane, is foundational to the security of the I2RS environment. Clearly = differentiating I2RS components from the rest of the network protects the I= 2RS components from vulnerabilities in other parts of the network, and prot= ect other systems vital to the health of the network from vulnerabilities i= n the I2RS Plane. Separating the I2RS Plane from other network control and = forwarding planes is similar to the best common practice of containerizing = software into modules, and defense in depth in the larger world of network = security.=0A=0A=0A That said, the I2RS Plane cannot be considered as being co= mpletely isolated from other planes, and interactions should be identified = and controlled. The following sections provide brief descriptions on how th= e I2RS Plane positions itself with regard to the other planes. =0A=0A =
=0AThe purpose of = the I2RS Plane is to provide a standard programmatic interface to the routi= ng system resources for network-oriented applications. Control and forwardi= ng planes are related to routing protocols, and I2RS is based on top of tho= se. The management plane is usually vendor specific, and provides broader c= ontrol over the networking equipment such as system services. Given its ass= ociated privileges, it is expected to be reserved for highly trusted users = such as network administrators. =0A =0A = The I2RS Plane and the management plane both interact with several = common elements on forwarding and packet processing devices. describes several of these interaction po= ints such as local configuration, static system state, routing, and signali= ng.=0ABecause of these potential overlaps, a routing resource may be access= ed by different means (e.g., APIs and applications) and different planes. T= o keep these overlaps under control, one could control access to these reso= urces with northbound APIs, for example. Northbound APIs are provided to li= mit the scope of the applications toward the routing resources. In our case= , the northbound API may be provided for the I2RS applications by the I2RS = Client as well as to the management plane. When conflicting overlaps canno= t be avoided, and routing resource can be accessed by both the management p= lane and the I2RS Plane, they should be resolved in a deterministic way.=0AOn the northbound side, there must be clear protections against the = I2RS system "infecting" the management system with bad information, or vice= -versa. The primary protection in this space is going to need to be validat= ion rules on the speed of information flow, value limits on the data presen= ted, and other protections of this type.=0A=0AOn the conflicting s= ide/issues, there should be clear rules about which plan's commands win in = the case of conflict in order to prevent attacks where the two systems can = be forced to deadlock.=0A=0A
= =0A=0A
=0A=0A = Applications hosted on I2RS Client belong to the I2RS Plane.= These Applications are hard to remain constrained into the I2RS Plane, or = even to limit their scope within the I2RS Plane.=0A =0A=0A Applications using I2RS are part of = the I2RS Plane but may also interact with other components outside the I2RS= Plane. A common example may be an application that uses I2RS to configure = the network according to security or monitored events. Since these events a= re monitored on the forwarding plane and not in the I2RS Plane, the applica= tion breaks plane isolation.=0A =0A=0A = In addition, applications may communicate with multiple I2RS= Clients. Thus any given application may have a broader view of the current= and potential states of the network and the I2RS Plane itself. Because of = this, any individual application could be an effective attack vector agains= t the operation of the network, the I2RS Plane, or any plane with which the= I2RS Plane interacts. There is little the I2RS Plane can do to validate ap= plications with which it interacts, other than to provide some general vali= dation against common misconfigurations or errors. As with the separation b= etween the management plane and the I2RS Plane, this should minimally take = the form of limits on information accepted, limits on the rate at which inf= ormation is accepted, and rudimentary checks against intentionally formed r= outing loops or injecting information that would cause the control plane to= fail to converge. Other forms of protection may be necessary.=0A=0A =
=0A=0A
=0A= =0A The network control plane consists of the processe= s and protocols that discover topology, advertise reachability, and determi= ne the path between any location on the network and any destination. It is = not anticipated there will be any interactions between the on-the-wire sign= aling used by the control plane and the I2RS Plane. However, in some situat= ions the I2RS system could modify information in the local databases of the= control plane. This is not normally recommended, as it can bypass the norm= al loop free, loop free alternate, and convergence properties of the contro= l plane. However, if the I2RS system does directly inject information into = these tables, the I2RS system should ensure that loop free routing is prese= rved, including loop free alternates, tunneled interfaces, virtual overlays= , and other such constructions. Any information injected into the control p= lane directly could cause the control plane to fail to converge, resulting = in a complete network outage.=0A=0A
=0A
=0A =0A To isolate I2RS transactions fro= m other planes, it is recommended that:=0A =0A =0A Application-to-routing sy= stem resources communications should use an isolated communication channel.= Various levels of isolation can be considered. The highest level of isolat= ion could be provided by using a physically isolated network. Alternatives = may also include logical isolation; for example by using vLANs. In virtual = environments that share a common infrastructure, encryption - for example, = TLS or IPsec - may also be used as a way to enforce isolation.=0A=0A = The IP interface used by the routing element to receive I2RS transa= ctions should be a dedicated physical or logical interface. As previously m= entioned, a dedicated physical interface may contribute to higher isolation= =2E However, logical isolation be also be considered - for example, by usin= g a dedicated IP address or a dedicated port. =0A=0A =0A =0A=0A When the I2= RS Agent performs an action on a routing element, the action is performed v= ia process(es) associated to a system user. In a typical UNIX system, the u= ser is designated with a user id (uid) and belong to groups designated by g= roup ids (gid). These users are dependent of the routing element's operatin= g system and are designated I2RS System Users. Some implementation may use = a single I2RS System User for the I2RS Agent that proxies the different I2R= S Clients, other implementations may use distinct I2RS System Users for eac= h I2RS Client.=0A =0A =0A=0A I2RS Agents should have perm= issions separate from any other entity; for example, any internal system ma= nagement or CLI processes. =0A=0A =0A =0A=0A = I2RS resources may be shared with the management plane and the control = plane. It is hardly possible to prevent interactions between the planes. I2= RS routing system resource management is limited to the I2RS Plane. As such= , updates to an I2RS-enabled routing system outside of the I2RS Plane may r= emain unnoticed unless the I2RS Plane is explicitly notified. Such notifica= tion is expected to trigger synchronization of the I2RS resource state with= in each I2RS component. This guarantees that I2RS resource are maintained i= n a coherent state within the I2RS Plane. In addition, depending on the I2R= S resource that is updated as well as the origin of the modification perfor= med, the I2RS Access Control policies may be impacted. For example, an I2RS= Client is more likely to update an I2RS resources that has been updated by= itself than by the management plane.=0A =0A=0A The I2RS Plane should be informed = when a routing system resource used by that plane is externally modified. T= he notification is not expected to flood the I2RS Plane. Instead, the notif= ication is expected to be provided to the I2RS components interacting, conf= iguring or monitoring the routing system resource. The notification is at l= east provided by the I2RS Agent to the various I2RS Client, but additional = mechanisms might eventually be required so I2RS Client can relay the notifi= cation to the I2RS applications. This is designated as "I2RS resource modi= fied out of I2RS Plane". This requirements is also described in section 7.6= of for the I2RS Client. This= document extends the requirement to the I2RS Plane, in case future evoluti= on of the I2RS Plane.=0A=0A The I2RS Plane should define an "= I2RS Plane overwrite policy". Such policy defines how an I2RS is able to up= date and overwrite a resource set by a user outside the I2RS Plane. Such hi= erarchy has been described in section 6.3 and 7.8 of =0A =0A =0A =0A
=0A=0A=0A
=0A=0A This section provi= des recommendations on how I2RS Access Control policies are associated to t= he routing system resources. These policies only apply within the I2RS Plan= e. More especially, the policies are associated to the Applications, the I= 2RS Clients, and the I2RS Agents with their associated identity and roles.<= /t>=0A=0A Note that the deployment of Applications, I2RS Clien= t, and I2RS Agent in a closed environment should not be considered by defau= lt as a secure environment. Even for closed environment access control poli= cies should be carefully defined to be able to, in the future, carefully ex= tend the I2RS Plane to remote Applications or remote I2RS Clients. As a res= ult, this section always consider the case where Applications and I2RS Clie= nt can be located locally, in a closed environment, or distributed over ope= n networks.=0A=0A Although provides security requirements for the tra= nsport and protocol between the I2RS Client and the I2RS Agent, this sectio= n is mostly focused on access control.=0A =0A=0A
=0A=0A Application access to routin= g system resources via numerous intermediaries nodes. The application commu= nicates with an I2RS Client. In some cases, the I2RS Client is only associa= ted to a single application, but the I2RS Client may also act as a broker. = The I2RS Client communicates with the I2RS Agent that may eventually access= the resource.=0A=0A The I2RS Client broker approach provides s= calability to the I2RS architecture since it avoids requiring each Applicat= ion be registered with the I2RS Agent. Similarly, I2RS Access Control shoul= d be able to scale numerous applications.=0A=0A =0A I2RS Access Control should be performed th= roughout the I2RS Plane. It should not be enforced by the I2RS Agent only w= ithin the routing element. Instead, the I2RS Client should enforce the I2RS= Client Access Control against Applications and the I2RS Agent should enfor= ce the I2RS Agent Access Control against the I2RS Clients. Note that I2RS C= lient Access Control is not in the scope of the I2RS architecture , which exclusively focuses on the I2RS= Agent Access Control. =0A =0A =0A =0A =0A This results i= n a layered and hierarchical or multi-party I2RS Access Control. An applica= tion will then be able to access a routing system resource only if both the= I2RS Client is granted access by the I2RS Agent and the application is gra= nted access by the I2RS Client. =0A =0A When an access request to a routing resource is re= fused by one party (the I2RS Client or the I2RS Agent), the initiator of th= e request (e.g., the Application) as well as all intermediaries should indi= cate the reason the access has not been granted, as well as the entity that= has rejected the request.=0A In order to provide coherent Access= Control policies enforced by multiple parties (e.g., the I2RS Client or th= e I2RS Agent), these parties should trust each other, and communication bet= ween them should also be trusted; that is they should not introduce additio= nal vectors of attack.=0A =0A =0A In case the I2RS Clien= t Access Control or the I2RS Agent Access Control does not grant access to = a routing system resource, the Application should be able to determine whet= her its request has been rejected by the I2RS Client or the I2RS Agent as w= ell as the reason that caused the rejection. More specifically, the I2RS Ag= ent may reject the request because, for example, the I2RS Client is not an = authorized I2RS Client, or because the I2RS Client does not not have enough= privileges. The I2RS Client should be notified of the reason that caused t= he rejection by the I2RS Agent, and The I2RS Client should return a message= to the Application, indicating the I2RS Client is not authorized or does n= ot have enough privileges. Similarly, if the I2RS Client does not grant acc= ess to the Application, the I2RS Client should also inform the Application.= =0A For example, the error message returned could be: "Read failure= : you do not have read permission", "Write failure: you do not have write p= ermission", or "Write failure: resource accessed by someone else". =0A=0AThis requirement has been written in a generic manner a= s it concerns various interactions: interactions between the application an= d the I2RS Client, interactions between the I2RS Client and the I2RS Agent.= In the latest case, the requirement is part of the protocol security requi= rements addressed by . =0A=0AAlthough is focused on transport security requirements between= the I2RS Client and the I2RS Agent, similar requirements may apply between= the Application and the I2RS Client for a remote Application.=0A =0A An I2RS Client = or I2RS Agent SHOULD also be able to refuse communication with an Applicati= on or an I2RS Client when the communication channel does not fulfill enough= security requirements. For example, it should be able to reject messages o= ver a communication channel that can be easily hijacked, such as a clear te= xt UDP channel. =0A =0A =0A=0A In order to limit the nu= mber of access request that result in an error, each Application or I2RS Cl= ient may be able to retrieve the I2RS Access Control policies that apply to= it. This subset of rules is designated as the "Individual I2RS Access Cont= rol policies". As these policies are subject to changes, a dynamic synchron= ization mechanism should be provided. However, such mechanism may be implem= ented with different levels of completeness and dynamicity of the Individua= l I2RS Access Control policies. Caching requests that have been rejected ma= y be one such variant. It remains relatively easy to implement and may avoi= d the complete disclosure of the Access Control policies of the I2RS Agent.= In fact the relative disclosure of Access Control policies may leak confid= ential information in case of misconfiguration and should be balanced with = the level of trust of the I2RS Client and the necessity of distributing the= enforcement of the Access Control policies.=0A=0A= =0A =0A The I2RS = Client may be able to request its I2RS Access Control subset policies from = the I2RS Agent, or cache requests that have been rejected by the I2RS Agent= to limit forwarding unnecessary queries to that I2RS Agent.=0A=0A An I2RS Client should be able to be notified when its I2RS Access Control = subset policies have been updated by the I2RS Agent. =0A =0A = =0A=0A Similarly, for the Applications:=0A =0A Applications may be able to request i= ts I2RS Access Control subset policies, in order to limit forwarding unnece= ssary queries to the I2RS Client.=0A Applications may be able to s= ubscribe to a service that provides notification when its I2RS Access Contr= ol subset policies have been updated. =0A =0A =0A=0A = I2RS Access Control should be appropriately be balanced between the I2RS Cl= ient and the I2RS Agent. I2RS Access Control should not solely rely only on= the I2RS Client or the I2RS Agent as illustrated below:=0A =0A In this case, it is likely tha= t I2RS Access Control is enforced only by the I2RS Agent, as the I2RS Clien= t is likely to accept all access request of the application. However, it is= recommended that even in this case, I2RS Client Access Control is not base= d on an "Allow anything from application" policy, but instead the I2RS Clie= nt specifies accesses that are enabled. In addition, the I2RS Client may sy= nc its associated I2RS Access Control policies with the I2RS Agent to limit= the number of refused access requests being sent to the I2RS Agent. The I2= RS Client is expected to balance pro and cons between sync its access contr= ol policies with the I2RS Agent and simply guessing the access request to t= he I2RS Agent.=0A In the case the I2RS Agent has a single I2RS = Client. This architecture results in an I2RS Client with high privileges, a= s it provides the union of the privileges of all applications. Since end-to= -end authentication is not provided between the Application and the I2RS Ag= ent, if the I2RS Client becomes compromised, it is possible for the malicio= us applications to escalate its privileges and make the I2RS Client perform= some action on behalf of the application with more privileges. This would = not have been possible with end-to-end authentication. In order to mitigate= such attack, the I2RS Client that acts as a broker is expected to host app= lication with an equivalent level of privileges.=0A =0A =0A=0A =0A =0A I2RS Access Control should explicitly specify accesses that= are granted. More specifically, anything not explicitly granted - the defa= ult rule - should be denied.=0A =0A =0A =0A = In addition to distribute the I2RS Access Control policies between = I2RS Clients and I2RS Agents, I2RS Access Control policies can also be dist= ributed within a set of I2RS Clients or a set of I2RS Agents. =0A=0A I2RS Clients should be di= stributed and act as brokers for Applications that share roughly similar pe= rmissions. This avoids ending with over privileges I2RS Client compared to = hosted applications and thus discourages applications to perform privilege = escalation within an I2RS Client. =0A =0A=0A I2RS Agents should be avoided being granted ove= r privileges regarding to their authorized I2RS Client. I2RS Agent should b= e shared by I2RS Client with roughly similar permissions. More explicitly, = an I2RS Agent shared between I2RS Clients that are only provided read acces= s to the routing system resources does not need to perform any write access= , and so should not be provided these accesses. Suppose an I2RS Client requ= ires write access to the resources. It is not recommended to grant the I2RS= Agent the write access in order to satisfy a unique I2RS Client. Instead, = the I2RS Client that requires write access should be connected to a I2RS Ag= ent that is already shared by I2RS Client that requires a write access.= =0A =0A=0A=0A =0AAccess Control policy enforcement should be monitored in or= der to detect violation of the policies or detect an attack. Access Control= policy enforcement may not be performed by the I2RS Client or the I2RS Age= nt since violation may require a more global view of the I2RS Access Contro= l policies. As a result, consistency checks and mitigation may instead be p= erformed by the management plane. However, I2RS Clients and I2RS Agents pla= y a central role. =0A= =0A I2RS Clients and I2RS Agents should be able to log the various tr= ansactions they perform, as well as suspicious activities. These logs shoul= d be collected regularly and analyzed by functions that may be out of the I= 2RS Plane.=0A=0A=0A=0A=0A=0A Access Control policies s= hould be implemented so that they remain manageable in the short and longer= term. This means the way they are managed today should address future depl= oyment and use of I2RS. =0A =0A Access Control should be managed in an au= tomated way, that=0A is granting or revoking an Application shoul= d not involve=0A manual configuration over the I2RS Plane, such a= s all the I2RS=0A Clients.=0A=0A Access Control= should be scalable when the number of=0A Applications grow, as w= ell as when the number of I2RS Clients=0A increase. A typical im= plementation of a local I2RS Client=0A Access Control policy may = result in manually creating a system user associated=0A with each= Application. Such an approach is likely not to scale=0A when th= e number of Applications increase or the number of=0A I2RS Client= s increase.=0A Access Control should be dynamically manag= ed and easy to be updated. Although the number=0A of I2RS Clients= is expected to be lower than the number of=0A Application, as I2= RS Agent provides access to the routing=0A resource. It is of pri= mary importance that access can be=0A granted or revoked in an ef= ficient way.=0A=0A I2RS Clients and I2RS Agents should be = uniquely identified in the network to enable centralized management of the = I2RS Access Control policies.=0A =0A =0A =0A =
=0A=0A
=0A=0AThe I2RS Agent Access Control restricts the routing system res= ource access to authorized identities. Possible access policies may be none= , read or write. =0AThe initiator of an access request to a routing resourc= e is always an Application. However, it remains challenging for the I2RS Ag= ent to establish its access control policies based on the application that = initiates the request. First, when an I2RS Client acts as a broker, the I2R= S Agent may not be able to authenticate the Application. In that sense, the= I2RS Agent relies on the capability of the I2RS Client to authenticate the= Applications and apply the appropriated I2RS Client Access Control. Then, = an I2RS Agent may not uniquely identify a piece of software implementing an= I2RS Client. In fact, an I2RS Client may be provided multiple identities w= hich can be associated to different roles or privileges. The I2RS Client is= left responsible for using them appropriately according to the Application= =2E Finally, each I2RS Client may contact various I2RS Agent with different= privileges and Access Control policies.=0A=0AThis section provides = recommendations for the I2RS Agent Access Control policies to keep I2RS Acc= ess Control coherent within the I2RS Plane. =0A=0A=0A=0A=0A I2RS Agent Access Control policies = should be primarily based on the I2RS Clients as described in .=0A =0A I2RS Agent Acc= ess Control policies may be based on the Application. In this case the iden= tity of the Application MUST be authenticated by the I2RS Agent, and the se= condary identity used to tag the application as defined in should be considered cautiously. The tag may = be used associated only to an authenticated I2RS Client that is known to au= thenticate its Application. =0A=0A=0A=0A=0AThe I2RS Agent= Access Control policies may evolve over time as resources may also be upda= ted outside the I2RS Plane. Similarly, a given resource may be accessed by = multiple I2RS users within the I2RS Plane. Although this is considered as a= n error, depending on the I2RS Client that performed the update, the I2RS m= ay accept or refuse to overwrite the routing system resource. =0A=0A The I2RS Agent should know= which identity (most likely system user) performed the latest update of th= e routing resource. This is true for an identity inside and outside the I2R= S Plane, so the I2RS Agent can appropriately perform an update according to= the priorities associated to the requesting identity and the identity that= last updated the resource. =0AOn an environment perspective, the I2RS Agen= t MUST be aware when the resource has been modified outside the I2RS Plane,= as well as its priority associated towards the I2RS Plane. =0ASimilar requ= irements exist for identities within the I2RS Plane, but belongs to the pro= tocol security requirements. =0A=0A the I2RS Agent should have a "I= 2RS Agent overwrite Policy" that indicates how identities can be prioritize= d. This requirements is also described in section 7.6 of . Similar requirements exist for components with= in the I2RS Plane, but belongs to the protocol security requirements.= =0A=0A=0A=0A
=0A=0A=0A
=0A=0A The I2RS Client Access Contro= l policies are responsible for authenticating the application managing the= privileges for the applications, and enforcing access control to resources= by the applications.=0AAs a result,=0A =0A An I2RS Client should authenticate = its applications. If the I2RS Client acts as a broker and supports multiple= Applications, it should authenticate each of them. Authentication of the a= pplication may used GSSAPI, Secure RPC mechanisms.=0A = An I2RS Client should define Access Control policies associated to eac= h application. Access to a routing resource by an Application should not be= forwarded by the I2RS Client based on the I2RS Agent Access Control polici= es. The I2RS Client should first check whether the Application has sufficie= nt privileges, and if so send an access request to the I2RS Agent. When an = I2RS Client has multiple identities that are associated with different priv= ileges, the I2RS Client Access Control policies should specify the associat= ed I2RS Client's identity, especially when the I2RS Agent Access Control po= licies are changed for a given I2RS Client's identity.=0A =0A =0A=0AIn case, no authentication mechanisms have being = provided between the I2RS Client and the application, then I2RS Client may = not act as broker, and be instead dedicated to a single application. By doi= ng so, application authentication may rely on the I2RS authentication mecha= nisms between the I2RS Client and the I2RS Agent. On the other hand, althou= gh this is not recommended, the I2RS Access Control policies is only enforc= ed by the I2RS Agent. =0A=0A=0A
=0A=0A=0A =
=0A= =0A Applications do not enforce access control policies. Instead, the= se are enforced by the I2RS Clients and the I2RS Agents. This section provi= des recommendations for Applications in order to ease I2RS Access Control b= y the I2RS Client and the I2RS Agent.=0A=0A Since multiple ways m= ay be used by an Application to=0A communicate with its associate= d I2RS Client, it is not=0A expected that all Applications use th= e same conventional=0A identifier format across the I2RS Plane. = However, if all=0A Applications are running on a dedicated system= sharing an=0A I2RS Client, it is expected each Application may u= niquely=0A identified, for example using different system users.= =0A =0A = Applications SHOULD be uniquely identified by their associated I2= RS Clients=0A =0A =0A=0A The I2RS Client pr= ovides access to resource on its behalf and this=0A access should= only be granted for trusted applications, =0A or Applications wi= th an similar level of trust. On the=0A other hand, this does no= t prevent an I2RS Client from hosting a=0A large number of Applic= ations. Similarly, an Application may=0A also require access to = multiple I2RS Clients depending on the=0A resource to be accessed= =2E Since I2RS Clients are restricted to a subset of Applications:=0A = =0A Each Application SHOULD be associated to a restricted number=0A = of I2RS Clients.=0A Applications SHOULD be provided the= means and methods to contact=0A their associated I2RS Client. I= f an I2RS Client belongs to=0A the Application (as a module or a = library for example), or=0A when the Application runs in a dedica= ted system (like a=0A container) with a I2RS Client, it is obviou= s which I2RS=0A Client the Application is associated to. On the = other hand,=0A Applications may also remotely access an I2RS Clie= nt. In=0A this case, the Application is expected to be provided = some=0A means to be able to retrieve the necessary information to= =0A contact its associated I2RS Client. The IP address may not= =0A be appropriated in case renumbering occurs within the network= =0A or in case the traffic from Applications should be shared=0A = between multiple instances of a given I2RS Client. In this=0A = case a FQDN may be preferred.=0A =0A =0A= =0A
=0A=0A=0A =0A=0A=0A=0A
= =0A
=0A =0A A key aspect of the I2RS architectur= e is the network oriented application. These application are controlled by = independent and various tenants. In addition to independent logic, these ap= plications may be malicious. These applications also introduce programmabil= ity which results in fast network settings.=0A =0AThe I2RS architect= ure should remain robust for these applications and make sure an applicatio= n does not impact the other applications. This section discusses both secur= ity aspects related to programmability as well as application isolation in = the I2RS architecture.=0A=0A
=0A I2RS provides a programmatic interface into and out of the= Internet routing system. This feature, in addition to the global network v= iew provided by the centralized architecture, comes with a few advantages i= n terms of security.=0A=0A The use of automation reduces configurati= on errors. In addition, this interface enables fast network reconfiguration= =2E Agility provides a key advantage in term of deployment as side effect c= onfiguration may be easily addressed. Finally, it also provides facilities = to monitor and mitigate an attack when the network is under attack.=0A= =0A On the other hand, programmability also comes with a few drawbacks: = Applications can belong to multiple tenants with different objectives. This= absence of coordination may result in unstable routing configurations such= as oscillations between network configurations, and creation of loops. A t= ypical example would be an application monitoring and changing some state. = If another application performs the reverse operation, the routing system m= ay become unstable. Data and application isolation is expected to prevent s= uch situations from happening. However, to guarantee network stability, con= stant monitoring and error detection are recommended.=0A =0A I2RS Agents should constantly m= onitor the parts of the system that I2RS Clients or Applications have provi= ded requests. It should also be able to detect I2RS Clients or Applications= that make the routing system unstable. Minimally, monitoring consists of l= ogging events and eventually providing notifications or alerts to the manag= ement plane when something has been detected. The management plane is in ch= arge of collecting the logs, the notifications, and eventually the consider= ation of appropriate actions. For example, a typical action may be the upda= te of I2RS Access Control policies or re-configuring routing elements.= =0A =0A =0A=0A
=0A=0A
=0A
=0A Requirements for robustnes= s to DoS Attacks have been addressed in the Communication channel section <= xref target=3D"I-D.ietf-i2rs-architecture"/>.=0A=0A The I2RS interf= ace is used by applications to interact with the routing states. Since the = I2RS Agent is shared between multiple applications, one application can pre= vent an application from performing DoS or DDoS attacks on the I2RS Agent o= r on the network.=0ADoS attacks targeting the I2RS Agent would consist of p= roviding requests that keep the I2RS Agent busy for a long time. This may i= nvolve heavy computation by the I2RS Agent, for example, to blocking operat= ions like disk access. In addition, DoS attacks targeting the network may u= se specific commands like monitoring stream over the network. Then, DoS att= ack may be also targeting the application directly by performing reflection= attacks. Such an attack could be performed by indicating the target applic= ation as the target for some information like the listing of the RIB. Refle= ction may be performed at various levels and can be based on the use of UDP= or at the service level like redirection of information to a specific repo= sitory.=0A =0A <= t>In order to prevent DoS, it is recommended the I2RS Agent controls the re= sources allocated to each I2RS Client. I2RS Clients that act as brokers may= not be protected as efficiently against these attacks unless they perform = resource controls themselves of their hosted applications. =0A An I2RS Agent does not make response redirection possible unless the redir= ection is previously validated and agreed by the destination. =0A=0A = Avoid the use of underlying protocols that are not robust to reflect= ion attacks. =0A =0A =0A
=0A
=0A=0A Requirements for Application Control = have been addressed in the I2RS Plane isolation as well as in the trusted C= ommunication Channel sections.=0A=0A Applications use the I2RS inte= rface in order to update the routing system. These updates may be driven by= behavior on the forwarding plane or any external behaviors. In this case, = correlating observation to the I2RS traffic may enable to derive the applic= ation logic. Once the application logic has been derived, a malicious appli= cation may generate traffic or any event in the network in order to activat= e the alternate application.=0A =0A =0A Application logic should remain opaque to = external listeners. Application logic may be partly hidden by encrypting th= e communication between the I2RS Client and the I2RS Agent. Additional ways= to obfuscate the communications may involve sending random messages of var= ious sizes. Such strategies have to be balanced with network load. Note tha= t I2RS Client broker are more likely to hide the application logic compared= to I2RS Client associated to a single application.=0A =0A = =0A=0A =0A
=0A=0A
=0A=0A
=0A=0A =
=0A The whole docum= ent is about security. =0A =0A
=0A=0A =0A=0A
=0A =0A =0A =0A=0A =0A
=0A =0A =0A=0A =0A
=0A A number o= f people provided a significant amount of helping comments and reviews. Amo= ng them the authors would like to thank Russ White, Russ Housley, Thomas Na= deau, Juergen Schoenwaelder, Jeffrey Haas, Alia Atlas, Linda Dunbar.=0A = =0A
=0A=0A =0A =0A =0A &rfc2119; =0A =0A =0A &I= -D.ietf-i2rs-architecture; =0A &I-D.ietf-i2rs-protocol-security-req= uirements; =0A =0A =0A=0A --CdrF4e02JqNVZeln-- From nobody Tue May 17 17:12:34 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED1212D15D for ; Tue, 17 May 2016 17:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLS0x14k7QH8 for ; Tue, 17 May 2016 17:12:32 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE6112D544 for ; Tue, 17 May 2016 17:12:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D2AAD266A0D; Tue, 17 May 2016 17:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463530352; bh=t56wV60sEIWqtp4GRLBzdT3/1I3H3OpV4g6LoYwK0ho=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=R+NGBNx4Ol+P+rpHRJJN8SSe6nFVl88P6NXG11QT1dmjKXEQbBh1HqH0sUYCGhsZE VUIB+n1khG7WMbXF2WbiylH9e48Kmv4yYV3iUgAPF9JmAEvUi4b2udEi6tnS732gKa +qB5o3zBH7fW1nPBjb6VOUXvq3gMQxyaMr8u/lZg= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 53F9F240783; Tue, 17 May 2016 17:12:30 -0700 (PDT) To: Jeffrey Haas References: <20160404200101.15723.87315.idtracker@ietfa.amsl.com> <20160517234632.GG17462@pfrc.org> <4540adf1-5087-853c-b043-b3eb37614ebc@joelhalpern.com> <20160518001535.GH17462@pfrc.org> From: "Joel M. Halpern" Message-ID: Date: Tue, 17 May 2016 20:12:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160518001535.GH17462@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-security-environment-reqs-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 00:12:34 -0000 Thanks Jeff. If others can live with it, I can live with the simplified phrasing you propose for the definition. Yours, Joel On 5/17/16 8:15 PM, Jeffrey Haas wrote: > Joel, > > On Tue, May 17, 2016 at 07:55:55PM -0400, Joel M. Halpern wrote: >> On the editorial matters, the edit to the definition of I2RS Plane >> seems somewhat off. I understand why you did not like referring to >> it as the environment for the "process", particularly since there >> are multiple "processes" involved. But one does not run an >> "architecture" in an environment either. How about defining it as >> "The environment the I2RS components" are running on."? Or maybe >> "The connected set of I2RS components" since the I2RS Plane is >> really that communication, not the underlay. > > I must admit to not having the best set of suggested wording here. The main > thing that seemed wrong was the use of processes in the context of UNIX and > there's no guarantee that such an ecosystem is used to instantiate I2RS. > > One suggestion may be to simply scrub the "flavor of UNIX" from the text and > simply continue to use "processes", perhaps being a bit more careful to > define what that means in context. > >> It is a bit awkward for either the authors or the WG to review the >> other notes, as apparently they are in the git but not in the diff >> (since they are only in the XML.) > > Fair point. I am attaching the .xml. I am also attaching a form of the > rfcdiff wherein the XXX comments have been exposed. I am not pushing that > altered .xml in order to let you authors have a clean bit of xml to use for > your edits. > > (Note that I encourage the authors to work from the git repository. It > makes further rounds of edits easier.) > > -- Jeff > From nobody Wed May 18 01:49:00 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0BC12D093 for ; Wed, 18 May 2016 01:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1By-p7ip9m9 for ; Wed, 18 May 2016 01:48:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5AB912B00D for ; Wed, 18 May 2016 01:48:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COX72534; Wed, 18 May 2016 08:48:52 +0000 (GMT) Received: from SZXEMA419-HUB.china.huawei.com (10.82.72.37) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 18 May 2016 09:48:17 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.199]) by SZXEMA419-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0235.001; Wed, 18 May 2016 16:48:10 +0800 From: "Zhangxian (Xian)" To: "draft-ietf-i2rs-rib-info-model@tools.ietf.org" , "i2rs@ietf.org" Thread-Topic: Routing directorate QA review of draft-ietf-i2rs-rib-info-model Thread-Index: AdGwXE/cjuqe7xG3Q8G/QzkJ5sJXpQAhS7NQ Date: Wed, 18 May 2016 08:48:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEC8055SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.573C2C76.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.199, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 62b44ed8a692567cd3ab0bec1cc11a5f Archived-At: Cc: Ravi Singh Subject: [i2rs] FW: Routing directorate QA review of draft-ietf-i2rs-rib-info-model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 08:48:58 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEC8055SZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SW5jbHVkaW5nIHRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQgYW5kIHRoZSBXRyBsaXN0Lg0KDQpU aGFuayBSYXZpIGZvciB0aGUgcmV2aWV3IGVmZm9ydHMuDQoNCkNoZWVycywNClhpYW4NCg0KRnJv bTogUmF2aSBTaW5naCBbbWFpbHRvOnJhdmlzQGp1bmlwZXIubmV0XQ0KU2VudDogMjAxNsTqNdTC MTjI1SAwOjU1DQpUbzogcnRnLWRpckBpZXRmLm9yZw0KQ2M6ICdKb25hdGhhbiBIYXJkd2ljayc7 ICdKb24gSHVkc29uJzsgU3VzYW4gSGFyZXM7IFpoYW5neGlhbiAoWGlhbikNClN1YmplY3Q6IFJF OiBSb3V0aW5nIGRpcmVjdG9yYXRlIFFBIHJldmlldyBvZiBkcmFmdC1pZXRmLWkycnMtcmliLWlu Zm8tbW9kZWwNCg0KDQpIaQ0KDQpJIGhhZCBiZWVuIGRlc2lnbmF0ZWQgdGhlIFJURy1ESVIgUUEt cmV2aWV3ZXIgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWkycnMt cmliLWluZm8tbW9kZWwtMDgNCg0KDQoNCkkgcmV2aWV3ZWQgdGhpcyBkb2MuDQoNCk92ZXJhbGws IHRoZSBkb2MgaXMgY2xlYXIgYW5kIGRvZXMgYSBkZWNlbnQgam9iIG9mIGNyZWF0aW5nIGEgUklC IG1vZGVsLg0KDQpIb3dldmVyLCBJIGhhdmUgYSBtaW5vciBjb25jZXJuIHdpdGggdGhlIHRvbmUg b2YgdGhlIGRvYyBhdCBjZXJ0YWluIHBsYWNlcy4NCg0KVGhlIGRvY3VtZW50LCBhdCBwbGFjZXMs IHJlYWRzIGxpa2UgYSByZXF1aXJlbWVudHMgZG9jIHNwZWNpZnlpbmcgd2hhdCBhbiBpbXBsZW1l bnRhdGlvbiBvZiB0aGUgUklCICJTSE9VTEQiL01VU1QgZG8uDQoNCkkgYW0gbm90IHN1cmUgaWYg dGhhdCBpcyBjb3JyZWN0IGZvcm0gZm9yIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgZG9jdW1lbnRp bmcgYSBzcGVjaWZpYyBSSUIgbW9kZWwuDQoNCkV4YW1wbGVzIG9mIHN1Y2ggaW5zdGFuY2VzIHdv dWxkIGJlOg0KQS4gICAgICBTZWN0aW9uIDgNCkIuICAgICAgU2VjdGlvbiA5DQpDLiAgICAgIFdo ZXJldmVyIGluIHRoZSBkb2MgYSAiU0hPVUxEIiBvciAiTVVTVCIgc2hvd3MgdXAgc3RhdGluZyBk ZXNpcmFiaWxpdHkgb2YgY2VydGFpbiBiZWhhdmlvciBvZiBhbiBleHRlcm5hbCBlbnRpdHkgYWNj ZXNzaW5nIHRoZSBSSUIuDQoNCg0KDQpBbiBhc3BlY3QgdGhhdCBoYXMgbm90IGJlZW4gdG91Y2hl ZC11cG9uIGluIHRoZSBkb2N1bWVudCwgdGhhdCBob3dldmVyIG1pZ2h0IGJlIHdvcnRoeSBvZiBj b25zaWRlcmF0aW9uIGlzIGFib3V0IGhvdyB0aGlzIFJJQiBtb2RlbCBhY2NvbW1vZGF0ZXMgYW4g ZXh0ZXJuYWwgaW5wdXQgYWJvdXQgdHJhZmZpYy1zdGF0aXN0aWNzLW1vbml0b3JpbmcgZGVzaXJl ZCBmb3IgdGhlIHZhcmlvdXMgY29uc3RydWN0cy4NCg0KDQoNClNwZWNpZmljIGNvbW1lbnRzIG9u IHRoZSB2YXJpb3VzIHNlY3Rpb25zIGluIHRoZSB0ZXh0Og0KMS4gICAgICAgSW50cm9kdWN0aW9u Og0KYS4gICAgICAgRmlyc3QgMiBwYXJhczogc29tZSB0eXBvcyBhbmQgc2VudGVuY2VzIHdpdGgg cmVkdW5kYW50IHdvcmRzLg0KDQoyLiAgICAgICAyLjE6DQphLiAgICAgICAidHlwZSIgaXMgc29t ZXdoYXQgYW1iaWd1b3VzLiBTdWdnZXN0IHJld29yZCAidHlwZSIgYXMgImFkZHJlc3MtZmFtaWx5 Ig0KDQozLiAgICAgICAyLjI6DQphLiAgICAgICBTb21lIHNlbnRlbmNlcyBjb3VsZCBiZSBtYWRl IHNob3J0ZXIvYnJva2VuLXVwIHRvIGltcHJvdmUgcmVhZGFiaWxpdHkgb2YgdGhpcyBzZWN0aW9u Lg0KYi4gICAgICBJbnRlcmZhY2VfbGlzdCBhbmQgcm91dGVyLWlkOiBGb3IgYSBmdW5jdGlvbmlu ZyByb3V0aW5nLWluc3RhbmNlLCBjYW4ndCB0aGluayBvZiBhIHJvdXRpbmctaW5zdGFuY2Ugd2l0 aG91dCBlaXRoZXIgb2YgdGhvc2UgZGVmaW5lZC4gU28sIGVpdGhlciB0aGUgb3B0aW9uYWxpdHkg YXNwZWN0IG5lZWRzIHRvIGJlIGNoYW5nZWQgdG8gInJlcXVpcmVkIiBvciBzcGVjaWZ5IGhvdyBh IHJvdXRpbmctaW5zdGFuY2Ugd291bGQgd29yayB3aXRoIGVpdGhlciBtaXNzaW5nLg0KYy4gICAg ICAgSW50ZXJmYWNlLWxpc3Q6IHBlci1pbnRlcmZhY2UgcGFyYW1ldGVycyBjb3VsZCBhbHNvIGJl IGxpc3RlZCAoc2luY2UgdGhlIGludGVyZmFjZS1saXN0IGlzIGNhbGxlZCBvdXQgaW4gYSBSSUIg bW9kZWwpOiBhZGRyZXNzLCBmYW1pbGllcywgTVRVLCBleHRlbnNpYmlsaXR5LWNvbnNpZGVyYXRp b24tZm9yLW90aGVyLWludGVyZmFjZS1hdHRyaWJ1dGVzDQoNCjQuICAgICAgIDIuMzoNCmEuICAg ICAgIFJPVVRFX1BSRUZFUkVOQ0U6IFRoZSB0ZXh0IGlzIG1peGluZy11cCByb3V0ZS1wcmVmZXJl bmNlIHdpdGggInJvdXRlLW1ldHJpYyIuIEFkbWluaXN0cmF0aXZlLWRpc3RhbmNlICh0aGUgcm91 dGUgbWV0cmljKSBpcyB0aGUgSUdQIGNvc3Qgb2YgYSByb3V0ZS4NCg0KQm90aCByb3V0ZV9wcmVm ZXJlbmNlIGFuZCByb3V0ZS1tZXRyaWMgd291bGQgYmUgYXR0cmlidXRlcyBvZiB0aGUgcm91dGUu DQpiLiAgICAgIEFuIGFkZGl0aW9uYWwgYXR0cmlidXRlIHRoYXQgc2hvdWxkIGJlIGluY2x1ZGVk IGlzICJpbnN0YWxsaW5nIHByb3RvY29sIi4gVGhhdCB3b3VsZCByZXF1aXJlIGRlZmluaW5nIGEg bGlzdCBvZiBwcm90b2NvbHMgdGhhdCBtYXkgaW5zdGFsbCBhIHJvdXRlLg0KDQo1LiAgICAgICAy LjQ6DQphLiAgICAgICBTZWNvbmQgcGFyYWdyYXBoIGNvdWxkIHVzZSByZXdvcmRpbmcgdG8gZW5o YW5jZSBjbGFyaXR5LiBTcGVjaWZpY2FsbHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpLiAgICAgICAgICAgIE5lZWQgdG8gbWVudGlvbiBhYm91dCAiKGFwcGVhcmlu ZyB0byBiZSkgZGlyZWN0bHkgY29ubmVjdGVkIElQIiB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuOg0K MS4gICAgICAgTmV4dGhvcHMgdGhhdCBkb24ndCBuZWVkIHRvIGJlIHJlc29sdmVkIChieSBvdGhl ciBSSUIgZXZlbnRzKSB0byBiZSBpbnN0YWxsYWJsZQ0KMi4gICAgICAgTmV4dGhvcHMgdGhhdCBu ZWVkIHRvIGJlIHJlc29sdmVkIChieSBvdGhlciBSSUIgZXZlbnRzL3Byb3BlcnRpZXMpIHRvIGJl IGluc3RhbGxhYmxlOg0KYS4gICAgICAgVGhvc2UgdGhhdCBhcmUgY3VycmVudGx5IHJlc29sdmVk DQpiLiAgICAgIFRob3NlIHRoYXQgYXJlIGN1cnJlbnRseSBub3QtcmVzb2x2ZWQNCmIuICAgICAg TmV4dC1ob3AgcHJvcGVydHkgc2hvdWxkIGFsc28gaW5jbHVkZSBJUCBvZiAoYXBwZWFyaW5nIHRv IGJlKSBsb2NhbGx5LWNvbm5lY3RlZCBkZXZpY2UgZm9yIHdoaWNoIHRvIEFSUA0KDQo2LiAgICAg ICAyLjQuMToNCmEuICAgICAgIExhc3QgcGFyYWdyYXBoOiAicHJlY2VkZWQgYnkiIHdvdWxkIGJl IG1vcmUgYWNjdXJhdGUgdGhhbiAiZm9sbG93ZWQgYnkiDQoNCjcuICAgICAgIDIuNC4zOg0KYS4g ICAgICAgVW5kZXIgInR1bm5lbCBlbmNhcCI6IFRoZSBmb2xsb3dpbmcgdGV4dA0KDQoiDQoNCkFu IG9wdGlvbmFsDQoNCiAgICAgIGVncmVzcyBpbnRlcmZhY2UgY2FuIGJlIGNoYWluZWQgdG8gdGhl IHR1bm5lbCBlbmNhcCB0byBpbmRpY2F0ZQ0KDQogICAgICB3aGljaCBpbnRlcmZhY2UgdG8gc2Vu ZCB0aGUgcGFja2V0IG91dCBvbi4gIFRoZSBlZ3Jlc3MgaW50ZXJmYWNlDQoNCiAgICAgIGlzIHVz ZWZ1bCB3aGVuIHRoZSBuZXR3b3JrIGRldmljZSBjb250YWlucyBFdGhlcm5ldCBpbnRlcmZhY2Vz IGFuZA0KDQogICAgICBvbmUgbmVlZHMgdG8gcGVyZm9ybSBhZGRyZXNzIHJlc29sdXRpb24gZm9y IHRoZSBJUCBwYWNrZXQuIg0KDQphcHBlYXJzIGEgYml0IGluY29ycmVjdC4NCg0KSWYgb25lIHdp c2hlcyB0byBkbyByZXNvbHV0aW9uIGZvciB0aGUgdHVubmVsLXJlbW90ZS1kc3QgdGhlbiBzcGVj aWZ5aW5nIGFuIGludGVyZmFjZSBzZXJ2ZXMgbm8gcHVycG9zZS4gRWl0aGVyIHRoYXQgYWRkcmVz cyBkb2VzIG5vdCBuZWVkIHJlc29sdXRpb24gYW5kIHRoaXMgc3BlY2lmaWVkIGludGVyZmFjZSBp cyBhIHAycCBpbnRlcmZhY2Ugb3IgdGhlcmUgaXMgYSBuZWVkIGZvciByZXNvbHV0aW9uICh3aXRo b3V0IG5lZWRpbmcgdG8gc3BlY2lmeSBhbiBpbnRlcmZhY2UtbmFtZSkuIENhbid0IGJlIGJvdGgu DQoNCg0KOC4gICAgICAgU2VjdGlvbnMgNCAmIDUgY2FuIGJlIG1lcmdlZC4gV2hhdCBpcyB0aGUg cG9pbnQgb2YgaGF2aW5nIGEgc2VwYXJhdGUgc2VjdGlvbiA1IHdoZW4gaXQgaXMgbm90IHJlYWxs eSBzYXlpbmcgYW55dGhpbmcgbmV3IGJleW9uZCB3aGF0IHRleHQgZXhpc3RzIGluIHNlY3Rpb24g NC4NCg0KDQo5LiAgICAgICBTZWN0aW9uIDY6DQphLiAgICAgICBOb3QgcmVwZWF0aW5nIHJlbWFy a3MgbWFkZSBhYm91dCBzcGVjaWZpYyBhdHRyaWJ1dGVzIChsaXN0ZWQgYWJvdmUpIGZvciBlYWNo IGl0ZW0gaW4gdGhlIEJORi4gRWcuIFJvdXRlLW1ldHJpYy9wcmVmZXJlbmNlIHJlbGF0ZWQgcmVt YXJrIG1hZGUgYWJvdmUgYWJvdXQgMi4zLg0KDQoNCmIuICAgICAgSW4tbGFiZWwgaXMgbm90IGxv Z2ljYWxseSBhIG5leHRob3AgYXR0cmlidXRlLiBJdCBpcyBpbmZhY3QgYSByb3V0ZS4gVGhpcyBz aG91bGQgYmUgZml4ZWQuDQoNCiAgPG1wbHMtbGFiZWwtb3BlcmF0aW9uPiA6Oj0gKDxNUExTX1BV U0g+IDxNUExTX0xBQkVMPiBbPFNfQklUPl0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgWzxUT1NfVkFMVUU+XSBbPFRUTF9WQUxVRT5dKSB8DQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKDxNUExTX1NXQVA+IDxJTl9MQUJFTD4gPE9VVF9MQUJFTD4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbPFRUTF9BQ1RJT04+ XSkNCmMuICAgICAgIFZYTEFOIGhlYWRlcnMgbmVlZHMgdG8gaGF2ZSBhIHdheSB0byBzcGVjaWZ5 IHNyYy9kc3QgTUFDIGluIGlubmVyIGhlYWRlciwgc2luY2UgaXQgaXMgcG9zc2libGUgdG8gdXNl IFZYTEFOIGFzIGEgZ2VuZXJhbC1wdXJwb3NlIGVuY2Fwc3VsYXRpb24gd2l0aG91dCBMMi1sZWFy bmluZyBzZW1hbnRpY3MuDQoNCg0KMTAuICAgU2VjdGlvbiA2IGRlc2NyaWJlcyB0aGUgUklCIGdy YW1tYXIuIFRoZSBuZXh0aG9wIGdyYW1tYXIgaXMgYSBwYXJ0IG9mIHRoYXQuIEhvd2V2ZXIsIHNv bWUgb2YgdGhhdCBzdWItZ3JhbW1hciBhcHBlYXJzIHVuZGVyIHNlY3Rpb24gNy4NCg0KDQoxMS4g ICBTZWN0aW9uIDcgIlVzaW5nIHRoZSBSSUIgZ3JhbW1hciIgc3RhcnRzIG91dCBieSBleHBsYWlu aW5nIGhvdyB0aGUgY29tcGxleCBuZXh0aG9wcyBtYXliZSB1c2VkLiBIb3dldmVyLCBpdCBlbmRz IHVwIGJlaW5nIGEgbGlzdGluZyBvZiB0aGUgbmV4dGhvcCBzdWItZ3JhbW1hciB3aGljaCBzaG91 bGQgcmVhbGx5IGhhdmUgYmVlbiBsaXN0ZWQgaW4gc2VjdGlvbiA2IGFsb25nIHdpdGggdGhlIFJJ QiBncmFtbWFyLg0KDQpJJ2Qgc3VnZ2VzdCBlaXRoZXIgdGFrZSB0aGUgZW50aXJldHkgb2YgdGhl IG5leHQtaG9wIGdyYW1tYXIgbGlzdGluZyB0byB0aGUgc2VjdGlvbiA2LCBvciBicmVhayBzZWN0 aW9uIDcgc28gdGhhdCB0aGUgbmV4dC1ob3AgZ3JhbW1hciBpcyBsaXN0ZWQgaW4gc2VjdGlvbiA3 ICYgdGhlICJ1c2luZyB0aGUgcmliIiBncmFtbWFyIGlzIGEgcHVyZWx5IHRleHQgb25seSBkZXNj cmlwdGlvbiBvZiBSaWIvTkggZ3JhbW1hciBtYXliZSB1c2VkLg0KDQoNCjEyLiAgIFN5bnRheCBm b3IgPG5leHRob3AtcmVwbGljYXRlPiAgbmVlZHMgdG8gYmUgcmVjb25jaWxlZCBiZXdlZW4gc2Vj dGlvbiA3LjIuMyBhbmQgc2VjdGlvbiA2IHdoZXJlDQoNCnRoZXJlIGlzIGFuIHN5bnRheCBtaXNt YXRjaCwNCg0KRG9lc26hr3Qgc2VjdGlvbiA2IG5lZWQgdG8gc2F5Og0KDQo8bmV4dGhvcC1yZXBs aWNhdGU+IDo6PSA8TkVYVEhPUF9SRVBMSUNBVEU+IDxuZXh0aG9wPiA8bmV4dGhvcD4gLi4uDQoN Cg0KDQpSZWdhcmRzDQoNClJhdmkNCg0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEC8055SZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Including the authors of this draft and the WG list.

 

Thank Ravi for the review efforts.

 

Cheers,

Xian

 

From: Ravi Singh [mailto:ravis@juniper.net]
Sent: 2016=C4=EA5=D4=C218= =C8=D5 0:55
To: rtg-dir@ietf.org
Cc: 'Jonathan Hardwick'; 'Jon Hudson'; Susan Hares; Zhangxian (Xian)=
Subject: RE: Routing directorate QA review of draft-ietf-i2rs-rib-in= fo-model

 

Hi

I had been designated the RTG-DIR QA-reviewer for h= ttps://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-08=

 

I reviewed this doc.

Overall, the doc is clear and does a decent job of creating a RI= B model.

However, I have a minor concern with the tone of the doc at cert= ain places.

The document, at places, reads like a requirements doc specifyin= g what an implementation of the RIB "SHOULD"/MUST do.

I am not sure if that is correct form for an informational draft= documenting a specific RIB model.

Examples of such instances would be:

A.      Section 8

B.      Section 9

C.      Wherever in the doc a &qu= ot;SHOULD" or "MUST" shows up stating desirability of certai= n behavior of an external entity accessing the RIB.

 

An aspect that has not been touched-upon in the document, that h= owever might be worthy of consideration is about how this RIB model accommodates an external input about traffic-statistics-monitori= ng desired for the various constructs.

 

Specific comments on the various sections in the text:

1.       Introduction:<= /span>

a.       First 2 paras: some typos= and sentences with redundant words.

<= span lang=3D"EN-US" style=3D"color:black"> 

2.       2.1:

a.       "type" is somew= hat ambiguous. Suggest reword "type" as "address-family"= ;

<= span lang=3D"EN-US" style=3D"color:black"> 

3.       2.2:

a.       Some sentences could be m= ade shorter/broken-up to improve readability of this section.

b.      Interface_list and router= -id: For a functioning routing-instance, can't think of a routing-instance = without either of those defined. So, either the optionality aspect needs to= be changed to "required" or specify how a routing-instance would work with either missing.

c.       Interface-list: per-inter= face parameters could also be listed (since the interface-list is called ou= t in a RIB model): address, families, MTU, extensibility-consideration-for-= other-interface-attributes

<= span lang=3D"EN-US" style=3D"color:black"> 

4.       2.3:

a.       ROUTE_PREFERENCE: The tex= t is mixing-up route-preference with "route-metric". Administrati= ve-distance (the route metric) is the IGP cost of a route.

Both route_preference and route-met= ric would be attributes of the route.

b.      An additional attribute t= hat should be included is "installing protocol". That would requi= re defining a list of protocols that may install a route.=

<= span lang=3D"EN-US" style=3D"color:black"> 

5.       2.4:

a.       Second paragraph could us= e rewording to enhance clarity. Specifically:

     &nb= sp;            =             &nb= sp;        i.        &= nbsp;   Need to mention about &qu= ot;(appearing to be) directly connected IP" to distinguish between:

1.       Nexthops that don't need = to be resolved (by other RIB events) to be installable

2.       Nexthops that need to be = resolved (by other RIB events/properties) to be installable:

a.       Those that are currently = resolved

b.      Those that are currently = not-resolved

b.      Next-hop property should = also include IP of (appearing to be) locally-connected device for which to = ARP

<= span lang=3D"EN-US" style=3D"color:black"> 

6.       2.4.1:<= /p>

a.       Last paragraph: "pre= ceded by" would be more accurate than "followed by"

<= span lang=3D"EN-US" style=3D"color:black"> 

7.       2.4.3:<= /p>

a.       Under "tunnel encap&= quot;: The following text

"

An optional

      egre= ss interface can be chained to the tunnel encap to indicate

      whic= h interface to send the packet out on.  The egress interface

      is u= seful when the network device contains Ethernet interfaces and

      one = needs to perform address resolution for the IP packet."

appears a bit incorrect.=

If one wishes to do resolution for = the tunnel-remote-dst then specifying an interface serves no purpose. Eithe= r that address does not need resolution and this specified interface is a p2p interface or there is a need for resolution (without ne= eding to specify an interface-name). Can't be both.

 

8.       Sections 4 & 5 can be= merged. What is the point of having a separate section 5 when it is not re= ally saying anything new beyond what text exists in section 4.

 

9.       Section 6:

a.       Not repeating remarks mad= e about specific attributes (listed above) for each item in the BNF. Eg. Ro= ute-metric/preference related remark made above about 2.3.

 

b.      In-label is not logically= a nexthop attribute. It is infact a route. This should be fixed.

  <mpls-label-operation>= ::=3D (<MPLS_PUSH> <MPLS_LABEL> [<S_BIT>]

      = ;            &n= bsp;            = ;           [<TOS_VALU= E>] [<TTL_VALUE>]) |

      = ;            &n= bsp;          (<MPLS_SWAP&g= t; <IN_LABEL> <OUT_LABEL>

      = ;             &= nbsp;           &nbs= p;         [<TTL_ACTION>= ])

c.       VXLAN headers needs to ha= ve a way to specify src/dst MAC in inner header, since it is possible to us= e VXLAN as a general-purpose encapsulation without L2-learning semantics.

 

10.   Section 6 describes the R= IB grammar. The nexthop grammar is a part of that. However, some of that su= b-grammar appears under section 7.

 

11.   Section 7 "Using the= RIB grammar" starts out by explaining how the complex nexthops maybe = used. However, it ends up being a listing of the nexthop sub-grammar which = should really have been listed in section 6 along with the RIB grammar.

I'd suggest either take the entiret= y of the next-hop grammar listing to the section 6, or break section 7 so t= hat the next-hop grammar is listed in section 7 & the "using the rib" grammar is a purely text only description of Rib/NH grammar = maybe used.

 

12.   Syntax for <nexthop-re= plicate>  needs to be reconciled beween section 7.2.3 and section 6= where

there is an syntax mismatch,

Doesn=A1=AFt section 6 need to say:

<nexthop-replicate> ::=3D <= ;NEXTHOP_REPLICATE> <nexthop> <nexthop> ...

 

Regards

Ravi

 

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEC8055SZXEMA512MBSchi_-- From nobody Wed May 18 01:51:05 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963C312D0F6 for ; Wed, 18 May 2016 01:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nksi1lSdo7T for ; Wed, 18 May 2016 01:51:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7571F12D09C for ; Wed, 18 May 2016 01:51:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COX73138; Wed, 18 May 2016 08:50:59 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 18 May 2016 09:50:58 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.199]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Wed, 18 May 2016 16:50:54 +0800 From: "Zhangxian (Xian)" To: "draft-ietf-i2rs-yang-l2-network-topology@tools.ietf.org" , "i2rs@ietf.org" Thread-Topic: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l2-network-topology Thread-Index: AQHRsAq9RFmKWcS270KqpnV/dHGMVp++Y+cw Date: Wed, 18 May 2016 08:50:54 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.573C2CF4.0001, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.199, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 38940ae29d323ac3b1cf80f9e57c5c93 Archived-At: Cc: Henning Rogge , Susan Hares Subject: [i2rs] FW: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l2-network-topology X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 08:51:03 -0000 VG8gZ2V0IHRoZSBhdHRlbnRpb24gb2YgZHJhZnQgYXV0aG9ycyBhbmQgdGhlIFdHIHRvIHRoZSBm b2xsb3dpbmcgcmV2aWV3L2NvbW1lbnRzLiANCg0KVGhhbmsgSGVubmluZyBmb3IgdGhlIGNvbnN0 cnVjdGl2ZSBjb21tZW50cy4gDQoNCkNoZWVycywNClhpYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHJ0Zy1kaXIgW21haWx0bzpydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBIZW5uaW5nIFJvZ2dlDQpTZW50OiAyMDE25bm0NeaciDE35pelIDE1OjA3 DQpUbzogWmhhbmd4aWFuIChYaWFuKTsgam9uYXRoYW4uaGFyZHdpY2tAbWV0YXN3aXRjaC5jb207 IGpvbi5odWRzb25AZ21haWwuY29tOyBzaGFyZXNAbmR6aC5jb20gPj4gU3VzYW4gSGFyZXMNCkNj OiBydGctZGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1JURy1ESVJdIFJvdXRpbmcgZGlyZWN0 b3JhdGUgUUEgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5ldHdvcmstdG9wb2xv Z3kNCg0KSGksDQoNCkkgaGF2ZSBiZWVuIGFza2VkIHRvIHByb3ZpZGUgYSByZXZpZXcgdG8gdGhl IGZvbGxvd2luZyBkb2N1bWVudCB0byB0aGUgDQpyb3V0aW5nIGRpcmVjdG9yYXRlIG1haWxpbmcg bGlzdC4NCg0KUGxlYXNlIGJlIGF3YXJlIHRoYXQgdGhpcyBpcyB0aGUgZmlyc3QgdGltZSBJIHdv cmsgd2l0aCBZQU5HIGFuZCByZWxhdGVkIA0KZHJhZnRzLg0KDQoNCkRvY3VtZW50OiBkcmFmdC1p ZXRmLWkycnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAyDQoNClJldmlld2VyOiBIZW5uaW5n IFJvZ2dlDQpSZXZpZXcgRGF0ZTogTWFpIDE2dGgsIDIwMTYNCg0KDQpJbnRlbmRlZCBTdGF0dXM6 IFN0YW5kYXJkcyBUcmFjaw0KDQoNClRoZSBkYXRhIHN0cnVjdHVyZSBzdWdnZXN0ZWQgYnkgdGhl IGRyYWZ0IGlzIHJlYXNvbmFibGUgYW5kIHdvdWxkIGZpdCANCm1vc3QgTGF5ZXIyIG5ldHdvcmsg dGVjaG5vbG9naWVzLiBJIGhhdmUgYSBjb3VwbGUgb2YgcG9pbnRzIG9uIHRoZSBkcmFmdCANCmRv Y3VtZW50IHdoaWNoIG1pZ2h0IGJlIHdvcnRoIGxvb2tpbmcgaW50bzoNCg0KKiBUaGUgaW50cm9k dWN0aW9uIGluIA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaTJycy15 YW5nLWwyLW5ldHdvcmstdG9wb2xvZ3ktMDIgDQppbmNsdWRlcyBhIGxpbmsgdG8gIkktRC5pZXRm LW5ldG1vZC1yZmM2MDIwYmlzIiB0aGF0IGxpbmtzIGJhY2sgdG8gdGhlIA0KZHJhZnQgZG9jdW1l bnQgaXRzZWxmLiBNYXliZSBzb21lIGxpbmtzIGluIHRoZSBkb2N1bWVudCByZWZlciB0byBhbiAN Cm9sZGVyIG5hbWUgb2YgdGhlIGRyYWZ0Pw0KDQoqIHRoZSAidGVybWluYXRpb24tcG9pbnQiIGVs ZW1lbnQgb25seSBjb250YWlucyB0aGUgdHlwZXMgImV0aGVybmV0IiBhbmQgDQoibGVnYWN5IiAo d2hpY2ggZG9lcyBub3QgY29udGFpbiBhbnkgZGF0YSBsaWtlIG1hYy1hZGRyZXNzKS4gSXMgdGhp cyANCnJlYXNvbmFibGUgb3Igc2hvdWxkIGEgZmV3IGRhdGEgZWxlbWVudHMgbW92ZWQgZnJvbSB0 aGUgImV0aGVybmV0IiANCmNhdGVnb3J5IHRvIHRoZSAibDItdGVybWluYXRpb24tcG9pbnQtYXR0 cmlidXRlcyIgY2F0ZWdvcnk/DQoNCiogdGhlcmUgYXJlIGRpZmZlcmVudCB0eXBlcyBvZiBWTEFO IHRhZ3MgYmUgdXNlZC4uLiBzaG91bGQgdGhlcmUgYmUgDQphbm90aGVyIGZpZWxkICgidmxhbi10 eXBlIiA/KSB0byBhbm5vdW5jZSA4MDIuMWFkIFFpblEgdXNhZ2U/IEkgdGhpbmsgDQp0aGUgODAy LjFhZCB0YWcgaXMgYWxzbyBzb21ldGltZXMgYWxzbyB1c2VkIHRvIG1vdmUgVkxBTiBvdmVyIGEg c3dpdGNoIA0KdGhhdCBkb2Vzbid0IHN1cHBvcnQgaXQgKHVua25vd24gRXRoZXJ0eXBlcyBhcmUg dXN1YWxseSBqdXN0IGlnbm9yZWQpLCANCndoaWNoIG1lYW5zIGp1c3Qga25vd2luZyB0aGUgVkxB Ti1pZCBpcyBub3QgZW5vdWdoIHRvIHJlYWNoIHRoZSBlbmRwb2ludC4NCg0KKiB0aGUgdHlwZSBv ZiBldGhlcm5ldCAoMTAwLCAxMDAwLCAxMDAwMCkgb3IgZGF0YS1yYXRlIGNvdWxkIGJlIGFuIA0K aW1wb3J0YW50IGF0dHJpYnV0ZSBmb3IgYW4gZXRoZXJuZXQgdGVybWluYXRpb24gcG9pbnQsIG5v dCBvbmx5IGZvciBsaW5rcy4NCg0KDQpIZW5uaW5nIFJvZ2dlDQotLSANCkRpcGxvbS1JbmZvcm1h dGlrZXIgSGVubmluZyBSb2dnZSAsIEZyYXVuaG9mZXItSW5zdGl0dXQgZsO8cg0KS29tbXVuaWth dGlvbiwgSW5mb3JtYXRpb25zdmVyYXJiZWl0dW5nIHVuZCBFcmdvbm9taWUgRktJRQ0KS29tbXVu aWthdGlvbnNzeXN0ZW1lIChLT00pDQpGcmF1bmhvZmVyIFN0cmHDn2UgMjAsIDUzMzQzIFdhY2h0 YmVyZywgR2VybWFueQ0KVGVsZWZvbiArNDkgMjI4IDk0MzUtOTYxLCAgIEZheCArNDkgMjI4IDk0 MzUgNjg1DQptYWlsdG86aGVubmluZy5yb2dnZUBma2llLmZyYXVuaG9mZXIuZGUgaHR0cDovL3d3 dy5ma2llLmZyYXVuaG9mZXIuZGUNCg0K From nobody Wed May 18 05:36:26 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A3912D0ED; Wed, 18 May 2016 05:36:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518123622.14705.11813.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 05:36:22 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com, menachemdodge1@gmail.com Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-traceability-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 12:36:22 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-traceability-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS points. From nobody Wed May 18 05:43:47 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C25BE12D133; Wed, 18 May 2016 05:43:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518124345.14603.17332.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 05:43:45 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-pub-sub-requirements@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-pub-sub-requirements-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 12:43:46 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-pub-sub-requirements-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENT. From nobody Wed May 18 09:29:04 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D25012D5C1; Wed, 18 May 2016 09:29:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518162903.14603.58138.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 09:29:03 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-traceability-11.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:29:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : Interface to the Routing System (I2RS) Traceability: Framework and Information Model Authors : Joe Clarke Gonzalo Salgueiro Carlos Pignataro Filename : draft-ietf-i2rs-traceability-11.txt Pages : 15 Date : 2016-05-18 Abstract: This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-traceability-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 18 09:31:02 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC3312D1AA for ; Wed, 18 May 2016 09:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.926 X-Spam-Level: X-Spam-Status: No, score=-14.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GqBs7PiNU5Q for ; Wed, 18 May 2016 09:31:00 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9E012D59F for ; Wed, 18 May 2016 09:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2223; q=dns/txt; s=iport; t=1463589060; x=1464798660; h=subject:references:cc:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=CH9WDqVP176srp9zRJJN35M7GnM73Xe8X+E4Djon6qI=; b=GTPGy9N4tScbNiWGUt3KjA83tFkExvcC4AWJ8VTM2mR0/B0iMVc0/36p IbaoS8t5we/E/dJMT0H0ow0zdYBDqngAVx+YdP+2v8zXw2z2VdoFo/UYN MfO9I72qrUtW2+EVMQA3tDAUQJTAJKib8JEctCR8Pk3B2TlZDTNc9PiYU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBBgCVlzxX/5BdJa1egzdWK0cMpj6Je?= =?us-ascii?q?IlBAQ2BdRcLhW8CKIETOBQBAQEBAQEBZSeEOgkBAQQBAQE1NgsQCxIGLiciDhM?= =?us-ascii?q?GAgEBhW6CPQ7DZAEBAQEBAQEDAQEBAQEBIYYlgXaCV4dPgkkBBJgrhgCIIIFpT?= =?us-ascii?q?oQBgwiFWoYxiRgeAQFChAkgMogGAQEF?= X-IronPort-AV: E=Sophos;i="5.26,329,1459814400"; d="scan'208";a="275008533" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2016 16:30:59 +0000 Received: from [10.152.201.113] ([10.152.201.113]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4IGUwWt000882 for ; Wed, 18 May 2016 16:30:59 GMT References: <20160518162903.14603.58138.idtracker@ietfa.amsl.com> Cc: i2rs@ietf.org From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <5a9e610c-cebc-68cf-c5a3-a8e954241602@cisco.com> Date: Wed, 18 May 2016 12:30:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160518162903.14603.58138.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-traceability-11.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:31:01 -0000 This update adds text around allowing optional fields in the trace log beyond what is explicitly enumerated here. This should take care of the rest of the IESG/AD comments. Joe On 5/18/16 12:29, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System of the IETF. > > Title : Interface to the Routing System (I2RS) Traceability: Framework and Information Model > Authors : Joe Clarke > Gonzalo Salgueiro > Carlos Pignataro > Filename : draft-ietf-i2rs-traceability-11.txt > Pages : 15 > Date : 2016-05-18 > > Abstract: > This document describes a framework for traceability in the Interface > to the Routing System (I2RS) and information model for that > framework. It specifies the motivation, requirements, use cases, and > defines an information model for recording interactions between > elements implementing the I2RS protocol. This framework provides a > consistent tracing interface for components implementing the I2RS > architecture to record what was done, by which component, and when. > It aims to improve the management of I2RS implementations, and can be > used for troubleshooting, auditing, forensics, and accounting > purposes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-traceability-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed May 18 15:44:19 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F08512D797; Wed, 18 May 2016 15:44:15 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518224415.14705.2829.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 15:44:15 -0700 Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, draft-ietf-i2rs-pub-sub-requirements@ietf.org, The IESG , shares@ndzh.com, rfc-editor@rfc-editor.org Subject: [i2rs] Document Action: 'Requirements for Subscription to YANG Datastores' to Informational RFC (draft-ietf-i2rs-pub-sub-requirements-09.txt) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 22:44:15 -0000 The IESG has approved the following document: - 'Requirements for Subscription to YANG Datastores' (draft-ietf-i2rs-pub-sub-requirements-09.txt) as Informational RFC This document is the product of the Interface to the Routing System Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ Technical Summary This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e. Netconf and Restconf). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. Working Group Summary Working consensus for requirements was honed over 6 months (May -Nov 2015). WG LC done on individual draft 5/26/2015 to 6/9/2015 WG LC done with All of requirement drafts 10/6/2015 to 10/20/2015 Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Document shepherd: Susan Hares WG Chairs: Susan Hares and Jeff Haas AD: Alia Atlas From nobody Wed May 18 19:10:52 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A30DC12D677; Wed, 18 May 2016 19:10:48 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160519021048.14705.71021.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 19:10:48 -0700 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-traceability@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, The IESG , shares@ndzh.com, rfc-editor@rfc-editor.org Subject: [i2rs] Document Action: 'Interface to the Routing System (I2RS) Traceability: Framework and Information Model' to Informational RFC (draft-ietf-i2rs-traceability-11.txt) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 02:10:49 -0000 The IESG has approved the following document: - 'Interface to the Routing System (I2RS) Traceability: Framework and Information Model' (draft-ietf-i2rs-traceability-11.txt) as Informational RFC This document is the product of the Interface to the Routing System Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ Technical Summary This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. Working Group Summary Working consensus for requirements was honed over 6 months (May -Nov 2015). WG LC done on individual draft 5/26/2015 to 6/9/2015 WG LC done with All of requirement drafts 10/6/2015 to 10/20/2015 Document Quality This draft is comes out of the work with Open Daylight Project and other implementations of early I2RS protocols. A significant number of vendors have indicated their plan to expand existing protocols to create an IRS amalgamate protocol. A list includes the following: Cisco, Juniper, Huawei, Ericsson, Google, Packetdesign (Client software) and others. Reviews of the requirement package did not change the traceability draft. The NETCONF reviewed the traceability document and found no additional requirements for the NETCONF or RESTCONF suite. The security directorate QA review found that traceability did not by itself provide security's level of assurance or tracing. Traceability was targeted for logging information that adds to data assurance or tracing. Personnel Document shepherd: Susan Hares WG Chairs: Susan Hares and Jeff Haas AD: Alia Atlas From nobody Thu May 19 09:39:35 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A6E12DA8C; Thu, 19 May 2016 09:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTIQrl_OLomp; Thu, 19 May 2016 09:39:29 -0700 (PDT) Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id 47B4312DA8E; Thu, 19 May 2016 09:39:25 -0700 (PDT) Received: from c0043i0.coe.ntt.com (c0043i0.nc.agilit-hosting.com [10.18.161.12]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id EDFEF1C5824F; Fri, 20 May 2016 01:39:23 +0900 (JST) Received: from C0568I0.coe.ntt.com (10.18.160.119) by c0043i0.coe.ntt.com (10.18.161.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 20 May 2016 01:39:20 +0900 Received: from C0561I0.coe.ntt.com ([169.254.1.38]) by C0568I0.coe.ntt.com ([10.18.161.254]) with mapi id 14.03.0181.006; Fri, 20 May 2016 01:39:23 +0900 From: Tomonori Takeda To: "rtg-ads@ietf.org" Thread-Topic: RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Thread-Index: AdGx5fCxDq0YNmnWSrK+7ayI8V3BEQ== Date: Thu, 19 May 2016 16:39:22 +0000 Message-ID: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: rtg-ads@ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-i2rs-protocol-security-requirements.all@ietf.org, i2rs@ietf.org x-originating-ip: [10.25.150.237] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 Archived-At: Cc: "'rtg-dir@ietf.org'" , "'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'" , "i2rs@ietf.org" Subject: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:39:33 -0000 Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-i2rs-protocol-security-requirements-04.txt Reviewer: Tomonori Takeda Review Date: May 20, 2016 Intended Status: Standards Track I am not following I2RS work closely, but in the spirit of QA review, this is OK in my understanding. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Here are my comments. I think it is very important to have documents dedicated for security for new protocols such as I2RS protocols. Overall, I think the document is well organized and clear what are security requirements for I2RS. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for requirement drafts to be Standards Track. 2) In Section 3.1, requirements are mentioned that are set in draft-ietf-i2rs-architecture-15. Some of these requirements are not directly mentioned in draft-ietf-i2rs-architecture-15, but rather implied. For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS client, but does not mention identifier for I2RS agent (IMO). Please note that I think requirements mentioned in Section 3.1. makes sense and valid. I am just commenting on the way of writing. 3) I think there is dependency on requirements mentioned in this document. Specifically, if mutual authentication (Section 3.1), secure transport (Section 3.2), and role-based security (Section 3.3) are met, confidentiality (Section 3.3) and integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability requirement). Perhaps, it depends on in which aspects security requirements should be written (in terms of mechanisms or in terms of features). Again, I am just commenting on the way of writing. 4) This is just an edit, but in page.10, "Requirements SEC-REQ-13 and SEC-REQ-14" should be "Requirements SEC-REQ-14 and SEC-REQ-15". Thanks, Tomonori Takeda From nobody Fri May 20 06:21:12 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7779912D953; Fri, 20 May 2016 06:21:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520132110.306.15312.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 06:21:10 -0700 Archived-At: Cc: i2rs@ietf.org, skh@ndzh.com, i2rs-chairs@ietf.org, akatlas@gmail.com Subject: [i2rs] i2rs - New Meeting Session Request for IETF 96 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 13:21:10 -0000 A new meeting session request has just been submitted by Susan Hares, a Chair of the i2rs working group. --------------------------------------------------------- Working Group Name: Interface to the Routing System Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: idr trill i2nsf netconf netmod Second Priority: rtgwg rtgarea opsarea opsawg Special Requests: --------------------------------------------------------- From nobody Fri May 20 06:23:16 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EAB12D95D; Fri, 20 May 2016 06:23:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520132313.340.24060.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 06:23:13 -0700 Archived-At: Cc: i2rs@ietf.org, skh@ndzh.com, i2rs-chairs@ietf.org, akatlas@gmail.com Subject: [i2rs] i2rs - Update to a Meeting Session Request for IETF 96 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 13:23:13 -0000 An update to a meeting session request has just been submitted by Susan Hares, a Chair of the i2rs working group. --------------------------------------------------------- Working Group Name: Interface to the Routing System Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: idr trill i2nsf netconf netmod Second Priority: rtgwg rtgarea opsarea opsawg teas bfcpbis pce nfvrg Third Priority: dots sdnrg Special Requests: --------------------------------------------------------- From nobody Fri May 20 07:04:17 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B6412D98F; Fri, 20 May 2016 07:04:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520140416.32707.45150.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 07:04:16 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-protocol-security-requirements-05.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 14:04:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Security Related Requirements Authors : Susan Hares Daniel Migault Joel Halpern Filename : draft-ietf-i2rs-protocol-security-requirements-05.txt Pages : 14 Date : 2016-05-20 Abstract: This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-protocol-security-requirements-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-protocol-security-requirements-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 20 07:05:43 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09C112D98E; Fri, 20 May 2016 07:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jasng2igxoJG; Fri, 20 May 2016 07:05:37 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 C00EB12D988; Fri, 20 May 2016 07:05:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Tomonori Takeda'" , References: In-Reply-To: Date: Fri, 20 May 2016 10:05:33 -0400 Message-ID: <00c701d1b2a0$ad254f30$076fed90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C8_01D1B27F.2616BC70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFZkbV8xMTMF+FMKLR7WGNqnq+0AaCxLJGA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-i2rs-protocol-security-requirements.all@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 14:05:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C8_01D1B27F.2616BC70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Takeda-san: Thank you for your excellent review. My responses to your comments are below. I've released a version-05 to address your comments. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Tomonori Takeda Sent: Thursday, May 19, 2016 12:39 PM To: rtg-ads@ietf.org Cc: 'rtg-dir@ietf.org'; 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org Subject: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-i2rs-protocol-security-requirements-04.txt Reviewer: Tomonori Takeda Review Date: May 20, 2016 Intended Status: Standards Track I am not following I2RS work closely, but in the spirit of QA review, this is OK in my understanding. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Here are my comments. I think it is very important to have documents dedicated for security for new protocols such as I2RS protocols. Overall, I think the document is well organized and clear what are security requirements for I2RS. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for requirement drafts to be Standards Track. Sue: You are correct. This is my error. I should have changed it this morning. 2) In Section 3.1, requirements are mentioned that are set in draft-ietf-i2rs-architecture-15. Some of these requirements are not directly mentioned in draft-ietf-i2rs-architecture-15, but rather implied. For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS client, but does not mention identifier for I2RS agent (IMO). Please note that I think requirements mentioned in Section 3.1. makes sense and valid. I am just commenting on the way of writing. Sue: You are correct that the mutual identification implies an identity for the agent. Also in Section 2 of draft-ietf-i2rs-architecture-15 mentions: role or security role: A security role specifies the scope, resources, priorities, etc. that a client or agent has. If a identity has multiple roles in the security system, the identity is permitted to perform any operations any of those roles permit. Multiple identities may use the same security role. 3) I think there is dependency on requirements mentioned in this document. Specifically, if mutual authentication (Section 3.1), secure transport (Section 3.2), and role-based security (Section 3.3) are met, confidentiality (Section 3.3) and integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability requirement). Perhaps, it depends on in which aspects security requirements should be written (in terms of mechanisms or in terms of features). Again, I am just commenting on the way of writing. Sue: You make an excellent point: I have added to the first part section 3.0 after the first paragraph: New/ There are dependencies in some of the requirements below. For confidentiality (section 3.3) and integrity (section 3.4) to be achieved, the client-agent must have mutual authentication (section 3.1) and secure transport (section 3.2). I2RS allows the use of an insecure transport for portions of data models that clearly indicate insecure transport. If insecure transport is used, then confidentiality and integrity cannot be achieved. 4) This is just an edit, but in page.10, "Requirements SEC-REQ-13 and SEC-REQ-14" should be "Requirements SEC-REQ-14 and SEC-REQ-15". --- Thank you for the editorial comment Thanks, Tomonori Takeda _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_00C8_01D1B27F.2616BC70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Takeda-san:

 

Thank = you for your excellent review.  My responses to your comments are = below.  I’ve released a version-05 to address your comments. =

 

Sue

 

-----Original Message-----

From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Tomonori Takeda

Sent: = Thursday, May 19, 2016 12:39 PM

To: rtg-ads@ietf.org

Cc: 'rtg-dir@ietf.org'; = 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org

Subject: [i2rs] RTG-DIR QA review: = draft-ietf-i2rs-protocol-security-requirements-04.txt

 

Hi,

 

I have = been selected as the Routing Directorate QA reviewer for this = draft.

 

Document: = draft-ietf-i2rs-protocol-security-requirements-04.txt

Reviewer: Tomonori Takeda

Review Date: May 20, 2016

Intended Status: Standards Track

 

I am = not following I2RS work closely, but in the spirit of QA review, this is = OK in my understanding.

https= ://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

<= p class=3DMsoPlainText> 

Here = are my comments.

 

I = think it is very important to have documents dedicated for security for = new protocols such as I2RS protocols.

Overall, I think the document is well organized and = clear what are security requirements for I2RS.

 

Some = specific comments.

 

1) The = document is intended to be Standards Track. I do not think it is common = for requirement drafts to be Standards Track.

 

Sue: = You are correct.  This is my error. I should have changed it this = morning.

 

2) In Section 3.1, requirements are mentioned that = are set in draft-ietf-i2rs-architecture-15.

   Some of these requirements are = not directly mentioned in draft-ietf-i2rs-architecture-15, =

   but rather = implied.

 

   For example, = draft-ietf-i2rs-architecture-15 mentions identifier for I2RS = client,

   but does not = mention identifier for I2RS agent (IMO).

   Please note that I think requirements = mentioned in Section 3.1. makes sense and valid.

   I am just commenting on the way of = writing.

 

Sue: You are correct = that the mutual identification implies an identity for the agent. =

Also in Section 2 of = draft-ietf-i2rs-architecture-15 mentions:

   role or security = role:   A security role specifies the = scope,

      resources, = priorities, etc. that a client or agent has.  If = a

      identity has = multiple roles in the security system, the = identity

      is permitted to = perform any operations any of those roles = permit.

      Multiple = identities may use the same security role.

 

 

3) I = think there is dependency on requirements mentioned in this = document.

   = Specifically, if mutual authentication (Section 3.1), secure transport = (Section 3.2),

   and = role-based security (Section 3.3) are met, confidentiality (Section 3.3) = and

   integrity = (Section 3.4) can be achieved (expect SEC-REQ-16: traceability = requirement).

 

   Perhaps, it depends on in which = aspects security requirements should be written

   (in terms of mechanisms or in terms of = features). Again, I am just commenting

   on the way of = writing.

 

Sue: You make an excellent point:

I have added to the first part section 3.0 after = the first paragraph:

New/

<t>There are = dependencies in some of the requirements below.  For =

confidentiality (section 3.3) and integrity = (section 3.4) to be achieved, the

client-agent must = have mutual authentication (section 3.1) and secure transport (section = 3.2).   I2RS allows the use of an insecure transport for = portions of data models that clearly indicate insecure transport.  = If insecure transport is used, then confidentiality and integrity cannot = be achieved.

</t>

4) This is just an edit, but in page.10, =

   "Requirements SEC-REQ-13 and = SEC-REQ-14" should be

   "Requirements SEC-REQ-14 and = SEC-REQ-15".

 

--- Thank you for the editorial comment =

 

Thanks,

Tomonori Takeda

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org

https://www.ietf.org/= mailman/listinfo/i2rs

------=_NextPart_000_00C8_01D1B27F.2616BC70-- From nobody Fri May 20 10:08:43 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E16112DC67; Fri, 20 May 2016 10:08:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520170842.380.58514.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 10:08:42 -0700 Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com Subject: [i2rs] i2rs - Update to a Meeting Session Request for IETF 96 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 17:08:42 -0000 An update to a meeting session request has just been submitted by Jeffrey Haas, a Chair of the i2rs working group. --------------------------------------------------------- Working Group Name: Interface to the Routing System Area Name: Routing Area Session Requester: Jeffrey Haas Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: idr trill i2nsf netconf netmod bfd Second Priority: opsawg opsarea rtgarea rtgwg teas bfcpbis pce nfvrg grow bess Third Priority: dots sdnrg Special Requests: --------------------------------------------------------- From nobody Sat May 21 06:51:30 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFB212B030; Sat, 21 May 2016 06:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX_ZRBa_HgeV; Sat, 21 May 2016 06:51:24 -0700 (PDT) Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52912D0AD; Sat, 21 May 2016 06:51:24 -0700 (PDT) Received: from c0042i0.coe.ntt.com (c0042i0.nc.agilit-hosting.com [10.18.161.11]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id 2987F1C58090; Sat, 21 May 2016 22:51:23 +0900 (JST) Received: from C0036I0.coe.ntt.com (10.18.160.40) by c0042i0.coe.ntt.com (10.18.161.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 21 May 2016 22:51:14 +0900 Received: from C0561I0.coe.ntt.com ([169.254.1.38]) by C0036I0.coe.ntt.com ([10.18.160.40]) with mapi id 14.03.0181.006; Sat, 21 May 2016 22:51:22 +0900 From: Tomonori Takeda To: 'Susan Hares' , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Thread-Index: AdGx5fCxDq0YNmnWSrK+7ayI8V3BEQAb0v2AAESJF1A= Date: Sat, 21 May 2016 13:51:21 +0000 Message-ID: References: <00c701d1b2a0$ad254f30$076fed90$@ndzh.com> In-Reply-To: <00c701d1b2a0$ad254f30$076fed90$@ndzh.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: shares@ndzh.com, rtg-ads@ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-i2rs-protocol-security-requirements.all@ietf.org, i2rs@ietf.org x-originating-ip: [10.25.130.6] Content-Type: multipart/alternative; boundary="_000_EB0F2EAC05E9C64D80571F2042700A2A6C7FE8AEC0561I0coenttco_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-protocol-security-requirements.all@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 13:51:28 -0000 --_000_EB0F2EAC05E9C64D80571F2042700A2A6C7FE8AEC0561I0coenttco_ Content-Type: text/plain; charset="iso-2022-jp" Hi Sue, Thanks for the update. This version looks good to me, except one editorial comment. > 4) This is just an edit, but in page.10, > "Requirements SEC-REQ-13 and SEC-REQ-14" should be > "Requirements SEC-REQ-14 and SEC-REQ-15". > > --- Thank you for the editorial comment Now, text is $B!H(BRequirements SEC-REQ-14 and SEC-REQ-16$B!I(B, but it should be $B!H(BRequirements SEC-REQ-14 and SEC-REQ-15$B!I(B. (Again, this is just an editorial comment.) Thanks, Tomonori Takeda From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, May 20, 2016 11:06 PM To: Tomonori Takeda$B!JIpEDCNE5!K(B; rtg-ads@ietf.org Cc: rtg-dir@ietf.org; draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; i2rs@ietf.org Subject: RE: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Takeda-san: Thank you for your excellent review. My responses to your comments are below. I$B!G(Bve released a version-05 to address your comments. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Tomonori Takeda Sent: Thursday, May 19, 2016 12:39 PM To: rtg-ads@ietf.org Cc: 'rtg-dir@ietf.org'; 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org Subject: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-i2rs-protocol-security-requirements-04.txt Reviewer: Tomonori Takeda Review Date: May 20, 2016 Intended Status: Standards Track I am not following I2RS work closely, but in the spirit of QA review, this is OK in my understanding. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Here are my comments. I think it is very important to have documents dedicated for security for new protocols such as I2RS protocols. Overall, I think the document is well organized and clear what are security requirements for I2RS. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for requirement drafts to be Standards Track. Sue: You are correct. This is my error. I should have changed it this morning. 2) In Section 3.1, requirements are mentioned that are set in draft-ietf-i2rs-architecture-15. Some of these requirements are not directly mentioned in draft-ietf-i2rs-architecture-15, but rather implied. For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS client, but does not mention identifier for I2RS agent (IMO). Please note that I think requirements mentioned in Section 3.1. makes sense and valid. I am just commenting on the way of writing. Sue: You are correct that the mutual identification implies an identity for the agent. Also in Section 2 of draft-ietf-i2rs-architecture-15 mentions: role or security role: A security role specifies the scope, resources, priorities, etc. that a client or agent has. If a identity has multiple roles in the security system, the identity is permitted to perform any operations any of those roles permit. Multiple identities may use the same security role. 3) I think there is dependency on requirements mentioned in this document. Specifically, if mutual authentication (Section 3.1), secure transport (Section 3.2), and role-based security (Section 3.3) are met, confidentiality (Section 3.3) and integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability requirement). Perhaps, it depends on in which aspects security requirements should be written (in terms of mechanisms or in terms of features). Again, I am just commenting on the way of writing. Sue: You make an excellent point: I have added to the first part section 3.0 after the first paragraph: New/ There are dependencies in some of the requirements below. For confidentiality (section 3.3) and integrity (section 3.4) to be achieved, the client-agent must have mutual authentication (section 3.1) and secure transport (section 3.2). I2RS allows the use of an insecure transport for portions of data models that clearly indicate insecure transport. If insecure transport is used, then confidentiality and integrity cannot be achieved. 4) This is just an edit, but in page.10, "Requirements SEC-REQ-13 and SEC-REQ-14" should be "Requirements SEC-REQ-14 and SEC-REQ-15". --- Thank you for the editorial comment Thanks, Tomonori Takeda _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_EB0F2EAC05E9C64D80571F2042700A2A6C7FE8AEC0561I0coenttco_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxtZXRhIG5hbWU9Ikdl bmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IhskQiNNI1MbKEIgGyRCTEBEKxsoQiI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4 IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiIbJEIjTSNTGyhCIBskQiU0JTclQyUv GyhCIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiIbJEIjTSNTGyhCIBskQiU0JTclQyUvGyhCIjsNCglwYW5vc2UtMToyIDExIDYg OSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi GyRCI00jUxsoQiAbJEIjUCU0JTclQyUvGyhCIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQBskQiNNI1Mb KEIgGyRCJTQlNyVDJS8bKEIiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAGyRCI00jUxsoQiAbJEIjUCU0JTclQyUvGyhCIjsN CglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQBskQiNNI1MbKEIgGyRCTEBEKxsoQiI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4 IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IhskQj1xPDAkSiQ3GyhCIFwoGyRCSjg7ehsoQlwpIjsNCgltYXJn aW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IhskQj9hJC09UCQ3GyhCIFwoGyRCSjg7ehsoQlwpIjsNCgltYXJnaW46MG1tOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYQ0KCXttc28tc3R5bGUtbmFtZToiGyRCPXE8 MCRKJDcbKEIgXCgbJEJKODt6GyhCXCkiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazobJEI9cTwwJEokNxsoQjsNCglmb250LWZhbWlseToiGyRCI00jUxsoQiAbJEJM QEQrGyhCIiwic2VyaWYiO30NCnNwYW4uYTANCgl7bXNvLXN0eWxlLW5hbWU6IhskQj9hJC09UCQ3 GyhCIFwoGyRCSjg7ehsoQlwpIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6GyRCP2EkLT1QJDcbKEI7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 fQ0KcC5QbGFpblRleHQsIGxpLlBsYWluVGV4dCwgZGl2LlBsYWluVGV4dA0KCXttc28tc3R5bGUt bmFtZToiUGxhaW4gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBtbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQsIGRpdi5C YWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowbW07DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi4yNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiI+DQo8djp0ZXh0Ym94IGluc2V0PSI1Ljg1cHQsLjdw dCw1Ljg1cHQsLjdwdCIgLz4NCjwvbzpzaGFwZWRlZmF1bHRzPjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJKQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkg U3VlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIHVwZGF0 ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIHZlcnNpb24gbG9va3MgZ29v ZCB0byBtZSwgZXhjZXB0IG9uZSBlZGl0b3JpYWwgY29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA0KSBUaGlzIGlzIGp1 c3QgYW4gZWRpdCwgYnV0IGluIHBhZ2UuMTAsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmbmJzcDsmbmJzcDsm bmJzcDsmcXVvdDtSZXF1aXJlbWVudHMgU0VDLVJFUS0xMyBhbmQgU0VDLVJFUS0xNCZxdW90OyBz aG91bGQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmbmJzcDsmbmJzcDsgJnF1b3Q7UmVxdWlyZW1lbnRzIFNF Qy1SRVEtMTQgYW5kIFNFQy1SRVEtMTUmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMDA3MEMwIj4mZ3Q7IC0tLSBUaGFuayB5b3UgZm9yIHRoZSBlZGl0b3JpYWwg Y29tbWVudA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm93LCB0ZXh0IGlzIBsk QiFIGyhCUmVxdWlyZW1lbnRzIFNFQy1SRVEtMTQgYW5kIFNFQy1SRVEtMTYbJEIhSRsoQiwgYnV0 IGl0IHNob3VsZCBiZSAbJEIhSBsoQlJlcXVpcmVtZW50cyBTRUMtUkVRLTE0IGFuZCBTRUMtUkVR LTE1GyRCIUkbKEIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KEFn YWluLCB0aGlzIGlzIGp1c3QgYW4gZWRpdG9yaWFsIGNvbW1lbnQuKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Ub21vbm9yaSBUYWtlZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MG1tIDBtbSAwbW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3VzYW4gSGFyZXMgW21haWx0bzpzaGFyZXNAbmR6aC5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMjAsIDIwMTYgMTE6MDYgUE08YnI+ DQo8Yj5Ubzo8L2I+IFRvbW9ub3JpIFRha2VkYTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDsbJEIjTSNTGyhCIBskQiNQJTQlNyVDJS8bKEImcXVv dDsiPhskQiFKSXBFRENORTUhSxsoQjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjsgcnRnLWFkc0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gcnRnLWRpckBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50cy5h bGxAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtpMnJz XSBSVEctRElSIFFBIHJldmlldzogZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJl cXVpcmVtZW50cy0wNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5U YWtlZGEtc2FuOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlvdSBmb3IgeW91ciBl eGNlbGxlbnQgcmV2aWV3LiZuYnNwOyBNeSByZXNwb25zZXMgdG8geW91ciBjb21tZW50cyBhcmUg YmVsb3cuJm5ic3A7IEkbJEIhRxsoQnZlIHJlbGVhc2VkIGEgdmVyc2lvbi0wNSB0byBhZGRyZXNz IHlvdXIgY29tbWVudHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlN1ZSA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 IGkycnMgWzxhIGhyZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppMnJz LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgVG9tb25vcmkgVGFrZWRhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPlNlbnQ6IFRodXJzZGF5LCBNYXkgMTksIDIwMTYgMTI6MzkgUE08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VG86IDxh IGhyZWY9Im1haWx0bzpydGctYWRzQGlldGYub3JnIj4NCnJ0Zy1hZHNAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkNjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wt c2VjdXJpdHktcmVxdWlyZW1lbnRzLmFsbEBpZXRmLm9yZyc7DQo8YSBocmVmPSJtYWlsdG86aTJy c0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U3ViamVjdDogW2kycnNdIFJU Ry1ESVIgUUEgcmV2aWV3OiBkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWly ZW1lbnRzLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSBRQSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRv Y3VtZW50OiBkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzLTA0 LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZXZpZXdlcjogVG9tb25vcmkgVGFrZWRhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJldmlldyBE YXRlOiBNYXkgMjAsIDIwMTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJh Y2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gbm90IGZvbGxvd2luZyBJMlJTIHdvcmsg Y2xvc2VseSwgYnV0IGluIHRoZSBzcGlyaXQgb2YgUUEgcmV2aWV3LCB0aGlzIGlzIE9LIGluIG15 IHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy50b29scy5pZXRm Lm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyRG9jUWEiPmh0dHBzOi8vdHJhYy50b29scy5p ZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyRG9jUWE8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5IZXJlIGFyZSBteSBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PkkgdGhpbmsgaXQgaXMgdmVyeSBpbXBvcnRhbnQgdG8gaGF2ZSBkb2N1bWVudHMgZGVkaWNhdGVk IGZvciBzZWN1cml0eSBmb3IgbmV3IHByb3RvY29scyBzdWNoIGFzIEkyUlMgcHJvdG9jb2xzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5PdmVyYWxsLCBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyB3ZWxsIG9yZ2FuaXplZCBh bmQgY2xlYXIgd2hhdCBhcmUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciBJMlJTLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+U29tZSBzcGVjaWZpYyBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjEpIFRoZSBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBiZSBTdGFuZGFyZHMgVHJh Y2suIEkgZG8gbm90IHRoaW5rIGl0IGlzIGNvbW1vbiBmb3IgcmVxdWlyZW1lbnQgZHJhZnRzIHRv IGJlIFN0YW5kYXJkcyBUcmFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlN1ZTogWW91IGFy ZSBjb3JyZWN0LiZuYnNwOyBUaGlzIGlzIG15IGVycm9yLiBJIHNob3VsZCBoYXZlIGNoYW5nZWQg aXQgdGhpcyBtb3JuaW5nLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4yKSBJbiBTZWN0aW9u IDMuMSwgcmVxdWlyZW1lbnRzIGFyZSBtZW50aW9uZWQgdGhhdCBhcmUgc2V0IGluIGRyYWZ0LWll dGYtaTJycy1hcmNoaXRlY3R1cmUtMTUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7U29t ZSBvZiB0aGVzZSByZXF1aXJlbWVudHMgYXJlIG5vdCBkaXJlY3RseSBtZW50aW9uZWQgaW4gZHJh ZnQtaWV0Zi1pMnJzLWFyY2hpdGVjdHVyZS0xNSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz cDtidXQgcmF0aGVyIGltcGxpZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsgRm9yIGV4YW1wbGUsIGRyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUtMTUgbWVudGlvbnMg aWRlbnRpZmllciBmb3IgSTJSUyBjbGllbnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBidXQgZG9l cyBub3QgbWVudGlvbiBpZGVudGlmaWVyIGZvciBJMlJTIGFnZW50IChJTU8pLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsgUGxlYXNlIG5vdGUgdGhhdCBJIHRoaW5rIHJlcXVpcmVtZW50cyBtZW50aW9u ZWQgaW4gU2VjdGlvbiAzLjEuIG1ha2VzIHNlbnNlIGFuZCB2YWxpZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7IEkgYW0ganVzdCBjb21tZW50aW5nIG9uIHRoZSB3YXkgb2Ygd3JpdGluZy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAw NzBDMCI+U3VlOiBZb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgbXV0dWFsIGlkZW50aWZpY2F0aW9u IGltcGxpZXMgYW4gaWRlbnRpdHkgZm9yIHRoZSBhZ2VudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+QWxzbyBpbiBTZWN0aW9uIDIgb2YgZHJhZnQtaWV0Zi1pMnJzLWFyY2hpdGVj dHVyZS0xNSBtZW50aW9uczoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7cm9sZSBvciBzZWN1cml0eSByb2xlOiZuYnNwOyZuYnNwOyBBIHNlY3VyaXR5 IHJvbGUgc3BlY2lmaWVzIHRoZSBzY29wZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNvdXJjZXMsIHByaW9yaXRpZXMsIGV0 Yy4gdGhhdCBhIGNsaWVudCBvciBhZ2VudCBoYXMuJm5ic3A7IElmIGE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eSBo YXMgbXVsdGlwbGUgcm9sZXMgaW4gdGhlIHNlY3VyaXR5IHN5c3RlbSwgdGhlIGlkZW50aXR5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaXMgcGVybWl0dGVkIHRvIHBlcmZvcm0gYW55IG9wZXJhdGlvbnMgYW55IG9mIHRob3NlIHJv bGVzIHBlcm1pdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBNdWx0aXBsZSBpZGVudGl0aWVzIG1heSB1c2UgdGhlIHNhbWUgc2Vj dXJpdHkgcm9sZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4zKSBJ IHRoaW5rIHRoZXJlIGlzIGRlcGVuZGVuY3kgb24gcmVxdWlyZW1lbnRzIG1lbnRpb25lZCBpbiB0 aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgU3BlY2lmaWNhbGx5LCBpZiBtdXR1 YWwgYXV0aGVudGljYXRpb24gKFNlY3Rpb24gMy4xKSwgc2VjdXJlIHRyYW5zcG9ydCAoU2VjdGlv biAzLjIpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgYW5kIHJvbGUtYmFzZWQgc2VjdXJpdHkgKFNl Y3Rpb24gMy4zKSBhcmUgbWV0LCBjb25maWRlbnRpYWxpdHkgKFNlY3Rpb24gMy4zKSBhbmQNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDtpbnRlZ3JpdHkgKFNlY3Rpb24gMy40KSBjYW4gYmUg YWNoaWV2ZWQgKGV4cGVjdCBTRUMtUkVRLTE2OiB0cmFjZWFiaWxpdHkgcmVxdWlyZW1lbnQpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IFBlcmhhcHMsIGl0IGRlcGVuZHMg b24gaW4gd2hpY2ggYXNwZWN0cyBzZWN1cml0eSByZXF1aXJlbWVudHMgc2hvdWxkIGJlIHdyaXR0 ZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IChpbiB0ZXJtcyBvZiBtZWNoYW5pc21zIG9yIGluIHRl cm1zIG9mIGZlYXR1cmVzKS4gQWdhaW4sIEkgYW0ganVzdCBjb21tZW50aW5nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyBvbiB0aGUgd2F5IG9mIHdyaXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij5TdWU6IFlvdSBtYWtlIGFuIGV4Y2VsbGVudCBwb2ludDogPG86cD4NCjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSBoYXZlIGFk ZGVkIHRvIHRoZSBmaXJzdCBwYXJ0IHNlY3Rpb24gMy4wIGFmdGVyIHRoZSBmaXJzdCBwYXJhZ3Jh cGg6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPk5ldy88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPiZsdDt0Jmd0O1RoZXJlIGFyZSBkZXBlbmRlbmNpZXMgaW4gc29tZSBv ZiB0aGUgcmVxdWlyZW1lbnRzIGJlbG93LiZuYnNwOyBGb3INCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+Y29uZmlkZW50aWFsaXR5IChzZWN0aW9uIDMuMykgYW5kIGludGVncml0eSAo c2VjdGlvbiAzLjQpIHRvIGJlIGFjaGlldmVkLCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMw MDcwQzAiPmNsaWVudC1hZ2VudCBtdXN0IGhhdmUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIChzZWN0 aW9uIDMuMSkgYW5kIHNlY3VyZSB0cmFuc3BvcnQgKHNlY3Rpb24gMy4yKS4mbmJzcDsmbmJzcDsg STJSUyBhbGxvd3MgdGhlIHVzZSBvZiBhbiBpbnNlY3VyZSB0cmFuc3BvcnQgZm9yIHBvcnRpb25z IG9mIGRhdGEgbW9kZWxzIHRoYXQgY2xlYXJseSBpbmRpY2F0ZQ0KIGluc2VjdXJlIHRyYW5zcG9y dC4mbmJzcDsgSWYgaW5zZWN1cmUgdHJhbnNwb3J0IGlzIHVzZWQsIHRoZW4gY29uZmlkZW50aWFs aXR5IGFuZCBpbnRlZ3JpdHkgY2Fubm90IGJlIGFjaGlldmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+Jmx0Oy90Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PjQpIFRoaXMgaXMganVzdCBhbiBlZGl0LCBidXQgaW4gcGFnZS4xMCwNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmcXVvdDtSZXF1aXJlbWVudHMgU0VDLVJFUS0xMyBhbmQgU0VDLVJFUS0x NCZxdW90OyBzaG91bGQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZxdW90O1JlcXVpcmVtZW50 cyBTRUMtUkVRLTE0IGFuZCBTRUMtUkVRLTE1JnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPi0tLSBUaGFuayB5b3UgZm9yIHRoZSBlZGl0b3JpYWwg Y29tbWVudA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRvbW9u b3JpIFRha2VkYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+aTJycyBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EB0F2EAC05E9C64D80571F2042700A2A6C7FE8AEC0561I0coenttco_-- From nobody Tue May 24 06:53:45 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9712D747; Tue, 24 May 2016 06:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8bWv6S2NvxY; Tue, 24 May 2016 06:53:41 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 E999612D7C6; Tue, 24 May 2016 06:53:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Tomonori Takeda'" , References: <00c701d1b2a0$ad254f30$076fed90$@ndzh.com> In-Reply-To: Date: Tue, 24 May 2016 09:53:35 -0400 Message-ID: <016501d1b5c3$ab225860$01670920$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0166_01D1B5A2.24132960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFZkbV8xMTMF+FMKLR7WGNqnq+0AQL2u+8nAWQrjXCglYvzsA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-i2rs-protocol-security-requirements.all@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 13:53:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0166_01D1B5A2.24132960 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Tomonori: Thanks for noticing my error. I$B!G(Bve released version -06 the change. Sue From: Tomonori Takeda [mailto:tomonori.takeda@ntt.com] Sent: Saturday, May 21, 2016 9:51 AM To: 'Susan Hares'; rtg-ads@ietf.org Cc: rtg-dir@ietf.org; draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; i2rs@ietf.org Subject: RE: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Hi Sue, Thanks for the update. This version looks good to me, except one editorial comment. > 4) This is just an edit, but in page.10, > "Requirements SEC-REQ-13 and SEC-REQ-14" should be > "Requirements SEC-REQ-14 and SEC-REQ-15". > > --- Thank you for the editorial comment Now, text is $B!H(BRequirements SEC-REQ-14 and SEC-REQ-16$B!I(B, but it should be $B!H(BRequirements SEC-REQ-14 and SEC-REQ-15$B!I(B. (Again, this is just an editorial comment.) Thanks, Tomonori Takeda From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, May 20, 2016 11:06 PM To: Tomonori Takeda$B!JIpEDCNE5!K(B; rtg-ads@ietf.org Cc: rtg-dir@ietf.org; draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; i2rs@ietf.org Subject: RE: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Takeda-san: Thank you for your excellent review. My responses to your comments are below. I$B!G(Bve released a version-05 to address your comments. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Tomonori Takeda Sent: Thursday, May 19, 2016 12:39 PM To: rtg-ads@ietf.org Cc: 'rtg-dir@ietf.org'; 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org Subject: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-i2rs-protocol-security-requirements-04.txt Reviewer: Tomonori Takeda Review Date: May 20, 2016 Intended Status: Standards Track I am not following I2RS work closely, but in the spirit of QA review, this is OK in my understanding. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Here are my comments. I think it is very important to have documents dedicated for security for new protocols such as I2RS protocols. Overall, I think the document is well organized and clear what are security requirements for I2RS. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for requirement drafts to be Standards Track. Sue: You are correct. This is my error. I should have changed it this morning. 2) In Section 3.1, requirements are mentioned that are set in draft-ietf-i2rs-architecture-15. Some of these requirements are not directly mentioned in draft-ietf-i2rs-architecture-15, but rather implied. For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS client, but does not mention identifier for I2RS agent (IMO). Please note that I think requirements mentioned in Section 3.1. makes sense and valid. I am just commenting on the way of writing. Sue: You are correct that the mutual identification implies an identity for the agent. Also in Section 2 of draft-ietf-i2rs-architecture-15 mentions: role or security role: A security role specifies the scope, resources, priorities, etc. that a client or agent has. If a identity has multiple roles in the security system, the identity is permitted to perform any operations any of those roles permit. Multiple identities may use the same security role. 3) I think there is dependency on requirements mentioned in this document. Specifically, if mutual authentication (Section 3.1), secure transport (Section 3.2), and role-based security (Section 3.3) are met, confidentiality (Section 3.3) and integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability requirement). Perhaps, it depends on in which aspects security requirements should be written (in terms of mechanisms or in terms of features). Again, I am just commenting on the way of writing. Sue: You make an excellent point: I have added to the first part section 3.0 after the first paragraph: New/ There are dependencies in some of the requirements below. For confidentiality (section 3.3) and integrity (section 3.4) to be achieved, the client-agent must have mutual authentication (section 3.1) and secure transport (section 3.2). I2RS allows the use of an insecure transport for portions of data models that clearly indicate insecure transport. If insecure transport is used, then confidentiality and integrity cannot be achieved. 4) This is just an edit, but in page.10, "Requirements SEC-REQ-13 and SEC-REQ-14" should be "Requirements SEC-REQ-14 and SEC-REQ-15". --- Thank you for the editorial comment Thanks, Tomonori Takeda _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_0166_01D1B5A2.24132960 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Tomonori:

 

Thanks for noticing my error.   I=1B$B!G=1B(Bve released = version -06 the change.

 

Sue

 

From:= = Tomonori Takeda [mailto:tomonori.takeda@ntt.com]
Sent: = Saturday, May 21, 2016 9:51 AM
To: 'Susan Hares'; = rtg-ads@ietf.org
Cc: rtg-dir@ietf.org; = draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; = i2rs@ietf.org
Subject: RE: [i2rs] RTG-DIR QA review: = draft-ietf-i2rs-protocol-security-requirements-04.txt

 

Hi Sue,

 

Thanks for the update.

 

This version looks good to me, except one editorial = comment.

 

> 4) This is = just an edit, but in page.10,

>    "Requirements = SEC-REQ-13 and SEC-REQ-14" should be

>    "Requirements SEC-REQ-14 and = SEC-REQ-15".

> =

> --- Thank you for the editorial comment =

 

Now, text is =1B$B!H=1B(BRequirements SEC-REQ-14 and = SEC-REQ-16=1B$B!I=1B(B, but it should be =1B$B!H=1B(BRequirements = SEC-REQ-14 and SEC-REQ-15=1B$B!I=1B(B.

(Again, this is just an editorial comment.)

 

Thanks,

Tomonori Takeda

 

From:= = Susan Hares [mailto:shares@ndzh.com] =
Sent: Friday, May 20, 2016 11:06 PM
To: Tomonori = Takeda=1B$B!JIpEDCNE5!K=1B(B; rtg-ads@ietf.org
Cc: rtg-dir@ietf.org; draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; i2rs@ietf.org
Subject: RE: = [i2rs] RTG-DIR QA review: = draft-ietf-i2rs-protocol-security-requirements-04.txt

 

Takeda-san:

 

Thank = you for your excellent review.  My responses to your comments are = below.  I=1B$B!G=1B(Bve released a version-05 to address your = comments.

 

Sue

 

-----Original Message-----

From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Tomonori Takeda

Sent: = Thursday, May 19, 2016 12:39 PM

To: rtg-ads@ietf.org

Cc: 'rtg-dir@ietf.org'; = 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org

Subject: [i2rs] RTG-DIR QA review: = draft-ietf-i2rs-protocol-security-requirements-04.txt

 

Hi,

 

I have = been selected as the Routing Directorate QA reviewer for this = draft.

 

Document: = draft-ietf-i2rs-protocol-security-requirements-04.txt

Reviewer: Tomonori Takeda

Review Date: May 20, 2016

Intended Status: Standards Track

 

I am = not following I2RS work closely, but in the spirit of QA review, this is = OK in my understanding.

https= ://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

<= p class=3DMsoPlainText> 

Here = are my comments.

 

I = think it is very important to have documents dedicated for security for = new protocols such as I2RS protocols.

Overall, I think the document is well organized and = clear what are security requirements for I2RS.

 

Some = specific comments.

 

1) The = document is intended to be Standards Track. I do not think it is common = for requirement drafts to be Standards Track.

 

Sue: = You are correct.  This is my error. I should have changed it this = morning.

 

2) In Section 3.1, requirements are mentioned that = are set in draft-ietf-i2rs-architecture-15.

   Some of these requirements are = not directly mentioned in draft-ietf-i2rs-architecture-15, =

   but rather = implied.

 

   For example, = draft-ietf-i2rs-architecture-15 mentions identifier for I2RS = client,

   but does not = mention identifier for I2RS agent (IMO).

   Please note that I think requirements = mentioned in Section 3.1. makes sense and valid.

   I am just commenting on the way of = writing.

 

Sue: You are correct = that the mutual identification implies an identity for the agent. =

Also in Section 2 of = draft-ietf-i2rs-architecture-15 mentions:

   role or security = role:   A security role specifies the = scope,

      resources, = priorities, etc. that a client or agent has.  If = a

      identity has = multiple roles in the security system, the = identity

      is permitted to = perform any operations any of those roles = permit.

      Multiple = identities may use the same security role.

 

 

3) I = think there is dependency on requirements mentioned in this = document.

   = Specifically, if mutual authentication (Section 3.1), secure transport = (Section 3.2),

   and = role-based security (Section 3.3) are met, confidentiality (Section 3.3) = and

   integrity = (Section 3.4) can be achieved (expect SEC-REQ-16: traceability = requirement).

 

   Perhaps, it depends on in which = aspects security requirements should be written

   (in terms of mechanisms or in terms of = features). Again, I am just commenting

   on the way of = writing.

 

Sue: You make an excellent point:

I have added to the first part section 3.0 after = the first paragraph:

New/

<t>There are = dependencies in some of the requirements below.  For =

confidentiality (section 3.3) and integrity = (section 3.4) to be achieved, the

client-agent must = have mutual authentication (section 3.1) and secure transport (section = 3.2).   I2RS allows the use of an insecure transport for = portions of data models that clearly indicate insecure transport.  = If insecure transport is used, then confidentiality and integrity cannot = be achieved.

</t>

4) This is just an edit, but in page.10, =

   "Requirements SEC-REQ-13 and = SEC-REQ-14" should be

   "Requirements SEC-REQ-14 and = SEC-REQ-15".

 

--- Thank you for the editorial comment =

 

Thanks,

Tomonori Takeda

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org

https://www.ietf.org/= mailman/listinfo/i2rs

------=_NextPart_000_0166_01D1B5A2.24132960-- From nobody Tue May 24 06:57:39 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A284312D541; Tue, 24 May 2016 06:57:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160524135735.4461.71749.idtracker@ietfa.amsl.com> Date: Tue, 24 May 2016 06:57:35 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-protocol-security-requirements-06.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 13:57:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Security Related Requirements Authors : Susan Hares Daniel Migault Joel Halpern Filename : draft-ietf-i2rs-protocol-security-requirements-06.txt Pages : 14 Date : 2016-05-24 Abstract: This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-protocol-security-requirements-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-protocol-security-requirements-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 24 09:11:11 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B9E12D0A2 for ; Tue, 24 May 2016 09:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIVzT8g1G25Z for ; Tue, 24 May 2016 09:11:00 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D872812D8D6 for ; Tue, 24 May 2016 09:11:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B591E1E335; Tue, 24 May 2016 12:16:22 -0400 (EDT) Date: Tue, 24 May 2016 12:16:22 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20160524161622.GK17462@pfrc.org> References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 16:11:02 -0000 Working Group, In the prior poll, we didn't get much in the way of input for adopting the filter-based RIB work. This work is explicitly in charter, and more importantly is *modeling* work and doesn't have to immediately deal with our protocol headaches. :-) Please respond to the list whether you would support or don't support adoption of this draft. The extended WGLC ends on June 10. -- Jeff On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote: > This begins a 2 week WG Adoption call for: > > > > draft-kini-i2rs-fb-rib-info-model-03 > > draft-hares-i2rs-fb-rib-data-model-03 > > draft-hares-i2rs-pkt-eca-data-model-02 > > > > Please send your comments on the technical merits and usefulness of these > models. > > > > Sue and Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 24 12:06:34 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6C712D9BA for ; Tue, 24 May 2016 12:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9tpPiSZbQpo for ; Tue, 24 May 2016 12:06:32 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 767D312D9B1 for ; Tue, 24 May 2016 12:06:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 585B02808EB; Tue, 24 May 2016 12:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464116792; bh=yfdATV7PIfGOY9iOCi51sXUkeTWR/RmjsaQa+ubDnbw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GsxI/hEIKGraTjvzGg8BRM6odh1j8PN7Tzi9utSPdnkMCpBvcOcJ8V62anSyuyfE1 djX8sRZAifQ0ZBBTum+liqceMis5q5gVxqhkcE0gXRZjbgTRkLLvLVFXBlc4otKMk6 m9E016U7mB0RQ9Y/ugTEOZCNdtLDsXqO3iDA0ClU= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E80472800EC; Tue, 24 May 2016 12:06:31 -0700 (PDT) To: Jeffrey Haas , i2rs@ietf.org References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> From: "Joel M. Halpern" Message-ID: <9be75ddc-da79-3643-c053-16858e2a4fe6@joelhalpern.com> Date: Tue, 24 May 2016 15:06:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160524161622.GK17462@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 19:06:33 -0000 I support the WG adopting these item. Yours, Joel On 5/24/16 12:16 PM, Jeffrey Haas wrote: > Working Group, > > In the prior poll, we didn't get much in the way of input for adopting the > filter-based RIB work. This work is explicitly in charter, and more > importantly is *modeling* work and doesn't have to immediately deal with our > protocol headaches. :-) > > Please respond to the list whether you would support or don't support > adoption of this draft. > > The extended WGLC ends on June 10. > > -- Jeff > > On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote: >> This begins a 2 week WG Adoption call for: >> >> >> >> draft-kini-i2rs-fb-rib-info-model-03 >> >> draft-hares-i2rs-fb-rib-data-model-03 >> >> draft-hares-i2rs-pkt-eca-data-model-02 >> >> >> >> Please send your comments on the technical merits and usefulness of these >> models. >> >> >> >> Sue and Jeff >> > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue May 24 12:24:39 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A7D12D148 for ; Tue, 24 May 2016 12:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAMearTlmRFt for ; Tue, 24 May 2016 12:24:34 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C4612B013 for ; Tue, 24 May 2016 12:24:33 -0700 (PDT) Received: from smtptc.telefonica.com (tgtim3c01.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1DAD24610A7 for ; Tue, 24 May 2016 21:24:30 +0200 (CEST) Received: from ESTGVMSP104.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP104", Issuer "ESTGVMSP104" (not verified)) by smtptc.telefonica.com (Postfix) with ESMTPS id 065AC461077 for ; Tue, 24 May 2016 21:24:30 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.50) with Microsoft SMTP Server (TLS) id 14.3.266.1; Tue, 24 May 2016 21:24:29 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (10.161.13.142) by DB4PR06MB0621.eurprd06.prod.outlook.com (10.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.506.2; Tue, 24 May 2016 19:23:28 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) with mapi id 15.01.0506.007; Tue, 24 May 2016 19:23:27 +0000 From: DIEGO LOPEZ GARCIA To: "i2rs@ietf.org" Thread-Topic: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) Thread-Index: AQHRtdb56u+SrQfHQ0O6VZIQO0nao5/IcwmAgAAExgA= Date: Tue, 24 May 2016 19:23:27 +0000 Message-ID: References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> <9be75ddc-da79-3643-c053-16858e2a4fe6@joelhalpern.com> In-Reply-To: <9be75ddc-da79-3643-c053-16858e2a4fe6@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.51.67.99] x-ms-office365-filtering-correlation-id: 14c9a423-0e00-4f58-38f6-08d38408e211 x-microsoft-exchange-diagnostics: 1; DB4PR06MB0621; 5:2bIG+GBDl0GONBLFaccQNuNHnJDXo+dOLj4B0ZokxZbgw929eWQhskw3RxlOjcLMVvQ650kK+S6QXKpfRID5KmoqnwhAvluabFqGQoty8EJctk/FiP6LOJ7Dalg+n3/Hu6J5wNXDVoYHbUqiQ9W3iA==; 24:wXpnBNAjHIJPwCJpn+MOe/eTQYS74zJC5mOJCOUclqOtnYaj5CHfPZwy6tC5B/O966OBWaSZIexnjAcBIPvrxFPjHcJzshTFLyqNG6laJ+I=; 7:BbpfmyTwz3Oe6wXdSfuOQJZDbZEVFyB0tYnKW6KS6pg4C+G2EZUlMvTDU8N1xvbDg1CwhonV+R+kJk0Ao+gLBgyugieDdAOX7CIEYpS1L+zO4mVWP1y5w2ZwDqlpsr+O25AlLk4qlz9BsY/mIFELJ+1q63QIfu2pg+8gIFMhUs2n1NnjBj0owJvKROhl98G/ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0621; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR06MB0621; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(252514010)(106116001)(2501003)(66066001)(83716003)(3280700002)(450100001)(15975445007)(1220700001)(122556002)(77096005)(3846002)(36756003)(102836003)(92566002)(586003)(3660700001)(6116002)(2950100001)(76176999)(2351001)(10400500002)(87936001)(2900100001)(8936002)(8676002)(5002640100001)(81166006)(16236675004)(82746002)(19617315012)(19580405001)(5640700001)(5008740100001)(54356999)(5004730100002)(33656002)(19580395003)(189998001)(50986999)(107886002)(2906002)(110136002)(86362001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C45104624BB34803B297C8144FD2BA46telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 19:23:27.5349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1549-8.0.0.1202-22344.002 X-TM-AS-Result: No--4.625-7.0-31-10 X-imss-scan-details: No--4.625-7.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1549-8.0.1202-22344.002 X-TMASE-Result: 10--4.625500-10.000000 X-TMASE-MatchedRID: Xxz90/Ib/ZhbJCKOm3VRCbBOE9APtGEpevuGN4aJZuXMU8uAdH6Xmm8h faOkiWq6F7SqjoBR8dZbuDP8ZuCmXq/rTR5bj3wyIFBEE5CFomL9VAbehV/HfnZVUWe9wUukjLw gL2JEtWX6TVRa33KnqDSZcp4JyEHBTyKSzNZShVvFJnEpmt9OE1DczN/SMpBYJaVXJb4ySQzPzW Nc0Cig+AUJ2rQm9htltT4jIeGRd/VBldmDYjwlpoDNW+VSeNngwlVhkh86Ot2RoTvsoP7DRetno 5Fr47QUNeyeXkXe6VkAz7oVOD+dyjQqyqvNOEEVKw/L2Xf1EeyYkTGnuLYuveE/SzJlpPqkkLzn 9Tg4v7KnruWtZz/0S08zV5CaQcvok2hl3qA6556vSp/UN11J6pExoZ469iqvb+7kjbdGITCmVQg pf/zWgg13q7nPpNoMe5wBpY24P3blB6zXVVZqqXypzdJ3MZ1K6Fl+KBsCJ13mXgnu9Pl+tWbGID aPck7A8pHdnFS/LwNI9rD1ir7Z9FAI6wCVrE3vH1bhq4z+yfSxgpAsVRsHu3yJcUmdDy/zbj46G 69Nmg29P47o5uZEhQiORHpWha5YW0/6WPAv0J8rJDMp92Wwbbe+caBr9G5nHcx2jfNbiYWy0wa5 2Ca6I/r+HtIyr2XB1ZTMiivFYJ/xittgViyLhduzxqqN2bRkUS8rH04fE6vyfw7PmvRW/U9qHtV mQZNb8PX6rfx/lnDlx7UWPyloUStksuw+iv1x5BYsdGp5ikfc2eoifeIcPoIECYgkYhsW4YS6Fy G8vyijlFSgXWPWuCI9MxSOQ6CStWrGVTnl6LibKItl61J/yZUdXE/WGn0FxbYCTleOUf7mFtt/5 bvnJQFQjCpZOMvVRdSZ75+gibRxQcI/3CzrQU6DPcWWckekTNkSk7Tw8MR4MULigUJEvvZG+Kbo nHx8Tm8g8o/iy0JAFt0zJhgmy8WFcyN1Agmm X-TMASE-SNAP-Result: 1.811037.0001-0-1-22:0,12:0 Archived-At: Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 19:24:37 -0000 --_000_C45104624BB34803B297C8144FD2BA46telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I support the adoption. On 5/24/16 12:16 PM, Jeffrey Haas wrote: Working Group, In the prior poll, we didn't get much in the way of input for adopting the filter-based RIB work. This work is explicitly in charter, and more importantly is *modeling* work and doesn't have to immediately deal with ou= r protocol headaches. :-) Please respond to the list whether you would support or don't support adoption of this draft. The extended WGLC ends on June 10. -- Jeff On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote: This begins a 2 week WG Adoption call for: draft-kini-i2rs-fb-rib-info-model-03 draft-hares-i2rs-fb-rib-data-model-03 draft-hares-i2rs-pkt-eca-data-model-02 Please send your comments on the technical merits and usefulness of these models. Sue and Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_C45104624BB34803B297C8144FD2BA46telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: quoted-printable I support the adoption.

On 5/24/16 12:16 PM, Jeffrey Haas wrote:
Working Group,

In the prior poll, we didn't get much in the way of input for adopting the<= br class=3D""> filter-based RIB work.  This work is explicitly in charter, and more importantly is *modeling* work and doesn't have to immediately deal with ou= r
protocol headaches. :-)

Please respond to the list whether you would support or don't support
adoption of this draft.

The extended WGLC ends on June 10.

-- Jeff

On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote:
This begins a 2 week WG Adoption call = for:



draft-kini-i2rs-fb-rib-info-model-03

draft-hares-i2rs-fb-rib-data-model-03

draft-hares-i2rs-pkt-eca-data-model-02



Please send your comments on the technical merits and usefulness of these models.



Sue  and Jeff


______________________________________= _________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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


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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_C45104624BB34803B297C8144FD2BA46telefonicacom_-- From nobody Tue May 24 12:53:19 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F256F12D6A7 for ; Tue, 24 May 2016 12:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1lzYgwfJPuK for ; Tue, 24 May 2016 12:53:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288B612D506 for ; Tue, 24 May 2016 12:53:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPN06466; Tue, 24 May 2016 19:53:02 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 24 May 2016 20:53:01 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Tue, 24 May 2016 12:52:55 -0700 From: Linda Dunbar To: "i2rs@ietf.org" Thread-Topic: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) Thread-Index: AQHRtdbuStK+m5YbekCuK8lWrFijr5/I6GKAgAAEx4D//5KzUA== Date: Tue, 24 May 2016 19:52:55 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657EA72F4@dfweml501-mbb> References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> <9be75ddc-da79-3643-c053-16858e2a4fe6@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.81] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657EA72F4dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5744B11E.0072, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d1508a8c1e37e90a8235905065dd2d68 Archived-At: Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 19:53:12 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657EA72F4dfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24uDQoNCkxpbmRhIER1bmJhcg0KDQpPbiA1LzI0LzE2 IDEyOjE2IFBNLCBKZWZmcmV5IEhhYXMgd3JvdGU6DQpXb3JraW5nIEdyb3VwLA0KDQpJbiB0aGUg cHJpb3IgcG9sbCwgd2UgZGlkbid0IGdldCBtdWNoIGluIHRoZSB3YXkgb2YgaW5wdXQgZm9yIGFk b3B0aW5nIHRoZQ0KZmlsdGVyLWJhc2VkIFJJQiB3b3JrLiAgVGhpcyB3b3JrIGlzIGV4cGxpY2l0 bHkgaW4gY2hhcnRlciwgYW5kIG1vcmUNCmltcG9ydGFudGx5IGlzICptb2RlbGluZyogd29yayBh bmQgZG9lc24ndCBoYXZlIHRvIGltbWVkaWF0ZWx5IGRlYWwgd2l0aCBvdXINCnByb3RvY29sIGhl YWRhY2hlcy4gOi0pDQoNClBsZWFzZSByZXNwb25kIHRvIHRoZSBsaXN0IHdoZXRoZXIgeW91IHdv dWxkIHN1cHBvcnQgb3IgZG9uJ3Qgc3VwcG9ydA0KYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4NCg0K VGhlIGV4dGVuZGVkIFdHTEMgZW5kcyBvbiBKdW5lIDEwLg0KDQotLSBKZWZmDQoNCk9uIEZyaSwg QXByIDAxLCAyMDE2IGF0IDA3OjM1OjEzUE0gLTA0MDAsIFN1c2FuIEhhcmVzIHdyb3RlOg0KDQpU aGlzIGJlZ2lucyBhIDIgd2VlayBXRyBBZG9wdGlvbiBjYWxsIGZvcjoNCg0KDQoNCmRyYWZ0LWtp bmktaTJycy1mYi1yaWItaW5mby1tb2RlbC0wMw0KDQpkcmFmdC1oYXJlcy1pMnJzLWZiLXJpYi1k YXRhLW1vZGVsLTAzDQoNCmRyYWZ0LWhhcmVzLWkycnMtcGt0LWVjYS1kYXRhLW1vZGVsLTAyDQoN Cg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIG9uIHRoZSB0ZWNobmljYWwgbWVyaXRzIGFu ZCB1c2VmdWxuZXNzIG9mIHRoZXNlDQptb2RlbHMuDQoNCg0KDQpTdWUgIGFuZCBKZWZmDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmkycnMgbWFp bGluZyBsaXN0DQppMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQppMnJzIG1haWxpbmcgbGlzdA0KaTJyc0BpZXRm Lm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaTJycw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KaTJycyBtYWlsaW5nIGxpc3QNCmkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCg0KLS0N CiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIu IExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXov DQoNCmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTxtYWlsdG86ZGllZ28uci5s b3BlekB0ZWxlZm9uaWNhLmNvbT4NClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICsz NCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1 bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBj b250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFy YSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5v IGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUg cXVlIGxhIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4g YXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lz bGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBs ZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1p c21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2Ug aXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29t bXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlh dGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBl IHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6Fy aW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFs IGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5v LiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmlj YSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6Nv IGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmly dHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBv ciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9y IGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657EA72F4dfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgc3VwcG9ydCB0aGUgYWRv cHRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpbmRhIER1bmJhcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNS8yNC8xNiAxMjoxNiBQTSwgSmVmZnJleSBI YWFzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Xb3JraW5nIEdyb3VwLDxicj4NCjxicj4NCkluIHRoZSBwcmlvciBwb2xsLCB3ZSBk aWRuJ3QgZ2V0IG11Y2ggaW4gdGhlIHdheSBvZiBpbnB1dCBmb3IgYWRvcHRpbmcgdGhlPGJyPg0K ZmlsdGVyLWJhc2VkIFJJQiB3b3JrLiAmbmJzcDtUaGlzIHdvcmsgaXMgZXhwbGljaXRseSBpbiBj aGFydGVyLCBhbmQgbW9yZTxicj4NCmltcG9ydGFudGx5IGlzICptb2RlbGluZyogd29yayBhbmQg ZG9lc24ndCBoYXZlIHRvIGltbWVkaWF0ZWx5IGRlYWwgd2l0aCBvdXI8YnI+DQpwcm90b2NvbCBo ZWFkYWNoZXMuIDotKTxicj4NCjxicj4NClBsZWFzZSByZXNwb25kIHRvIHRoZSBsaXN0IHdoZXRo ZXIgeW91IHdvdWxkIHN1cHBvcnQgb3IgZG9uJ3Qgc3VwcG9ydDxicj4NCmFkb3B0aW9uIG9mIHRo aXMgZHJhZnQuPGJyPg0KPGJyPg0KVGhlIGV4dGVuZGVkIFdHTEMgZW5kcyBvbiBKdW5lIDEwLjxi cj4NCjxicj4NCi0tIEplZmY8YnI+DQo8YnI+DQpPbiBGcmksIEFwciAwMSwgMjAxNiBhdCAwNzoz NToxM1BNIC0wNDAwLCBTdXNhbiBIYXJlcyB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhp cyBiZWdpbnMgYSAyIHdlZWsgV0cgQWRvcHRpb24gY2FsbCBmb3I6PGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KZHJhZnQta2luaS1pMnJzLWZiLXJpYi1pbmZvLW1vZGVsLTAzPGJyPg0KPGJyPg0KZHJh ZnQtaGFyZXMtaTJycy1mYi1yaWItZGF0YS1tb2RlbC0wMzxicj4NCjxicj4NCmRyYWZ0LWhhcmVz LWkycnMtcGt0LWVjYS1kYXRhLW1vZGVsLTAyPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNl IHNlbmQgeW91ciBjb21tZW50cyBvbiB0aGUgdGVjaG5pY2FsIG1lcml0cyBhbmQgdXNlZnVsbmVz cyBvZiB0aGVzZTxicj4NCm1vZGVscy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpTdWUgJm5ic3A7 YW5kIEplZmY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQppMnJzIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmkycnMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pMnJzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmky cnMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pMnJzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LS08YnI+DQomcXVvdDtFc3RhIHZleiBubyBmYWxs YXJlbW9zLCBEb2N0b3IgSW5maWVybm8mcXVvdDs8YnI+DQo8YnI+DQpEciBEaWVnbyBSLiBMb3Bl ejxicj4NClRlbGVmb25pY2EgSSYjNDM7RDxicj4NCjxhIGhyZWY9Imh0dHA6Ly9wZW9wbGUudGlk LmVzL2RpZWdvLmxvcGV6LyI+aHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovPC9hPjxi cj4NCjxicj4NCmUtbWFpbDogPGEgaHJlZj0ibWFpbHRvOmRpZWdvLnIubG9wZXpAdGVsZWZvbmlj YS5jb20iPmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb208L2E+PGJyPg0KVGVsOiAmbmJzcDsg Jm5ic3A7JiM0MzszNCA5MTMgMTI5IDA0MTxicj4NCk1vYmlsZTogJiM0MzszNCA2ODIgMDUxIDA5 MTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1h bGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjMiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmdyYXkiPjxicj4NCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4 Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nD s24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRl IGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0 aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhDQogbGVjdHVyYSwg dXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1 ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUu IFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5v cyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2Nl ZGEgYSBzdSBkZXN0cnVjY2nDs24uPGJyPg0KPGJyPg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBk aXNzZW1pbmF0aW9uLA0KIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNh dGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRy YW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSBy ZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0 aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC48YnI+DQo8YnI+DQpFc3RhIG1lbnNhZ2Vt IGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTD oXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNp YWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rp bm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBm aWNhIG5vdGlmaWNhZG8gZGUgcXVlIGENCiBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HD p8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVt IHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdl bSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRl IHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657EA72F4dfweml501mbb_-- From nobody Tue May 24 15:04:40 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B717C12D9D5 for ; Tue, 24 May 2016 15:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFabXzcQQpxv for ; Tue, 24 May 2016 15:04:37 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4A07A12D9CA for ; Tue, 24 May 2016 15:04:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Jeffrey Haas'" , References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> In-Reply-To: <20160524161622.GK17462@pfrc.org> Date: Tue, 24 May 2016 18:04:38 -0400 Message-ID: <03ce01d1b608$43e9bb80$cbbd3280$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIkn2ewTbjJAB5VkFLwvfRSa8Kf8wK0fbzunw0toIA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 22:04:39 -0000 I support the adoption of these drafts. Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, May 24, 2016 12:16 PM To: i2rs@ietf.org Subject: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) Working Group, In the prior poll, we didn't get much in the way of input for adopting the filter-based RIB work. This work is explicitly in charter, and more importantly is *modeling* work and doesn't have to immediately deal with our protocol headaches. :-) Please respond to the list whether you would support or don't support adoption of this draft. The extended WGLC ends on June 10. -- Jeff On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote: > This begins a 2 week WG Adoption call for: > > > > draft-kini-i2rs-fb-rib-info-model-03 > > draft-hares-i2rs-fb-rib-data-model-03 > > draft-hares-i2rs-pkt-eca-data-model-02 > > > > Please send your comments on the technical merits and usefulness of > these models. > > > > Sue and Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 24 15:17:38 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A0C12B007 for ; Tue, 24 May 2016 15:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyIxUmeLMtGO for ; Tue, 24 May 2016 15:17:35 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E838812D52A for ; Tue, 24 May 2016 15:17:34 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id k23so50192977oih.0 for ; Tue, 24 May 2016 15:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pzu0DxSAZJDQJXzjXlV/f334kMhXNsTR6QMFiwAXfcE=; b=t0IYgbP8myR1EtfdggnCDlxbSU+q3/6VHdnbewfzE+UvhT2XuqcNGeZ6FJ8boHqozl sbjJ0VWaAW3qBENO7yUMlfmkyAc4XZDCUtbs/VKuN/V/eFhN+z5OE5OcwxZCPxzMvOP7 Pq3hOPpacBbQWzOlkXRv3pe+e+mzIjghD3rbxeilmr54HQZbqdK5hOdKWXjq93S1/ozh Q1BQ1nX3KnRblfslolIJ2+J6N8PpvoBye0KlZ56WuopcDAedneVaAqaTFKWhktY/5cDT JCw4rIZq8cUhe8fMoNy+Jn9KBvZaQGhiXmfN6I7P0NoJpsjIvY49J9unYMXgwk5keYXq ZnlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pzu0DxSAZJDQJXzjXlV/f334kMhXNsTR6QMFiwAXfcE=; b=YESuD2p7eEAixRVKriKPlKUkfQIxQQRYBCFjx8TeHq479s9vrxAlmYgCFmL0xKFqTs Ub62cLTcsLRDxugCQzLyjm9O6N2nFSrEty1Gy6798+UlJrJ1rftnTuZ9qHONWzYN6J0P DWB5yYqEjqz7P9ImtgJ7MHV208Ce79poGRM6GkKiTRFRthcnwaBwfZ6Med1XQ6oA1ajN Pwn3iTqsmNM5j4s07W7HTXIsRgUbp1uDNb2CAxbkl7WSMt1A+w3pxLsQ2PgUuL/yPHFJ Uvr2Xk92nmlD/iVM7lqM35MrIpObS5ZTujosC05NXGnpuEwMA5c7q8cO1DRgJmGcmuVo fNNg== X-Gm-Message-State: ALyK8tJvL34jiibkY9hf5vCPBbvWxpnH2X8lFfEjTIuq9MVXkmxSCX4dSY8hdtUq2sIYW33UmpQB6Lgu3J6obw== X-Received: by 10.157.19.124 with SMTP id q57mr338092otq.174.1464128254323; Tue, 24 May 2016 15:17:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.223.213 with HTTP; Tue, 24 May 2016 15:17:04 -0700 (PDT) In-Reply-To: <03ce01d1b608$43e9bb80$cbbd3280$@ndzh.com> References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> <03ce01d1b608$43e9bb80$cbbd3280$@ndzh.com> From: Sri Date: Tue, 24 May 2016 15:17:04 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a1141b8488134ad05339deceb Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 22:17:37 -0000 --001a1141b8488134ad05339deceb Content-Type: text/plain; charset=UTF-8 I support the adoption of these drafts. Sri On Tue, May 24, 2016 at 3:04 PM, Susan Hares wrote: > > > > I support the adoption of these drafts. > > Sue Hares > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Tuesday, May 24, 2016 12:16 PM > To: i2rs@ietf.org > Subject: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June > 10) > > Working Group, > > In the prior poll, we didn't get much in the way of input for adopting the > filter-based RIB work. This work is explicitly in charter, and more > importantly is *modeling* work and doesn't have to immediately deal with > our > protocol headaches. :-) > > Please respond to the list whether you would support or don't support > adoption of this draft. > > The extended WGLC ends on June 10. > > -- Jeff > > On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote: > > This begins a 2 week WG Adoption call for: > > > > > > > > draft-kini-i2rs-fb-rib-info-model-03 > > > > draft-hares-i2rs-fb-rib-data-model-03 > > > > draft-hares-i2rs-pkt-eca-data-model-02 > > > > > > > > Please send your comments on the technical merits and usefulness of > > these models. > > > > > > > > Sue and Jeff > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a1141b8488134ad05339deceb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the adoption of these drafts.

Sri

O= n Tue, May 24, 2016 at 3:04 PM, Susan Hares <shares@ndzh.com> wrote:
<WG hat off>
<Draft-author hat on>

I support the adoption of these drafts.

Sue Hares

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Jeffrey Haas
Sent: Tuesday, May 24, 2016 12:16 PM
To: i2rs@ietf.org
Subject: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10)

Working Group,

In the prior poll, we didn't get much in the way of input for adopting = the
filter-based RIB work.=C2=A0 This work is explicitly in charter, and more importantly is *modeling* work and doesn't have to immediately deal wit= h our
protocol headaches. :-)

Please respond to the list whether you would support or don't support adoption of this draft.

The extended WGLC ends on June 10.

-- Jeff

On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote:
> This begins a 2 week WG Adoption call for:
>
>
>
> draft-kini-i2rs-fb-rib-info-model-03
>
> draft-hares-i2rs-fb-rib-data-model-03
>
> draft-hares-i2rs-pkt-eca-data-model-02
>
>
>
> Please send your comments on the technical merits and usefulness of > these models.
>
>
>
> Sue=C2=A0 and Jeff
>

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

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

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

--001a1141b8488134ad05339deceb-- From nobody Tue May 24 19:25:39 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77FD12D5E9 for ; Tue, 24 May 2016 19:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JOYOLcQTNef for ; Tue, 24 May 2016 19:25:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92CD12D53F for ; Tue, 24 May 2016 19:25:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKR41981; Wed, 25 May 2016 02:25:32 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 25 May 2016 03:25:31 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.148]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 25 May 2016 10:25:24 +0800 From: "Zhuangyan (Yan)" To: Jeffrey Haas , "i2rs@ietf.org" Thread-Topic: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) Thread-Index: AQHRtdbtVk0irEhXHE2VQuOJ8HkV4J/I7Uuw Date: Wed, 25 May 2016 02:25:23 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785941F7F09@nkgeml513-mbx.china.huawei.com> References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> In-Reply-To: <20160524161622.GK17462@pfrc.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.41] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57450D1D.0037, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9b154f10fce851e44a7665c0b818732b Archived-At: Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 02:25:37 -0000 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGVzZSBkcmFmdHMuDQoNCkJlc3QgUmVnYXJkcywN Cg0KWWFuDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBpMnJzIFttYWlsdG86aTJycy1i b3VuY2VzQGlldGYub3JnXSC0+rHtIEplZmZyZXkgSGFhcw0Kt6LLzcqxvOQ6IDIwMTbE6jXUwjI0 yNUgOToxNg0KytW8/sjLOiBpMnJzQGlldGYub3JnDQrW98ziOiBbaTJyc10gRXh0ZW5kaW5nIFdH IGFkb3B0aW9uIGNhbGwgZm9yIEZCLVJJQiBkcmFmdHMgKGVuZGluZyBKdW5lIDEwKQ0KDQpXb3Jr aW5nIEdyb3VwLA0KDQpJbiB0aGUgcHJpb3IgcG9sbCwgd2UgZGlkbid0IGdldCBtdWNoIGluIHRo ZSB3YXkgb2YgaW5wdXQgZm9yIGFkb3B0aW5nIHRoZSBmaWx0ZXItYmFzZWQgUklCIHdvcmsuICBU aGlzIHdvcmsgaXMgZXhwbGljaXRseSBpbiBjaGFydGVyLCBhbmQgbW9yZSBpbXBvcnRhbnRseSBp cyAqbW9kZWxpbmcqIHdvcmsgYW5kIGRvZXNuJ3QgaGF2ZSB0byBpbW1lZGlhdGVseSBkZWFsIHdp dGggb3VyIHByb3RvY29sIGhlYWRhY2hlcy4gOi0pDQoNClBsZWFzZSByZXNwb25kIHRvIHRoZSBs aXN0IHdoZXRoZXIgeW91IHdvdWxkIHN1cHBvcnQgb3IgZG9uJ3Qgc3VwcG9ydCBhZG9wdGlvbiBv ZiB0aGlzIGRyYWZ0Lg0KDQpUaGUgZXh0ZW5kZWQgV0dMQyBlbmRzIG9uIEp1bmUgMTAuDQoNCi0t IEplZmYNCg0KT24gRnJpLCBBcHIgMDEsIDIwMTYgYXQgMDc6MzU6MTNQTSAtMDQwMCwgU3VzYW4g SGFyZXMgd3JvdGU6DQo+IFRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIEFkb3B0aW9uIGNhbGwgZm9y OiANCj4gDQo+ICANCj4gDQo+IGRyYWZ0LWtpbmktaTJycy1mYi1yaWItaW5mby1tb2RlbC0wMw0K PiANCj4gZHJhZnQtaGFyZXMtaTJycy1mYi1yaWItZGF0YS1tb2RlbC0wMw0KPiANCj4gZHJhZnQt aGFyZXMtaTJycy1wa3QtZWNhLWRhdGEtbW9kZWwtMDINCj4gDQo+ICANCj4gDQo+IFBsZWFzZSBz ZW5kIHlvdXIgY29tbWVudHMgb24gdGhlIHRlY2huaWNhbCBtZXJpdHMgYW5kIHVzZWZ1bG5lc3Mg b2YgDQo+IHRoZXNlIG1vZGVscy4NCj4gDQo+ICANCj4gDQo+IFN1ZSAgYW5kIEplZmYNCj4gDQoN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaTJy cyBtYWlsaW5nIGxpc3QNCj4gaTJyc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2kycnMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCmkycnMgbWFpbGluZyBsaXN0DQppMnJzQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCg== From nobody Tue May 24 20:17:44 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CEE12D0B6 for ; Tue, 24 May 2016 20:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVC8x7lQcX9v for ; Tue, 24 May 2016 20:17:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB2C12D15C for ; Tue, 24 May 2016 20:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1206; q=dns/txt; s=iport; t=1464146261; x=1465355861; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=vkBMp6a3LV3ld/o/zenhXSzjkbXed3W32e5Pvjq62B0=; b=UN+v2sDZECp/w+ewGWiZ6/PM6h9QtY6Tz0WseWQ07c1faMhx+aKy4Img sc9xUmjOWsd9cWcGKXMy61k+gwAQ+i9KG6HYp1HS22Hp7PhLchbCIdqog h2m7njTff1O6ipk1hyaR2U6IbQ3oqtxQsFavUExWn050wZ1gSK9cFpHCa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgCyGEVX/4MNJK1bgzdWK1K6BAENg?= =?us-ascii?q?XYXC4VvAoE4OBQBAQEBAQEBZSeEQwEBBAEBARobNhsLDgouJzAGAQwGAgEBiCs?= =?us-ascii?q?OxCkBAQEBAQEBAQEBAQEBAQEBAQEaBYYngXYIgk6BOYhgAQSYN44ggWmET4MJh?= =?us-ascii?q?VuPTB4BAUKCE4F2IDKKBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,362,1459814400"; d="scan'208";a="105758313" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2016 03:17:40 +0000 Received: from [10.118.87.85] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4P3HdBZ017111; Wed, 25 May 2016 03:17:40 GMT To: Jeffrey Haas , i2rs@ietf.org References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <8c958108-adb3-f1df-7968-36fc1e77929f@cisco.com> Date: Tue, 24 May 2016 23:17:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160524161622.GK17462@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 03:17:43 -0000 On 5/24/16 12:16, Jeffrey Haas wrote: > Working Group, > > In the prior poll, we didn't get much in the way of input for adopting the > filter-based RIB work. This work is explicitly in charter, and more > importantly is *modeling* work and doesn't have to immediately deal with our > protocol headaches. :-) > > Please respond to the list whether you would support or don't support > adoption of this draft. > > The extended WGLC ends on June 10. I support the adoption of these drafts. Joe > > -- Jeff > > On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote: >> This begins a 2 week WG Adoption call for: >> >> >> >> draft-kini-i2rs-fb-rib-info-model-03 >> >> draft-hares-i2rs-fb-rib-data-model-03 >> >> draft-hares-i2rs-pkt-eca-data-model-02 >> >> >> >> Please send your comments on the technical merits and usefulness of these >> models. >> >> >> >> Sue and Jeff >> > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed May 25 06:40:45 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C8F12D6B5 for ; Wed, 25 May 2016 06:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKli_T4Wik9n for ; Wed, 25 May 2016 06:40:41 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0650.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::650]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A9712DBE0 for ; Wed, 25 May 2016 06:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Yvw0oLUjA4hs2AU8J0ANrDh8+8132gWm0c9mIfgNR8w=; b=CO4FD6X89FMl02sLlbpAlfQVlxlXeWZpDnvECqqbx6Ei812EsPUgejjYOpjlec5zjtrtcWGl9xtEj1VLDELkXODht1fulYg8xA3Iq/Ft67redzQxym2asvkFbAnbA9Ls0XU3u1sDy3/k2GY+OX3pSMMnHO0anhcKJSRAdKjuz2M= Received: from DBXPR06MB623.eurprd06.prod.outlook.com (10.255.71.170) by DBXPR06MB623.eurprd06.prod.outlook.com (10.255.71.170) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 25 May 2016 13:35:36 +0000 Received: from DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.6]) by DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.6]) with mapi id 15.01.0497.022; Wed, 25 May 2016 13:35:35 +0000 From: Xufeng Liu To: Jeffrey Haas , "i2rs@ietf.org" Thread-Topic: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) Thread-Index: AQIkn2ewTbjJAB5VkFLwvfRSa8Kf8wK0fbzunw4xo2A= Date: Wed, 25 May 2016 13:35:35 +0000 Message-ID: References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> In-Reply-To: <20160524161622.GK17462@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pfrc.org; dkim=none (message not signed) header.d=none;pfrc.org; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 8248bcb9-3784-4a85-edec-08d384a173fc x-microsoft-exchange-diagnostics: 1; DBXPR06MB623; 5:1c12tVJ5Q3yjdLjTzYlr5+PO6zmElb+kmh1e7jjgSq31ejIwO2o77N+5BPmSw0Aow1YLcSBqNgrsJdEp8WExRTEpadzNvS9VtHajVFuDY/JfgLs5fBnwvdmZNn5IZrFwol2WwMochhKh90GgQJIeuw==; 24:PR6KrsKL1qlOI3TGSVo2d0HJs6S+bUPb2P4iw25e8VSXmsd5VD6qX6wM8nPTdYotzac93UX1BJY+bJRgYgb/650SLo7ECXL3b36ywg7L8YE=; 7:6rlIsbY404EW+Levz/C0U6YKrOILo3WgSbPq7o2FYs10BNRX5+YAZp+30HZK62DlF/jBqKmyFGyS15fv8Ehx2T7DvrMeMeUMFr5530OLi5gNfPBgtRPGfPCPP3vti9k003IHEUbIfC9G73mJQYhaa/zx0rXO5cyntw0pNp49q3PiykSZTqLb3asmkp8joOW3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR06MB623; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:DBXPR06MB623; BCL:0; PCL:0; RULEID:; SRVR:DBXPR06MB623; x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(377454003)(24454002)(74316001)(8936002)(586003)(5004730100002)(15975445007)(107886002)(5002640100001)(106116001)(9686002)(189998001)(19580405001)(66066001)(19580395003)(2900100001)(10400500002)(76576001)(33656002)(122556002)(87936001)(92566002)(1220700001)(3280700002)(5001770100001)(85806002)(76176999)(54356999)(8676002)(50986999)(5003600100002)(6116002)(102836003)(3846002)(2906002)(3660700001)(81166006)(2501003)(5008740100001)(86362001)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR06MB623; H:DBXPR06MB623.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2016 13:35:35.6496 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR06MB623 Archived-At: Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 13:40:43 -0000 Support. Regards, - Xufeng > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Tuesday, May 24, 2016 12:16 PM > To: i2rs@ietf.org > Subject: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June= 10) >=20 > Working Group, >=20 > In the prior poll, we didn't get much in the way of input for adopting th= e filter- > based RIB work. This work is explicitly in charter, and more importantly= is > *modeling* work and doesn't have to immediately deal with our protocol > headaches. :-) >=20 > Please respond to the list whether you would support or don't support ado= ption > of this draft. >=20 > The extended WGLC ends on June 10. >=20 > -- Jeff >=20 > On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote: > > This begins a 2 week WG Adoption call for: > > > > > > > > draft-kini-i2rs-fb-rib-info-model-03 > > > > draft-hares-i2rs-fb-rib-data-model-03 > > > > draft-hares-i2rs-pkt-eca-data-model-02 > > > > > > > > Please send your comments on the technical merits and usefulness of > > these models. > > > > > > > > Sue and Jeff > > >=20 > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 25 15:00:16 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9D612D552 for ; Wed, 25 May 2016 15:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMz555GjZ0xi for ; Wed, 25 May 2016 15:00:12 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 D6B9712D555 for ; Wed, 25 May 2016 15:00:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Jeffrey Haas'" Date: Wed, 25 May 2016 17:59:54 -0400 Message-ID: <010101d1b6d0$c51fbf60$4f5f3e20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0102_01D1B6AF.3E1439E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdG2u40tT65IQmFGQ9esZvboRFRzVw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt -- X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 22:00:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0102_01D1B6AF.3E1439E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juergen:=20 =20 Thank you for your comments on the ephemeral state. =20 =20 On Ephemeral-REQ-05, does this clarify the requirement:=20 =20 Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of objects) that have the property of being ephemeral. An object defined = as Yang module, schema tree, a schema node, submodule or components of a submodule = (derived types, groupings, data node, RPCs, actions, and notifications). =20 Any ephemeral object must be able to be identified by a yang key word.=20 =20 On Ephemeral-REQ-06, does this text restrict the definition to just requirements:=20 =20 "Ephemeral-REQ-06: Yang MUST have a way to=20 indicate in a data model that nodes have the following=20 properties: ephemeral, writable/not-writable, status/configuration, and secure/non-secure transport. =20 (If you desire examples, please see draft-hares-i2rs-protocol-strawman = for=20 potential yang syntax). " =20 On Ephemeral-REQ-07, NETCONF chairs asked for conceptual changes to = NETCONF and RESTCONF. Does change to Ephemeral-REQ-07 requirement set work for = you? If it does, I will create a similar reduction for Ephemeral-REQ-08:=20 --------- Ephemeral-REQ-07: The bundle of conceptual changes to NETCONF to = required to support the I2RS protocol are the following:=20 1) protocol version support for I2RS protocol modifications - (e.g. = I2RS version 1); 2) support ephemeral model scope indication - which indicates whether a module is ephemeral only, mixed config module (config with ephemeral), = mixed derived state (ephemeral and config),=20 =20 3) multiple message support - uses the I2RS "all or none" (ietf-i2rs-architecture, section 7.9) which is the same as the NETCONF "roll-back-on-error". =20 4) Support for the following NETCONF protocol specifications:=20 NETCONF [RFC6241],=20 yang pub-sub push [draft-ietf-netconf-yang-push],=20 Yang module library [draft-ietf-netconf-yang-library],=20 call-home support [draft-ietf-netconf-call-home],=20 zero-touch support [draft-ietf-netconf-zero-touch], and server model [draft-ietf-netconf-server-module] with=20 server module must be augmented to support mutual authentication (see details in [draft-ietf-i2rs-protocol-security-requirements] section 3.1=20 in requirements: SEC-REQ-01 to SEC-REQ-08)),=20 =20 5) Support the following encodings XML and JSON;=20 6) support the following transports : "TCP", "SSH", TLS", and = non-secure. =20 (See ietf-i2rs-protocol-security-requirements in section 3.2 in = requirements SEC-REQ-09 and SEC-REQ-11 for details). NETCONF should be able to=20 Expand for I2RS transport support is requirement as future I2RS protocol versions will support other transports.=20 =20 7) The ability to restrict insecure transports to specific portions of a data model marked as valid to transfer via an insecure protocol, =20 =20 8) ephemeral overwriting of ephemeral MUST be controlled by the = following two policy knobs (draft-ietf-i2rs-architecture, section 6.3, 6.3.1):=20 * Policy Knob 1: ephemeral configuration overwrites local = configuration (normal value: true)=20 *Policy Knob 2: update of local configuration value supersedes and overwrites the ephemeral configuration value (normal value: false)=20 =20 9) The ephemeral state overwriting a local configuration described in = 8) above is considered to be the composite of all ephemeral state values = by all clients. Some may consider this a single "pane of glass" for the ephemeral values. =20 10) The ephemeral state must support notification of write conflicts = using the priority requirements (see section 3.7 below, specifically = requirements Ephemeral-REQ-09 through Ephemeral-REQ-14). =20 =20 11) Ephemeral data stores SHOULD not require support for interactions = with writeable-running, candidate data stores, confirmed commit, and a = distinct start-up capability.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =20 =20 On Ephemeral-09, this is covered in SEC-REQ-01. Section 3.7.1 was added = as explanation. It will be moved to the protocol-security-strawman.=20 =20 On Ephemeral-09 (second instance): is an extension of SEC-REQ-07 and SEC-REQ-08. Will this change to Ephemeral-09 work for you?=20 =20 "Ephemeral-REQ-09: The data nodes MAY store I2RS client identity and not = the effective priority at the time the data node is stored. Per SEC-REQ-07 = in section 3.1 of [draft-ietf-i2rs-protocol-security-requirements], an identifier must have just one priority. Therefore, the data nodes MAY = store I2RS client identity and not the effective priority at the time the data node is stored. Priority MAY be dynamically changed by AAA protocols = and how the protocol handles the revision of a client's priority SHOULD be defined by the protocol specification as long as the collisions are = handled as described by Ephemeral-REQ-10, Ephemeral-REQ-11, and = Ephemeral-REQ-12."=20 =20 To your questions of repetition in Ephemeral-REQ-10, Ephemeral-REQ-11, Ephemeral-REQ-12: Ephemeral write collisions utilize SEC-REQ-07 which defines that an identifier MUST have only one priority. Ephemeral write collisions are related to role-based data model security (draft-ietf-i2rs-protocol-security-requirements, section 3.5), but only SEC-REQ-19 underscores the use of "one identifier with one priority" in = the use of a I2RS client by multiple applications. You may be recalling = input from the I2RS-architecture document. =20 =20 On Ephemeral-REQ-13: This requirement has an explanation that I would = like to keep because the requirement has been misunderstood repeatedly in = both groups. Since this requirement represents to summation of the = NETCONF/I2RS sessions, I prefer to keep this requirement =96 and ask the WG for = input.=20 =20 On the Pub-sub requirements:=20 I will remove all pub-sub-requirements and add the following: =20 1) Pub-Sub-REQ-01: The Subscription Service MUST support = subscriptions against ephemeral data in operational data stores, configuration data = stores or both.=20 2) Pub-Sub-REQ-02: The Subscription Service MUST support filtering = so that subscribed updates under a target node might publish only ephemeral data in operational data or configuration data, or publish both = ephemeral and operational data.=20 =20 Sue=20 =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder Sent: Tuesday, May 17, 2016 2:24 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt =20 On Tue, May 17, 2016 at 12:26:35PM -0400, Jeffrey Haas wrote: > J=FCrgen, >=20 > On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder wrote: > > I have a hard time with this document. Section 3 is labelled=20 > > requirements but it actually details solution and I disagree with a=20 > > significant number of the solution elements. >=20 > If you were to restrict your comments to the requirements labeled variously: > Ephemeral-REQ-XX > PubSub-REQ-X >=20 > do you consider the items sufficiently well described to be a=20 > requirements document? =20 Mostly: =20 - I do not understand what Ephemeral-REQ-05 is trying to say. =20 - I disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds like solution attempts (to which I do not agree). =20 =20 - I disagree with Ephemeral-REQ-07 and all of section 3.5 and subsections; this is not a requirement but an attempt to describe a solution. - I disagree with Ephemeral-REQ-08 and all of section 3.5 and subsections; this is not a requirement but an attempt to describe a solution. =20 - Has Ephemeral-REQ-09 (the first one) not been stated elsewhere already? =20 - Ephemeral-REQ-xx with xx >=3D 09 and xx <=3D 13 seem repetitions from requirements already stated elsewhere? =20 - I did not understand section 3.7.3 and I am unsure what Ephemeral-REQ-13 or more specifically whether it is different from what is already stated in the requirements. I have trouble parsing some of the sentences, e.g. =20 [...] I2RS notes multiple operations in one or more messages handling can handle errors within the set of operations in many ways. =20 - I do not understand PubSub-REQ-1; what is the difference between synchronous and asynchronous push? =20 - I may disagree with PubSub-REQ-2 but then I do not know what 'real time for notifications' means. =20 - I may disagree with PubSub-REQ-3. =20 - I do not understand what PubSub-REQ-4 means; what is a 'critical node event'? How do I decide this requirement has been met? =20 - PubSub-REQ-5 seems to mix up different issues. I do not know what a hierarchy of filters of XPATHs is. =20 - PubSub-REQ-6 is likely underspecified. =20 Overall, I do not understand why we need these additional requirements = given that we have draft-ietf-i2rs-pub-sub-requirements-08.txt. > As Sue mentioned, we can migrate solution-space discussion wholly into = > the strawman document. =20 In general, it would help me if you make an effort to reduce the number = of documents and if you make an effort to avoid document overlaps. = Sometimes less is more. =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 < http://www.jacobs-university.de/> =20 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_0102_01D1B6AF.3E1439E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Juergen:

 

Thank = you for your comments on the ephemeral state.=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0

On = Ephemeral-REQ-05, does this clarify the requirement: =

 

Ephemeral-REQ-05: The ability to add on an object = (or a hierarchy of objects) that have the property of being = ephemeral.=A0 An object defined as Yang module,

schema tree, a schema node, submodule or = components of a submodule (derived types, groupings, data node, RPCs, = actions, and notifications).=A0 =A0

Any ephemeral object must be able to be identified = by a yang key word.

 

On = Ephemeral-REQ-06, does this text restrict the definition to just = requirements:

 

"Ephemeral-REQ-06: =A0Yang MUST have a way to =

indicate in a data model that = nodes have the following

properties: ephemeral, writable/not-writable, = status/configuration,

and = secure/non-secure transport.=A0

(If you desire examples, please see = draft-hares-i2rs-protocol-strawman for

potential yang syntax).=A0 "

 

On = Ephemeral-REQ-07, =A0NETCONF chairs asked for conceptual changes to = NETCONF and RESTCONF. =A0Does change to Ephemeral-REQ-07 requirement set = work for you? If it does, I will create a similar reduction for = Ephemeral-REQ-08:

---------

Ephemeral-REQ-07: The bundle of conceptual changes = to NETCONF to required to support the I2RS protocol are the following: =

=A01) protocol version support = for I2RS protocol modifications - =A0(e.g. I2RS version = 1);

2) support ephemeral model = scope indication - which indicates whether a module is ephemeral only, = mixed config module (config with ephemeral), mixed derived state = (ephemeral and config),

 

3) = multiple message support - uses the I2RS "all or none" = (ietf-i2rs-architecture, section 7.9) which is the same as the NETCONF = "roll-back-on-error".

=A0 =A0

4) = Support for the following =A0NETCONF protocol specifications: =

=A0=A0=A0=A0=A0NETCONF [RFC6241], =

=A0=A0=A0=A0=A0yang pub-sub push = [draft-ietf-netconf-yang-push],

=A0=A0=A0=A0=A0Yang module library = [draft-ietf-netconf-yang-library],

=A0=A0=A0=A0=A0call-home support = [draft-ietf-netconf-call-home],

=A0=A0=A0=A0=A0zero-touch support = [draft-ietf-netconf-zero-touch], and

=A0=A0=A0 =A0server model = [draft-ietf-netconf-server-module] =A0with

=A0=A0=A0=A0=A0server module must be augmented to = support mutual authentication

=A0=A0=A0=A0 (see details in = [draft-ietf-i2rs-protocol-security-requirements] section 3.1 =

=A0=A0=A0=A0=A0=A0in = requirements: SEC-REQ-01 to SEC-REQ-08)),

 

5) = Support the following encodings =A0=A0XML and JSON;

6) support the following transports : = "TCP", "SSH", TLS", and non-secure.=A0 =

(See = ietf-i2rs-protocol-security-requirements in section 3.2 in requirements = SEC-REQ-09 and SEC-REQ-11 for details). =A0NETCONF should be able to =

Expand for I2RS transport support = is requirement as future I2RS protocol versions will support other = transports.

 

7) The = ability to restrict insecure transports to specific portions of a data = model marked as valid to transfer via an insecure protocol, = =A0

 

8) ephemeral overwriting of ephemeral MUST be = controlled by the following two policy knobs = (draft-ietf-i2rs-architecture, section 6.3, 6.3.1):

=A0=A0=A0* Policy Knob 1: ephemeral configuration = overwrites local configuration (normal value: true)

=A0=A0=A0*Policy Knob 2: update of local = configuration value supersedes and overwrites the ephemeral = configuration value (normal value: false)

 

9) = =A0=A0The ephemeral state overwriting a local configuration described in = 8) above =A0is considered to be the composite of all ephemeral state = values by all clients.=A0 Some may consider this a single "pane of = glass" for the ephemeral values.

 

10) = The ephemeral state must support notification of write conflicts using = the priority requirements (see section 3.7 below, specifically = requirements Ephemeral-REQ-09 through Ephemeral-REQ-14).=A0 =

 

11) Ephemeral data stores SHOULD not require = support for interactions with writeable-running, candidate data stores, = confirmed commit, and a distinct start-up capability.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

 

On Ephemeral-09, this is covered in = SEC-REQ-01.=A0 Section 3.7.1 was added as explanation.=A0 It will be = moved to the protocol-security-strawman.

 

On = Ephemeral-09 (second instance): is an extension of SEC-REQ-07 and = SEC-REQ-08.=A0=A0 Will this change to Ephemeral-09 work for you? =

 

"Ephemeral-REQ-09: The data nodes MAY store = I2RS client identity and not the effective priority at the time the data = node is stored.=A0 Per SEC-REQ-07 in section 3.1 of = [draft-ietf-i2rs-protocol-security-requirements], an identifier must = have just one priority.=A0 Therefore, the data nodes MAY store I2RS = client identity and not the effective priority at the time the data node = is stored.=A0 Priority MAY be dynamically changed by AAA protocols and = how the protocol handles the revision of a client's priority SHOULD be = defined by the protocol specification as long as the collisions are = handled as described by Ephemeral-REQ-10, Ephemeral-REQ-11, and = Ephemeral-REQ-12."

 

To = your questions of repetition in Ephemeral-REQ-10, Ephemeral-REQ-11, = Ephemeral-REQ-12: Ephemeral write collisions utilize SEC-REQ-07 = which defines that an identifier MUST have only one priority.=A0 = Ephemeral write collisions are related to role-based data model security = (draft-ietf-i2rs-protocol-security-requirements, section 3.5), but only = SEC-REQ-19 underscores the use of "one identifier with one = priority" in the use of a I2RS client by multiple applications. = =A0=A0You may be recalling input from the I2RS-architecture document. = =A0

 

On Ephemeral-REQ-13: This requirement has an = explanation that I would like to keep because the requirement has been = misunderstood repeatedly in both groups.=A0 Since this requirement = represents to summation of the NETCONF/I2RS sessions,=A0 I prefer to = keep this requirement – and ask the WG for input. =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

On the Pub-sub requirements: =

I will remove all = pub-sub-requirements and add the following:

 

1)      = Pub-Sub-REQ-01: The Subscription Service MUST = support subscriptions against ephemeral data in operational data stores, = configuration data stores or both.

2)      = Pub-Sub-REQ-02: The Subscription Service MUST = support filtering so that subscribed updates under a target node might = publish only ephemeral data in operational data or configuration data, = or publish both ephemeral and operational data.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

Sue

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder
Sent: Tuesday, May 17, 2016 2:24 PM
To: Jeffrey = Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] I-D Action: = draft-ietf-i2rs-ephemeral-state-06.txt

 

On = Tue, May 17, 2016 at 12:26:35PM -0400, Jeffrey Haas = wrote:

> = J=FCrgen,

>

> On Fri, May 06, 2016 at 09:34:45AM +0200, = Juergen Schoenwaelder wrote:

> = > I have a hard time with this document. Section 3 is labelled =

> > requirements but it = actually details solution and I disagree with a

> > significant number of the solution = elements.

>

> If you were to restrict your comments to the = requirements labeled variously:

> Ephemeral-REQ-XX

> PubSub-REQ-X

>

> do = you consider the items sufficiently well described to be a =

> requirements = document?

 

Mostly:

 

- I do = not understand what Ephemeral-REQ-05 is trying to say.

 

- I = disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds = like

=A0 solution attempts (to = which I do not agree).

 

 

- I = disagree with Ephemeral-REQ-07 and all of section 3.5 = and

=A0 subsections; this is not a = requirement but an attempt to describe a

=A0 solution.

- I = disagree with Ephemeral-REQ-08 and all of section 3.5 = and

=A0 subsections; this is not a = requirement but an attempt to describe a

=A0 solution.

 

- Has = Ephemeral-REQ-09 (the first one) not been stated = elsewhere

=A0 = already?

 

- Ephemeral-REQ-xx with xx >=3D 09 and xx = <=3D 13 seem repetitions from

=A0 requirements already stated = elsewhere?

 

- I did not understand section 3.7.3 and I am = unsure what

=A0 Ephemeral-REQ-13 = or more specifically whether it is different from

=A0 what is already stated in the requirements. I = have trouble parsing

=A0 some of = the sentences, e.g.

 

=A0=A0 = [...] I2RS notes multiple operations in one or

=A0=A0 more messages handling can handle errors = within the set of operations

=A0=A0 in many ways.

 

- I do = not understand PubSub-REQ-1; what is the difference = between

=A0 synchronous and = asynchronous push?

 

- I = may disagree with PubSub-REQ-2 but then I do not know what = 'real

=A0 time for notifications' = means.

 

- I may disagree with = PubSub-REQ-3.

 

- I do = not understand what PubSub-REQ-4 means; what is a = 'critical

=A0 node event'? How do = I decide this requirement has been met?

 

- = PubSub-REQ-5 seems to mix up different issues. I do not know what = a

=A0 hierarchy of filters of = XPATHs is.

 

- PubSub-REQ-6 is likely = underspecified.

 

Overall, I do not understand why we need these = additional requirements given that we have = draft-ietf-i2rs-pub-sub-requirements-08.txt.

> As Sue = mentioned, we can migrate solution-space discussion wholly into =

> the strawman = document.

 

In general, it would help me if you make an effort = to reduce the number of documents and if you make an effort to avoid = document overlaps. Sometimes less is more.

 

/js

 

-- =

Juergen = Schoenwaelder=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Jacobs University Bremen = gGmbH

Phone: +49 421 200 = 3587=A0=A0=A0=A0=A0=A0=A0=A0 Campus Ring 1 | 28759 Bremen | = Germany

Fax:=A0=A0 +49 421 200 = 3103=A0=A0=A0=A0=A0=A0=A0=A0 <http://www.jacobs-univers= ity.de/>

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_0102_01D1B6AF.3E1439E0-- From nobody Wed May 25 15:34:52 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A012B056 for ; Wed, 25 May 2016 15:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk4__PO-Bxb6 for ; Wed, 25 May 2016 15:34:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037CF12DE09 for ; Wed, 25 May 2016 15:33:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 538C1715; Thu, 26 May 2016 00:33:56 +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 yTa6uhZedsjN; Thu, 26 May 2016 00:33:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 May 2016 00:33:54 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 161ED2005F; Thu, 26 May 2016 00:33:54 +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 2An4qgrbWcof; Thu, 26 May 2016 00:33: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 F2AF62005E; Thu, 26 May 2016 00:33:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D57DB3AF3A9E; Thu, 26 May 2016 00:33:48 +0200 (CEST) Date: Thu, 26 May 2016 00:33:47 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160525223345.GA12545@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org References: <010101d1b6d0$c51fbf60$4f5f3e20$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <010101d1b6d0$c51fbf60$4f5f3e20$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt -- X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 22:34:50 -0000 On Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hares wrote: > Juergen: > > > > Thank you for your comments on the ephemeral state. > > > > On Ephemeral-REQ-05, does this clarify the requirement: > > > > Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of > objects) that have the property of being ephemeral. An object defined as > Yang module, > > schema tree, a schema node, submodule or components of a submodule (derived > types, groupings, data node, RPCs, actions, and notifications). I have no clue what the above sentence is trying to say. Please try to use YANG terminology. > Any ephemeral object must be able to be identified by a yang key word. Why does there have to be a YANG keyword? > On Ephemeral-REQ-06, does this text restrict the definition to just > requirements: > > > > "Ephemeral-REQ-06: Yang MUST have a way to > > indicate in a data model that nodes have the following > > properties: ephemeral, writable/not-writable, status/configuration, > > and secure/non-secure transport. > > (If you desire examples, please see draft-hares-i2rs-protocol-strawman for > > potential yang syntax). " We do have config true/false this implies writable/not-writable. I find the idea strange that a data model defines secure/non-secure transport as a property of an data model definition since it usually depends on the deployment context whether it is acceptable to carry data over a non-secure transport. > On Ephemeral-REQ-07, NETCONF chairs asked for conceptual changes to NETCONF > and RESTCONF. Does change to Ephemeral-REQ-07 requirement set work for you? > If it does, I will create a similar reduction for Ephemeral-REQ-08: > > --------- > > Ephemeral-REQ-07: The bundle of conceptual changes to NETCONF to required to > support the I2RS protocol are the following: > > 1) protocol version support for I2RS protocol modifications - (e.g. I2RS > version 1); I do not understand what this is supposed to mean since NETCONF extensions usually are identified by a capability URN. So why is there a need for something else? > 2) support ephemeral model scope indication - which indicates whether a > module is ephemeral only, mixed config module (config with ephemeral), mixed > derived state (ephemeral and config), Not sure what this means. > 3) multiple message support - uses the I2RS "all or none" > (ietf-i2rs-architecture, section 7.9) which is the same as the NETCONF > "roll-back-on-error". So what is the requirement here? > 4) Support for the following NETCONF protocol specifications: > > NETCONF [RFC6241], > > yang pub-sub push [draft-ietf-netconf-yang-push], > > Yang module library [draft-ietf-netconf-yang-library], > > call-home support [draft-ietf-netconf-call-home], > > zero-touch support [draft-ietf-netconf-zero-touch], and > > server model [draft-ietf-netconf-server-module] with Why do you list this under changes to NETCONF? > 7) The ability to restrict insecure transports to specific portions of a > data model marked as valid to transfer via an insecure protocol, See above. > 8) ephemeral overwriting of ephemeral MUST be controlled by the following > two policy knobs (draft-ietf-i2rs-architecture, section 6.3, 6.3.1): > > * Policy Knob 1: ephemeral configuration overwrites local configuration > (normal value: true) > > *Policy Knob 2: update of local configuration value supersedes and > overwrites the ephemeral configuration value (normal value: false) And if I set both to true we run into a race? I am stopping here. I do not even understand why we need yet another list of requirements that just rephrase requirements already written down in other documents. What is the goal of this exercise? /js > 9) The ephemeral state overwriting a local configuration described in 8) > above is considered to be the composite of all ephemeral state values by > all clients. Some may consider this a single "pane of glass" for the > ephemeral values. You seem to assume a certain architectural model and it is unclear whether there is agreement on this model. There is ongoing discussion about this, see for example draft-schoenw-netmod-revised-datastores-00. > 10) The ephemeral state must support notification of write conflicts using > the priority requirements (see section 3.7 below, specifically requirements > Ephemeral-REQ-09 through Ephemeral-REQ-14). > > > > 11) Ephemeral data stores SHOULD not require support for interactions with > writeable-running, candidate data stores, confirmed commit, and a distinct > start-up capability. > > > > ========== > > > > On Ephemeral-09, this is covered in SEC-REQ-01. Section 3.7.1 was added as > explanation. It will be moved to the protocol-security-strawman. > > > > On Ephemeral-09 (second instance): is an extension of SEC-REQ-07 and > SEC-REQ-08. Will this change to Ephemeral-09 work for you? > > > > "Ephemeral-REQ-09: The data nodes MAY store I2RS client identity and not the > effective priority at the time the data node is stored. Per SEC-REQ-07 in > section 3.1 of [draft-ietf-i2rs-protocol-security-requirements], an > identifier must have just one priority. Therefore, the data nodes MAY store > I2RS client identity and not the effective priority at the time the data > node is stored. Priority MAY be dynamically changed by AAA protocols and > how the protocol handles the revision of a client's priority SHOULD be > defined by the protocol specification as long as the collisions are handled > as described by Ephemeral-REQ-10, Ephemeral-REQ-11, and Ephemeral-REQ-12." > > > > To your questions of repetition in Ephemeral-REQ-10, Ephemeral-REQ-11, > Ephemeral-REQ-12: Ephemeral write collisions utilize SEC-REQ-07 which > defines that an identifier MUST have only one priority. Ephemeral write > collisions are related to role-based data model security > (draft-ietf-i2rs-protocol-security-requirements, section 3.5), but only > SEC-REQ-19 underscores the use of "one identifier with one priority" in the > use of a I2RS client by multiple applications. You may be recalling input > from the I2RS-architecture document. > > > > On Ephemeral-REQ-13: This requirement has an explanation that I would like > to keep because the requirement has been misunderstood repeatedly in both > groups. Since this requirement represents to summation of the NETCONF/I2RS > sessions, I prefer to keep this requirement – and ask the WG for input. > > > > > On the Pub-sub requirements: > > I will remove all pub-sub-requirements and add the following: > > > > 1) Pub-Sub-REQ-01: The Subscription Service MUST support subscriptions > against ephemeral data in operational data stores, configuration data stores > or both. > > 2) Pub-Sub-REQ-02: The Subscription Service MUST support filtering so > that subscribed updates under a target node might publish only ephemeral > data in operational data or configuration data, or publish both ephemeral > and operational data. > > > > > Sue > > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, May 17, 2016 2:24 PM > To: Jeffrey Haas > Cc: i2rs@ietf.org > Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt > > > > On Tue, May 17, 2016 at 12:26:35PM -0400, Jeffrey Haas wrote: > > > Jürgen, > > > > > > On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder wrote: > > > > I have a hard time with this document. Section 3 is labelled > > > > requirements but it actually details solution and I disagree with a > > > > significant number of the solution elements. > > > > > > If you were to restrict your comments to the requirements labeled > variously: > > > Ephemeral-REQ-XX > > > PubSub-REQ-X > > > > > > do you consider the items sufficiently well described to be a > > > requirements document? > > > > Mostly: > > > > - I do not understand what Ephemeral-REQ-05 is trying to say. > > > > - I disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds like > > solution attempts (to which I do not agree). > > > > > > - I disagree with Ephemeral-REQ-07 and all of section 3.5 and > > subsections; this is not a requirement but an attempt to describe a > > solution. > > - I disagree with Ephemeral-REQ-08 and all of section 3.5 and > > subsections; this is not a requirement but an attempt to describe a > > solution. > > > > - Has Ephemeral-REQ-09 (the first one) not been stated elsewhere > > already? > > > > - Ephemeral-REQ-xx with xx >= 09 and xx <= 13 seem repetitions from > > requirements already stated elsewhere? > > > > - I did not understand section 3.7.3 and I am unsure what > > Ephemeral-REQ-13 or more specifically whether it is different from > > what is already stated in the requirements. I have trouble parsing > > some of the sentences, e.g. > > > > [...] I2RS notes multiple operations in one or > > more messages handling can handle errors within the set of operations > > in many ways. > > > > - I do not understand PubSub-REQ-1; what is the difference between > > synchronous and asynchronous push? > > > > - I may disagree with PubSub-REQ-2 but then I do not know what 'real > > time for notifications' means. > > > > - I may disagree with PubSub-REQ-3. > > > > - I do not understand what PubSub-REQ-4 means; what is a 'critical > > node event'? How do I decide this requirement has been met? > > > > - PubSub-REQ-5 seems to mix up different issues. I do not know what a > > hierarchy of filters of XPATHs is. > > > > - PubSub-REQ-6 is likely underspecified. > > > > Overall, I do not understand why we need these additional requirements given > that we have draft-ietf-i2rs-pub-sub-requirements-08.txt. > > > As Sue mentioned, we can migrate solution-space discussion wholly into > > > the strawman document. > > > > In general, it would help me if you make an effort to reduce the number of > documents and if you make an effort to avoid document overlaps. Sometimes > less is more. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 < > http://www.jacobs-university.de/> > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed May 25 18:39:25 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C923612D165; Wed, 25 May 2016 18:39:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2016 18:39:21 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-07.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 01:39:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-07.txt Pages : 14 Date : 2016-05-25 Abstract: This document covers requests to the NETMOD and NETCONF Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 25 18:40:35 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B2412D1B5 for ; Wed, 25 May 2016 18:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u23OZjNVHpEf for ; Wed, 25 May 2016 18:40:30 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 496EF12B025 for ; Wed, 25 May 2016 18:40:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <010101d1b6d0$c51fbf60$4f5f3e20$@ndzh.com> <20160525223345.GA12545@elstar.local> In-Reply-To: <20160525223345.GA12545@elstar.local> Date: Wed, 25 May 2016 21:40:03 -0400 Message-ID: <01c901d1b6ef$86be9150$943bb3f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CA_01D1B6CD.FFB30BD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/JAKNkO8ofPtuVY7KY8y82XrZmwGE7LbjnuNE4pA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Mehmet Ersue' , 'Alia Atlas' , 'Mahesh Jethanandani' , 'Benoit Claise' , 'Jeffrey Haas' Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt -- X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 01:40:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01CA_01D1B6CD.FFB30BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juergen:=20 =20 Thank you for your comments and questions. I have answered the point-by-point comments below.=20 =20 The goal of the exercise was to make one more attempt to resolve your comments at the request of Alia Atlas and Benoit Claise. You are a brilliant person who has worked in NETCONF and NETMOD for several years. = I hope to continue to resolve your concerns, but perhaps you are missing = some context from I2RS work. =20 =20 At this point, I find the following things in your response:=20 1) Request for clarity on requirements (Ephemeral-REQ-05, = Ephemeral-REQ-06)=20 that were reviewed in 3 IETF meetings (IETF-93, IETF-94, and IETF-95) in which you or other NETCONF/RESTCONF/YANG individuals did not comment. = Also there were no additional questions. I welcome further discussion with = you, but I am copying the NETCONF chairs to determine if they can help you understand these requirements or provide me suggestion on a resolution = for your comments.=20 =20 2) A disconnect from the charter that of I2RS. The charter specifies protocol-independent ephemeral state only document will be done in I2RS, = and protocol-dependent ephemeral state models (or augmentations) will be = done in other WGs. This charter defines the ephemeral-only data models, and two types of mixed data models (draft-ietf-bgp-model example given below).=20 =20 3) A disconnect from the process of I2RS requirements as a re-use = protocol=20 The re-use methodology requires I2RS protocol to: =20 a) require support for I2RS protocol version number identifier that=20 identifies the support of a set of YANG, NETCONF, and RESTCONF features; b) specifying the existing Yang, NETCONF, and RESTCONF features needed = for I2RS protocol version 1 (ephemeral state, protocol security, pub/sub, = and traceability) and its security environment; and=20 c) specifying the additions to YANG, NETCONF, and RESTCONF needed for = I2RS=20 support of ephemeral state, protocol security, pub/sub and = traceability).=20 =20 To try to clarify these points, I have uploaded a -07.txt with = clarifying comments.=20 =20 https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ =20 =20 Sue Hares=20 =20 =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder Sent: Wednesday, May 25, 2016 6:34 PM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt = -- =20 On Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hares wrote: >> Juergen: =20 >> Thank you for your comments on the ephemeral state. =20 >> On Ephemeral-REQ-05, does this clarify the requirement:=20 >>=20 >> Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of >> objects) that have the property of being ephemeral. An object = defined=20 >> as Yang module,=20 >> schema tree, a schema node, submodule or components of a submodule=20 >> (derived types, groupings, data node, RPCs, actions, and = notifications). =20 >I have no clue what the above sentence is trying to say. Please try to = use YANG >terminology. =20 Let me try again:=20 =20 Ephemeral-REQ-05: The ability to augment an object with appropriate=20 Yang structures that have the property of being ephemeral. An object is defined as being one of the following: yang module, schema tree, schema node,=20 Submodule, components of a submodule (derived types, groupings,=20 data nod, RPCs, actions, and notifications). =20 The following are definitions in draft-ietf-netmod-rfc6020bis-09.txt=20 1) Yang module (p. 12) - A Yang module defines a hierarchy of schema = nodes.=20 With its definitions and the definitions it imports or includes from elsewhere, A module is self-contained and "compilable".=20 2) schema tree (p. 13) - The definition hierarchy specified within a = module. 3) schema node (p. 12) - a node in the schema tree.=20 4) submodule (p. 13) - partial module definition that contributes = derived types, groupings, data modules, RPCs, actions, and notifications to a module.=20 =20 The term "object" is defined to allow the data to augment each of these structures. Is this clearer?=20 =20 >> Any ephemeral object must be able to be identified by a yang key = word.=20 > Why does there have to be a YANG keyword? =20 Answer: There MUST be a way to writers of a data model to define = sections of a data model that are ephemeral configuration and derived state. No = one has suggested any other reasonable way to accomplish this in the last 2 years.=20 =20 > On Ephemeral-REQ-06, does this text restrict the definition to just > requirements:=20 >=20 > =20 >=20 >> "Ephemeral-REQ-06: Yang MUST have a way to=20 >> indicate in a data model that nodes have the following=20 >> properties: ephemeral, writable/not-writable, status/configuration, >> and secure/non-secure transport. =20 >> (If you desire examples, please see = draft-hares-i2rs-protocol-strawman=20 >> for potential yang syntax). " =20 >We do have config true/false this implies writable/not-writable.=20 Sue: I am glad we agree:=20 =20 >I find the idea strange that a data model defines secure/non-secure transport as >a property of an data model definition since it usually depends on the >deployment context whether it is acceptable to carry = data over a non-secure >transport. =20 Sue: The ability to utilize a non-secure transport requires: a) support for non-secure transport in protocol,=20 b) data-model definition that indicates a portion of the data model may = be passed over non-secure, and=20 c) deployment context (via local node's policy on supporting this = portion of a data model). =20 If you do not have a and b and c - then you should not send the data = over insecure channels.=20 =20 =20 >> On Ephemeral-REQ-07, NETCONF chairs asked for conceptual changes to=20 >> NETCONF and RESTCONF. Does change to Ephemeral-REQ-07 requirement >> set work for you? >> If it does, I will create a similar reduction for Ephemeral-REQ-08: =20 >> --------- >> Ephemeral-REQ-07: The bundle of conceptual changes to NETCONF to=20 >> required to support the I2RS protocol are the following: >> 1) protocol version support for I2RS protocol modifications - (e.g. = >> I2RS version 1); >I do not understand what this is supposed to mean since NETCONF = extensions=20 > usually are identified by a capability URN. So why is there a need for something > else? =20 Sue: Do these capabilities allow for grouping of the NETCONF extensions supported by a node to a specific set of extensions related to the I2RS protocol set? If not, this is the request.=20 =20 >> 2) support ephemeral model scope indication - which indicates whether = >> a module is ephemeral only, mixed config module (config with=20 >> ephemeral), mixed derived state (ephemeral and config), =20 >Not sure what this means. =20 =20 Let me give you an example: =20 a) ephemeral only data model: draft-i2rs-rib-data-model-05=20 b) mixed configuration model: draft-bgp-model-01 (sections 6.1 - 6.4) could be augmented to add ephemeral state to the configuration,=20 c) mixed derived state: draft-bgp-model-01 section 6.5 defines = operational state, and this could be augmented to add ephemeral operational within = this data model.=20 =20 I suspect this reflects back to your misunderstanding Ephemeral-REQ-05.=20 =20 >> 3) multiple message support - uses the I2RS "all or none" >> (ietf-i2rs-architecture, section 7.9) which is the same as the = NETCONF=20 >> "roll-back-on-error". =20 >So what is the requirement here? =20 Sue: The requirement is to support NETCONF "roll-back-on-error" for ephemeral state.=20 =20 >> 4) Support for the following NETCONF [RFC6241] protocol = specifications: >> yang pub-sub push [draft-ietf-netconf-yang-push], >> Yang module library [draft-ietf-netconf-yang-library], >> call-home support [draft-ietf-netconf-call-home], >> zero-touch support [draft-ietf-netconf-zero-touch], and >> server model [draft-ietf-netconf-server-module] with =20 >Why do you list this under changes to NETCONF?=20 Sue: The Ephemeral Requirements are defining a minimal set of=20 NETCONF features to be absolutely required within the I2RS protocol definition. =20 To recreate I2RS as a re-use protocol, we are defining the features that must be there to support the I2RS work. =20 =20 >> 7) The ability to restrict insecure transports to specific portions = of=20 >> a data model marked as valid to transfer via an insecure protocol, >See above. Sue: See above answer.=20 =20 >> 8) ephemeral overwriting of ephemeral MUST be controlled by the=20 >> following two policy knobs (draft-ietf-i2rs-architecture, section = 6.3, 6.3.1): >> * Policy Knob 1: ephemeral configuration overwrites local=20 >> configuration (normal value: true) >>=20 >> *Policy Knob 2: update of local configuration value supersedes and=20 >> overwrites the ephemeral configuration value (normal value: false) >And if I set both to true we run into a race? =20 Sue: No, please see draft-ietf-i2rs-architecture, section 6.3.1 with the full description.=20 =20 >I am stopping here. I do not even understand why we need yet another = list of >requirements that just rephrase requirements already written down in other >documents. What is the goal of this exercise? =20 Sue: The goal of the exercise was to try to resolve your comments on the ietf-i2rs-ephemeral-state-06.txt. I promised Alia Atlas and Benoit = Claise that I would give this discussion one more try. See above for = additional comments on the "goal of the exercise".=20 =20 /js =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 > 9) The ephemeral state overwriting a local configuration described = in 8) > above is considered to be the composite of all ephemeral state values = > by all clients. Some may consider this a single "pane of glass" for=20 > the ephemeral values. =20 You seem to assume a certain architectural model and it is unclear = whether there is agreement on this model. There is ongoing discussion about = this, see for example draft-schoenw-netmod-revised-datastores-00. =20 > 10) The ephemeral state must support notification of write conflicts=20 > using the priority requirements (see section 3.7 below, specifically=20 > requirements > Ephemeral-REQ-09 through Ephemeral-REQ-14). =20 >=20 > =20 >=20 > 11) Ephemeral data stores SHOULD not require support for interactions=20 > with writeable-running, candidate data stores, confirmed commit, and a = > distinct start-up capability. >=20 > =20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =20 >=20 > =20 >=20 > On Ephemeral-09, this is covered in SEC-REQ-01. Section 3.7.1 was=20 > added as explanation. It will be moved to the = protocol-security-strawman. >=20 > =20 >=20 > On Ephemeral-09 (second instance): is an extension of SEC-REQ-07 and > SEC-REQ-08. Will this change to Ephemeral-09 work for you?=20 >=20 > =20 >=20 > "Ephemeral-REQ-09: The data nodes MAY store I2RS client identity and=20 > not the effective priority at the time the data node is stored. Per=20 > SEC-REQ-07 in section 3.1 of=20 > [draft-ietf-i2rs-protocol-security-requirements], an identifier must=20 > have just one priority. Therefore, the data nodes MAY store I2RS=20 > client identity and not the effective priority at the time the data=20 > node is stored. Priority MAY be dynamically changed by AAA protocols=20 > and how the protocol handles the revision of a client's priority=20 > SHOULD be defined by the protocol specification as long as the = collisions are handled as described by Ephemeral-REQ-10, Ephemeral-REQ-11, and Ephemeral-REQ-12." >=20 > =20 >=20 > To your questions of repetition in Ephemeral-REQ-10, Ephemeral-REQ-11, > Ephemeral-REQ-12: Ephemeral write collisions utilize SEC-REQ-07 which=20 > defines that an identifier MUST have only one priority. Ephemeral=20 > write collisions are related to role-based data model security=20 > (draft-ietf-i2rs-protocol-security-requirements, section 3.5), but=20 > only > SEC-REQ-19 underscores the use of "one identifier with one priority" = in the > use of a I2RS client by multiple applications. You may be recalling input > from the I2RS-architecture document. =20 >=20 > =20 >=20 > On Ephemeral-REQ-13: This requirement has an explanation that I would=20 > like to keep because the requirement has been misunderstood repeatedly = > in both groups. Since this requirement represents to summation of the = > NETCONF/I2RS sessions, I prefer to keep this requirement =96 and ask = the WG for input. >=20 > =20 >=20 >=20 > On the Pub-sub requirements:=20 >=20 > I will remove all pub-sub-requirements and add the following: >=20 > =20 >=20 > 1) Pub-Sub-REQ-01: The Subscription Service MUST support subscriptions > against ephemeral data in operational data stores, configuration data=20 > stores or both. >=20 > 2) Pub-Sub-REQ-02: The Subscription Service MUST support = filtering so > that subscribed updates under a target node might publish only=20 > ephemeral data in operational data or configuration data, or publish=20 > both ephemeral and operational data. >=20 > =20 >=20 >=20 > Sue >=20 > =20 >=20 > -----Original Message----- > From: i2rs [ = mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Tuesday, May 17, 2016 2:24 PM > To: Jeffrey Haas > Cc: i2rs@ietf.org > Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt >=20 > =20 >=20 > On Tue, May 17, 2016 at 12:26:35PM -0400, Jeffrey Haas wrote: >=20 > > J=FCrgen, >=20 > >=20 >=20 > > On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder = wrote: >=20 > > > I have a hard time with this document. Section 3 is labelled >=20 > > > requirements but it actually details solution and I disagree with=20 > > > a >=20 > > > significant number of the solution elements. >=20 > >=20 >=20 > > If you were to restrict your comments to the requirements labeled > variously: >=20 > > Ephemeral-REQ-XX >=20 > > PubSub-REQ-X >=20 > >=20 >=20 > > do you consider the items sufficiently well described to be a >=20 > > requirements document? >=20 > =20 >=20 > Mostly: >=20 > =20 >=20 > - I do not understand what Ephemeral-REQ-05 is trying to say. >=20 > =20 >=20 > - I disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds like >=20 > solution attempts (to which I do not agree). >=20 > =20 >=20 > =20 >=20 > - I disagree with Ephemeral-REQ-07 and all of section 3.5 and >=20 > subsections; this is not a requirement but an attempt to describe a >=20 > solution. >=20 > - I disagree with Ephemeral-REQ-08 and all of section 3.5 and >=20 > subsections; this is not a requirement but an attempt to describe a >=20 > solution. >=20 > =20 >=20 > - Has Ephemeral-REQ-09 (the first one) not been stated elsewhere >=20 > already? >=20 > =20 >=20 > - Ephemeral-REQ-xx with xx >=3D 09 and xx <=3D 13 seem repetitions = from >=20 > requirements already stated elsewhere? >=20 > =20 >=20 > - I did not understand section 3.7.3 and I am unsure what >=20 > Ephemeral-REQ-13 or more specifically whether it is different from >=20 > what is already stated in the requirements. I have trouble parsing >=20 > some of the sentences, e.g. >=20 > =20 >=20 > [...] I2RS notes multiple operations in one or >=20 > more messages handling can handle errors within the set of=20 > operations >=20 > in many ways. >=20 > =20 >=20 > - I do not understand PubSub-REQ-1; what is the difference between >=20 > synchronous and asynchronous push? >=20 > =20 >=20 > - I may disagree with PubSub-REQ-2 but then I do not know what 'real >=20 > time for notifications' means. >=20 > =20 >=20 > - I may disagree with PubSub-REQ-3. >=20 > =20 >=20 > - I do not understand what PubSub-REQ-4 means; what is a 'critical >=20 > node event'? How do I decide this requirement has been met? >=20 > =20 >=20 > - PubSub-REQ-5 seems to mix up different issues. I do not know what a >=20 > hierarchy of filters of XPATHs is. >=20 > =20 >=20 > - PubSub-REQ-6 is likely underspecified. >=20 > =20 >=20 > Overall, I do not understand why we need these additional requirements = > given that we have draft-ietf-i2rs-pub-sub-requirements-08.txt. >=20 > > As Sue mentioned, we can migrate solution-space discussion wholly=20 > > into >=20 > > the strawman document. >=20 > =20 >=20 > In general, it would help me if you make an effort to reduce the=20 > number of documents and if you make an effort to avoid document=20 > overlaps. Sometimes less is more. >=20 > =20 >=20 > /js >=20 > =20 >=20 > -- >=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH >=20 > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >=20 > Fax: +49 421 200 3103 < < http://www.jacobs-university.de/> > http://www.jacobs-university.de/> >=20 > =20 >=20 > _______________________________________________ >=20 > i2rs mailing list >=20 > < mailto:i2rs@ietf.org> = i2rs@ietf.org >=20 > < https://www.ietf.org/mailman/listinfo/i2rs> > https://www.ietf.org/mailman/listinfo/i2rs >=20 =20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/> =20 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_01CA_01D1B6CD.FFB30BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Juergen:

 

Thank = you for your comments and questions. =A0=A0I have answered the = point-by-point comments below.

 

The = goal of the exercise was to make one more attempt to resolve your = comments at the request of Alia Atlas and Benoit Claise. =A0=A0You are a = brilliant person who has worked in NETCONF and NETMOD for several years. = =A0I hope to continue to resolve your concerns, but perhaps you are = missing some context from I2RS work. =A0

 

At = this point, I find the following things in your response: =

1) Request for clarity on = requirements (Ephemeral-REQ-05, Ephemeral-REQ-06)

that were reviewed in 3 IETF meetings (IETF-93, = IETF-94, and IETF-95) in which you or other NETCONF/RESTCONF/YANG = individuals did not comment. Also there were no additional questions. = =A0I welcome further discussion with you, but I am copying the NETCONF = chairs to determine if they can help you understand these requirements = or provide me suggestion on a resolution for your comments. =

 

2) A disconnect from the charter that of I2RS.=A0 = The charter specifies protocol-independent ephemeral state only document = will be done in I2RS, and protocol-dependent ephemeral state models (or = augmentations) will be done in other WGs. =A0This charter defines the = ephemeral-only data models, and two types of mixed data models = (draft-ietf-bgp-model example given below).

 

3) A = disconnect from the process of I2RS requirements as a re-use protocol =

The re-use =A0methodology = requires I2RS protocol to: =A0

a) = require support for I2RS protocol version number identifier that =

identifies the support of a set = of YANG, NETCONF, and RESTCONF features;

b) specifying the existing Yang, NETCONF, and = RESTCONF features needed for I2RS protocol version 1 (ephemeral state, = protocol security, pub/sub, and traceability) and its security = environment; and

c) specifying = the additions to YANG, NETCONF, and RESTCONF needed for I2RS =

support of ephemeral state, = protocol security, pub/sub and traceability).

 

To try = to clarify these points, I have uploaded a -07.txt with clarifying = comments.

 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

 

 

Sue = Hares

 

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder
Sent: Wednesday, May 25, 2016 6:34 PM
To: Susan = Hares
Cc: 'Jeffrey Haas'; i2rs@ietf.org
Subject: Re: [i2rs] I-D = Action: draft-ietf-i2rs-ephemeral-state-06.txt --

 

On = Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hares = wrote:

>> Juergen: = =A0

>> Thank you for your = comments on the ephemeral state.=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

>> On Ephemeral-REQ-05, does this clarify the = requirement:

>> 

>> Ephemeral-REQ-05: The ability to add on an = object (or a hierarchy of

>> = objects) that have the property of being ephemeral.=A0 An object defined =

>> as Yang module, =

>> schema tree, a schema = node, submodule or components of a submodule

>> (derived types, groupings, data node, = RPCs, actions, and notifications).

 

>I = have no clue what the above sentence is trying to say. Please try to use = YANG >terminology.

 

Let me try again: =

 

Ephemeral-REQ-05: The = ability to augment an object with =A0appropriate =

Yang structures that have the property of being = ephemeral. =A0An object is defined as being one of the following: = =A0yang module, schema tree, schema node,

Submodule, components = of a submodule (derived types, groupings,

data nod, RPCs, = actions, and notifications). = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

 

The following are = definitions in draft-ietf-netmod-rfc6020bis-09.txt =

1) Yang module (p. 12) - A Yang module defines a = hierarchy of schema nodes.

With its definitions = and the definitions it imports or includes from = elsewhere,

A module is self-contained and = "compilable".

2) schema tree (p. 13) = - The definition hierarchy specified within a module. =

3) schema node (p. 12) - a node in the schema = tree.

4)=A0 submodule (p. 13) - partial module = definition that contributes derived types, groupings, data modules, = RPCs, actions, and notifications to a module.

 

The term = "object" is defined to allow the data to augment each of these = structures. =A0Is this clearer?

 

>> = Any ephemeral object must be able to be identified by a yang key word. =

> Why does there have to be a = YANG keyword?

 

Answer: There MUST be a = way to writers of a data=A0 model to define sections of a data model = that are ephemeral configuration and derived state.=A0 =A0No one has = suggested any other reasonable way to accomplish this in the last 2 = years.

 

> = On Ephemeral-REQ-06, does this text restrict the definition to = just

> requirements: =

>

>=A0

> =

>> = "Ephemeral-REQ-06:=A0 Yang MUST have a way to

>> indicate in a data model that nodes have = the following

>> = properties: ephemeral, writable/not-writable, = status/configuration,

>> and = secure/non-secure transport.=A0

>> (If you desire examples, please see = draft-hares-i2rs-protocol-strawman

>> for potential yang syntax).=A0 = "

 

>We do have config true/false this implies = writable/not-writable.

Sue: I am = glad we agree:

 

>I = find the idea strange that a data model defines secure/non-secure = transport as >a property of an data model definition since it usually = depends on the >deployment context whether it is acceptable to carry = data over a non-secure >transport.

 

Sue: The ability to = utilize a non-secure transport requires:

a) support for = non-secure transport in protocol,

b) data-model = definition that indicates a portion of the data model may be passed over = non-secure, and

c) deployment context (via local node's policy on = supporting this portion of a data model). =A0

If you do not have a = and b and c - then you should not send the data over insecure channels. =

 

 

>> On Ephemeral-REQ-07,=A0 NETCONF chairs = asked for conceptual changes to

>> NETCONF and RESTCONF.=A0 Does change to = Ephemeral-REQ-07 requirement

>> set work for you?

>> If it does, I will create a similar = reduction for Ephemeral-REQ-08: =A0

>> ---------

>> Ephemeral-REQ-07: The bundle of conceptual = changes to NETCONF to

>> = required to support the I2RS protocol are the = following:

>>=A0 1) protocol = version support for I2RS protocol modifications -=A0 (e.g. =

>> I2RS version = 1);

>I do not understand what = this is supposed to mean since NETCONF extensions

> usually are identified by a capability URN. So = why is there a need for something > else?

 

Sue: Do these = capabilities allow for grouping of the NETCONF extensions supported by a = node to a specific set of extensions related to the I2RS protocol = set?=A0 =A0If not, this is the request.

 

>> 2) support ephemeral model scope = indication - which indicates whether

>> a module is ephemeral only, mixed config = module (config with

>> = ephemeral), mixed derived state (ephemeral and config),

 

>Not sure what this means.=A0

 

Let me give you an = example:=A0

a) ephemeral only data model: = draft-i2rs-rib-data-model-05

b) mixed configuration = model: =A0draft-bgp-model-01 =A0(sections 6.1 - 6.4) could be augmented = to add ephemeral state to the configuration,

c) mixed derived state: = draft-bgp-model-01 section 6.5 defines operational state, and this could = be augmented to add ephemeral operational within this data model. =

 

I suspect this reflects = back to your misunderstanding Ephemeral-REQ-05.

 

>> 3) multiple message support - uses the = I2RS "all or none"

>> (ietf-i2rs-architecture, section 7.9) = which is the same as the NETCONF

>> = "roll-back-on-error".

 

>So what is the requirement here?=A0=A0=A0 =

Sue: = The requirement is to support NETCONF "roll-back-on-error" for = ephemeral state.

=A0

>> = 4) Support for the following=A0 NETCONF [RFC6241] protocol = specifications:

>>=A0=A0=A0=A0=A0 yang pub-sub push = [draft-ietf-netconf-yang-push],

>>=A0=A0=A0=A0=A0 Yang module library = [draft-ietf-netconf-yang-library],

>>=A0=A0=A0=A0=A0 call-home support = [draft-ietf-netconf-call-home],

>>=A0=A0=A0=A0=A0 zero-touch support = [draft-ietf-netconf-zero-touch], and

>>=A0=A0=A0=A0=A0 server model = [draft-ietf-netconf-server-module]=A0 with

 

>Why do you list this under changes to NETCONF? =

Sue:=A0 The Ephemeral Requirements are defining a = minimal set of

NETCONF features to be absolutely required within = the I2RS protocol definition.=A0 =A0

To recreate I2RS as a = re-use protocol, we are defining the features that must be there to = support the I2RS work.=A0=A0

=A0=A0

>> 7) The ability to restrict insecure = transports to specific portions of

>> a data model marked as valid to transfer = via an insecure protocol,

=

>See above.

Sue: See above answer.

=A0

>> = 8) ephemeral overwriting of ephemeral MUST be controlled by the =

>> following two policy = knobs (draft-ietf-i2rs-architecture, section 6.3, = 6.3.1):

>>=A0=A0=A0 * Policy = Knob 1: ephemeral configuration overwrites local

>> configuration (normal value: = true)

>>

>>=A0 *Policy Knob 2: update of local = configuration value supersedes and

>> overwrites the ephemeral configuration = value (normal value: false)

>And if I set both to true we run into a = race?

 

Sue: No, please see = draft-ietf-i2rs-architecture, section 6.3.1 with the full description. =

 

>I am stopping here. I do not even understand = why we need yet another list of >requirements that just rephrase = requirements already written down in other >documents. What is the = goal of this exercise?

 

Sue: The goal of the = exercise was to try to resolve your comments on the = ietf-i2rs-ephemeral-state-06.txt. =A0I promised Alia Atlas and Benoit = Claise that I would give this discussion one more try. =A0=A0See above = for additional comments on the "goal of the exercise". =

 

/js

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

 

> 9)=A0=A0 The ephemeral state overwriting a = local configuration described in 8)

> above=A0 is considered to be the composite of = all ephemeral state values

> = by all clients.=A0 Some may consider this a single "pane of = glass" for

> the = ephemeral values.

 

You = seem to assume a certain architectural model and it is unclear whether = there is agreement on this model. There is ongoing discussion about = this, see for example = draft-schoenw-netmod-revised-datastores-00.

 

> = 10) The ephemeral state must support notification of write conflicts =

> using the priority = requirements (see section 3.7 below, specifically

> requirements

> Ephemeral-REQ-09 through Ephemeral-REQ-14).=A0 =

>

>=A0

> =

> 11) Ephemeral data stores = SHOULD not require support for interactions

> with writeable-running, candidate data stores, = confirmed commit, and a

> = distinct start-up capability.

> =

>=A0

>

> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

>

>=A0 =

>

> On Ephemeral-09, this is covered in = SEC-REQ-01.=A0 Section 3.7.1 was

> added as explanation.=A0 It will be moved to = the protocol-security-strawman.

>

>=A0 =

>

> On Ephemeral-09 (second instance): is an = extension of SEC-REQ-07 and

> = SEC-REQ-08.=A0=A0 Will this change to Ephemeral-09 work for you? =

>

>=A0

> =

> "Ephemeral-REQ-09: The = data nodes MAY store I2RS client identity and

> not the effective priority at the time the = data node is stored.=A0 Per

> = SEC-REQ-07 in section 3.1 of

> = [draft-ietf-i2rs-protocol-security-requirements], an identifier must =

> have just one priority.=A0 = Therefore, the data nodes MAY store I2RS

> client identity and not the effective priority = at the time the data

> node is = stored.=A0 Priority MAY be dynamically changed by AAA protocols =

> and how the protocol handles = the revision of a client's priority

> SHOULD be defined by the protocol = specification as long as the collisions are handled as described by = Ephemeral-REQ-10, Ephemeral-REQ-11, and = Ephemeral-REQ-12."

> =

>=A0

>

> To = your questions of repetition in Ephemeral-REQ-10, = Ephemeral-REQ-11,

> = Ephemeral-REQ-12: Ephemeral write collisions utilize SEC-REQ-07 which =

> defines that an identifier = MUST have only one priority.=A0 Ephemeral

> write collisions are related to role-based = data model security

> = (draft-ietf-i2rs-protocol-security-requirements, section 3.5), but =

> only

> SEC-REQ-19 underscores the use of "one = identifier with one priority" in the

> use of a I2RS client by multiple = applications.=A0=A0 You may be recalling input

> from the I2RS-architecture document.=A0 =

>

>=A0

> =

> On Ephemeral-REQ-13: This = requirement has an explanation that I would

> like to keep because the requirement has been = misunderstood repeatedly

> in = both groups.=A0 Since this requirement represents to summation of the =

> NETCONF/I2RS sessions,=A0 I = prefer to keep this requirement – and ask the WG for = input.

>

>=A0

> =

>

> On the Pub-sub requirements:

>

> I = will remove all pub-sub-requirements and add the = following:

>

>=A0

> =

> 1)=A0=A0=A0=A0=A0 = Pub-Sub-REQ-01: The Subscription Service MUST support = subscriptions

> against = ephemeral data in operational data stores, configuration data =

> stores or = both.

>

> 2)=A0=A0=A0=A0=A0 Pub-Sub-REQ-02: The = Subscription Service MUST support filtering so

> that subscribed updates under a target node = might publish only

> ephemeral = data in operational data or configuration data, or publish =

> both ephemeral and = operational data.

> =

>=A0

>

> =

> Sue

>

>=A0 =

>

> -----Original Message-----

> From: i2rs [mailto:i2rs-bounces@ietf.= org] On Behalf Of Juergen

> Schoenwaelder

> Sent: Tuesday, May 17, 2016 2:24 = PM

> To: Jeffrey = Haas

> Cc: i2rs@ietf.org<= o:p>

> Subject: Re: [i2rs] I-D = Action: draft-ietf-i2rs-ephemeral-state-06.txt

>

>=A0 =

>

> On Tue, May 17, 2016 at 12:26:35PM -0400, = Jeffrey Haas wrote:

> =

> > = J=FCrgen,

>

> >

>

> = > On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder = wrote:

>

> > > I have a hard time with this = document. Section 3 is labelled

>

> = > > requirements but it actually details solution and I disagree = with

> > > = a

>

> > > significant number of the solution = elements.

>

> >

>

> = > If you were to restrict your comments to the requirements = labeled

> = variously:

>

> > Ephemeral-REQ-XX

>

> = > PubSub-REQ-X

> =

> >

>

> = > do you consider the items sufficiently well described to be = a

>

> > requirements document?

>

>=A0 =

>

> Mostly:

>

>=A0 =

>

> - I do not understand what Ephemeral-REQ-05 is = trying to say.

> =

>=A0

>

> - = I disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds = like

>

>=A0=A0 solution attempts (to which I do not = agree).

>

>=A0

> =

>=A0

>

> - = I disagree with Ephemeral-REQ-07 and all of section 3.5 = and

>

>=A0=A0 subsections; this is not a requirement = but an attempt to describe a

> =

>=A0=A0 = solution.

>

> - I disagree with Ephemeral-REQ-08 and all of = section 3.5 and

> =

>=A0=A0 subsections; this is = not a requirement but an attempt to describe a

>

>=A0=A0 solution.

>

>=A0 =

>

> - Has Ephemeral-REQ-09 (the first one) not = been stated elsewhere

> =

>=A0=A0 = already?

>

>=A0

> =

> - Ephemeral-REQ-xx with xx = >=3D 09 and xx <=3D 13 seem repetitions from

>

>=A0=A0 requirements already stated = elsewhere?

>

>=A0

> =

> - I did not understand = section 3.7.3 and I am unsure what

>

>=A0=A0 Ephemeral-REQ-13 or more specifically = whether it is different from

> =

>=A0=A0 what is already stated = in the requirements. I have trouble parsing

>

>=A0=A0 some of the sentences, = e.g.

>

>=A0

> =

>=A0=A0=A0 [...] I2RS notes = multiple operations in one or

> =

>=A0=A0=A0 more messages = handling can handle errors within the set of

> operations

>

>=A0=A0=A0 in many ways.

>

>=A0 =

>

> - I do not understand PubSub-REQ-1; what is = the difference between

> =

>=A0=A0 synchronous and = asynchronous push?

> =

>=A0

>

> - = I may disagree with PubSub-REQ-2 but then I do not know what = 'real

>

>=A0=A0 time for notifications' = means.

>

>=A0

> =

> - I may disagree with = PubSub-REQ-3.

> =

>=A0

>

> - = I do not understand what PubSub-REQ-4 means; what is a = 'critical

>

>=A0=A0 node event'? How do I decide this = requirement has been met?

> =

>=A0

>

> - = PubSub-REQ-5 seems to mix up different issues. I do not know what = a

>

>=A0=A0 hierarchy of filters of XPATHs = is.

>

>=A0

> =

> - PubSub-REQ-6 is likely = underspecified.

> =

>=A0

>

> = Overall, I do not understand why we need these additional requirements =

> given that we have = draft-ietf-i2rs-pub-sub-requirements-08.txt.

>

> = > As Sue mentioned, we can migrate solution-space discussion wholly =

> > into

>

> = > the strawman document.

> =

>=A0

>

> In = general, it would help me if you make an effort to reduce the =

> number of documents and if = you make an effort to avoid document

> overlaps. Sometimes less is = more.

>

>=A0

> =

> /js

>

>=A0 =

>

> --

> =

> Juergen = Schoenwaelder=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Jacobs University Bremen = gGmbH

>

> Phone: +49 421 200 = 3587=A0=A0=A0=A0=A0=A0=A0=A0 Campus Ring 1 | 28759 Bremen | = Germany

>

> Fax:=A0=A0 +49 421 200 = 3103=A0=A0=A0=A0=A0=A0=A0=A0 < <http://www.jacobs-univers= ity.de/>

> http://www.jacobs-univers= ity.de/>

> =

>=A0

>

> = _______________________________________________

>

> = i2rs mailing list

> =

>=A0 <mailto:i2rs@ietf.org> i2rs@ietf.org<= o:p>

>

>=A0 <https://www.ietf.org/mail= man/listinfo/i2rs>

> https://www.ietf.org/mail= man/listinfo/i2rs

> =

 

--

Juergen = Schoenwaelder=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Jacobs University Bremen = gGmbH

Phone: +49 421 200 = 3587=A0=A0=A0=A0=A0=A0=A0=A0 Campus Ring 1 | 28759 Bremen | = Germany

Fax:=A0=A0 +49 421 200 = 3103=A0=A0=A0=A0=A0=A0=A0=A0 <http://www.jacobs-univers= ity.de/>

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_01CA_01D1B6CD.FFB30BD0-- From nobody Wed May 25 19:04:42 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E7D12D1E2 for ; Wed, 25 May 2016 19:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGBWaq-zDNdD for ; Wed, 25 May 2016 19:04:39 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6FD12D140 for ; Wed, 25 May 2016 19:04:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 005E824EA91 for ; Wed, 25 May 2016 19:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464228279; bh=F+TQjK+IxNrev3hOLduV2dnxV01/tJhmjW57n/UoFNg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nvSvvSiYJDFm+m/5wak5HptTJJxP9UommO/yBIhYQgBe8iWf+pnprYhs6utM6/5Ig AnLOBid6/2ctBe/2uKIZqaszI8kB49KD0YPOqtjaM4IgJopjPTTsyrMRzYUvhOPA8X r0bI3jtTr3GkdGLW4Ko8gIBOs/f0Cn5pqSXVkb2c= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 88D3E245C30 for ; Wed, 25 May 2016 19:04:38 -0700 (PDT) To: "i2rs@ietf.org" References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> From: Joel Halpern Message-ID: Date: Wed, 25 May 2016 22:04:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 02:04:41 -0000 Mostly, this looks very good. I find it odd and overspecified that the first requirement for netConf and Restconf is described as indicating I2RS support via the protocol version. It seems unlikely that the protocol version is the right way to represent this. And it seems that the I2RS WG should specify the need, not the mechanism used to represent it. Yours, Joel On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System of the IETF. > > Title : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-07.txt > Pages : 14 > Date : 2016-05-25 > > Abstract: > This document covers requests to the NETMOD and NETCONF Working > Groups for functionality to support the ephemeral state requirements > to implement the I2RS architecture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > I2RS From nobody Wed May 25 19:12:50 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8885612D105 for ; Wed, 25 May 2016 19:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ctJ9UyDzCKP for ; Wed, 25 May 2016 19:12:46 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E77112B00D for ; Wed, 25 May 2016 19:12:46 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id x189so64078652ywe.3 for ; Wed, 25 May 2016 19:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=QRoiEzjk75j7pcLIANZpXsWNSn+gn7qjEol0pd8YxC0=; b=oS6MCg4ZxuhSYRR7z8fo1WMbKGoZS7xGNDcVnFW2ACs077fIC0M5w52UrNvZ0uHUCQ UGEYbJB4l6LljPuBxKLv4IsxufZOOQ0YC4tksXgC2/uCCeaRSWHwWzEpjAV4e3/KGeEI pa7pYrkY5I4jTbz9lgLxfpnWDDYFIrCEj1BuBpKNmpyyDDzEv3bex4va4d0ho7jz0JcT vE+Ecsw6XnPDyuIcNLihsTGlYrIaaY5LQrr1j7n1ezRdU9c6TaIlrbtnO948tcMenDJo hW99ef1XE13ddxF6Jrx3OQ/PuMLYr2CUAXMr/JeP7aNgde9LAe+NUJZrCJ3gqoq7OEKF mjQg== 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; bh=QRoiEzjk75j7pcLIANZpXsWNSn+gn7qjEol0pd8YxC0=; b=ew3eMqJI7khbWu2AnIInH/f1JlHnVVuDpNOKNx2ZFusu1xOubQnmVytTkgUQ4Lua/7 AJNf2iV1EM+NWOoHaOOqeR84XeZCnSHDPbtpZNRuzNXFJbXDnYhVinN8x3qDGgHgE81q wSVHNPN7oGKeN5GgBkzW8fUm99mjUrp90UVtC3j5n2kiUcQ1+dwmrUa4Ql/xLmIUJu1X 52bA2JINnUb/GgAQDy6pfNKUTBFOUWTp17Fg4qc4SK13rGdOwbbZc6ITA6jQurrcrvf5 TO8O7LriIXarjVLP4twfCSaDxjqWPyg32vrE0NcdPAIwbHU0U47y7EyXRsPL3uHIPhTe ynFA== X-Gm-Message-State: ALyK8tLyTjFyA3UvuifK7B+MLG3KslR97yUBHMl0aZGHBjJZ3Wgtjcn0JFRa2aQai4noLucu0M6D73LgHVgmmQ== MIME-Version: 1.0 X-Received: by 10.129.74.86 with SMTP id x83mr4850483ywa.38.1464228765229; Wed, 25 May 2016 19:12:45 -0700 (PDT) Received: by 10.37.44.199 with HTTP; Wed, 25 May 2016 19:12:45 -0700 (PDT) In-Reply-To: <20160525223345.GA12545@elstar.local> References: <010101d1b6d0$c51fbf60$4f5f3e20$@ndzh.com> <20160525223345.GA12545@elstar.local> Date: Wed, 25 May 2016 19:12:45 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Susan Hares , Jeffrey Haas , "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=001a114c8c3a6c335f0533b55384 Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt -- X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 02:12:49 -0000 --001a114c8c3a6c335f0533b55384 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 25, 2016 at 3:33 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hares wrote: > > Juergen: > > > > > > > > Thank you for your comments on the ephemeral state. > > > > > > > > On Ephemeral-REQ-05, does this clarify the requirement: > > > > > > > > Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of > > objects) that have the property of being ephemeral. An object defined = as > > Yang module, > > > > schema tree, a schema node, submodule or components of a submodule > (derived > > types, groupings, data node, RPCs, actions, and notifications). > > I have no clue what the above sentence is trying to say. Please try to > use YANG terminology. > > > Any ephemeral object must be able to be identified by a yang key word. > > Why does there have to be a YANG keyword? > > This could be an extension and not a keyword, depending on how it is done. The extension vs. keyword debate will not be rehashed here, but there is an issue wrt/ how the data definition is interpreted by tools/protocols that do not understand the extension and just ignore it. Shared: list foo { i2rs:ephemeral true; .... } I2RS-only: i2rs:ephemeral { list foo { ... } } > > On Ephemeral-REQ-06, does this text restrict the definition to just > > requirements: > > > > > > > > "Ephemeral-REQ-06: Yang MUST have a way to > > > > indicate in a data model that nodes have the following > > > > properties: ephemeral, writable/not-writable, status/configuration, > > > > and secure/non-secure transport. > > > > (If you desire examples, please see draft-hares-i2rs-protocol-strawman > for > > > > potential yang syntax). " > > We do have config true/false this implies writable/not-writable. I > find the idea strange that a data model defines secure/non-secure > transport as a property of an data model definition since it usually > depends on the deployment context whether it is acceptable to carry > data over a non-secure transport. > > This is a very expensive feature wrt/ standards resources. First the WG has to agree that all the subtree data is OK to send in the clear under all circumstances. (Including augmenting nodes?) Then this needs to be carefully reviewed by the SECDIR and IESG. Both steps will require lots of IETF time. I agree that operators need to have the final say. This extension is the opposite of the nacm:default-deny-all extension. But it is designed to allow operators to configure access through NACM. How does an operator override the extension? And if the operator can override, why is an extension even needed? If not, then what criteria is used to decide the data is universally non-secure? Andy > > On Ephemeral-REQ-07, NETCONF chairs asked for conceptual changes to > NETCONF > > and RESTCONF. Does change to Ephemeral-REQ-07 requirement set work for > you? > > If it does, I will create a similar reduction for Ephemeral-REQ-08: > > > > --------- > > > > Ephemeral-REQ-07: The bundle of conceptual changes to NETCONF to > required to > > support the I2RS protocol are the following: > > > > 1) protocol version support for I2RS protocol modifications - (e.g. > I2RS > > version 1); > > I do not understand what this is supposed to mean since NETCONF > extensions usually are identified by a capability URN. So why is > there a need for something else? > > > 2) support ephemeral model scope indication - which indicates whether a > > module is ephemeral only, mixed config module (config with ephemeral), > mixed > > derived state (ephemeral and config), > > Not sure what this means. > > > 3) multiple message support - uses the I2RS "all or none" > > (ietf-i2rs-architecture, section 7.9) which is the same as the NETCONF > > "roll-back-on-error". > > So what is the requirement here? > > > 4) Support for the following NETCONF protocol specifications: > > > > NETCONF [RFC6241], > > > > yang pub-sub push [draft-ietf-netconf-yang-push], > > > > Yang module library [draft-ietf-netconf-yang-library], > > > > call-home support [draft-ietf-netconf-call-home], > > > > zero-touch support [draft-ietf-netconf-zero-touch], and > > > > server model [draft-ietf-netconf-server-module] with > > Why do you list this under changes to NETCONF? > > > 7) The ability to restrict insecure transports to specific portions of = a > > data model marked as valid to transfer via an insecure protocol, > > See above. > > > 8) ephemeral overwriting of ephemeral MUST be controlled by the followi= ng > > two policy knobs (draft-ietf-i2rs-architecture, section 6.3, 6.3.1): > > > > * Policy Knob 1: ephemeral configuration overwrites local > configuration > > (normal value: true) > > > > *Policy Knob 2: update of local configuration value supersedes and > > overwrites the ephemeral configuration value (normal value: false) > > And if I set both to true we run into a race? > > I am stopping here. I do not even understand why we need yet another > list of requirements that just rephrase requirements already written > down in other documents. What is the goal of this exercise? > > /js > > > 9) The ephemeral state overwriting a local configuration described in > 8) > > above is considered to be the composite of all ephemeral state values = by > > all clients. Some may consider this a single "pane of glass" for the > > ephemeral values. > > You seem to assume a certain architectural model and it is unclear whethe= r > there is agreement on this model. There is ongoing discussion about this, > see for example draft-schoenw-netmod-revised-datastores-00. > > > 10) The ephemeral state must support notification of write conflicts > using > > the priority requirements (see section 3.7 below, specifically > requirements > > Ephemeral-REQ-09 through Ephemeral-REQ-14). > > > > > > > > 11) Ephemeral data stores SHOULD not require support for interactions > with > > writeable-running, candidate data stores, confirmed commit, and a > distinct > > start-up capability. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > On Ephemeral-09, this is covered in SEC-REQ-01. Section 3.7.1 was adde= d > as > > explanation. It will be moved to the protocol-security-strawman. > > > > > > > > On Ephemeral-09 (second instance): is an extension of SEC-REQ-07 and > > SEC-REQ-08. Will this change to Ephemeral-09 work for you? > > > > > > > > "Ephemeral-REQ-09: The data nodes MAY store I2RS client identity and no= t > the > > effective priority at the time the data node is stored. Per SEC-REQ-07 > in > > section 3.1 of [draft-ietf-i2rs-protocol-security-requirements], an > > identifier must have just one priority. Therefore, the data nodes MAY > store > > I2RS client identity and not the effective priority at the time the dat= a > > node is stored. Priority MAY be dynamically changed by AAA protocols a= nd > > how the protocol handles the revision of a client's priority SHOULD be > > defined by the protocol specification as long as the collisions are > handled > > as described by Ephemeral-REQ-10, Ephemeral-REQ-11, and > Ephemeral-REQ-12." > > > > > > > > To your questions of repetition in Ephemeral-REQ-10, Ephemeral-REQ-11, > > Ephemeral-REQ-12: Ephemeral write collisions utilize SEC-REQ-07 which > > defines that an identifier MUST have only one priority. Ephemeral writ= e > > collisions are related to role-based data model security > > (draft-ietf-i2rs-protocol-security-requirements, section 3.5), but only > > SEC-REQ-19 underscores the use of "one identifier with one priority" in > the > > use of a I2RS client by multiple applications. You may be recalling > input > > from the I2RS-architecture document. > > > > > > > > On Ephemeral-REQ-13: This requirement has an explanation that I would > like > > to keep because the requirement has been misunderstood repeatedly in bo= th > > groups. Since this requirement represents to summation of the > NETCONF/I2RS > > sessions, I prefer to keep this requirement =E2=80=93 and ask the WG f= or input. > > > > > > > > > > On the Pub-sub requirements: > > > > I will remove all pub-sub-requirements and add the following: > > > > > > > > 1) Pub-Sub-REQ-01: The Subscription Service MUST support > subscriptions > > against ephemeral data in operational data stores, configuration data > stores > > or both. > > > > 2) Pub-Sub-REQ-02: The Subscription Service MUST support filtering > so > > that subscribed updates under a target node might publish only ephemera= l > > data in operational data or configuration data, or publish both ephemer= al > > and operational data. > > > > > > > > > > Sue > > > > > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > > Sent: Tuesday, May 17, 2016 2:24 PM > > To: Jeffrey Haas > > Cc: i2rs@ietf.org > > Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt > > > > > > > > On Tue, May 17, 2016 at 12:26:35PM -0400, Jeffrey Haas wrote: > > > > > J=C3=BCrgen, > > > > > > > > > > On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder wrote= : > > > > > > I have a hard time with this document. Section 3 is labelled > > > > > > requirements but it actually details solution and I disagree with a > > > > > > significant number of the solution elements. > > > > > > > > > > If you were to restrict your comments to the requirements labeled > > variously: > > > > > Ephemeral-REQ-XX > > > > > PubSub-REQ-X > > > > > > > > > > do you consider the items sufficiently well described to be a > > > > > requirements document? > > > > > > > > Mostly: > > > > > > > > - I do not understand what Ephemeral-REQ-05 is trying to say. > > > > > > > > - I disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds like > > > > solution attempts (to which I do not agree). > > > > > > > > > > > > - I disagree with Ephemeral-REQ-07 and all of section 3.5 and > > > > subsections; this is not a requirement but an attempt to describe a > > > > solution. > > > > - I disagree with Ephemeral-REQ-08 and all of section 3.5 and > > > > subsections; this is not a requirement but an attempt to describe a > > > > solution. > > > > > > > > - Has Ephemeral-REQ-09 (the first one) not been stated elsewhere > > > > already? > > > > > > > > - Ephemeral-REQ-xx with xx >=3D 09 and xx <=3D 13 seem repetitions from > > > > requirements already stated elsewhere? > > > > > > > > - I did not understand section 3.7.3 and I am unsure what > > > > Ephemeral-REQ-13 or more specifically whether it is different from > > > > what is already stated in the requirements. I have trouble parsing > > > > some of the sentences, e.g. > > > > > > > > [...] I2RS notes multiple operations in one or > > > > more messages handling can handle errors within the set of operation= s > > > > in many ways. > > > > > > > > - I do not understand PubSub-REQ-1; what is the difference between > > > > synchronous and asynchronous push? > > > > > > > > - I may disagree with PubSub-REQ-2 but then I do not know what 'real > > > > time for notifications' means. > > > > > > > > - I may disagree with PubSub-REQ-3. > > > > > > > > - I do not understand what PubSub-REQ-4 means; what is a 'critical > > > > node event'? How do I decide this requirement has been met? > > > > > > > > - PubSub-REQ-5 seems to mix up different issues. I do not know what a > > > > hierarchy of filters of XPATHs is. > > > > > > > > - PubSub-REQ-6 is likely underspecified. > > > > > > > > Overall, I do not understand why we need these additional requirements > given > > that we have draft-ietf-i2rs-pub-sub-requirements-08.txt. > > > > > As Sue mentioned, we can migrate solution-space discussion wholly int= o > > > > > the strawman document. > > > > > > > > In general, it would help me if you make an effort to reduce the number > of > > documents and if you make an effort to avoid document overlaps. Sometim= es > > less is more. > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > Fax: +49 421 200 3103 < > > http://www.jacobs-university.de/> > > > > > > > > _______________________________________________ > > > > i2rs mailing list > > > > i2rs@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a114c8c3a6c335f0533b55384 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 25, 2016 at 3:33 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hare= s wrote:
> Juergen:
>
>
>
> Thank you for your comments on the ephemeral state.
>
>
>
> On Ephemeral-REQ-05, does this clarify the requirement:
>
>
>
> Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of > objects) that have the property of being ephemeral.=C2=A0 An object de= fined as
> Yang module,
>
> schema tree, a schema node, submodule or components of a submodule (de= rived
> types, groupings, data node, RPCs, actions, and notifications).

I have no clue what the above sentence is trying to say. Please try to
use YANG terminology.

> Any ephemeral object must be able to be identified by a yang key word.=

Why does there have to be a YANG keyword?



This could be an extens= ion and not a keyword, depending on how it is done.
The extension= vs. keyword debate will not be rehashed here, but there is
an is= sue wrt/ how the data definition is interpreted by tools/protocols
that do not understand the extension and just ignore it.

Shared:

=C2=A0 =C2=A0list foo {
=C2=A0 =C2=A0 =C2=A0 i2rs:ephemeral true;
=C2=A0 =C2=A0 =C2=A0 .= ...
=C2=A0 =C2=A0 }

I2RS-only:

=C2=A0 =C2=A0i2rs:ephemeral {
=C2=A0 =C2=A0 =C2= =A0 list foo { =C2=A0... }
=C2=A0 =C2=A0}

=C2=A0
> On Ephemeral-REQ-06, does this text restrict the definition to just > requirements:
>
>
>
> "Ephemeral-REQ-06:=C2=A0 Yang MUST have a way to
>
> indicate in a data model that nodes have the following
>
> properties: ephemeral, writable/not-writable, status/configuration, >
> and secure/non-secure transport.
>
> (If you desire examples, please see draft-hares-i2rs-protocol-strawman= for
>
> potential yang syntax).=C2=A0 "

We do have config true/false this implies writable/not-writable. I
find the idea strange that a data model defines secure/non-secure
transport as a property of an data model definition since it usually
depends on the deployment context whether it is acceptable to carry
data over a non-secure transport.



This is a very expensiv= e feature wrt/ standards resources.
First the WG has to agree tha= t all the subtree data is OK to send in the clear
under all circu= mstances. (Including augmenting nodes?) =C2=A0Then this needs to be
carefully reviewed by the SECDIR and IESG.=C2=A0 Both steps will require= lots of IETF time.

I agree that operators need to= have the final say.
This extension is the opposite of the nacm:d= efault-deny-all extension.
But it is designed to allow operators = to configure access through NACM.
How does an operator override t= he extension?
And if the operator can override, why is an extensi= on even needed?
If not, then what criteria is used to decide the = data is universally non-secure?


And= y


=C2=A0
> On Ephemeral-REQ-07,=C2=A0 NETCONF chairs asked for conceptual changes= to NETCONF
> and RESTCONF.=C2=A0 Does change to Ephemeral-REQ-07 requirement set wo= rk for you?
> If it does, I will create a similar reduction for Ephemeral-REQ-08: >
> ---------
>
> Ephemeral-REQ-07: The bundle of conceptual changes to NETCONF to requi= red to
> support the I2RS protocol are the following:
>
>=C2=A0 1) protocol version support for I2RS protocol modifications -=C2= =A0 (e.g. I2RS
> version 1);

I do not understand what this is supposed to mean since NETCONF
extensions usually are identified by a capability URN. So why is
there a need for something else?

> 2) support ephemeral model scope indication - which indicates whether = a
> module is ephemeral only, mixed config module (config with ephemeral),= mixed
> derived state (ephemeral and config),

Not sure what this means.

> 3) multiple message support - uses the I2RS "all or none" > (ietf-i2rs-architecture, section 7.9) which is the same as the NETCONF=
> "roll-back-on-error".

So what is the requirement here?

> 4) Support for the following=C2=A0 NETCONF protocol specifications: >
>=C2=A0 =C2=A0 =C2=A0 NETCONF [RFC6241],
>
>=C2=A0 =C2=A0 =C2=A0 yang pub-sub push [draft-ietf-netconf-yang-push],<= br> >
>=C2=A0 =C2=A0 =C2=A0 Yang module library [draft-ietf-netconf-yang-libra= ry],
>
>=C2=A0 =C2=A0 =C2=A0 call-home support [draft-ietf-netconf-call-home],<= br> >
>=C2=A0 =C2=A0 =C2=A0 zero-touch support [draft-ietf-netconf-zero-touch]= , and
>
>=C2=A0 =C2=A0 =C2=A0 server model [draft-ietf-netconf-server-module]=C2= =A0 with

Why do you list this under changes to NETCONF?

> 7) The ability to restrict insecure transports to specific portions of= a
> data model marked as valid to transfer via an insecure protocol,

See above.

> 8) ephemeral overwriting of ephemeral MUST be controlled by the follow= ing
> two policy knobs (draft-ietf-i2rs-architecture, section 6.3, 6.3.1): >
>=C2=A0 =C2=A0 * Policy Knob 1: ephemeral configuration overwrites local= configuration
> (normal value: true)
>
>=C2=A0 =C2=A0 *Policy Knob 2: update of local configuration value super= sedes and
> overwrites the ephemeral configuration value (normal value: false)

And if I set both to true we run into a race?

I am stopping here. I do not even understand why we need yet another
list of requirements that just rephrase requirements already written
down in other documents. What is the goal of this exercise?

/js

> 9)=C2=A0 =C2=A0The ephemeral state overwriting a local configuration d= escribed in 8)
> above=C2=A0 is considered to be the composite of all ephemeral state v= alues by
> all clients.=C2=A0 Some may consider this a single "pane of glass= " for the
> ephemeral values.

You seem to assume a certain architectural model and it is unclear whether<= br> there is agreement on this model. There is ongoing discussion about this, see for example draft-schoenw-netmod-revised-datastores-00.

> 10) The ephemeral state must support notification of write conflicts u= sing
> the priority requirements (see section 3.7 below, specifically require= ments
> Ephemeral-REQ-09 through Ephemeral-REQ-14).
>
>
>
> 11) Ephemeral data stores SHOULD not require support for interactions = with
> writeable-running, candidate data stores, confirmed commit, and a dist= inct
> start-up capability.
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
> On Ephemeral-09, this is covered in SEC-REQ-01.=C2=A0 Section 3.7.1 wa= s added as
> explanation.=C2=A0 It will be moved to the protocol-security-strawman.=
>
>
>
> On Ephemeral-09 (second instance): is an extension of SEC-REQ-07 and > SEC-REQ-08.=C2=A0 =C2=A0Will this change to Ephemeral-09 work for you?=
>
>
>
> "Ephemeral-REQ-09: The data nodes MAY store I2RS client identity = and not the
> effective priority at the time the data node is stored.=C2=A0 Per SEC-= REQ-07 in
> section 3.1 of [draft-ietf-i2rs-protocol-security-requirements], an > identifier must have just one priority.=C2=A0 Therefore, the data node= s MAY store
> I2RS client identity and not the effective priority at the time the da= ta
> node is stored.=C2=A0 Priority MAY be dynamically changed by AAA proto= cols and
> how the protocol handles the revision of a client's priority SHOUL= D be
> defined by the protocol specification as long as the collisions are ha= ndled
> as described by Ephemeral-REQ-10, Ephemeral-REQ-11, and Ephemeral-REQ-= 12."
>
>
>
> To your questions of repetition in Ephemeral-REQ-10, Ephemeral-REQ-11,=
> Ephemeral-REQ-12: Ephemeral write collisions utilize SEC-REQ-07 which<= br> > defines that an identifier MUST have only one priority.=C2=A0 Ephemera= l write
> collisions are related to role-based data model security
> (draft-ietf-i2rs-protocol-security-requirements, section 3.5), but onl= y
> SEC-REQ-19 underscores the use of "one identifier with one priori= ty" in the
> use of a I2RS client by multiple applications.=C2=A0 =C2=A0You may be = recalling input
> from the I2RS-architecture document.
>
>
>
> On Ephemeral-REQ-13: This requirement has an explanation that I would = like
> to keep because the requirement has been misunderstood repeatedly in b= oth
> groups.=C2=A0 Since this requirement represents to summation of the NE= TCONF/I2RS
> sessions,=C2=A0 I prefer to keep this requirement =E2=80=93 and ask th= e WG for input.
>
>
>
>
> On the Pub-sub requirements:
>
> I will remove all pub-sub-requirements and add the following:
>
>
>
> 1)=C2=A0 =C2=A0 =C2=A0 Pub-Sub-REQ-01: The Subscription Service MUST s= upport subscriptions
> against ephemeral data in operational data stores, configuration data = stores
> or both.
>
> 2)=C2=A0 =C2=A0 =C2=A0 Pub-Sub-REQ-02: The Subscription Service MUST s= upport filtering so
> that subscribed updates under a target node might publish only ephemer= al
> data in operational data or configuration data, or publish both epheme= ral
> and operational data.
>
>
>
>
> Sue
>
>
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounc= es@ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, May 17, 2016 2:24 PM
> To: Jeffrey Haas
> Cc: i2rs@ietf.org
> Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt=
>
>
>
> On Tue, May 17, 2016 at 12:26:35PM -0400, Jeffrey Haas wrote:
>
> > J=C3=BCrgen,
>
> >
>
> > On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder w= rote:
>
> > > I have a hard time with this document. Section 3 is labelled=
>
> > > requirements but it actually details solution and I disagree= with a
>
> > > significant number of the solution elements.
>
> >
>
> > If you were to restrict your comments to the requirements labeled=
> variously:
>
> > Ephemeral-REQ-XX
>
> > PubSub-REQ-X
>
> >
>
> > do you consider the items sufficiently well described to be a
>
> > requirements document?
>
>
>
> Mostly:
>
>
>
> - I do not understand what Ephemeral-REQ-05 is trying to say.
>
>
>
> - I disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds like >
>=C2=A0 =C2=A0solution attempts (to which I do not agree).
>
>
>
>
>
> - I disagree with Ephemeral-REQ-07 and all of section 3.5 and
>
>=C2=A0 =C2=A0subsections; this is not a requirement but an attempt to d= escribe a
>
>=C2=A0 =C2=A0solution.
>
> - I disagree with Ephemeral-REQ-08 and all of section 3.5 and
>
>=C2=A0 =C2=A0subsections; this is not a requirement but an attempt to d= escribe a
>
>=C2=A0 =C2=A0solution.
>
>
>
> - Has Ephemeral-REQ-09 (the first one) not been stated elsewhere
>
>=C2=A0 =C2=A0already?
>
>
>
> - Ephemeral-REQ-xx with xx >=3D 09 and xx <=3D 13 seem repetitio= ns from
>
>=C2=A0 =C2=A0requirements already stated elsewhere?
>
>
>
> - I did not understand section 3.7.3 and I am unsure what
>
>=C2=A0 =C2=A0Ephemeral-REQ-13 or more specifically whether it is differ= ent from
>
>=C2=A0 =C2=A0what is already stated in the requirements. I have trouble= parsing
>
>=C2=A0 =C2=A0some of the sentences, e.g.
>
>
>
>=C2=A0 =C2=A0 [...] I2RS notes multiple operations in one or
>
>=C2=A0 =C2=A0 more messages handling can handle errors within the set o= f operations
>
>=C2=A0 =C2=A0 in many ways.
>
>
>
> - I do not understand PubSub-REQ-1; what is the difference between
>
>=C2=A0 =C2=A0synchronous and asynchronous push?
>
>
>
> - I may disagree with PubSub-REQ-2 but then I do not know what 're= al
>
>=C2=A0 =C2=A0time for notifications' means.
>
>
>
> - I may disagree with PubSub-REQ-3.
>
>
>
> - I do not understand what PubSub-REQ-4 means; what is a 'critical=
>
>=C2=A0 =C2=A0node event'? How do I decide this requirement has been= met?
>
>
>
> - PubSub-REQ-5 seems to mix up different issues. I do not know what a<= br> >
>=C2=A0 =C2=A0hierarchy of filters of XPATHs is.
>
>
>
> - PubSub-REQ-6 is likely underspecified.
>
>
>
> Overall, I do not understand why we need these additional requirements= given
> that we have draft-ietf-i2rs-pub-sub-requirements-08.txt.
>
> > As Sue mentioned, we can migrate solution-space discussion wholly= into
>
> > the strawman document.
>
>
>
> In general, it would help me if you make an effort to reduce the numbe= r of
> documents and if you make an effort to avoid document overlaps. Someti= mes
> less is more.
>
>
>
> /js
>
>
>
> --
>
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
>
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
>
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ; <http://www.jacobs-university.de/>
> http://www.jacobs-university.de/>
>
>
>
> _______________________________________________
>
> i2rs mailing list
>
>=C2=A0 <mailto:i2rs@ietf.org>= ; i2rs@ietf.org
>
>=C2=A0 <https://www.ietf.org/mailman/listinfo/i2r= s>
> https://www.ietf.org/mailman/listinfo/i2rs
>

--
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/>

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

--001a114c8c3a6c335f0533b55384-- From nobody Wed May 25 20:17:17 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DEB12D53F for ; Wed, 25 May 2016 20:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq6ixfzZb4Sd for ; Wed, 25 May 2016 20:17:14 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65BB12D539 for ; Wed, 25 May 2016 20:17:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CF270240E13 for ; Wed, 25 May 2016 20:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464232634; bh=FRvDuTC7XYomCBLHOu538aguPJUDSrQnQYdE+kJrlQc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lJcSvzX9P3MdEOLlEkQQ7bJpbv/ZtRG2WPr95mmdzoVo+yNXtXqu8oJlWX3uGZ+R+ vZHETEfeSaK8iHzUqe3Fiu757BS9nxKUhJedtEc20KBScGSI4K1MX/lEoipoDMou/G UHfCIjNoZ5959Nqzz7GKVyx/naYjBcj/2ahuVLY8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 76F932404B4 for ; Wed, 25 May 2016 20:17:14 -0700 (PDT) To: "i2rs@ietf.org" References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> From: Joel Halpern Message-ID: <1d33bfff-bd6c-f376-8c9c-aef611670311@joelhalpern.com> Date: Wed, 25 May 2016 23:17:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node transport security X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 03:17:16 -0000 While I agree with the overall requirement that I2RS support both secured and unsecured communication, I find Ephemeral-REQ-06 rather odd. Trying to have the module designer specify whether the usage of a node (get, set, ...?) must be via a secure or unsecure transport seems a very odd placement of the control. Why are we mandating this on a per-node level? Thank you, Joel On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System of the IETF. > > Title : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-07.txt > Pages : 14 > Date : 2016-05-25 > > Abstract: > This document covers requests to the NETMOD and NETCONF Working > Groups for functionality to support the ephemeral state requirements > to implement the I2RS architecture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Thu May 26 09:55:48 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7D912D671 for ; Thu, 26 May 2016 09:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIoXGo_43YU3 for ; Thu, 26 May 2016 09:55:46 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 2AB5712D0F3 for ; Thu, 26 May 2016 09:55:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Joel Halpern'" , References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 26 May 2016 12:55:39 -0400 Message-ID: <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWZbgrR/rETZCVhEoXYOsiMgM15wIlr7gon7DjJGA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 16:55:48 -0000 Joel: I2RS protocol as a re-use protocol is specifying a set of changes to NETCONF or RESTCONF. We have two ways it can be identified: 1) Implementations can "value" (I2RS protocol version) to query that indicates the NETCONF implementation or the RESTCONF implementation provides all the features requested by I2RS protocol requirements. 2) Implementations query the NETCONF implementation or the RESTCONF implementation supports all the features required for the I2RS protocol. It seemed reasonable to me to specify that NETCONF or RESTCONF set-up a value that implementations can query to indicate it supports I2RS protocol requirements. Did you have a better way to do this? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Wednesday, May 25, 2016 10:04 PM To: i2rs@ietf.org Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification Mostly, this looks very good. I find it odd and overspecified that the first requirement for netConf and Restconf is described as indicating I2RS support via the protocol version. It seems unlikely that the protocol version is the right way to represent this. And it seems that the I2RS WG should specify the need, not the mechanism used to represent it. Yours, Joel On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System of the IETF. > > Title : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-07.txt > Pages : 14 > Date : 2016-05-25 > > Abstract: > This document covers requests to the NETMOD and NETCONF Working > Groups for functionality to support the ephemeral state requirements > to implement the I2RS architecture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > I2RS _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 26 10:09:08 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED1B12D7B7 for ; Thu, 26 May 2016 10:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUvwy80zvzgW for ; Thu, 26 May 2016 10:09:04 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 B1A7312D7C1 for ; Thu, 26 May 2016 10:09:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Joel Halpern'" , References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <1d33bfff-bd6c-f376-8c9c-aef611670311@joelhalpern.com> In-Reply-To: <1d33bfff-bd6c-f376-8c9c-aef611670311@joelhalpern.com> Date: Thu, 26 May 2016 13:08:57 -0400 Message-ID: <03fe01d1b771$4ac13ae0$e043b0a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWZbgrR/rETZCVhEoXYOsiMgM15wKIt/qen63PRFA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node transport security X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:09:05 -0000 Joel: The purpose of allowing a non-security transport was to report status or telemetry information. This information may be in a specific model, or a portion of a model. While nodes may be too small an area, can you suggest alternate wording here? Please look at Ephemeral-REQ-05 for context of the use of "object" Sue ----------- Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that nodes have the following properties: ephemeral, writable/not- writable, status/configuration, and secure/non-secure transport. (If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for potential yang syntax). Ephemeral-REQ-05: The ability to augment an object with appropriate YANG structures that have the property of being ephemeral. An object defined as Yang module, schema tree, a schema node, submodule or components of a submodule (derived types, groupings, data node, RPCs, actions, and notifications". -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Wednesday, May 25, 2016 11:17 PM To: i2rs@ietf.org Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node transport security While I agree with the overall requirement that I2RS support both secured and unsecured communication, I find Ephemeral-REQ-06 rather odd. Trying to have the module designer specify whether the usage of a node (get, set, ...?) must be via a secure or unsecure transport seems a very odd placement of the control. Why are we mandating this on a per-node level? Thank you, Joel On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System of the IETF. > > Title : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-07.txt > Pages : 14 > Date : 2016-05-25 > > Abstract: > This document covers requests to the NETMOD and NETCONF Working > Groups for functionality to support the ephemeral state requirements > to implement the I2RS architecture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 26 10:21:56 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0375112D78B for ; Thu, 26 May 2016 10:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAK3kDwj5so8 for ; Thu, 26 May 2016 10:21:51 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 C39D312D7CB for ; Thu, 26 May 2016 10:21:41 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Zhangxian \(Xian\)'" , , , "'Dongjie \(Jimmy\)'" References: In-Reply-To: Date: Thu, 26 May 2016 13:21:30 -0400 Message-ID: <040901d1b773$0b25be40$21713ac0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFOOsXOiL4AmCi0KcVH2q9aO8IHQaDSZx3g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Henning Rogge' Subject: Re: [i2rs] FW: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l2-network-topology X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:21:53 -0000 Henning:=20 Thank you for reviewing draft-ietf-i2rs-yang-l2-netconf-topology. Jie = Dong will be getting back to you shortly.=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Zhangxian (Xian) Sent: Wednesday, May 18, 2016 4:51 AM To: draft-ietf-i2rs-yang-l2-network-topology@tools.ietf.org; = i2rs@ietf.org Cc: Henning Rogge; Susan Hares Subject: [i2rs] FW: [RTG-DIR] Routing directorate QA review of = draft-ietf-i2rs-yang-l2-network-topology To get the attention of draft authors and the WG to the following = review/comments.=20 Thank Henning for the constructive comments.=20 Cheers, Xian -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Henning = Rogge Sent: 2016=E5=B9=B45=E6=9C=8817=E6=97=A5 15:07 To: Zhangxian (Xian); jonathan.hardwick@metaswitch.com; = jon.hudson@gmail.com; shares@ndzh.com >> Susan Hares Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] Routing directorate QA review of = draft-ietf-i2rs-yang-l2-network-topology Hi, I have been asked to provide a review to the following document to the = routing directorate mailing list. Please be aware that this is the first time I work with YANG and related = drafts. Document: draft-ietf-i2rs-yang-l2-network-topology-02 Reviewer: Henning Rogge Review Date: Mai 16th, 2016 Intended Status: Standards Track The data structure suggested by the draft is reasonable and would fit=20 most Layer2 network technologies. I have a couple of points on the draft = document which might be worth looking into: * The introduction in=20 https://tools.ietf.org/html/draft-ietf-i2rs-yang-l2-network-topology-02=20 includes a link to "I-D.ietf-netmod-rfc6020bis" that links back to the=20 draft document itself. Maybe some links in the document refer to an=20 older name of the draft? * the "termination-point" element only contains the types "ethernet" and = "legacy" (which does not contain any data like mac-address). Is this=20 reasonable or should a few data elements moved from the "ethernet"=20 category to the "l2-termination-point-attributes" category? * there are different types of VLAN tags be used... should there be=20 another field ("vlan-type" ?) to announce 802.1ad QinQ usage? I think=20 the 802.1ad tag is also sometimes also used to move VLAN over a switch=20 that doesn't support it (unknown Ethertypes are usually just ignored),=20 which means just knowing the VLAN-id is not enough to reach the = endpoint. * the type of ethernet (100, 1000, 10000) or data-rate could be an=20 important attribute for an ethernet termination point, not only for = links. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 26 10:42:37 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8B812D7EB for ; Thu, 26 May 2016 10:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF3hvYpwGV1c for ; Thu, 26 May 2016 10:42:34 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924EC12D7E2 for ; Thu, 26 May 2016 10:42:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7972E24EA94; Thu, 26 May 2016 10:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464284554; bh=HMpmCcfe0RurnCLUC7l1LN5geGfaxSlsHTtBwTgVml8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GVU50jKgjrsdYschqhYzAAjFUw/bzKYzDQDD/aIDa9fQemGBm/jpinrXLqF4VLX2f BlLFflSWbKkgEjh+m7yUoQR8krxrMNdG++3R/EYGSJSVK46AHz/SxdA0nucHM5NIkv RhwWOEJNlOehwRVMNXSunXpuR+tsfrB6YrbE9Bp4= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id EE272247557; Thu, 26 May 2016 10:42:33 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com> From: "Joel M. Halpern" Message-ID: <85ce0bf3-3e2e-23e6-4e14-5ed4bc423a18@joelhalpern.com> Date: Thu, 26 May 2016 13:42:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:42:36 -0000 First, I would prefer that we express our requirements, and let the protocol developers determine what is the best way of meeting those requirements. That is what I want when I receive requirements, so I try to meet that standard when I send them. As for a proposed mechanism, I would again separate pieces. The I12RS Client needs to know if certain capabilities are present. These include support for specific models (already present in netConf), support for specific additional capabilities such as Ephemeral handling, and support for the attribution mechanisms. There may be others. Depending upon how these needs are met, there are multiple ways to indicate these capabilities within the NetConf and YANG framework. Further, and part of the reason for my concerns, is that I would want to know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a future YANG 1.2 or 2.0. Without having to change the I2RS "protocol" indication. If we were really in a situation where I2RS support was a fork from the base protocols, then a protocol version would be appropriate. That situation would be extremely unfortunate. I believe we are avoiding that. yours, Joel On 5/26/16 12:55 PM, Susan Hares wrote: > Joel: > > I2RS protocol as a re-use protocol is specifying a set of changes to NETCONF > or RESTCONF. We have two ways it can be identified: > > 1) Implementations can "value" (I2RS protocol version) to query that > indicates the NETCONF implementation or the RESTCONF implementation provides > all the features requested by I2RS protocol requirements. > > 2) Implementations query the NETCONF implementation or the RESTCONF > implementation supports all the features required for the I2RS protocol. > > It seemed reasonable to me to specify that NETCONF or RESTCONF set-up a > value that implementations can query to indicate it supports I2RS protocol > requirements. > > Did you have a better way to do this? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern > Sent: Wednesday, May 25, 2016 10:04 PM > To: i2rs@ietf.org > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol > identification > > Mostly, this looks very good. > > I find it odd and overspecified that the first requirement for netConf and > Restconf is described as indicating I2RS support via the protocol version. > > It seems unlikely that the protocol version is the right way to represent > this. And it seems that the I2RS WG should specify the need, not the > mechanism used to represent it. > > Yours, > Joel > > On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Interface to the Routing System of the > IETF. >> >> Title : I2RS Ephemeral State Requirements >> Authors : Jeff Haas >> Susan Hares >> Filename : draft-ietf-i2rs-ephemeral-state-07.txt >> Pages : 14 >> Date : 2016-05-25 >> >> Abstract: >> This document covers requests to the NETMOD and NETCONF Working >> Groups for functionality to support the ephemeral state requirements >> to implement the I2RS architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at > tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > I2RS > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Thu May 26 10:50:47 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A70412D562 for ; Thu, 26 May 2016 10:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQgxZHCw8MOs for ; Thu, 26 May 2016 10:50:45 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 30EE912D7E1 for ; Thu, 26 May 2016 10:50:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Andy Bierman'" , "'Juergen Schoenwaelder'" , "'Jeffrey Haas'" , References: <010101d1b6d0$c51fbf60$4f5f3e20$@ndzh.com> <20160525223345.GA12545@elstar.local> In-Reply-To: Date: Thu, 26 May 2016 13:50:30 -0400 Message-ID: <041e01d1b777$185ca110$4915e330$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/JAKNkO8ofPtuVY7KY8y82XrZmwGE7LbjAWBPWuye2XMqMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt -- X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:50:46 -0000 Andy:=20 On Ephemeral-REQ-05/06: You are correct, the ephemeral indication in = Yang could be an extension. Do you have a suggestion to revise the = text for Ephemeral-REQ-05?=20 Ephemeral-REQ-05: The ability to augment an object with appropriate YANG structures that have the property of being ephemeral. An object defined as Yang module, schema tree, a schema node, submodule or components of a submodule (derived types, groupings, data node, RPCs, actions, and notifications". Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that nodes have the following properties: ephemeral, writable/not- writable, status/configuration, and secure/non-secure transport. (If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for potential yang syntax). Sue=20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, May 25, 2016 10:13 PM To: Juergen Schoenwaelder; Susan Hares; Jeffrey Haas; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt = -- On Wed, May 25, 2016 at 3:33 PM, Juergen Schoenwaelder = wrote: On Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hares wrote: >> Juergen: >> Thank you for your comments on the ephemeral state\ >> On Ephemeral-REQ-05, does this clarify the requirement: >> Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of >> objects) that have the property of being ephemeral. An object = defined as > Yang module, schema tree, a schema node, submodule or components of a = submodule (derived types, groupings, data node, RPCs, actions, and = notifications). > [Juergen]: I have no clue what the above sentence is trying to say. = Please try to use YANG terminology. >> Any ephemeral object must be able to be identified by a yang key = word. >[Andy]: Why does there have to be a YANG keyword? >This could be an extension and not a keyword, depending on how it is = done. The=20 > extension vs. keyword debate will not be rehashed here, but there is = an issue wrt/ >how the data definition is interpreted by tools/protocols = that do not understand the >extension and just ignore it. >Shared: > > list foo { > i2rs:ephemeral true; > .... > } I2RS-only: > i2rs:ephemeral { > list foo { ... } > } Sue: This works for me.=20 >> On Ephemeral-REQ-06, does this text restrict the definition to just >> requirements: >> "Ephemeral-REQ-06: Yang MUST have a way to >> indicate in a data model that nodes have the following >> properties: ephemeral, writable/not-writable, status/configuration, >> and secure/non-secure transport. >> (If you desire examples, please see = draft-hares-i2rs-protocol-strawman for >> potential yang syntax). =20 > [Andy]: We do have config true/false this implies = writable/not-writable. I > find the idea strange that a data model defines secure/non-secure > transport as a property of an data model definition since it usually > depends on the deployment context whether it is acceptable to carry > data over a non-secure transport. Sue: You are correct that config true/false implies that = writable/non-writeable. =20 Sue: On Secure/non-secure: The data model defines information that must = be passed over secure or non-secure transport. The type of transport = is left to the protocol.=20 >This is a very expensive feature wrt/ standards resources. > First the WG has to agree that all the subtree data is OK to send in = the clear under all circumstances. (Including augmenting nodes?) =20 > Then this needs to be carefully reviewed by the SECDIR and IESG. =20 > Both steps will require lots of IETF time. Sue: Agreed. However, the WG set this in its architecture and its = initial requirements. =20 > I agree that operators need to have the final say. Sue: Ok, then we should design it and see if the operators use it.=20 >This extension is the opposite of the nacm:default-deny-all extension. >But it is designed to allow operators to configure access through NACM. >How does an operator override the extension? >And if the operator can override, why is an extension even needed? >If not, then what criteria is used to decide the data is universally = non-secure? Sue: I do not see how this extension is the opposite of = "nacm:default-deny-all" extension or relates to the operators access = through NACM. The purpose is not to change who can connect, only what = type of transport the messages go over.=20 =20 >>Andy Thanks for commenting. Sue =20 =3D [snip] =20 From nobody Thu May 26 10:54:32 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D981412D0DD for ; Thu, 26 May 2016 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebtjIDNWLjAM for ; Thu, 26 May 2016 10:54:29 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1325B12D6E9 for ; Thu, 26 May 2016 10:47:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 006B124D440; Thu, 26 May 2016 10:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464284846; bh=MFRlSjgRQx8Knh36X4VV87J9dektA/KY/QukpSxcUIo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NSb8veJakbBAry8LhLdyYMfJizu7qS+cu/sIQCirJS577RsyWpI0HAQqTFnAnwd8e 3tYx2jl9HCQLAJ1tr5IjiWi6p2P6UQ5KlSNVgadnRI+f+xC+5KOBeG+6jYMf1b6Aet AAi4aEJIL3wxGpL/T8JNQM5vlxxSdPe8m2VUrAJk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 774EC240E72; Thu, 26 May 2016 10:47:25 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <1d33bfff-bd6c-f376-8c9c-aef611670311@joelhalpern.com> <03fe01d1b771$4ac13ae0$e043b0a0$@ndzh.com> From: "Joel M. Halpern" Message-ID: <9be08105-b5b1-4d34-caf4-c13ee3a12881@joelhalpern.com> Date: Thu, 26 May 2016 13:47:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <03fe01d1b771$4ac13ae0$e043b0a0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node transport security X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:54:31 -0000 We could take the view that all nodes in a model being used by I2RS had to have the potential to be ephemeral. While that would be attractive for consistency, it puts a massive burden on the routing system implemention. So we agreed that ephemeral marking was on a per-node basis. Yes, that means that the model designer has to look at the usage. Unfortunate, but a tradeoff. When it comes to securing the transfer, the situation is very different. Most importantly, the cost for supporting sending whatever the client requests over an unsecure transport is small. And trying to guess which information will be needed by monitoring or telemetry seems like to end up with "all". Yes, there is a security risk with saying that telemetry information may be send unencrypted. But either wwe accept that or we don't. Trying to do node based marking does not seem to help the situation, and it creates operational restrictions and complications. Yours, joel On 5/26/16 1:08 PM, Susan Hares wrote: > Joel: > > The purpose of allowing a non-security transport was to report status or > telemetry information. This information may be in a specific model, or a > portion of a model. While nodes may be too small an area, can you suggest > alternate wording here? > > Please look at Ephemeral-REQ-05 for context of the use of "object" > > Sue > > ----------- > > Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model > that nodes have the following properties: ephemeral, writable/not- > writable, status/configuration, and secure/non-secure transport. (If > you desire examples, please see [I-D.hares-i2rs-protocol-strawman] > for potential yang syntax). > > Ephemeral-REQ-05: The ability to augment an object with appropriate > YANG structures that have the property of being ephemeral. An object > defined as Yang module, schema tree, a schema node, submodule or > components of a submodule (derived types, groupings, data node, RPCs, > actions, and notifications". > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern > Sent: Wednesday, May 25, 2016 11:17 PM > To: i2rs@ietf.org > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node > transport security > > While I agree with the overall requirement that I2RS support both secured > and unsecured communication, I find Ephemeral-REQ-06 rather odd. Trying to > have the module designer specify whether the usage of a node (get, set, > ...?) must be via a secure or unsecure transport seems a very odd placement > of the control. > > Why are we mandating this on a per-node level? > > Thank you, > Joel > > On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Interface to the Routing System of the > IETF. >> >> Title : I2RS Ephemeral State Requirements >> Authors : Jeff Haas >> Susan Hares >> Filename : draft-ietf-i2rs-ephemeral-state-07.txt >> Pages : 14 >> Date : 2016-05-25 >> >> Abstract: >> This document covers requests to the NETMOD and NETCONF Working >> Groups for functionality to support the ephemeral state requirements >> to implement the I2RS architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at > tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu May 26 11:03:57 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CE312D807 for ; Thu, 26 May 2016 11:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsEVMhTaXXrO for ; Thu, 26 May 2016 11:03:54 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 E486112D7FC for ; Thu, 26 May 2016 11:03:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Joel M. Halpern'" , References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com> <85ce0bf3-3e2e-23e6-4e14-5ed4bc423a18@joelhalpern.com> In-Reply-To: <85ce0bf3-3e2e-23e6-4e14-5ed4bc423a18@joelhalpern.com> Date: Thu, 26 May 2016 14:03:48 -0400 Message-ID: <042001d1b778$f4297050$dc7c50f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWZbgrR/rETZCVhEoXYOsiMgM15wIlr7goAetCa58CO6ccwZ+PvnyA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 18:03:56 -0000 Joel: This requirement is not about forking I2RS protocol off the NETCONF/RESTCONF stream. My requirement is to have a parameter in some NETCONF model (? Extension to draft-ietf-netconf-yang-library) that that indicates I2RS protocol version 1 (with all its requirements) are supported (true/false). Otherwise, as a developer of an implementation - you must go to check all the different types of netconf. It would seem to me that causing the implementation to check all of the specific NETCONF and model support would be much more work that indicating a I2RS protocol version support. I think your mechanism is a lot more work for the I2RS client querying 1 variable. Sue -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, May 26, 2016 1:42 PM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification First, I would prefer that we express our requirements, and let the protocol developers determine what is the best way of meeting those requirements. That is what I want when I receive requirements, so I try to meet that standard when I send them. As for a proposed mechanism, I would again separate pieces. The I12RS Client needs to know if certain capabilities are present. These include support for specific models (already present in netConf), support for specific additional capabilities such as Ephemeral handling, and support for the attribution mechanisms. There may be others. Depending upon how these needs are met, there are multiple ways to indicate these capabilities within the NetConf and YANG framework. Further, and part of the reason for my concerns, is that I would want to know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a future YANG 1.2 or 2.0. Without having to change the I2RS "protocol" indication. If we were really in a situation where I2RS support was a fork from the base protocols, then a protocol version would be appropriate. That situation would be extremely unfortunate. I believe we are avoiding that. yours, Joel On 5/26/16 12:55 PM, Susan Hares wrote: > Joel: > > I2RS protocol as a re-use protocol is specifying a set of changes to > NETCONF or RESTCONF. We have two ways it can be identified: > > 1) Implementations can "value" (I2RS protocol version) to query that > indicates the NETCONF implementation or the RESTCONF implementation > provides all the features requested by I2RS protocol requirements. > > 2) Implementations query the NETCONF implementation or the RESTCONF > implementation supports all the features required for the I2RS protocol. > > It seemed reasonable to me to specify that NETCONF or RESTCONF set-up > a value that implementations can query to indicate it supports I2RS > protocol requirements. > > Did you have a better way to do this? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern > Sent: Wednesday, May 25, 2016 10:04 PM > To: i2rs@ietf.org > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol > identification > > Mostly, this looks very good. > > I find it odd and overspecified that the first requirement for netConf > and Restconf is described as indicating I2RS support via the protocol version. > > It seems unlikely that the protocol version is the right way to > represent this. And it seems that the I2RS WG should specify the > need, not the mechanism used to represent it. > > Yours, > Joel > > On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Interface to the Routing System of >> the > IETF. >> >> Title : I2RS Ephemeral State Requirements >> Authors : Jeff Haas >> Susan Hares >> Filename : draft-ietf-i2rs-ephemeral-state-07.txt >> Pages : 14 >> Date : 2016-05-25 >> >> Abstract: >> This document covers requests to the NETMOD and NETCONF Working >> Groups for functionality to support the ephemeral state requirements >> to implement the I2RS architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at > tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > I2RS > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Thu May 26 11:17:06 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E31612D81B for ; Thu, 26 May 2016 11:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye8Q2TdWhYZm for ; Thu, 26 May 2016 11:17:02 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0283412D828 for ; Thu, 26 May 2016 11:16:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Joel M. Halpern'" , References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <1d33bfff-bd6c-f376-8c9c-aef611670311@joelhalpern.com> <03fe01d1b771$4ac13ae0$e043b0a0$@ndzh.com> <9be08105-b5b1-4d34-caf4-c13ee3a12881@joelhalpern.com> In-Reply-To: <9be08105-b5b1-4d34-caf4-c13ee3a12881@joelhalpern.com> Date: Thu, 26 May 2016 14:16:52 -0400 Message-ID: <042201d1b77a$c74165a0$55c430e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWZbgrR/rETZCVhEoXYOsiMgM15wKIt/qeAtGcDU4B3ysjXp+IWucQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node transport security X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 18:17:04 -0000 Joel: Here's what [draft-ietf-i2rs-ephemeral-state-07.txt] says: SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. A secure transport MUST provide data confidentiality, data integrity, and replay prevention. The default I2RS transport is a secure transport. A non-secure transport can be can be used for publishing telemetry data or other operational state that was specifically indicated to non-confidential in the data model in the Yang syntax. The configuration of ephemeral data in the I2RS Agent by the I2RS client SHOULD be done over a secure transport. It is anticipated that the passing of most I2RS ephemeral state operational status SHOULD be done over a secure transport. As [I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate whether the transport exchanging the data between I2RS client and I2RS agent is secure or insecure. The default mode of transport is secure so data models SHOULD clearly annotate what data nodes can be passed over an insecure connection. ============= Are you trying to suggest that the ability to do secure transports should be at the data model level? If so, does this text change work for you: Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that nodes have the following properties: ephemeral, writable/not-writable and status/configuration. Yang MUST have a way to indicate whether data models can be passed over secure or non-secure transport. (If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for potential yang syntax). Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, May 26, 2016 1:47 PM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node transport security We could take the view that all nodes in a model being used by I2RS had to have the potential to be ephemeral. While that would be attractive for consistency, it puts a massive burden on the routing system implemention. So we agreed that ephemeral marking was on a per-node basis. Yes, that means that the model designer has to look at the usage. Unfortunate, but a tradeoff. When it comes to securing the transfer, the situation is very different. Most importantly, the cost for supporting sending whatever the client requests over an unsecure transport is small. And trying to guess which information will be needed by monitoring or telemetry seems like to end up with "all". Yes, there is a security risk with saying that telemetry information may be send unencrypted. But either wwe accept that or we don't. Trying to do node based marking does not seem to help the situation, and it creates operational restrictions and complications. Yours, joel On 5/26/16 1:08 PM, Susan Hares wrote: > Joel: > > The purpose of allowing a non-security transport was to report status or > telemetry information. This information may be in a specific model, or a > portion of a model. While nodes may be too small an area, can you suggest > alternate wording here? > > Please look at Ephemeral-REQ-05 for context of the use of "object" > > Sue > > ----------- > > Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model > that nodes have the following properties: ephemeral, writable/not- > writable, status/configuration, and secure/non-secure transport. (If > you desire examples, please see [I-D.hares-i2rs-protocol-strawman] > for potential yang syntax). > > Ephemeral-REQ-05: The ability to augment an object with appropriate > YANG structures that have the property of being ephemeral. An object > defined as Yang module, schema tree, a schema node, submodule or > components of a submodule (derived types, groupings, data node, RPCs, > actions, and notifications". > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern > Sent: Wednesday, May 25, 2016 11:17 PM > To: i2rs@ietf.org > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node > transport security > > While I agree with the overall requirement that I2RS support both > secured and unsecured communication, I find Ephemeral-REQ-06 rather > odd. Trying to have the module designer specify whether the usage of > a node (get, set, > ...?) must be via a secure or unsecure transport seems a very odd > placement of the control. > > Why are we mandating this on a per-node level? > > Thank you, > Joel > > On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Interface to the Routing System of >> the > IETF. >> >> Title : I2RS Ephemeral State Requirements >> Authors : Jeff Haas >> Susan Hares >> Filename : draft-ietf-i2rs-ephemeral-state-07.txt >> Pages : 14 >> Date : 2016-05-25 >> >> Abstract: >> This document covers requests to the NETMOD and NETCONF Working >> Groups for functionality to support the ephemeral state requirements >> to implement the I2RS architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at > tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 26 11:30:19 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2903712D162 for ; Thu, 26 May 2016 11:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZkQkpg8ZaXw for ; Thu, 26 May 2016 11:30:15 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F10A12D0FF for ; Thu, 26 May 2016 11:30:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 86BCA240E72; Thu, 26 May 2016 11:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464287415; bh=HhYEKUA6R5aIXKTZ6YZqBJ46fS98D0EHe8fGiv3GWUQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=F30DxWpa3RlRr867NLY96lBkENZQx2Wolk3uZyU0okYNs/chs6Q9GchgHB0kR08kK ANJbQswP/Zdyf0S0eoLmhQSNtOxhBR2FQiPeaqntdKePgVKiH5ppG8G73qXSBlg/FX +hNtpMkmyzZdJfS9SxanaFuhrXU1iVg9f+cVi2p4= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 087AA24EA9A; Thu, 26 May 2016 11:30:14 -0700 (PDT) To: Susan Hares , "i2rs@ietf.org" References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com> <85ce0bf3-3e2e-23e6-4e14-5ed4bc423a18@joelhalpern.com> <042001d1b778$f4297050$dc7c50f0$@ndzh.com> From: Joel Halpern Direct Message-ID: <489ac126-449f-fb10-b6fa-9408c3650688@joelhalpern.com> Date: Thu, 26 May 2016 14:29:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <042001d1b778$f4297050$dc7c50f0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 18:30:18 -0000 As far as I can tell, there is no such thing as i2RS protocol version 1. Rather there are (or more accurately) will be, a package of features the I2RS uses. Asking of identification as a singular thing is an efficiency gain, but not a requirement. And masking the YANG version is an extremely undesirable side-effect. Yours, Joel On 5/26/16 2:03 PM, Susan Hares wrote: > Joel: > > > > This requirement is not about forking I2RS protocol off the NETCONF/RESTCONF > stream. > > My requirement is to have a parameter in some NETCONF model (? Extension to > draft-ietf-netconf-yang-library) that that indicates I2RS protocol version 1 > (with all its requirements) are supported (true/false). > > Otherwise, as a developer of an implementation - you must go to check all > the different types of netconf. It would seem to me that causing the > implementation to check all of the specific NETCONF and model support would > be much more work that indicating a I2RS protocol version support. I think > your mechanism is a lot more work for the I2RS client querying 1 variable. > > > Sue > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, May 26, 2016 1:42 PM > To: Susan Hares; i2rs@ietf.org > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol > identification > > First, I would prefer that we express our requirements, and let the protocol > developers determine what is the best way of meeting those requirements. > That is what I want when I receive requirements, so I try to meet that > standard when I send them. > > As for a proposed mechanism, I would again separate pieces. The I12RS > Client needs to know if certain capabilities are present. These include > support for specific models (already present in netConf), support for > specific additional capabilities such as Ephemeral handling, and support for > the attribution mechanisms. There may be others. Depending upon how these > needs are met, there are multiple ways to indicate these capabilities within > the NetConf and YANG framework. > > Further, and part of the reason for my concerns, is that I would want to > know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a future > YANG 1.2 or 2.0. Without having to change the I2RS "protocol" > indication. > > If we were really in a situation where I2RS support was a fork from the base > protocols, then a protocol version would be appropriate. That situation > would be extremely unfortunate. I believe we are avoiding that. > > yours, > Joel > > On 5/26/16 12:55 PM, Susan Hares wrote: >> Joel: >> >> I2RS protocol as a re-use protocol is specifying a set of changes to >> NETCONF or RESTCONF. We have two ways it can be identified: >> >> 1) Implementations can "value" (I2RS protocol version) to query that >> indicates the NETCONF implementation or the RESTCONF implementation >> provides all the features requested by I2RS protocol requirements. >> >> 2) Implementations query the NETCONF implementation or the RESTCONF >> implementation supports all the features required for the I2RS protocol. >> >> It seemed reasonable to me to specify that NETCONF or RESTCONF set-up >> a value that implementations can query to indicate it supports I2RS >> protocol requirements. >> >> Did you have a better way to do this? >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern >> Sent: Wednesday, May 25, 2016 10:04 PM >> To: i2rs@ietf.org >> Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol >> identification >> >> Mostly, this looks very good. >> >> I find it odd and overspecified that the first requirement for netConf >> and Restconf is described as indicating I2RS support via the protocol > version. >> >> It seems unlikely that the protocol version is the right way to >> represent this. And it seems that the I2RS WG should specify the >> need, not the mechanism used to represent it. >> >> Yours, >> Joel >> >> On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Interface to the Routing System of >>> the >> IETF. >>> >>> Title : I2RS Ephemeral State Requirements >>> Authors : Jeff Haas >>> Susan Hares >>> Filename : draft-ietf-i2rs-ephemeral-state-07.txt >>> Pages : 14 >>> Date : 2016-05-25 >>> >>> Abstract: >>> This document covers requests to the NETMOD and NETCONF Working >>> Groups for functionality to support the ephemeral state requirements >>> to implement the I2RS architecture. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >> tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> I2RS >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > From nobody Thu May 26 11:32:37 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9347C12D560 for ; Thu, 26 May 2016 11:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UpySbN_rme3 for ; Thu, 26 May 2016 11:32:34 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A4812D13A for ; Thu, 26 May 2016 11:32:33 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id o16so84803244ywd.2 for ; Thu, 26 May 2016 11:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=E9aDmwSBjboo70QU3e2YFfLv7ucV/NQ1b3ywd6rUdgw=; b=yeB770MDzNhzEnKVlFUjMFWAjlxqiPFF0N2H2Apm38a4eXqPak5mj+LEK2X/5LwueK PFA7qMqo+Se5eHeEW/pK6H1QgT3CedExRjw6fri4prAAQkFT5Qr2KTNwLoKg2Mok99HJ gHHa7StW31Itk9/FN+FsvrrU1DMRUpzvkDDt+9vliaLCz2WDKdivbMCZqpJppawYV69V 5Sl8hClCoOrYShEtzZiPm5whaAYa5JtwGMA36oHm4ZjUlBP1WcISSKuq3wGWGRsXxKiD NHBqN7pNgELcNIthFH2RYg8SD/nbo97Lmj08mNoGDqIxXpktobEpsecwU19PL3tt/XbO +q+w== 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; bh=E9aDmwSBjboo70QU3e2YFfLv7ucV/NQ1b3ywd6rUdgw=; b=Rhknz2VAAQQAagKEsee6J4p0sgSwHl1z7vU4XPce4mmIXvRe10apVA4mhwIzf14XKD 946qI4kZDMPw8hen8tRKuYxKfL5I1GD5H6p5Nlt+92Y+UUasz00dYN6Dhk5/V7iBCstP I7khoIYKEH/VaRxJhuw9ODrofgLUIOXW054D0m5SHyD/0d8pHJIyODdr1fYUB/iDjXCJ PxDXZOcqptqrTq6Dbnj2Kl4GxGVbRUG7CcsZ+MvgzkACsOch50ozi1kQEs2tl5taFYbT hi/2f6mxpJwP6B3ZrXoZQFElhngPJ3gdbQHV2ZUO9mzSiIpyVyF5t39h59ALBklRIVkh im9A== X-Gm-Message-State: ALyK8tJPYRtTnFR6COMUR6snw7FxiPznBwP36a+s8bsIK/EbfEXM2Ri9YTg0pmvIUf1xCqs10CAVUA2yRNidyQ== MIME-Version: 1.0 X-Received: by 10.37.80.133 with SMTP id e127mr5977031ybb.162.1464287552991; Thu, 26 May 2016 11:32:32 -0700 (PDT) Received: by 10.37.44.199 with HTTP; Thu, 26 May 2016 11:32:32 -0700 (PDT) In-Reply-To: <042001d1b778$f4297050$dc7c50f0$@ndzh.com> References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com> <85ce0bf3-3e2e-23e6-4e14-5ed4bc423a18@joelhalpern.com> <042001d1b778$f4297050$dc7c50f0$@ndzh.com> Date: Thu, 26 May 2016 11:32:32 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a113e9b6c7251a90533c303e4 Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 18:32:36 -0000 --001a113e9b6c7251a90533c303e4 Content-Type: text/plain; charset=UTF-8 On Thu, May 26, 2016 at 11:03 AM, Susan Hares wrote: > Joel: > > > > This requirement is not about forking I2RS protocol off the > NETCONF/RESTCONF > stream. > > My requirement is to have a parameter in some NETCONF model (? Extension to > draft-ietf-netconf-yang-library) that that indicates I2RS protocol version > 1 > (with all its requirements) are supported (true/false). > > Otherwise, as a developer of an implementation - you must go to check all > the different types of netconf. It would seem to me that causing the > implementation to check all of the specific NETCONF and model support would > be much more work that indicating a I2RS protocol version support. I > think > your mechanism is a lot more work for the I2RS client querying 1 variable. > > The protocol identification was removed from the YANG library. It was decided that each protocol would return the view of the library that is supported in the protocol. Only NETCONF and RESTCONF were considered, but if I2RS uses these protocols then it is covered. IMO there should be an optional capability for "ephemeral" that indicates the I2RS extensions (to NETCONF or RESTCONF) are supported. There really isn't a separate I2RS protocol (e.g., entry points are the same) > Sue > > Andy > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, May 26, 2016 1:42 PM > To: Susan Hares; i2rs@ietf.org > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol > identification > > First, I would prefer that we express our requirements, and let the > protocol > developers determine what is the best way of meeting those requirements. > That is what I want when I receive requirements, so I try to meet that > standard when I send them. > > As for a proposed mechanism, I would again separate pieces. The I12RS > Client needs to know if certain capabilities are present. These include > support for specific models (already present in netConf), support for > specific additional capabilities such as Ephemeral handling, and support > for > the attribution mechanisms. There may be others. Depending upon how these > needs are met, there are multiple ways to indicate these capabilities > within > the NetConf and YANG framework. > > Further, and part of the reason for my concerns, is that I would want to > know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a future > YANG 1.2 or 2.0. Without having to change the I2RS "protocol" > indication. > > If we were really in a situation where I2RS support was a fork from the > base > protocols, then a protocol version would be appropriate. That situation > would be extremely unfortunate. I believe we are avoiding that. > > yours, > Joel > > On 5/26/16 12:55 PM, Susan Hares wrote: > > Joel: > > > > I2RS protocol as a re-use protocol is specifying a set of changes to > > NETCONF or RESTCONF. We have two ways it can be identified: > > > > 1) Implementations can "value" (I2RS protocol version) to query that > > indicates the NETCONF implementation or the RESTCONF implementation > > provides all the features requested by I2RS protocol requirements. > > > > 2) Implementations query the NETCONF implementation or the RESTCONF > > implementation supports all the features required for the I2RS protocol. > > > > It seemed reasonable to me to specify that NETCONF or RESTCONF set-up > > a value that implementations can query to indicate it supports I2RS > > protocol requirements. > > > > Did you have a better way to do this? > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern > > Sent: Wednesday, May 25, 2016 10:04 PM > > To: i2rs@ietf.org > > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol > > identification > > > > Mostly, this looks very good. > > > > I find it odd and overspecified that the first requirement for netConf > > and Restconf is described as indicating I2RS support via the protocol > version. > > > > It seems unlikely that the protocol version is the right way to > > represent this. And it seems that the I2RS WG should specify the > > need, not the mechanism used to represent it. > > > > Yours, > > Joel > > > > On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> This draft is a work item of the Interface to the Routing System of > >> the > > IETF. > >> > >> Title : I2RS Ephemeral State Requirements > >> Authors : Jeff Haas > >> Susan Hares > >> Filename : draft-ietf-i2rs-ephemeral-state-07.txt > >> Pages : 14 > >> Date : 2016-05-25 > >> > >> Abstract: > >> This document covers requests to the NETMOD and NETCONF Working > >> Groups for functionality to support the ephemeral state requirements > >> to implement the I2RS architecture. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > > tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html or > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > I2RS > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a113e9b6c7251a90533c303e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 26, 2016 at 11:03 AM, Susan Hares <shares@ndzh.com> wrote:
Joel:

<wg chair hat off>

This requirement is not about forking I2RS protocol off the NETCONF/RESTCON= F
stream.

My requirement is to have a parameter in some NETCONF model (? Extension to=
draft-ietf-netconf-yang-library) that that indicates I2RS protocol version = 1
(with all its requirements) are supported (true/false).

Otherwise, as a developer of an implementation - you must go to check all the different types of netconf.=C2=A0 It would seem to me that causing the<= br> implementation to check all of the specific NETCONF and model support would=
be much more work that indicating a I2RS protocol version support.=C2=A0 = =C2=A0I think
your mechanism is a lot more work for the I2RS client querying 1 variable.<= br>


The protocol identifica= tion was removed from the YANG library.
It was decided that each = protocol would return the view of the library
that is supported i= n the protocol.=C2=A0 Only NETCONF and RESTCONF
were considered, = but if I2RS uses these protocols then it is covered.
IMO there sh= ould be an optional capability for "ephemeral" that
ind= icates the I2RS extensions (to NETCONF or RESTCONF) are supported.
There really isn't a separate I2RS protocol (e.g., entry points are t= he same)



Sue


Andy
=C2=A0

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@jo= elhalpern.com]
Sent: Thursday, May 26, 2016 1:42 PM
To: Susan Hares; i2rs@ietf.org
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
identification

First, I would prefer that we express our requirements, and let the protoco= l
developers determine what is the best way of meeting those requirements. That is what I want when I receive requirements, so I try to meet that
standard when I send them.

As for a proposed mechanism, I would again separate pieces.=C2=A0 The I12RS=
Client needs to know if certain capabilities are present.=C2=A0 These inclu= de
support for specific models (already present in netConf), support for
specific additional capabilities such as Ephemeral handling, and support fo= r
the attribution mechanisms.=C2=A0 There may be others.=C2=A0 Depending upon= how these
needs are met, there are multiple ways to indicate these capabilities withi= n
the NetConf and YANG framework.

Further, and part of the reason for my concerns, is that I would want to know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a future YANG 1.2 or 2.0.=C2=A0 Without having to change the I2RS "protocol&quo= t;
indication.

If we were really in a situation where I2RS support was a fork from the bas= e
protocols, then a protocol version would be appropriate.=C2=A0 That situati= on
would be extremely unfortunate.=C2=A0 I believe we are avoiding that.

yours,
Joel

On 5/26/16 12:55 PM, Susan Hares wrote:
> Joel:
>
> I2RS protocol as a re-use protocol is specifying a set of changes to > NETCONF or RESTCONF.=C2=A0 We have two ways it can be identified:
>
> 1) Implementations can "value" (I2RS protocol version) to qu= ery that
> indicates the NETCONF implementation or the RESTCONF implementation > provides all the features requested by I2RS protocol requirements.
>
> 2) Implementations query the NETCONF implementation or the RESTCONF > implementation supports all the features required for the I2RS protoco= l.
>
> It seemed reasonable to me to specify that NETCONF or RESTCONF set-up<= br> > a value that implementations can query to indicate it supports I2RS > protocol requirements.
>
> Did you have a better way to do this?
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounc= es@ietf.org] On Behalf Of Joel Halpern
> Sent: Wednesday, May 25, 2016 10:04 PM
> To: i2rs@ietf.org
> Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol<= br> > identification
>
> Mostly, this looks very good.
>
> I find it odd and overspecified that the first requirement for netConf=
> and Restconf is described as indicating I2RS support via the protocol<= br> version.
>
> It seems unlikely that the protocol version is the right way to
> represent this.=C2=A0 And it seems that the I2RS WG should specify the=
> need, not the mechanism used to represent it.
>
> Yours,
> Joel
>
> On 5/25/16 9:39 PM, intern= et-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
> directories.
>> This draft is a work item of the Interface to the Routing System o= f
>> the
> IETF.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: I2RS Ephemeral State Requirements
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Jeff Haas
>>=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=A0Susan Hares
>>=C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ie= tf-i2rs-ephemeral-state-07.txt
>>=C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 14
>>=C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : 2016-05-25
>>
>> Abstract:
>>=C2=A0 =C2=A0 This document covers requests to the NETMOD and NETCO= NF Working
>>=C2=A0 =C2=A0 Groups for functionality to support the ephemeral sta= te requirements
>>=C2=A0 =C2=A0 to implement the I2RS architecture.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.o= rg/doc/draft-ietf-i2rs-ephemeral-state/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/d= raft-ietf-i2rs-ephemeral-state-07
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-i2rs-ephemeral-state-07
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> submission until the htmlized version and diff are available at > tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org=
>> https://www.ietf.org/mailman/listinfo/i-d= -announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html<= /a> or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
> I2RS
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
>

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

--001a113e9b6c7251a90533c303e4-- From nobody Thu May 26 11:35:29 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC9A12D846 for ; Thu, 26 May 2016 11:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOPNsf87GfRL for ; Thu, 26 May 2016 11:35:24 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93D312D0A1 for ; Thu, 26 May 2016 11:35:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A43F226614E; Thu, 26 May 2016 11:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464287724; bh=kPdoQuzzTxmlMy2ACW9wHJhwyQ1PYNlnMFmxm5Dxcyw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=J6HcyAVRckbD+n1jAg3e0z9abzIUEaznZ6nYZNqlAaFP+peLDRvJV6JdqXw5ic2pr 3hWOSCDYpYZ9bhw8UCgdeYDfPSiYePV7GmP3rQt0anZU1FGVbuAxuZrjzO/CDfm+ql Kam9s6JbZBh6gsuOHZfF5RqruiH259hFgr94QMoU= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 18B64266130; Thu, 26 May 2016 11:35:24 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <1d33bfff-bd6c-f376-8c9c-aef611670311@joelhalpern.com> <03fe01d1b771$4ac13ae0$e043b0a0$@ndzh.com> <9be08105-b5b1-4d34-caf4-c13ee3a12881@joelhalpern.com> <042201d1b77a$c74165a0$55c430e0$@ndzh.com> From: "Joel M. Halpern" Message-ID: <94134224-d9ca-672d-9fc7-f24c9ef21055@joelhalpern.com> Date: Thu, 26 May 2016 14:35:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <042201d1b77a$c74165a0$55c430e0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node transport security X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 18:35:28 -0000 Hmmm. I tend to assume that the ability to support non-secure transport is at a device level. That is, and I2RS Agent supports both, or it doesn't. If we want enforceable controls over which data can be sent over which channels, we are opening a very large additional can of worms. No, the Module is not the right basis, since a module typically includes writeable, readable, and notification related information. The Node seems equally bad, since trying to guess at Module design team which nodes will be needed by which monitoring and telemetry operations, or will be provided by which kinds of devices, or will be used within vs across organizational boundaries, seems unknowable. Given that the I2RS approach is to let the operator use the tools in the way he wants, I think the only practical solution is to let him use the channels the way he wants. Yours, Joel On 5/26/16 2:16 PM, Susan Hares wrote: > Joel: > > > > Here's what [draft-ietf-i2rs-ephemeral-state-07.txt] says: > > SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. > > The default I2RS transport is a secure transport. > > A non-secure transport can be can be used for publishing telemetry > data or other operational state that was specifically indicated to > non-confidential in the data model in the Yang syntax. > > The configuration of ephemeral data in the I2RS Agent by the I2RS > client SHOULD be done over a secure transport. It is anticipated > that the passing of most I2RS ephemeral state operational status > SHOULD be done over a secure transport. As > [I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate > whether the transport exchanging the data between I2RS client and > I2RS agent is secure or insecure. The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > ============= > > Are you trying to suggest that the ability to do secure transports should be > at the data model level? If so, does this text change work for you: > > Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that > nodes have the following properties: ephemeral, writable/not-writable and > status/configuration. Yang MUST have a way to indicate > whether data models can be passed over secure or non-secure transport. > (If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for > potential yang syntax). > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, May 26, 2016 1:47 PM > To: Susan Hares; i2rs@ietf.org > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node > transport security > > We could take the view that all nodes in a model being used by I2RS had to > have the potential to be ephemeral. While that would be attractive for > consistency, it puts a massive burden on the routing system implemention. > So we agreed that ephemeral marking was on a per-node basis. Yes, that > means that the model designer has to look at the usage. Unfortunate, but a > tradeoff. > > When it comes to securing the transfer, the situation is very different. > Most importantly, the cost for supporting sending whatever the client > requests over an unsecure transport is small. And trying to guess which > information will be needed by monitoring or telemetry seems like to end up > with "all". Yes, there is a security risk with saying that telemetry > information may be send unencrypted. But either wwe accept that or we > don't. Trying to do node based marking does not seem to help the situation, > and it creates operational restrictions and complications. > > Yours, > joel > > On 5/26/16 1:08 PM, Susan Hares wrote: >> Joel: >> >> The purpose of allowing a non-security transport was to report status or >> telemetry information. This information may be in a specific model, or a >> portion of a model. While nodes may be too small an area, can you > suggest >> alternate wording here? >> >> Please look at Ephemeral-REQ-05 for context of the use of "object" >> >> Sue >> >> ----------- >> >> Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model >> that nodes have the following properties: ephemeral, writable/not- >> writable, status/configuration, and secure/non-secure transport. (If >> you desire examples, please see [I-D.hares-i2rs-protocol-strawman] >> for potential yang syntax). >> >> Ephemeral-REQ-05: The ability to augment an object with appropriate >> YANG structures that have the property of being ephemeral. An object >> defined as Yang module, schema tree, a schema node, submodule or >> components of a submodule (derived types, groupings, data node, RPCs, >> actions, and notifications". >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern >> Sent: Wednesday, May 25, 2016 11:17 PM >> To: i2rs@ietf.org >> Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node >> transport security >> >> While I agree with the overall requirement that I2RS support both >> secured and unsecured communication, I find Ephemeral-REQ-06 rather >> odd. Trying to have the module designer specify whether the usage of >> a node (get, set, >> ...?) must be via a secure or unsecure transport seems a very odd >> placement of the control. >> >> Why are we mandating this on a per-node level? >> >> Thank you, >> Joel >> >> On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Interface to the Routing System of >>> the >> IETF. >>> >>> Title : I2RS Ephemeral State Requirements >>> Authors : Jeff Haas >>> Susan Hares >>> Filename : draft-ietf-i2rs-ephemeral-state-07.txt >>> Pages : 14 >>> Date : 2016-05-25 >>> >>> Abstract: >>> This document covers requests to the NETMOD and NETCONF Working >>> Groups for functionality to support the ephemeral state requirements >>> to implement the I2RS architecture. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >> tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Thu May 26 11:52:55 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C294612D756 for ; Thu, 26 May 2016 11:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llUT6UX2LVbI for ; Thu, 26 May 2016 11:52:40 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 6097912D84F for ; Thu, 26 May 2016 11:52:19 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id c127so85224993ywb.1 for ; Thu, 26 May 2016 11:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=e4S/BsB+u9Mq8yAn8ngUYVarAlVfRkQXAyHHSR+jJH0=; b=aDHDP+8/PCWfCFx2uNHVtD1F1cbKxx+zn9j8c6IxLB/X9ZcZVBZ0hUwKzQzXMOWJYQ 39SRQYwdLRC9L+TC29tQTWqm4OkIqW/FM4gdTTWJk7MEX4UyWpd+SRZoz7zAnnLiFGjw 8ZFiL7F03Pd5yVpiSVCc7j2y7vLSfwWxr2JLUi0MRGbqw/0OusI7P51huX5iXQ3T8Odv 7grEedAATcvwkIAHCwrvzcydv/kBgm08GG1KEoQRzKNr0WfmFCtqZrgNzEZt3dX/FDXJ PzzxeKQBPGwMoWmNt865IN611kSqegSN1M/ijNUqGE/8o+nEcoUn0lJ9XgwoFi603xds 03zg== 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; bh=e4S/BsB+u9Mq8yAn8ngUYVarAlVfRkQXAyHHSR+jJH0=; b=fx8sAiua3TOzWxJtLXynLUFfLdrv5TEgLylmM0uzu9Bm7V92Pi3DkUlkOjp/CInNWY eb5yuaFwMPDfzubj8FRGhmEfkYYeWzyRv29mlsm0RpxYQ5RQfr4BVewlV7tAfJTDE+/m fBpjzVTQn7uFzRIztk10xkfVVggBxyfWwFyOXCXhmtFo0UMyHa+zG2h54Z44sGF37Ibf K9pssBVx+jyDVbPs1dKKxCTVYaxtID7JY8ORdcqfWx7ni0b8Yb3/Q3FB1yxgn8rLv5A1 CUsJMl0xG3g9so50NK5L9UQx36jdEreQDR81wVyZNE7ah7Z44g0tjKYk3z4KqEsaweR3 YuQA== X-Gm-Message-State: ALyK8tL0a1SKf5kcX05mFpobc3PMiyee8w3cym/H9ZJhVxdFLT7yn3qzUrMhHKHVcRPR+SsRS3D44xHkG5A0xA== MIME-Version: 1.0 X-Received: by 10.129.74.86 with SMTP id x83mr7255758ywa.38.1464288738515; Thu, 26 May 2016 11:52:18 -0700 (PDT) Received: by 10.37.44.199 with HTTP; Thu, 26 May 2016 11:52:18 -0700 (PDT) In-Reply-To: <94134224-d9ca-672d-9fc7-f24c9ef21055@joelhalpern.com> References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <1d33bfff-bd6c-f376-8c9c-aef611670311@joelhalpern.com> <03fe01d1b771$4ac13ae0$e043b0a0$@ndzh.com> <9be08105-b5b1-4d34-caf4-c13ee3a12881@joelhalpern.com> <042201d1b77a$c74165a0$55c430e0$@ndzh.com> <94134224-d9ca-672d-9fc7-f24c9ef21055@joelhalpern.com> Date: Thu, 26 May 2016 11:52:18 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a114c8c3a1bd6950533c34a08 Archived-At: Cc: "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node transport security X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 18:52:45 -0000 --001a114c8c3a1bd6950533c34a08 Content-Type: text/plain; charset=UTF-8 On Thu, May 26, 2016 at 11:35 AM, Joel M. Halpern wrote: > Hmmm. > I tend to assume that the ability to support non-secure transport is at a > device level. That is, and I2RS Agent supports both, or it doesn't. > > If we want enforceable controls over which data can be sent over which > channels, we are opening a very large additional can of worms. No, the > Module is not the right basis, since a module typically includes writeable, > readable, and notification related information. > > The Node seems equally bad, since trying to guess at Module design team > which nodes will be needed by which monitoring and telemetry operations, or > will be provided by which kinds of devices, or will be used within vs > across organizational boundaries, seems unknowable. > > Given that the I2RS approach is to let the operator use the tools in the > way he wants, I think the only practical solution is to let him use the > channels the way he wants. > > I think I agree with you. Take SNMP no-auth/no-priv as an example. It is a deployment decision whether or not to allow that. NETCONF and RESTCONF do not support non-secure transports so I assume a new document standardizing new transports would be needed. The RFCs actually say the protocol MUST NOT be used over a non-secure transport, so maybe a different protocol has to be used for this purpose. The NACM extensions make sense for subtree-level tagging. These alter the default NACM behavior for the subtree. The I2RS tag could be useful it there was agreement the node was non-secure in every possible application and no operator could ever disagree with this WG decision for any reason. IMO that will never happen. It is fairly easy in the server implementation to check whether the node being sent on a non-secure stream is tagged as "nonsecure OK". It is harder on readers and writers than tool makers. > Yours, > Joel > Andy > > On 5/26/16 2:16 PM, Susan Hares wrote: > >> Joel: >> >> >> >> Here's what [draft-ietf-i2rs-ephemeral-state-07.txt] says: >> >> SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a >> secure transport and optionally MAY be able to transfer data over a >> non-secure transport. A secure transport MUST provide data >> confidentiality, data integrity, and replay prevention. >> >> The default I2RS transport is a secure transport. >> >> A non-secure transport can be can be used for publishing telemetry >> data or other operational state that was specifically indicated to >> non-confidential in the data model in the Yang syntax. >> >> The configuration of ephemeral data in the I2RS Agent by the I2RS >> client SHOULD be done over a secure transport. It is anticipated >> that the passing of most I2RS ephemeral state operational status >> SHOULD be done over a secure transport. As >> [I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate >> whether the transport exchanging the data between I2RS client and >> I2RS agent is secure or insecure. The default mode of transport is >> secure so data models SHOULD clearly annotate what data nodes can be >> passed over an insecure connection. >> ============= >> >> Are you trying to suggest that the ability to do secure transports should >> be >> at the data model level? If so, does this text change work for you: >> >> Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that >> nodes have the following properties: ephemeral, writable/not-writable and >> status/configuration. Yang MUST have a way to indicate >> whether data models can be passed over secure or non-secure transport. >> (If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for >> potential yang syntax). >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Thursday, May 26, 2016 1:47 PM >> To: Susan Hares; i2rs@ietf.org >> Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node >> transport security >> >> We could take the view that all nodes in a model being used by I2RS had to >> have the potential to be ephemeral. While that would be attractive for >> consistency, it puts a massive burden on the routing system implemention. >> So we agreed that ephemeral marking was on a per-node basis. Yes, that >> means that the model designer has to look at the usage. Unfortunate, but >> a >> tradeoff. >> >> When it comes to securing the transfer, the situation is very different. >> Most importantly, the cost for supporting sending whatever the client >> requests over an unsecure transport is small. And trying to guess which >> information will be needed by monitoring or telemetry seems like to end up >> with "all". Yes, there is a security risk with saying that telemetry >> information may be send unencrypted. But either wwe accept that or we >> don't. Trying to do node based marking does not seem to help the >> situation, >> and it creates operational restrictions and complications. >> >> Yours, >> joel >> >> On 5/26/16 1:08 PM, Susan Hares wrote: >> >>> Joel: >>> >>> The purpose of allowing a non-security transport was to report status or >>> telemetry information. This information may be in a specific model, or >>> a >>> portion of a model. While nodes may be too small an area, can you >>> >> suggest >> >>> alternate wording here? >>> >>> Please look at Ephemeral-REQ-05 for context of the use of "object" >>> >>> Sue >>> >>> ----------- >>> >>> Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model >>> that nodes have the following properties: ephemeral, writable/not- >>> writable, status/configuration, and secure/non-secure transport. (If >>> you desire examples, please see [I-D.hares-i2rs-protocol-strawman] >>> for potential yang syntax). >>> >>> Ephemeral-REQ-05: The ability to augment an object with appropriate >>> YANG structures that have the property of being ephemeral. An object >>> defined as Yang module, schema tree, a schema node, submodule or >>> components of a submodule (derived types, groupings, data node, RPCs, >>> actions, and notifications". >>> >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern >>> Sent: Wednesday, May 25, 2016 11:17 PM >>> To: i2rs@ietf.org >>> Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node >>> transport security >>> >>> While I agree with the overall requirement that I2RS support both >>> secured and unsecured communication, I find Ephemeral-REQ-06 rather >>> odd. Trying to have the module designer specify whether the usage of >>> a node (get, set, >>> ...?) must be via a secure or unsecure transport seems a very odd >>> placement of the control. >>> >>> Why are we mandating this on a per-node level? >>> >>> Thank you, >>> Joel >>> >>> On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> >>> directories. >>> >>>> This draft is a work item of the Interface to the Routing System of >>>> the >>>> >>> IETF. >>> >>>> >>>> Title : I2RS Ephemeral State Requirements >>>> Authors : Jeff Haas >>>> Susan Hares >>>> Filename : draft-ietf-i2rs-ephemeral-state-07.txt >>>> Pages : 14 >>>> Date : 2016-05-25 >>>> >>>> Abstract: >>>> This document covers requests to the NETMOD and NETCONF Working >>>> Groups for functionality to support the ephemeral state requirements >>>> to implement the I2RS architecture. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >>>> >>> tools.ietf.org. >>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a114c8c3a1bd6950533c34a08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 26, 2016 at 11:35 AM, Joel M. Halpern <= ;jmh@joelhalpern.c= om> wrote:
Hmmm.
I tend to assume that the ability to support non-secure transport is at a d= evice level.=C2=A0 That is, and I2RS Agent supports both, or it doesn't= .

If we want enforceable controls over which data can be sent over which chan= nels, we are opening a very large additional can of worms.=C2=A0 No, the Mo= dule is not the right basis, since a module typically includes writeable, r= eadable, and notification related information.

The Node seems equally bad, since trying to guess at Module design team whi= ch nodes will be needed by which monitoring and telemetry operations, or wi= ll be provided by which kinds of devices, or will be used within vs across = organizational boundaries, seems unknowable.

Given that the I2RS approach is to let the operator use the tools in the wa= y he wants, I think the only practical solution is to let him use the chann= els the way he wants.



I think I agree with yo= u.
Take SNMP no-auth/no-priv as an example.
It is a dep= loyment decision whether or not to allow that.
NETCONF and RESTCO= NF do not support non-secure transports
so I assume a new documen= t standardizing new transports
would be needed.=C2=A0 The RFCs ac= tually say the protocol MUST NOT
be used over a non-secure transp= ort, so maybe a different protocol
has to be used for this purpos= e.

The NACM extensions make sense for subtree-leve= l tagging.
These alter the default NACM behavior for the subtree.=
The I2RS tag could be useful it there was agreement
th= e node was non-secure in every possible application and no
operat= or could ever disagree with this WG decision for any reason.
IMO = that will never happen.

It is fairly easy in the s= erver implementation to check whether the node
being sent on a no= n-secure stream is tagged as "nonsecure OK".
It is hard= er on readers and writers than tool makers.


=C2=A0
Yours,
Joel

Andy
=C2=A0

On 5/26/16 2:16 PM, Susan Hares wrote:
Joel:
<wg chair hat off>
<author hat on>

Here's what [draft-ietf-i2rs-ephemeral-state-07.txt] says:

SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
=C2=A0 =C2=A0secure transport and optionally MAY be able to transfer data o= ver a
=C2=A0 =C2=A0non-secure transport.=C2=A0 A secure transport MUST provide da= ta
=C2=A0 =C2=A0confidentiality, data integrity, and replay prevention.

=C2=A0 =C2=A0The default I2RS transport is a secure transport.

=C2=A0 =C2=A0A non-secure transport can be can be used for publishing telem= etry
=C2=A0 =C2=A0data or other operational state that was specifically indicate= d to
=C2=A0 =C2=A0non-confidential in the data model in the Yang syntax.

=C2=A0 =C2=A0The configuration of ephemeral data in the I2RS Agent by the I= 2RS
=C2=A0 =C2=A0client SHOULD be done over a secure transport.=C2=A0 It is ant= icipated
=C2=A0 =C2=A0that the passing of most I2RS ephemeral state operational stat= us
=C2=A0 =C2=A0SHOULD be done over a secure transport.=C2=A0 As
=C2=A0 =C2=A0[I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate=
=C2=A0 =C2=A0whether the transport exchanging the data between I2RS client = and
=C2=A0 =C2=A0I2RS agent is secure or insecure.=C2=A0 The default mode of tr= ansport is
=C2=A0 =C2=A0secure so data models SHOULD clearly annotate what data nodes = can be
=C2=A0 =C2=A0passed over an insecure connection.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Are you trying to suggest that the ability to do secure transports should b= e
at the data model level? If so, does this text change work for you:

Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that
nodes have the following properties: ephemeral, writable/not-writable and status/configuration.=C2=A0 Yang MUST have a way to indicate
whether data models can be passed over secure or non-secure transport.
(If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for<= br> potential yang syntax).

Sue

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Thursday, May 26, 2016 1:47 PM
To: Susan Hares; i2rs@ie= tf.org
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node
transport security

We could take the view that all nodes in a model being used by I2RS had to<= br> have the potential to be ephemeral.=C2=A0 While that would be attractive fo= r
consistency, it puts a massive burden on the routing system implemention. So we agreed that ephemeral marking was on a per-node basis.=C2=A0 Yes, tha= t
means that the model designer has to look at the usage.=C2=A0 Unfortunate, = but a
tradeoff.

When it comes to securing the transfer, the situation is very different. =C2=A0 Most importantly, the cost for supporting sending whatever the clien= t
requests over an unsecure transport is small.=C2=A0 And trying to guess whi= ch
information will be needed by monitoring or telemetry seems like to end up<= br> with "all".=C2=A0 Yes, there is a security risk with saying that = telemetry
information may be send unencrypted.=C2=A0 But either wwe accept that or we=
don't.=C2=A0 Trying to do node based marking does not seem to help the = situation,
and it creates operational restrictions and complications.

Yours,
joel

On 5/26/16 1:08 PM, Susan Hares wrote:
Joel:

The purpose of allowing a non-security transport was to report status or telemetry information.=C2=A0 =C2=A0This information may be in a specific mo= del, or a
portion of a model.=C2=A0 =C2=A0 While nodes may be too small an area, can = you
suggest
alternate wording here?

Please look at Ephemeral-REQ-05 for context of the use of "object"= ;

Sue

-----------

=C2=A0 =C2=A0Ephemeral-REQ-06: Yang MUST have a way to indicate in a data m= odel
=C2=A0 =C2=A0that nodes have the following properties: ephemeral, writable/= not-
=C2=A0 =C2=A0writable, status/configuration, and secure/non-secure transpor= t.=C2=A0 (If
=C2=A0 =C2=A0you desire examples, please see [I-D.hares-i2rs-protocol-straw= man]
=C2=A0 =C2=A0for potential yang syntax).

=C2=A0 Ephemeral-REQ-05: The ability to augment an object with appropriate<= br> =C2=A0 =C2=A0YANG structures that have the property of being ephemeral.=C2= =A0 An object
=C2=A0 =C2=A0defined as Yang module, schema tree, a schema node, submodule = or
=C2=A0 =C2=A0components of a submodule (derived types, groupings, data node= , RPCs,
=C2=A0 =C2=A0actions, and notifications".


-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern
Sent: Wednesday, May 25, 2016 11:17 PM
To: i2rs@ietf.org Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node
transport security

While I agree with the overall requirement that I2RS support both
secured and unsecured communication, I find Ephemeral-REQ-06 rather
odd.=C2=A0 Trying to have the module designer specify whether the usage of<= br> a node (get, set,
...?) must be via a secure or unsecure transport seems a very odd
placement of the control.

Why are we mandating this on a per-node level?

Thank you,
Joel

On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Interface to the Routing System of
the
IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= I2RS Ephemeral State Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jeff= Haas
=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 Susan Hares
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-i2rs-ephemeral-state-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-05-25

Abstract:
=C2=A0 =C2=A0This document covers requests to the NETMOD and NETCONF Workin= g
=C2=A0 =C2=A0Groups for functionality to support the ephemeral state requir= ements
=C2=A0 =C2=A0to implement the I2RS architecture.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-i2rs-ephemeral-state/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf= -i2rs-ephemeral-state-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-i2rs-ephemeral-state-07


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

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


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



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

--001a114c8c3a1bd6950533c34a08-- From nobody Thu May 26 12:49:32 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2499A12D8BF for ; Thu, 26 May 2016 12:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP5RXCzIqN6B for ; Thu, 26 May 2016 12:49:29 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 CBF9112D99E for ; Thu, 26 May 2016 12:49:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Andy Bierman'" References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com> <85ce0bf3-3e2e-23e6-4e14-5ed4bc423a18@joelhalpern.com> <042001d1b778$f4297050$dc7c50f0$@ndzh.com> In-Reply-To: Date: Thu, 26 May 2016 15:49:22 -0400 Message-ID: <047401d1b787$b3695df0$1a3c19d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0475_01D1B766.2C5ACB30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWZbgrR/rETZCVhEoXYOsiMgM15wIlr7goAetCa58CO6ccwQGnSlPtAktHGjifcD0nYA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 19:49:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0475_01D1B766.2C5ACB30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy and Joel:=20 =20 =20 =20 On Ephemeral-REQ-07.1 - draft-ietf-i2rs-ephemeral-state-07 - I2RS = Ephemeral State Requirements =20 I think the efficiency gain for a single place to check I2RS protocol = support is useful. How about if I propose in the protocol-strawman a = specific set of support that can be implemented in open source? And we = can take this to the rest of the list.=20 =20 I do not intend to masking the NETCONF/RESTCONF version. If = implementations want to go through all the checking, this is fine for = the implementations. However, this is a simple place to store the = checking. As Andy notes, we will need to indicate the ephemeral support = in the draft-ietf-netconf-yang-library. =20 =20 On Ephemeral-REQ-06: ] - did you like this revision?=20 Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that = nodes have the following properties: ephemeral, writable/not-writable = and status/configuration. Yang MUST have a way to indicate whether data = models can be passed over secure or non-secure transport. =20 (If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] = for potential yang syntax). =20 Sue=20 =20 =20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, May 26, 2016 2:33 PM To: Susan Hares Cc: Joel M. Halpern; i2rs@ietf.org Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol = identification =20 =20 =20 On Thu, May 26, 2016 at 11:03 AM, Susan Hares wrote: Joel: This requirement is not about forking I2RS protocol off the = NETCONF/RESTCONF stream. My requirement is to have a parameter in some NETCONF model (? Extension = to draft-ietf-netconf-yang-library) that that indicates I2RS protocol = version 1 (with all its requirements) are supported (true/false). Otherwise, as a developer of an implementation - you must go to check = all the different types of netconf. It would seem to me that causing the implementation to check all of the specific NETCONF and model support = would be much more work that indicating a I2RS protocol version support. I = think your mechanism is a lot more work for the I2RS client querying 1 = variable. =20 =20 The protocol identification was removed from the YANG library. It was decided that each protocol would return the view of the library that is supported in the protocol. Only NETCONF and RESTCONF were considered, but if I2RS uses these protocols then it is covered. IMO there should be an optional capability for "ephemeral" that indicates the I2RS extensions (to NETCONF or RESTCONF) are supported. There really isn't a separate I2RS protocol (e.g., entry points are the = same) =20 =20 Sue =20 Andy =20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, May 26, 2016 1:42 PM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification First, I would prefer that we express our requirements, and let the = protocol developers determine what is the best way of meeting those requirements. That is what I want when I receive requirements, so I try to meet that standard when I send them. As for a proposed mechanism, I would again separate pieces. The I12RS Client needs to know if certain capabilities are present. These include support for specific models (already present in netConf), support for specific additional capabilities such as Ephemeral handling, and support = for the attribution mechanisms. There may be others. Depending upon how = these needs are met, there are multiple ways to indicate these capabilities = within the NetConf and YANG framework. Further, and part of the reason for my concerns, is that I would want to know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a = future YANG 1.2 or 2.0. Without having to change the I2RS "protocol" indication. If we were really in a situation where I2RS support was a fork from the = base protocols, then a protocol version would be appropriate. That situation would be extremely unfortunate. I believe we are avoiding that. yours, Joel On 5/26/16 12:55 PM, Susan Hares wrote: > Joel: > > I2RS protocol as a re-use protocol is specifying a set of changes to > NETCONF or RESTCONF. We have two ways it can be identified: > > 1) Implementations can "value" (I2RS protocol version) to query that > indicates the NETCONF implementation or the RESTCONF implementation > provides all the features requested by I2RS protocol requirements. > > 2) Implementations query the NETCONF implementation or the RESTCONF > implementation supports all the features required for the I2RS = protocol. > > It seemed reasonable to me to specify that NETCONF or RESTCONF set-up > a value that implementations can query to indicate it supports I2RS > protocol requirements. > > Did you have a better way to do this? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern > Sent: Wednesday, May 25, 2016 10:04 PM > To: i2rs@ietf.org > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol > identification > > Mostly, this looks very good. > > I find it odd and overspecified that the first requirement for netConf > and Restconf is described as indicating I2RS support via the protocol version. > > It seems unlikely that the protocol version is the right way to > represent this. And it seems that the I2RS WG should specify the > need, not the mechanism used to represent it. > > Yours, > Joel > > On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Interface to the Routing System of >> the > IETF. >> >> Title : I2RS Ephemeral State Requirements >> Authors : Jeff Haas >> Susan Hares >> Filename : draft-ietf-i2rs-ephemeral-state-07.txt >> Pages : 14 >> Date : 2016-05-25 >> >> Abstract: >> This document covers requests to the NETMOD and NETCONF Working >> Groups for functionality to support the ephemeral state = requirements >> to implement the I2RS architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 >> >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-ephemeral-state-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at > tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > I2RS > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_0475_01D1B766.2C5ACB30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy and Joel:

 

<draft author hat on>

 

On Ephemeral-REQ-07.1 - draft-ietf-i2rs-ephemeral-state-07 - I2RS = Ephemeral State Requirements

 

I think the efficiency gain for a single place to check I2RS protocol = support is useful. =C2=A0How about if I propose in the protocol-strawman = a specific set of support that can be implemented in open source? = =C2=A0=C2=A0And we can take this to the rest of the list. =

 

I do not intend to masking the NETCONF/RESTCONF version.=C2=A0 If = implementations want to go through all the checking, this is fine for = the implementations.=C2=A0 However, this is a simple place to store the = checking.=C2=A0 As Andy notes, we will need to indicate the ephemeral = support in the =C2=A0draft-ietf-netconf-yang-library.=C2=A0=C2=A0 =

 

On Ephemeral-REQ-06: ] =C2=A0- did you = like this revision?

Ephemeral-REQ-06: Yang MUST have a way to indicate = in a data model that nodes have the following properties: ephemeral, = writable/not-writable and status/configuration.=C2=A0 Yang MUST have a = way to indicate whether data models can be passed over secure or = non-secure transport.=C2=A0

(If = you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for = potential yang syntax).

 

Sue

 

 

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, May = 26, 2016 2:33 PM
To: Susan Hares
Cc: Joel M. = Halpern; i2rs@ietf.org
Subject: Re: [i2rs] = draft-ietf-i2rs-ephemeral-state-07.txt - protocol = identification

 

 

 

On Thu, = May 26, 2016 at 11:03 AM, Susan Hares <shares@ndzh.com> wrote:

Joel:

<wg = chair hat off>

This requirement is not about forking I2RS = protocol off the NETCONF/RESTCONF
stream.

My requirement is to = have a parameter in some NETCONF model (? Extension = to
draft-ietf-netconf-yang-library) that that indicates I2RS protocol = version 1
(with all its requirements) are supported = (true/false).

Otherwise, as a developer of an implementation - = you must go to check all
the different types of netconf.  It = would seem to me that causing the
implementation to check all of the = specific NETCONF and model support would
be much more work that = indicating a I2RS protocol version support.   I think
your = mechanism is a lot more work for the I2RS client querying 1 = variable.

 

 

The protocol identification was removed from the YANG = library.

It was decided = that each protocol would return the view of the = library

that is supported = in the protocol.  Only NETCONF and = RESTCONF

were considered, = but if I2RS uses these protocols then it is = covered.

IMO there should = be an optional capability for "ephemeral" = that

indicates the I2RS = extensions (to NETCONF or RESTCONF) are = supported.

There really = isn't a separate I2RS protocol (e.g., entry points are the = same)

 

 


Sue

 

Andy

 


-----Original Message-----
From: Joel M. = Halpern [mailto:jmh@joelhalpern.com]
Sent: = Thursday, May 26, 2016 1:42 PM
To: Susan Hares; i2rs@ietf.org
Subject: Re: [i2rs] = draft-ietf-i2rs-ephemeral-state-07.txt - = protocol
identification

First, I would prefer that we express = our requirements, and let the protocol
developers determine what is = the best way of meeting those requirements.
That is what I want when = I receive requirements, so I try to meet that
standard when I send = them.

As for a proposed mechanism, I would again separate = pieces.  The I12RS
Client needs to know if certain capabilities = are present.  These include
support for specific models (already = present in netConf), support for
specific additional capabilities = such as Ephemeral handling, and support for
the attribution = mechanisms.  There may be others.  Depending upon how = these
needs are met, there are multiple ways to indicate these = capabilities within
the NetConf and YANG framework.

Further, = and part of the reason for my concerns, is that I would want to
know = whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a = future
YANG 1.2 or 2.0.  Without having to change the I2RS = "protocol"
indication.

If we were really in a = situation where I2RS support was a fork from the base
protocols, then = a protocol version would be appropriate.  That situation
would = be extremely unfortunate.  I believe we are avoiding = that.

yours,
Joel

On 5/26/16 12:55 PM, Susan Hares = wrote:
> Joel:
>
> I2RS protocol as a re-use protocol = is specifying a set of changes to
> NETCONF or RESTCONF.  We = have two ways it can be identified:
>
> 1) Implementations = can "value" (I2RS protocol version) to query that
> = indicates the NETCONF implementation or the RESTCONF = implementation
> provides all the features requested by I2RS = protocol requirements.
>
> 2) Implementations query the = NETCONF implementation or the RESTCONF
> implementation supports = all the features required for the I2RS protocol.
>
> It = seemed reasonable to me to specify that NETCONF or RESTCONF = set-up
> a value that implementations can query to indicate it = supports I2RS
> protocol requirements.
>
> Did you = have a better way to do this?
>
> Sue
>
> = -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On = Behalf Of Joel Halpern
> Sent: Wednesday, May 25, 2016 10:04 = PM
> To: i2rs@ietf.org
> Subject: Re: = [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
> = identification
>
> Mostly, this looks very = good.
>
> I find it odd and overspecified that the first = requirement for netConf
> and Restconf is described as indicating = I2RS support via the protocol
version.
>
> It seems = unlikely that the protocol version is the right way to
> represent = this.  And it seems that the I2RS WG should specify the
> = need, not the mechanism used to represent it.
>
> = Yours,
> Joel
>
> On 5/25/16 9:39 PM, internet-drafts@ietf.org = wrote:
>>
>> A New Internet-Draft is available from = the on-line Internet-Drafts
> directories.
>> This draft = is a work item of the Interface to the Routing System of
>> = the
> IETF.
>>
>>        =  Title           : I2RS Ephemeral = State Requirements
>>        =  Authors         : Jeff = Haas
>>                =            Susan Hares
>>  =     Filename        : = draft-ietf-i2rs-ephemeral-state-07.txt
>>      = Pages           : 14
>>  =     Date            : = 2016-05-25
>>
>> Abstract:
>>    = This document covers requests to the NETMOD and NETCONF = Working
>>    Groups for functionality to support the = ephemeral state requirements
>>    to implement the = I2RS architecture.
>>
>>
>> The IETF = datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-epheme= ral-state/
>>
>> There's also a htmlized version = available at:
>> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-s= tate-07
>>
>> A diff from the previous version is = available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-eph= emeral-state-07
>>
>>
>> Please note that = it may take a couple of minutes from the time of
>> submission = until the htmlized version and diff are available at
> tools.ietf.org.
>>
>> = Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
= >> _______________________________________________
>> = I-D-Announce mailing list
>> I-D-Announce@ietf.org
>&g= t; https://www.ietf.org/mailman/listinfo/i-d-announce<= br>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>&g= t;
> I2RS
>
> = _______________________________________________
> i2rs mailing = list
> i2rs@ietf.org
> = https://www.ietf.org/mailman/listinfo/i2rs
><= br>>

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

 

------=_NextPart_000_0475_01D1B766.2C5ACB30-- From nobody Thu May 26 15:03:02 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994AD12D71A for ; Thu, 26 May 2016 15:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px7A2jwgha_y for ; Thu, 26 May 2016 15:02:58 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 EC5F512D526 for ; Thu, 26 May 2016 15:02:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B9CC51C0D9D; Thu, 26 May 2016 15:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464300178; bh=59NUunK7PnQDooIQsfm3rUOA6rhr9NCboiM811rGUOc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Y20DpBoRkqWgJqcKxNuy829sXzP3yKDl8gqsqy1roJ0WT93qUP6lK1mIFP2aHd5sk nQbnsgw7AeX1C9gsQeth3MuMmk38Lnvr5tROmQVsyImmLsMCvEY1G3/OzNoGtlxweA 8EiBBaIpLkQsQf9NOt34zf7qL4QHLUWyO6HdFuuM= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1FD95FC0169; Thu, 26 May 2016 15:02:58 -0700 (PDT) To: Susan Hares , 'Andy Bierman' References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com> <85ce0bf3-3e2e-23e6-4e14-5ed4bc423a18@joelhalpern.com> <042001d1b778$f4297050$dc7c50f0$@ndzh.com> <047401d1b787$b3695df0$1a3c19d0$@ndzh.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 26 May 2016 18:02:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <047401d1b787$b3695df0$1a3c19d0$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:03:01 -0000 That text change seems good. Moving specific mechanism protocol proposals to the protocol strawman also seems appropriate. Yours, Joel On 5/26/16 3:49 PM, Susan Hares wrote: > Andy and Joel: > > > > > > > > On Ephemeral-REQ-07.1 - draft-ietf-i2rs-ephemeral-state-07 - I2RS > Ephemeral State Requirements > > > > I think the efficiency gain for a single place to check I2RS protocol > support is useful. How about if I propose in the protocol-strawman a > specific set of support that can be implemented in open source? And we > can take this to the rest of the list. > > > > I do not intend to masking the NETCONF/RESTCONF version. If > implementations want to go through all the checking, this is fine for > the implementations. However, this is a simple place to store the > checking. As Andy notes, we will need to indicate the ephemeral support > in the draft-ietf-netconf-yang-library. > > > > On Ephemeral-REQ-06: ] - did you like this revision? > > Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that > nodes have the following properties: ephemeral, writable/not-writable > and status/configuration. Yang MUST have a way to indicate whether data > models can be passed over secure or non-secure transport. > > (If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] > for potential yang syntax). > > > > Sue > > > > > > > > *From:*Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, May 26, 2016 2:33 PM > *To:* Susan Hares > *Cc:* Joel M. Halpern; i2rs@ietf.org > *Subject:* Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol > identification > > > > > > > > On Thu, May 26, 2016 at 11:03 AM, Susan Hares > wrote: > > Joel: > > > > This requirement is not about forking I2RS protocol off the NETCONF/RESTCONF > stream. > > My requirement is to have a parameter in some NETCONF model (? Extension to > draft-ietf-netconf-yang-library) that that indicates I2RS protocol version 1 > (with all its requirements) are supported (true/false). > > Otherwise, as a developer of an implementation - you must go to check all > the different types of netconf. It would seem to me that causing the > implementation to check all of the specific NETCONF and model support would > be much more work that indicating a I2RS protocol version support. I think > your mechanism is a lot more work for the I2RS client querying 1 variable. > > > > > > The protocol identification was removed from the YANG library. > > It was decided that each protocol would return the view of the library > > that is supported in the protocol. Only NETCONF and RESTCONF > > were considered, but if I2RS uses these protocols then it is covered. > > IMO there should be an optional capability for "ephemeral" that > > indicates the I2RS extensions (to NETCONF or RESTCONF) are supported. > > There really isn't a separate I2RS protocol (e.g., entry points are the > same) > > > > > > > Sue > > > > Andy > > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com > ] > Sent: Thursday, May 26, 2016 1:42 PM > To: Susan Hares; i2rs@ietf.org > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol > identification > > First, I would prefer that we express our requirements, and let the > protocol > developers determine what is the best way of meeting those requirements. > That is what I want when I receive requirements, so I try to meet that > standard when I send them. > > As for a proposed mechanism, I would again separate pieces. The I12RS > Client needs to know if certain capabilities are present. These include > support for specific models (already present in netConf), support for > specific additional capabilities such as Ephemeral handling, and > support for > the attribution mechanisms. There may be others. Depending upon > how these > needs are met, there are multiple ways to indicate these > capabilities within > the NetConf and YANG framework. > > Further, and part of the reason for my concerns, is that I would want to > know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a > future > YANG 1.2 or 2.0. Without having to change the I2RS "protocol" > indication. > > If we were really in a situation where I2RS support was a fork from > the base > protocols, then a protocol version would be appropriate. That situation > would be extremely unfortunate. I believe we are avoiding that. > > yours, > Joel > > On 5/26/16 12:55 PM, Susan Hares wrote: > > Joel: > > > > I2RS protocol as a re-use protocol is specifying a set of changes to > > NETCONF or RESTCONF. We have two ways it can be identified: > > > > 1) Implementations can "value" (I2RS protocol version) to query that > > indicates the NETCONF implementation or the RESTCONF implementation > > provides all the features requested by I2RS protocol requirements. > > > > 2) Implementations query the NETCONF implementation or the RESTCONF > > implementation supports all the features required for the I2RS > protocol. > > > > It seemed reasonable to me to specify that NETCONF or RESTCONF set-up > > a value that implementations can query to indicate it supports I2RS > > protocol requirements. > > > > Did you have a better way to do this? > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org > ] On Behalf Of Joel Halpern > > Sent: Wednesday, May 25, 2016 10:04 PM > > To: i2rs@ietf.org > > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol > > identification > > > > Mostly, this looks very good. > > > > I find it odd and overspecified that the first requirement for netConf > > and Restconf is described as indicating I2RS support via the protocol > version. > > > > It seems unlikely that the protocol version is the right way to > > represent this. And it seems that the I2RS WG should specify the > > need, not the mechanism used to represent it. > > > > Yours, > > Joel > > > > On 5/25/16 9:39 PM, internet-drafts@ietf.org > wrote: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> This draft is a work item of the Interface to the Routing System of > >> the > > IETF. > >> > >> Title : I2RS Ephemeral State Requirements > >> Authors : Jeff Haas > >> Susan Hares > >> Filename : draft-ietf-i2rs-ephemeral-state-07.txt > >> Pages : 14 > >> Date : 2016-05-25 > >> > >> Abstract: > >> This document covers requests to the NETMOD and NETCONF Working > >> Groups for functionality to support the ephemeral state > requirements > >> to implement the I2RS architecture. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07 > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > > tools.ietf.org . > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html or > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > I2RS > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > From nobody Fri May 27 01:37:31 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF8E12D5FE for ; Fri, 27 May 2016 01:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPp_XVcknx5B for ; Fri, 27 May 2016 01:37:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF8412D506 for ; Fri, 27 May 2016 01:37:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKX23300; Fri, 27 May 2016 08:37:23 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 27 May 2016 09:37:19 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Fri, 27 May 2016 16:37:14 +0800 From: Mach Chen To: Jeffrey Haas , "i2rs@ietf.org" Thread-Topic: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) Thread-Index: AQHRtdbsWAFUm7E8KESvhNc8ER/CW5/MehCg Date: Fri, 27 May 2016 08:37:13 +0000 Message-ID: References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> In-Reply-To: <20160524161622.GK17462@pfrc.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.57480745.0067, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c5c4399e588a13a5e36c433fa4472de2 Archived-At: Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 08:37:30 -0000 Hi Jeff, I support the adoption of these drafts. Best regards, Mach > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Wednesday, May 25, 2016 12:16 AM > To: i2rs@ietf.org > Subject: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June= 10) >=20 > Working Group, >=20 > In the prior poll, we didn't get much in the way of input for adopting th= e > filter-based RIB work. This work is explicitly in charter, and more impo= rtantly > is *modeling* work and doesn't have to immediately deal with our protocol > headaches. :-) >=20 > Please respond to the list whether you would support or don't support ado= ption > of this draft. >=20 > The extended WGLC ends on June 10. >=20 > -- Jeff >=20 > On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote: > > This begins a 2 week WG Adoption call for: > > > > > > > > draft-kini-i2rs-fb-rib-info-model-03 > > > > draft-hares-i2rs-fb-rib-data-model-03 > > > > draft-hares-i2rs-pkt-eca-data-model-02 > > > > > > > > Please send your comments on the technical merits and usefulness of > > these models. > > > > > > > > Sue and Jeff > > >=20 > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri May 27 18:10:53 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4560312D586 for ; Fri, 27 May 2016 18:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlLPvZJXndEj for ; Fri, 27 May 2016 18:10:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B4D12D108 for ; Fri, 27 May 2016 18:10:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKY23501; Sat, 28 May 2016 01:10:37 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 28 May 2016 02:10:36 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 28 May 2016 09:10:29 +0800 From: "Dongjie (Jimmy)" To: Jeffrey Haas , "i2rs@ietf.org" Thread-Topic: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) Thread-Index: AQHRtdbt0/5/Sybi7Eujd2YyfBycS5/Nj46Q Date: Sat, 28 May 2016 01:10:29 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E837BD@NKGEML515-MBS.china.huawei.com> References: <002201d18c6f$24bab790$6e3026b0$@ndzh.com> <20160524161622.GK17462@pfrc.org> In-Reply-To: <20160524161622.GK17462@pfrc.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5748F00E.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c5c4399e588a13a5e36c433fa4472de2 Archived-At: Subject: Re: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June 10) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 01:10:42 -0000 I support the adoption of these drafts.=20 -Jie > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Wednesday, May 25, 2016 12:16 AM > To: i2rs@ietf.org > Subject: [i2rs] Extending WG adoption call for FB-RIB drafts (ending June= 10) >=20 > Working Group, >=20 > In the prior poll, we didn't get much in the way of input for adopting th= e > filter-based RIB work. This work is explicitly in charter, and more > importantly is *modeling* work and doesn't have to immediately deal with > our protocol headaches. :-) >=20 > Please respond to the list whether you would support or don't support > adoption of this draft. >=20 > The extended WGLC ends on June 10. >=20 > -- Jeff >=20 > On Fri, Apr 01, 2016 at 07:35:13PM -0400, Susan Hares wrote: > > This begins a 2 week WG Adoption call for: > > > > > > > > draft-kini-i2rs-fb-rib-info-model-03 > > > > draft-hares-i2rs-fb-rib-data-model-03 > > > > draft-hares-i2rs-pkt-eca-data-model-02 > > > > > > > > Please send your comments on the technical merits and usefulness of > > these models. > > > > > > > > Sue and Jeff > > >=20 > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri May 27 19:32:46 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F62A12B056 for ; Fri, 27 May 2016 19:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAXhz8xMnWDU for ; Fri, 27 May 2016 19:32:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A9312B038 for ; Fri, 27 May 2016 19:32:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPS62048; Sat, 28 May 2016 02:32:39 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 28 May 2016 03:32:38 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Sat, 28 May 2016 10:32:27 +0800 From: "Dongjie (Jimmy)" To: "Zhangxian (Xian)" , "draft-ietf-i2rs-yang-l2-network-topology@tools.ietf.org" , "i2rs@ietf.org" Thread-Topic: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l2-network-topology Thread-Index: AQHRsAq9RFmKWcS270KqpnV/dHGMVp++Y+cwgA88reA= Date: Sat, 28 May 2016 02:32:26 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E83804@NKGEML515-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57490347.012A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 00867e79bc9e955359079ce1a4ca1d53 Archived-At: Cc: Henning Rogge , Susan Hares Subject: Re: [i2rs] [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l2-network-topology X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 02:32:45 -0000 SGkgSGVubmluZywgDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZpZXcgYW5kIHNvcnJ5IGZv ciB0aGUgbGF0ZSByZXNwb25zZS4gUGxlYXNlIHNlZSBteSByZXBsaWVzIGlubGluZToNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpMnJzIFttYWlsdG86aTJycy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWmhhbmd4aWFuIChYaWFuKQ0KPiBTZW50OiBXZWRu ZXNkYXksIE1heSAxOCwgMjAxNiA0OjUxIFBNDQo+IFRvOiBkcmFmdC1pZXRmLWkycnMteWFuZy1s Mi1uZXR3b3JrLXRvcG9sb2d5QHRvb2xzLmlldGYub3JnOyBpMnJzQGlldGYub3JnDQo+IENjOiBI ZW5uaW5nIFJvZ2dlIDxocm9nZ2VAZ21haWwuY29tPjsgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpo LmNvbT4NCj4gU3ViamVjdDogW2kycnNdIEZXOiBbUlRHLURJUl0gUm91dGluZyBkaXJlY3RvcmF0 ZSBRQSByZXZpZXcgb2YNCj4gZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDItbmV0d29yay10b3BvbG9n eQ0KPiANCj4gVG8gZ2V0IHRoZSBhdHRlbnRpb24gb2YgZHJhZnQgYXV0aG9ycyBhbmQgdGhlIFdH IHRvIHRoZSBmb2xsb3dpbmcNCj4gcmV2aWV3L2NvbW1lbnRzLg0KPiANCj4gVGhhbmsgSGVubmlu ZyBmb3IgdGhlIGNvbnN0cnVjdGl2ZSBjb21tZW50cy4NCj4gDQo+IENoZWVycywNCj4gWGlhbg0K PiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcnRnLWRpciBbbWFpbHRv OnJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhlbm5pbmcgUm9nZ2UNCj4g U2VudDogMjAxNuW5tDXmnIgxN+aXpSAxNTowNw0KPiBUbzogWmhhbmd4aWFuIChYaWFuKTsgam9u YXRoYW4uaGFyZHdpY2tAbWV0YXN3aXRjaC5jb207DQo+IGpvbi5odWRzb25AZ21haWwuY29tOyBz aGFyZXNAbmR6aC5jb20gPj4gU3VzYW4gSGFyZXMNCj4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtSVEctRElSXSBSb3V0aW5nIGRpcmVjdG9yYXRlIFFBIHJldmlldyBvZg0K PiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5DQo+IA0KPiBIaSwNCj4g DQo+IEkgaGF2ZSBiZWVuIGFza2VkIHRvIHByb3ZpZGUgYSByZXZpZXcgdG8gdGhlIGZvbGxvd2lu ZyBkb2N1bWVudCB0byB0aGUNCj4gcm91dGluZyBkaXJlY3RvcmF0ZSBtYWlsaW5nIGxpc3QuDQo+ IA0KPiBQbGVhc2UgYmUgYXdhcmUgdGhhdCB0aGlzIGlzIHRoZSBmaXJzdCB0aW1lIEkgd29yayB3 aXRoIFlBTkcgYW5kIHJlbGF0ZWQNCj4gZHJhZnRzLg0KPiANCj4gDQo+IERvY3VtZW50OiBkcmFm dC1pZXRmLWkycnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAyDQo+IA0KPiBSZXZpZXdlcjog SGVubmluZyBSb2dnZQ0KPiBSZXZpZXcgRGF0ZTogTWFpIDE2dGgsIDIwMTYNCj4gDQo+IA0KPiBJ bnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KPiANCj4gDQo+IFRoZSBkYXRhIHN0cnVj dHVyZSBzdWdnZXN0ZWQgYnkgdGhlIGRyYWZ0IGlzIHJlYXNvbmFibGUgYW5kIHdvdWxkIGZpdA0K PiBtb3N0IExheWVyMiBuZXR3b3JrIHRlY2hub2xvZ2llcy4gSSBoYXZlIGEgY291cGxlIG9mIHBv aW50cyBvbiB0aGUgZHJhZnQNCj4gZG9jdW1lbnQgd2hpY2ggbWlnaHQgYmUgd29ydGggbG9va2lu ZyBpbnRvOg0KPiANCj4gKiBUaGUgaW50cm9kdWN0aW9uIGluDQo+IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWkycnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAyDQo+ IGluY2x1ZGVzIGEgbGluayB0byAiSS1ELmlldGYtbmV0bW9kLXJmYzYwMjBiaXMiIHRoYXQgbGlu a3MgYmFjayB0byB0aGUNCj4gZHJhZnQgZG9jdW1lbnQgaXRzZWxmLiBNYXliZSBzb21lIGxpbmtz IGluIHRoZSBkb2N1bWVudCByZWZlciB0byBhbg0KPiBvbGRlciBuYW1lIG9mIHRoZSBkcmFmdD8N Cg0KSSBmb3VuZCBvdXQgdGhhdCBpZiB5b3UgY2xpY2sgdGhlIGxpbmsgaW4gdGhlIG1haW4gdGV4 dCwgaXQgd2lsbCBnbyB0byB0aGUgcmVmZXJlbmNlIGF0IHRoZSBlbmQgb2YgdGhlIGRyYWZ0LiBU aGVuIGlmIHlvdSBjbGljayB0aGUgbGluayBpbiB0aGUgcmVmZXJlbmNlLCBpdCB3aWxsIG9wZW4g dGhlIDYwMjBiaXMgZHJhZnQuIE5vdCBxdWl0ZSBzdXJlIHdoeSBpdCB3b3JrcyBsaWtlIHRoaXMs IGJ1dCB0aGUgZHJhZnQgbmFtZSBpcyBjb3JyZWN0IGluIGJvdGggcGxhY2VzLg0KDQo+ICogdGhl ICJ0ZXJtaW5hdGlvbi1wb2ludCIgZWxlbWVudCBvbmx5IGNvbnRhaW5zIHRoZSB0eXBlcyAiZXRo ZXJuZXQiIGFuZA0KPiAibGVnYWN5IiAod2hpY2ggZG9lcyBub3QgY29udGFpbiBhbnkgZGF0YSBs aWtlIG1hYy1hZGRyZXNzKS4gSXMgdGhpcw0KPiByZWFzb25hYmxlIG9yIHNob3VsZCBhIGZldyBk YXRhIGVsZW1lbnRzIG1vdmVkIGZyb20gdGhlICJldGhlcm5ldCINCj4gY2F0ZWdvcnkgdG8gdGhl ICJsMi10ZXJtaW5hdGlvbi1wb2ludC1hdHRyaWJ1dGVzIiBjYXRlZ29yeT8NCg0KR29vZCBxdWVz dGlvbi4gUHJldmlvdXNseSB3ZSBkaWRuJ3QgYWRkIG11Y2ggZGF0YSB1bmRlciB0aGUgbGVnYWN5 IHR5cGUsIGJ1dCBhcyB5b3Ugc2FpZCwgc29tZXRoaW5nIGxpa2UgbWFjLWFkZHJlc3MgZm9yIEV0 aGVybmV0IHNob3VsZCBhbHNvIGJlIGluY2x1ZGVkIGZvciBsZWdhY3kuIFdlIHdpbGwgY29uc2lk ZXIgdGhpcyBpbiBuZXh0IHJldmlzaW9uLg0KDQo+ICogdGhlcmUgYXJlIGRpZmZlcmVudCB0eXBl cyBvZiBWTEFOIHRhZ3MgYmUgdXNlZC4uLiBzaG91bGQgdGhlcmUgYmUNCj4gYW5vdGhlciBmaWVs ZCAoInZsYW4tdHlwZSIgPykgdG8gYW5ub3VuY2UgODAyLjFhZCBRaW5RIHVzYWdlPyBJIHRoaW5r DQo+IHRoZSA4MDIuMWFkIHRhZyBpcyBhbHNvIHNvbWV0aW1lcyBhbHNvIHVzZWQgdG8gbW92ZSBW TEFOIG92ZXIgYSBzd2l0Y2gNCj4gdGhhdCBkb2Vzbid0IHN1cHBvcnQgaXQgKHVua25vd24gRXRo ZXJ0eXBlcyBhcmUgdXN1YWxseSBqdXN0IGlnbm9yZWQpLA0KPiB3aGljaCBtZWFucyBqdXN0IGtu b3dpbmcgdGhlIFZMQU4taWQgaXMgbm90IGVub3VnaCB0byByZWFjaCB0aGUgZW5kcG9pbnQuDQoN CkluIHRoaXMgZHJhZnQgYW4gaWRlbnRpdHlyZWYgIiBldGgtZW5jYXBzdWxhdGlvbiIgaXMgdXNl ZCB0byBzcGVjaWZ5IHRoZSBFdGhlcm5ldCBlbmNhcHN1bGF0aW9uIG9mIHRoZSB0ZXJtaW5hdGlv biBwb2ludCwgd2hpY2ggY2FuIGJlIG5hdGl2ZSBFdGhlcm5ldCwgUWluUSwgTWFjLWluLU1hYywg ZXRjLiBGb3IgZWFjaCBlbmNhcHN1bGF0aW9uIHR5cGUsIGFuIGlkZW50aXR5IGlzIGRlZmluZWQu DQoNCj4gKiB0aGUgdHlwZSBvZiBldGhlcm5ldCAoMTAwLCAxMDAwLCAxMDAwMCkgb3IgZGF0YS1y YXRlIGNvdWxkIGJlIGFuDQo+IGltcG9ydGFudCBhdHRyaWJ1dGUgZm9yIGFuIGV0aGVybmV0IHRl cm1pbmF0aW9uIHBvaW50LCBub3Qgb25seSBmb3IgbGlua3MuDQoNClllcywgdGhlIGRhdGEgcmF0 ZSAoYmFuZHdpZHRoKSBvZiBhIGxpbmsgY2FuIGJlIGRldGVybWluZWQgYnkgdGhlIHR5cGUvY2Fw YWJpbGl0eSBvZiB0aGUgY29ubmVjdGVkIHBoeXNpY2FsIGludGVyZmFjZXMuIA0KDQpXaGlsZSBh cyB0aGlzIEwyIHRvcG9sb2d5IG1vZGVsIGlzIGRlc2lnbmVkIHRvIGJlIGFwcGxpY2FibGUgZm9y IGJvdGggcGh5c2ljYWwgYW5kIHZpcnR1YWwgbGF5ZXIgMiBuZXR3b3JrcywgYXR0cmlidXRlcyBv ZiBwaHlzaWNhbCBpbnRlcmZhY2VzIGFyZSBub3QgaW5jbHVkZWQuDQoNCkJlc3QgcmVnYXJkcywN CkppZQ0KDQo+IEhlbm5pbmcgUm9nZ2UNCj4gLS0NCj4gRGlwbG9tLUluZm9ybWF0aWtlciBIZW5u aW5nIFJvZ2dlICwgRnJhdW5ob2Zlci1JbnN0aXR1dCBmw7xyDQo+IEtvbW11bmlrYXRpb24sIElu Zm9ybWF0aW9uc3ZlcmFyYmVpdHVuZyB1bmQgRXJnb25vbWllIEZLSUUNCj4gS29tbXVuaWthdGlv bnNzeXN0ZW1lIChLT00pDQo+IEZyYXVuaG9mZXIgU3RyYcOfZSAyMCwgNTMzNDMgV2FjaHRiZXJn LCBHZXJtYW55DQo+IFRlbGVmb24gKzQ5IDIyOCA5NDM1LTk2MSwgICBGYXggKzQ5IDIyOCA5NDM1 IDY4NQ0KPiBtYWlsdG86aGVubmluZy5yb2dnZUBma2llLmZyYXVuaG9mZXIuZGUgaHR0cDovL3d3 dy5ma2llLmZyYXVuaG9mZXIuZGUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGkycnMgbWFpbGluZyBsaXN0DQo+IGkycnNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo= From nobody Mon May 30 17:43:30 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7876D12D58A for ; Mon, 30 May 2016 17:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AP-GceZYUwD for ; Mon, 30 May 2016 17:43:26 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0685B12D586 for ; Mon, 30 May 2016 17:43:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: Date: Mon, 30 May 2016 20:43:23 -0400 Message-ID: <000601d1bad5$70523090$50f691b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01D1BAB3.E946AB10" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdG61L6g3aiXYrSlRh21l2xYII5VzQ== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 00:43:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0007_01D1BAB3.E946AB10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01D1BAB3.E946AB10" ------=_NextPart_001_0008_01D1BAB3.E946AB10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I2RS Meeting will try a new format to aid Participants in multiple Time = zones. The presentation for this interim has been recorded, and the = presentation is online. We expect participants to listen to the = interim meeting presentation before the session. During the 1 hour = interim, we will discuss the questions below. We will summarize the = results of the interim, and start mail threads on these questions this = week.=20 =20 Webex info:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm163079dec821ba49f3eec1f97b52006= f =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) =20 Topic:=20 We will focus on the one topic: the discussion of the I2RS ephemeral = state requirements. You can review the ephemeral state requirements at: = =20 https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ =20 The presentation for this interim has been recorded, and the = presentation is online. The questions are listed below, and we will = start mail threads on this questions this week. =20 =20 Agenda:=20 =20 The agenda is simply a discussion of I2RS Ephemeral State requirements. = The presentation is online, and it is expected people will view the = presentation before the meeting.=20 =20 Description: Ephemeral State Update Review=20 =20 Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=3D47311823b09d78f541a6276705b187= 95 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=3Dd57e5e4c6ba68521d21dd33971d3b5= 8d =20 presentation:=20 https://www.ietf.org/proceedings/interim/2016/06/01/i2rs/slides/slides-in= terim-2016-i2rs-9-0.pdf =20 Discussion of I2RS Ephemeral State=20 Questions:=20 1. Do you think Ephemeral-REQ-05 covers the resource constraint issue discussed on the list and at IETF-95?=20 =20 2. Does Ephemeral-REQ-06 provide the Yang requirements in=20 a clear fashion? Do you have any suggestions for alternative text?=20 =20 3. Do you think any of the Ephemeral-REQ-07 NETCONF Changes=20 are not necessary? If so, what changes would you leave out? Do the "policy-knobs" seem useful to you?=20 =20 4. Do you think any of the Ephemeral-REQ-08 RESTCONF changes=20 are not necessary? If so, what changes would you leave out?=20 Do we need all the features (yang module library, call-home,=20 server)?=20 =20 =20 5. Do you think the pub/sub requirements are sufficient?=20 (PUB-SUB-REQ-01, PUB-SUB-REQ-02) =20 6. Do you have any concerns about Ephemeral-REQ-01 to=20 Ephemeral-REQ-04?=20 =20 =20 From: I2RS Working Group [mailto:messenger@webex.com]=20 Sent: Monday, May 30, 2016 8:18 PM To: i2rs-chairs@tools.ietf.org Subject: (Forward to others) WebEx meeting invitation: Ephemeral State =20 You can forward this invitation to others.=20 =20 Hello,=20 I2RS Working Group invites you to join this WebEx meeting.=20 =20 =20 =20 Ephemeral State=20 Wednesday, June 1, 2016=20 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr=20 =20 Meeting number (access code): 647 996 643=20 =20 Meeting password: wisp.o.wind =20 =20 =20 = Add to Calendar=20 When it's time, = join the meeting. =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Toll-free calling = restrictions =20 =20 =20 Can't join the meeting?=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. =20 ------=_NextPart_001_0008_01D1BAB3.E946AB10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I2RS Meeting will try a new format to aid Participants in multiple = Time zones.=C2=A0=C2=A0 =C2=A0The presentation for this interim has been = recorded, and the presentation is online.=C2=A0 =C2=A0We expect = participants to listen to the interim meeting presentation before the = session.=C2=A0 During the 1 hour interim, we will discuss the questions = below.=C2=A0=C2=A0 We will summarize the results of the interim, and = start mail threads on these questions this week. =

 

Webex info:

https://ietf.webex.com/ietf/j.php?MTID=3Dm163079dec821ba49f3eec1f97b52= 006f

 

Join by phone

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

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

 

Topic:

We will focus on the one topic: the discussion of the I2RS ephemeral = state requirements.=C2=A0 You can review the ephemeral state = requirements at: =C2=A0

https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

 

The presentation for this interim has been recorded, and the = presentation is online.=C2=A0 The questions are listed below, and we = will start mail threads on this questions this week. = =C2=A0

 

Agenda:

 

The agenda is simply a discussion of I2RS Ephemeral State = requirements.=C2=A0

The presentation is online, and it is expected people will view the = presentation

before the meeting.

 

Description: Ephemeral State Update Review =

 

Streaming recording link:

https://ietf.webex.com/ietf/ldr.php?RCID=3D47311823b09d78f541a6276705b= 18795

Download recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=3Dd57e5e4c6ba68521d21dd33971d= 3b58d

 

presentation:

https://www.ietf.org/proceedings/interim/2016/06/01/i2rs/slides/slides= -interim-2016-i2rs-9-0.pdf

 

Discussion of I2RS Ephemeral State

Questions:

1.=C2=A0 Do you think Ephemeral-REQ-05 covers the resource = constraint

issue discussed on the list and at IETF-95?

 

2.=C2=A0 Does Ephemeral-REQ-06 provide the Yang requirements in =

a clear fashion?=C2=A0 Do you have any suggestions for alternative = text?

 

3. Do you think any of the Ephemeral-REQ-07 NETCONF Changes =

=C2=A0=C2=A0=C2=A0are not necessary?=C2=A0=C2=A0 If so, what changes = would you leave out?

=C2=A0=C2=A0 Do the "policy-knobs" seem useful to you? =

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

4. Do you think any of the Ephemeral-REQ-08 RESTCONF changes =

=C2=A0=C2=A0=C2=A0are not necessary?=C2=A0 If so, what changes would = you leave out?

=C2=A0=C2=A0=C2=A0Do we need all the features (yang module library, = call-home,

=C2=A0=C2=A0=C2=A0server)?

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

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

5. Do you think the pub/sub requirements are sufficient? =

=C2=A0=C2=A0=C2=A0=C2=A0(PUB-SUB-REQ-01, = PUB-SUB-REQ-02)

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

6. Do you have any concerns about Ephemeral-REQ-01 to =

=C2=A0=C2=A0=C2=A0Ephemeral-REQ-04?

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

 

From:= = I2RS Working Group [mailto:messenger@webex.com]
Sent: Monday, = May 30, 2016 8:18 PM
To: = i2rs-chairs@tools.ietf.org
Subject: (Forward to others) WebEx = meeting invitation: Ephemeral State

 

You can forward this invitation to others. =

 

Hello,

I2RS Working Group invites you to join this WebEx meeting. =

 

 

 

Ephemeral = State =

Wednesday, June 1, 2016

10:00 am  |  Eastern Daylight Time (New York, = GMT-04:00)  |  1 hr =

 

Meeting number (access code): 647 996 643 =

 

Meeting password: wisp.o.wind

 

 

 

 

Add to = Calendar

When it's time, join the = meeting.

 

 

Join by = phone

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

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

Toll-free = calling = restrictions

 

 

 

Can't join the meeting? =

 

 

 

= IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session.

 

------=_NextPart_001_0008_01D1BAB3.E946AB10-- ------=_NextPart_000_0007_01D1BAB3.E946AB10 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting.ics" BEGIN:VCALENDAR=0A= PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN=0A= VERSION:2.0=0A= METHOD:REQUEST=0A= BEGIN:VTIMEZONE=0A= TZID:Eastern Time=0A= BEGIN:STANDARD=0A= DTSTART:20141101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0A= TZOFFSETTO:-0500=0A= TZNAME:Standard Time=0A= END:STANDARD=0A= BEGIN:DAYLIGHT=0A= DTSTART:20140301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0A= TZOFFSETTO:-0400=0A= TZNAME:Daylight Savings Time=0A= END:DAYLIGHT=0A= END:VTIMEZONE=0A= BEGIN:VEVENT=0A= ATTENDEE;CN=3D"I2RS Working = Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:i2rs-chairs@tools.ietf.o= rg=0A= ORGANIZER;CN=3D"I2RS Working Group":MAILTO:i2rs-chairs@tools.ietf.org=0A= DTSTART;TZID=3D"Eastern Time":20160601T100000=0A= DTEND;TZID=3D"Eastern Time":20160601T110000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1464653868=0A= UID:2091576b-b738-4fea-ba04-4869e4accfcb=0A= DTSTAMP:20160601T140000Z=0A= DESCRIPTION:\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dma082a23428e121666ccccd= 02c07dd73a\nMeeting number (access code): 647 996 643\nMeeting password: = wisp.o.wind\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free number = (US/Canada) \n1-650-479-3208 Call-in toll number = (US/Canada)\n\nToll-free dialing restrictions: = \nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join = the meeting?\nhttps://help.webex.com/docs/DOC-5412\n\n\nIMPORTANT = NOTICE: Please note that this WebEx service allows audio and other = information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:  
 
 
Join WebEx = meeting
Meeting number (access code): 647 996 = 643
Meeting = password:wisp.o.wind
 
 
Join by = phone 
1-877-668-4493 Call-in toll free = number (US/Canada) 
1-650-479-3208 Call-in toll number = (US/Canada) 
Toll-free calling = restrictions  


 
Can't join the meeting? =  
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the session.=0A= SUMMARY:Ephemeral State=0A= PRIORITY:5=0A= CLASS:PUBLIC=0A= BEGIN:VALARM=0A= TRIGGER:-PT5M=0A= ACTION:DISPLAY=0A= DESCRIPTION:Reminder=0A= END:VALARM=0A= END:VEVENT=0A= END:VCALENDAR=0A= ------=_NextPart_000_0007_01D1BAB3.E946AB10-- From nobody Mon May 30 23:38:55 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BCF12D177 for ; Mon, 30 May 2016 23:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpDT3ZvA7_jg for ; Mon, 30 May 2016 23:38:50 -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 3335712D6A6 for ; Mon, 30 May 2016 23:38: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 681F8AC1; Tue, 31 May 2016 08:38:48 +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 LRol-nUBQr7g; Tue, 31 May 2016 08:38:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 31 May 2016 08:38:46 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 820EE2004E; Tue, 31 May 2016 08:38:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xHDvkjc1M-ar; Tue, 31 May 2016 08:38:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFF6C20047; Tue, 31 May 2016 08:38:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DAC8D3AFD518; Tue, 31 May 2016 08:38:42 +0200 (CEST) Date: Tue, 31 May 2016 08:38:42 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160531063840.GA21289@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, 'Jeffrey Haas' , 'Alia Atlas' References: <000601d1bad5$70523090$50f691b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000601d1bad5$70523090$50f691b0$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 06:38:53 -0000 > Discussion of I2RS Ephemeral State > > Questions: > > 1. Do you think Ephemeral-REQ-05 covers the resource constraint > issue discussed on the list and at IETF-95? > I read: Ephemeral-REQ-05: The ability to augment an object with appropriate YANG structures that have the property of being ephemeral. An object defined as Yang module, schema tree, a schema node, submodule or components of a submodule (derived types, groupings, data node, RPCs, actions, and notifications". I have trouble to parse this since the 1st sentence does not seem to make sense for each element that you consider an object. That said, the real issue here are lifetimes. The lifetime of a config true object is determined by config changes, the lifetime of config false objects is determined by operational state changes. What happens to an ephemeral augmentation of objects if their lifetime expires? The revised datastore model I have described in draft-schoenw-netmod-revised-datastores-00 links the ephemeral state only to operational state, not at all to configuration. Does this model not satisfy the I2RS requirements and make things much simpler? 2. Does Ephemeral-REQ-06 provide the Yang requirements in > a clear fashion? Do you have any suggestions for alternative text? I think it is clear but broken. In particular the part about indicating secure/non-secure transport. > 3. Do you think any of the Ephemeral-REQ-07 NETCONF Changes > are not necessary? If so, what changes would you leave out? > Do the "policy-knobs" seem useful to you? > > 4. Do you think any of the Ephemeral-REQ-08 RESTCONF changes > are not necessary? If so, what changes would you leave out? > Do we need all the features (yang module library, call-home, > server)? I think this needs to be trimmed down. I think it should be avoided to create I2RS specific solutions for things that are already in place (e.g., NETCONF has a mechanism for protocol capability discovery and negotiation, NETCONF already supports multiple (secure) transports). I think that having a clear architectural view is essential. I am not sure the 'single pane of glass' model is the way to go. I think the decision on the architectural model is key because it impacts many of the other requirements and solutions. You want both NC and RC to support XML and JSON and SSH and TLS and (plaintext) TCP? Does this maximum of variability and flexibility really help interoperability? Perhaps things should be reorganized into things that are protocol agnostic (and should not be repeated) and things that are protocol specific - if there is indeed a need to work with multiple protocols. I also think that it is not needed to write down requirements to NETCONF for things that are already solved or being worked on. > 5. Do you think the pub/sub requirements are sufficient? > > (PUB-SUB-REQ-01, PUB-SUB-REQ-02) I would hope that draft-ietf-i2rs-pub-sub-requirements-09 covers everything that is needed. Again, this is linked to architectural question. The text, for example, assumes that there is an 'operational data stores'. As of today, this is not really the case. See draft-schoenw-netmod-revised-datastores-00 for more details. > 6. Do you have any concerns about Ephemeral-REQ-01 to > > Ephemeral-REQ-04? I think this sentence in Ephemeral-REQ-04 should be taken out: The designer of ephemeral state modules are advised that such constraints may impact the speed of processing ephemeral state commits and should avoid them when speed is essential. First, it may depend on the architectural model that will be used and it likely also depends on implementation details whether something is fast or not. Or is there in inherent reason why a reference to non-ephemeral state has to be 'slow'? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 31 05:40:15 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB1612D7A0; Tue, 31 May 2016 05:40:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531124007.18728.40884.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 05:40:07 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-08.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 12:40:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-08.txt Pages : 14 Date : 2016-05-31 Abstract: This document covers requests to the NETMOD and NETCONF Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 07:02:47 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DF312D53A for ; Tue, 31 May 2016 07:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEjTw02fsupo for ; Tue, 31 May 2016 07:02:38 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 DA6AE12D542 for ; Tue, 31 May 2016 07:02:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> In-Reply-To: <20160531063840.GA21289@elstar.local> Date: Tue, 31 May 2016 10:02:17 -0400 Message-ID: <00d501d1bb45$0da83500$28f89f00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01D1BB23.869CAF80" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJdaenpM7ljbP1C/TwjkI20GPnldwI0uYM8nqn4TnA= X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Benoit Claise' , 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:02:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D6_01D1BB23.869CAF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Juergen: Thank you for the second response. The questions were on version 8 of the draft. Jeff wanted to review version 8 before posting - so I delayed posting of version 8 until this morning. I've answered your questions based on version 08. I think you understood that the ephemeral datastores defined by i2RS are not what you defined in draft-schoenw-netmod-revised-datastores-00: o The model foresees ephemeral datastores that are by definition not part of the persistent configuration of a device. These ephemeral datastores are considered to interact with the rest of the system like any other control-plane mechanisms (e.g., routing protocols, discovery protocols). [XXX Note that this is different from what is described in some of the I2RS documents. XXX] The difference is that I2RS defines ephemeral configuration and ephemeral operational state. You see this in all of the I2RS data modules. I have augmented your diagram with the proposed I2RS datastore. +------------+ | | // Subject to validation | (ct, ro) | // e.g., missing resources or delays +------------+ // Here I2RS ephemeral configuration fits | // so missing resources/delays can be handled v +------------+ | | - here I2RS defines ephemeral | (ct, ro) | configuration data store +------------+ | // e.g., autodiscovery of values v +--------------------------------+ | |<-- control plane and | (ct + cf, ro) | ephemeral datastores +--------------------------------------------------+ Your definitions ignored the WG requirements and the existing discussions. Is there a reason why? I2RS follows the break between operational state and configuration data store. o configuration datastore: When modeled with YANG, a configuration datastore is realized as an instantiated data tree with configuration data. o Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols. This document is proposed on May 12, 2016 and we have been working on I2RS for over 3 years. You provided something that does not satisfy the requirements of the existing I2RS data models (prepared for over 18 months). Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, May 31, 2016 2:39 AM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements >> Discussion of I2RS Ephemeral State >> >> Questions: >> >> 1. Do you think Ephemeral-REQ-05 covers the resource constraint issue >> discussed on the list and at IETF-95? > > > > Ephemeral-REQ-05: The ability to augment an object with appropriate > YANG structures that have the property of being ephemeral. An object > defined as Yang module, schema tree, a schema node, submodule or > components of a submodule (derived types, groupings, data node, RPCs, > actions, and notifications". Version -08 has the following for -05: Ephemeral-REQ-05: Ephemeral state handling and notifications could increase need for CPU processing, data flow rates across a transport, or the rate of publication of data in a subscription or the logging for traceability. The I2RS Agent SHOULD have the ability to constraints for OAM functions operating to limit CPU processing, data rate across a transport, the rate of publication of data in a subscription, and logging rates; and the I2RS Agent SHOULD have the ability to prioritize some of the management data flows between the I2RS Agent and I2RS Client. In order to constrain resources needed, the I2RS Agent MAY also schedule data flows or split data flows unto multiple data flow streams. I suspect you are working on Ephemeral-REQ-06: Ephemeral-REQ-06: The ability to augment an object with appropriate YANG structures that have the property of being ephemeral. An object defined as any one of the following: o Yang module(and the module's schema tree), o submodule or components of a submodule (e.g. derived types, groupings, data node, RPCs, actions, and notifications), or o a schema node (container, leaf, leaf-list, choice, case, rpc, input, output, notifications, and anyxml). >I have trouble to parse this since the 1st sentence does not seem to make sense for each element that you >consider an object. Do the three things make sense? I used the work "object" because it had not been used in yang 1.1. >That said, the real issue here are lifetimes. The lifetime of a config true object is determined by config >changes, the lifetime of config false objects is determined by operational state changes. What happens to an >ephemeral augmentation of objects if their lifetime expires? For config false objects, the ephemeral augmentation of opstate objects depends on the opstate objects. Let's examine the augmentation of bgp-global-config with node-type (see interim presentation) used for operational state. This operational state exists as long as BGP exists in a node. The data model has not defined a life time. The changes to operational state for node-type would occur when BGP adds different peers. There are three ways a implementation can keep this state: periodically (every n second update), or query bgp-neighbor, or every time an bgp-neighbor changes - queue the change. The data model should define the type of lifetime the operational state has. If a periodic method is used, then the data model should indicate the last time opstate was updated. presentation https://www.ietf.org/proceedings/interim/2016/06/01/i2rs/slides/slides-inter im-2016-i2rs-9-0.pdf If we have opstate that disappears when the lifetime expires, then the ephemeral state would disappear and a notification would be sent to the I2RS client. For example, let us say that dynamic LSP has a lifetime and after the lifetime expires - it disappears. The I2RS client augments the LSP with additional ephemeral operational state. If the dynamic LSP lifetime expires, and the opstate for the LSPs disappears - then the I2RS ephemeral state would disappear as well. A notification would be sent to the I2RS client monitoring such state. The revised datastore model I have described in draft-schoenw-netmod-revised-datastores-00 links the ephemeral state only to operational state, not at all to configuration. Does this model not satisfy the I2RS requirements and make things much simpler? No, it is does not satisfy the I2RS requirements for configuration and operational state. I2RS wants to be able to query applied configuration (ephemeral and local configuration) as well as the operational state. I2RS state may have routes with next-hop that are intended - that is the next-hop is not resolved. >> 2. Does Ephemeral-REQ-06 provide the Yang requirements in > >a clear fashion? Do you have any suggestions for alternative text? >I think it is clear but broken. In particular the part about indicating secure/non-secure transport. >From version 8: Ephemeral-REQ-07: Yang MUST have a way to indicate in a data model that nodes have the following properties: ephemeral, writable/not- writable, and status/configuration. Yang must also have a way to specify on a module or submodule level whether the data MAY optionally flow across an non-secure transport. Do you feel this is better or still broken? >> 3. Do you think any of the Ephemeral-REQ-07 NETCONF Changes >> are not necessary? If so, what changes would you leave out? >> Do the "policy-knobs" seem useful to you? >> >> 4. Do you think any of the Ephemeral-REQ-08 RESTCONF changes >> are not necessary? If so, what changes would you leave out? >> Do we need all the features (yang module library, call-home, >> server)? >I think this needs to be trimmed down. I think it should be avoided to create I2RS specific solutions for things >that are already in place (e.g., NETCONF has a mechanism for protocol capability discovery and negotiation, >NETCONF already supports multiple (secure) transports). >I think that having a clear architectural view is essential. I am not sure the 'single pane of glass' model is the >way to go. I think the decision on the architectural model is key because it impacts many of the other >requirements and solutions. Please see version 8 of the document. If you feel that I2RS requirements suggest an existing solution, please indicate the solution. Per your request, these are requirements, not solutions. NETCONF & RESTCONF changes 1) I2rs protocol-version 2) Support module scope (ephemeral only, mixed (config & ephemeral), mixed (opstate & ephemeral), 3) Ability to restrict non-secure transport to specific models or submodules (see above) 4) Ephemeral overwriting of local configuration state controlled by 2 knobs 5) Ephemeral overwriting of local configuration state is considered as composite of all I2RS clients 6) Write conflicts handled as error using priority (ephemeral-REQ-10 to ephemeral-REQ-13). Support for write-conflict notification Existing features: XML/JSON encoding, features (pub-sub, yang module library, call-home, server-module). NETCONF only: 1) multiple message support - "I2RS all-or-nothng" aka NETCONF "roll-back-on-error" 2) transports: SSH, TLS, TCP with non-secure 3) No support of writable-running, candidate data store, confirmed commit, or distinct start-up. RESTCONF only: 1) http over TLS, http used in non-secure fashion 2) support for development of pub/sub in RESTCONF 3) Expansion of RESTCONF write-config support to include I2RS config support (rather than replacement). >You want both NC and RC to support XML and JSON and SSH and TLS and >(plaintext) TCP? Does this maximum of variability and flexibility really help interoperability? Perhaps things >should be reorganized into things that are protocol agnostic (and should not be repeated) and things that are >protocol specific - if there is indeed a need to work with multiple protocols. No, see above. Per your comments, version 08 clarifies. I have provided this above. The current format was chosen based on request from NETMOD/NETCONF for protocol specific. I will be glad to switch the format to common, NETCONF only, RESTCONF only. >I also think that it is not needed to write down requirements to NETCONF for things that are already solved > or being worked on. Thank you for your comments. However, some people have requested us to indicate which NETCONF/RESTCONF features are required. This allows implementers to know what NETCONF/RESTCONF features must be implemented. > 5. Do you think the pub/sub requirements are sufficient? > > (PUB-SUB-REQ-01, PUB-SUB-REQ-02) >I would hope that draft-ietf-i2rs-pub-sub-requirements-09 covers everything that is needed. Again, this is >linked to architectural question. The text, for example, assumes that there is an 'operational data stores'. As >of today, this is not really the case. See >draft-schoenw-netmod-revised-datastores-00 for more details. The draft proposal does not align with the I2RS architecture design of ephemeral having (config + operational state). It does not allow the I2RS client to query both ephemeral config and ephemeral operational state separately. See above. >> 6. Do you have any concerns about Ephemeral-REQ-01 to >> >> Ephemeral-REQ-04? >I think this sentence in Ephemeral-REQ-04 should be taken out: >The designer of ephemeral state modules are advised that such > constraints may impact the speed of processing ephemeral state > commits and should avoid them when speed is essential. > First, it may depend on the architectural model that will be used and it likely also depends on > implementation details whether something is fast or not. > Or is there in inherent reason why a reference to non-ephemeral state has to be 'slow'? I agree that architecture + implementation defines the final speed of a implementation. Today's experience with NETCONF implementations (architecture + speed) leads to this comment. Since, this particular sentence was requested by several people - we will need to poll the WG to determine if this sentence gets removed. I will add it to the questions for the WG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_00D6_01D1BB23.869CAF80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen:

 

Thank = you for the second response.    The questions were on = version 8 of the draft.  Jeff wanted to review version 8 before = posting - so I delayed posting of version 8 until this morning. =    I’ve answered your questions based on version = 08.

 

I think you understood that the ephemeral = datastores defined by i2RS are not what you defined in = draft-schoenw-netmod-revised-datastores-00:

 

   o  The model foresees ephemeral =
datastores that are by definition not
      part of the =
persistent configuration of a device.  These =
ephemeral
      datastores are =
considered to interact with the rest of the =
system
      like any other =
control-plane mechanisms (e.g., routing =
protocols,
      discovery =
protocols).  [XXX Note that this is different from =
what
      is described in =
some of the I2RS documents.  XXX]

 

The = difference is that I2RS defines ephemeral configuration and ephemeral = operational state.  You see this in all of the I2RS data modules. =  I have augmented your diagram with the proposed I2RS datastore. =

 

      =
;    =
          +------------=
+
      =
;            =
  | <intended> |  //  Subject to =
validation
      =
;            =
  | (ct, ro)   | //   e.g., missing resources =
or delays
      =
;            =
  +------------+   // Here I2RS ephemeral =
configuration fits 
      =
;            =
        |    =
     //  so missing resources/delays can be =
handled
      =
;            =
        =
v
      =
;            =
  +------------+
      =
;            =
  | <applied>  |    - here I2RS =
defines ephemeral 
      =
;            =
  | (ct, ro)   |      =
configuration data store 
      =
;            =
  +------------+
      =
;            =
        =
|         // e.g., autodiscovery =
of values
      =
;            =
        =
v
      =
;    =
+--------------------------------+
      =
;    | =
<operational-state>        =
    |<-- control plane =
and
      =
;    | (ct + cf, =
ro)           &nbs=
p;      |    ephemeral =
datastores

        &nbs= p;            = ; +--------------------------------------------------+

 

Your = definitions ignored the WG requirements and the existing = discussions.  Is there a reason why?  I2RS follows the break = between operational state and configuration data store. = 

 
o  configuration datastore: =
When modeled with YANG, a =
configuration
      =
datastore is realized as an instantiated data tree =
with
      =
configuration data.
 
=
o  Operational state =
data is a set of data that has been obtained =
by
      the =
system at runtime and influences the system's behavior =
similar
      to =
configuration data.  In contrast to configuration =
data,
      =
operational state is transient and modified by interactions =
with
      =
internal components or other systems via specialized =
protocols.
 
This document is proposed on May 12, 2016 and we have been working on =
I2RS for over 3 years.  You provided something that does not =
satisfy the requirements of the existing I2RS data models (prepared for =
over 18 months).  

 

 

Sue = Hares

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder
Sent: Tuesday, May 31, 2016 2:39 AM
To: Susan = Hares
Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Alia Atlas'
Subject: Re: = [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: = Ephemeral State Requirements

 

>> Discussion of I2RS Ephemeral = State

>>

>> Questions:

>>

>> 1.  Do you think Ephemeral-REQ-05 = covers the resource constraint issue

>> discussed on the list and at = IETF-95?

> 

> 

> 

= > Ephemeral-REQ-05: The ability to augment an object with = appropriate

> YANG structures = that have the property of being ephemeral.  An = object

> defined as Yang = module, schema tree, a schema node, submodule or

> components of a submodule (derived types, = groupings, data node, RPCs,

> = actions, and notifications".

 

Version -08 has the following for -05: =

 

 

   = Ephemeral-REQ-05: Ephemeral state handling and notifications = could

   increase need for CPU processing, = data flow rates across a transport,

   or the = rate of publication of data in a subscription or the = logging

   for traceability.  The I2RS = Agent SHOULD have the ability to

   = constraints for OAM functions operating to limit CPU processing, = data

   rate across a transport, the rate of = publication of data in a

   = subscription, and logging rates; and the I2RS Agent SHOULD have = the

   ability to prioritize some of the = management data flows between the

   I2RS Agent = and I2RS Client.  In order to constrain resources = needed,

   the I2RS Agent MAY also schedule data = flows or split data flows unto

   multiple = data flow streams.

 

I suspect you are = working on Ephemeral-REQ-06:

 

   = Ephemeral-REQ-06: The ability to augment an object with = appropriate

   YANG structures that have the = property of being ephemeral.  An object

   defined as = any one of the following:

   o  = Yang module(and the module's schema tree),

   o  = submodule or components of a submodule (e.g. derived = types,

      groupings, data = node, RPCs, actions, and notifications), or

   o  a = schema node (container, leaf, leaf-list, choice, case, = rpc,

      input, output, = notifications, and anyxml).

 

>I have trouble to parse this since the 1st = sentence does not seem to make sense for each element that you = >consider an object.

Do the = three things make sense?  I used the work "object" = because it had not been used in yang 1.1. 

 

>That said, the real issue here are lifetimes. = The lifetime of a config true object is determined by config = >changes, the lifetime of config false objects is determined by = operational state changes. What happens to an >ephemeral augmentation = of objects if their lifetime expires?

 

For config false = objects,  the ephemeral augmentation of opstate objects depends on = the opstate objects. 

 

Let's examine the = augmentation of bgp-global-config with node-type (see interim = presentation) used for operational state.  This operational state = exists as long as BGP exists in a node.   The data model has = not defined a life time.   The changes to operational state = for node-type would occur when BGP adds different peers.  There are = three ways a implementation can keep this state:  periodically = (every n second update), or

query bgp-neighbor, or = every time an bgp-neighbor changes - queue the change.   The = data model should define the type of lifetime the operational state = has.   If a periodic method is used, then the data model = should indicate the last time opstate was updated. =   

 

presentation

https://www.ietf.org/proceedings/interim/2016/06/01= /i2rs/slides/slides-interim-2016-i2rs-9-0.pdf

 

If we have opstate that = disappears when the lifetime expires, then the ephemeral state would = disappear and a notification would be sent to the I2RS client.  =  For example, let us say that dynamic LSP has a lifetime and after = the lifetime expires - it disappears.   The I2RS client = augments the LSP with additional ephemeral operational = state.   If the dynamic LSP lifetime expires, and the opstate = for the LSPs disappears - then the I2RS ephemeral state would disappear = as well.  A notification would be sent to the I2RS client = monitoring such state.

 

The revised datastore model I have described = in

draft-schoenw-netmod-revised-datastores-00 links = the ephemeral state only to operational state, not at all to = configuration. Does this model not satisfy the I2RS requirements and = make things much simpler?

 

No, it is does not = satisfy the I2RS requirements for configuration and operational state. =   I2RS wants to be able to query applied configuration = (ephemeral and local configuration) as well as the operational = state.   I2RS state may have routes with next-hop that are = intended – that is the next-hop is not resolved. =

 

>> 2.  Does Ephemeral-REQ-06 provide the = Yang requirements in

> >a = clear fashion?  Do you have any suggestions for alternative text? =

 

>I think it is clear but broken. In particular = the part about indicating secure/non-secure transport.

 

From version 8: =

   Ephemeral-REQ-07: Yang MUST have a = way to indicate in a data model

   that nodes have the following properties: = ephemeral, writable/not-

   writable, and status/configuration.  = Yang must also have a way to

   specify on a module or submodule level = whether the data MAY optionally

   flow across an non-secure = transport.

 

Do you feel this is = better or still broken?

 

>> 3. = Do you think any of the Ephemeral-REQ-07 NETCONF Changes =

>>    are = not necessary?   If so, what changes would you leave = out?

>>    Do = the "policy-knobs" seem useful to you?

>> 

>> 4. Do you think any of the = Ephemeral-REQ-08 RESTCONF changes

>>    are not necessary?  = If so, what changes would you leave out?

>>    Do we need all the = features (yang module library, call-home,

>>    server)? =

 

>I think this needs to be trimmed down. I think = it should be avoided to create I2RS specific solutions for things = >that are already in place (e.g., NETCONF has a mechanism for = protocol capability discovery and negotiation, >NETCONF already = supports multiple (secure) transports).

>I think that having a clear architectural view = is essential. I am not sure the 'single pane of glass' model is the = >way to go. I think the decision on the architectural model is key = because it impacts many of the other >requirements and = solutions.

 

Please see version 8 of = the document.  If you feel that I2RS requirements suggest an = existing solution, please indicate the solution.  Per your request, = these are requirements, not solutions.

 

NETCONF & RESTCONF = changes

1)      = I2rs = protocol-version

2)      = Support = module scope (ephemeral only, mixed (config & ephemeral), mixed = (opstate & ephemeral),

3)      = Ability to = restrict non-secure transport to specific models or submodules (see = above)

4)      = Ephemeral = overwriting of local configuration state controlled by 2 knobs =

5)      = Ephemeral = overwriting of local configuration state is considered as composite of = all I2RS clients

6)      = Write = conflicts handled as error using priority (ephemeral-REQ-10 to = ephemeral-REQ-13).  Support for write-conflict notification =

 

Existing = features:  XML/JSON encoding,  features (pub-sub, yang module = library, call-home, server-module).

 

NETCONF only: =

1)      = multiple message support – “I2RS = all-or-nothng” aka NETCONF = “roll-back-on-error”

2)      = transports:  SSH, TLS, TCP with = non-secure

3)      = No support of = writable-running, candidate data store, confirmed commit, or distinct = start-up.  

 

RESTCONF only: =

1)      = http over = TLS,  http used in non-secure fashion

2)      = support for = development of pub/sub in RESTCONF

3)      = Expansion of = RESTCONF write-config support to include I2RS config support (rather = than replacement).

 

 

>You want both NC and RC to support XML and JSON = and SSH and TLS and

>(plaintext) TCP? Does this maximum of = variability and flexibility really help interoperability? Perhaps things = >should be reorganized into things that are protocol agnostic (and = should not be repeated) and things that are >protocol specific - if = there is indeed a need to work with multiple protocols.

 

No, see above.  = Per your comments, version 08 clarifies.  I have provided this = above.   The current format was chosen based on request from = NETMOD/NETCONF for protocol specific.  I will be glad to switch the = format to common, NETCONF only, RESTCONF only.

 

>I also think that it is not needed to write = down requirements to NETCONF for things that are already = solved

> or being worked = on.

 

Thank you for your = comments.  However, some people have requested us to indicate which = NETCONF/RESTCONF features are required.   This allows = implementers to know what NETCONF/RESTCONF features must be implemented. =

 

> 5. Do you think the pub/sub requirements are = sufficient?

> =

>     = (PUB-SUB-REQ-01, PUB-SUB-REQ-02)

=

>I would hope that = draft-ietf-i2rs-pub-sub-requirements-09 covers everything that is = needed. Again, this is >linked to architectural question. The text, = for example, assumes that there is an 'operational data stores'. As = >of today, this is not really the case. See

>draft-schoenw-netmod-revised-datastores-00 for = more details.

 

The draft proposal does = not align with the I2RS architecture design of ephemeral having (config = + operational state).   It does not allow the I2RS client to = query both ephemeral config and ephemeral operational state separately. =   See above.

 

>> 6. Do you have any concerns about = Ephemeral-REQ-01 to

>> 

>>    Ephemeral-REQ-04? =

>I think this sentence in = Ephemeral-REQ-04 should be taken out:

 

>The designer of ephemeral state modules are = advised that such

> constraints = may impact the speed of processing ephemeral state

> commits and should avoid them when speed is = essential.

 

> First, it may depend on the architectural = model that will be used and it likely also depends on

> implementation details whether something is = fast or not.

>  Or is = there in inherent reason why a reference to non-ephemeral state has to = be 'slow'?

 

I agree that architecture + implementation defines = the final speed of a implementation.  Today’s experience with = NETCONF implementations (architecture + speed) leads to this comment. =   Since, this particular sentence was requested by several = people – we will need to poll the WG to determine if this sentence = gets removed.  I will add it to the questions for the WG. =

 

/js

 

-- =

Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_00D6_01D1BB23.869CAF80-- From nobody Tue May 31 07:25:54 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4159812D17E for ; Tue, 31 May 2016 07:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATrIzfsHko_i for ; Tue, 31 May 2016 07:25:50 -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 68DF912B00C for ; Tue, 31 May 2016 07:25: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 B57BC8DD; Tue, 31 May 2016 16:25:48 +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 m0ZIsKVqOgSL; Tue, 31 May 2016 16:25:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 31 May 2016 16:25:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7C5C20054; Tue, 31 May 2016 16:25:46 +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 zDx6LjO5-iYn; Tue, 31 May 2016 16:25:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E785C20062; Tue, 31 May 2016 16:25:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B81B33AFE399; Tue, 31 May 2016 16:25:40 +0200 (CEST) Date: Tue, 31 May 2016 16:25:40 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160531142540.GA22420@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org, 'Benoit Claise' , 'Alia Atlas' References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d501d1bb45$0da83500$28f89f00$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Benoit Claise' , 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:25:54 -0000 On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote: > Juergen: > > > > Thank you for the second response. The questions were on version 8 of the > draft. Jeff wanted to review version 8 before posting - so I delayed > posting of version 8 until this morning. I've answered your questions > based on version 08. > > > > I think you understood that the ephemeral datastores defined by i2RS are not > what you defined in draft-schoenw-netmod-revised-datastores-00: > > o The model foresees ephemeral datastores that are by definition not > part of the persistent configuration of a device. These ephemeral > datastores are considered to interact with the rest of the system > like any other control-plane mechanisms (e.g., routing protocols, > discovery protocols). [XXX Note that this is different from what > is described in some of the I2RS documents. XXX] > > The difference is that I2RS defines ephemeral configuration and ephemeral > operational state. You see this in all of the I2RS data modules. I have > augmented your diagram with the proposed I2RS datastore. > > > +------------+ > | | // Subject to validation > | (ct, ro) | // e.g., missing resources or delays > +------------+ // Here I2RS ephemeral configuration > fits > | // so missing resources/delays can be > handled > v > +------------+ > | | - here I2RS defines ephemeral > | (ct, ro) | configuration data store > +------------+ > | // e.g., autodiscovery of values > v > +--------------------------------+ > | |<-- control plane and > | (ct + cf, ro) | ephemeral datastores > > +--------------------------------------------------+ > > > > Your definitions ignored the WG requirements and the existing discussions. > Is there a reason why? I2RS follows the break between operational state and > configuration data store. > There needs to be _one_ architectural model. I may be ignorant but we have to look at how things fit together. What you are drawing is ignoring for instance the fact that is the subject of configuration validation while I2RS explicitly states that ephemeral is not part of configuration validation. So your model is not a workable solution either. > o configuration datastore: When modeled with YANG, a configuration > datastore is realized as an instantiated data tree with > configuration data. > > o Operational state data is a set of data that has been obtained by > the system at runtime and influences the system's behavior similar > to configuration data. In contrast to configuration data, > operational state is transient and modified by interactions with > internal components or other systems via specialized protocols. > > This document is proposed on May 12, 2016 and we have been working on I2RS > for over 3 years. You provided something that does not satisfy the > requirements of the existing I2RS data models (prepared for over 18 months). > Which I2RS requirements? Please be specific. There needs to be _one_ architectural model for all the datastores people to introduce in various places and it does not help to complain. Please get down to the I2RS requirements that the above proposal does not address. Make a better proposal. Iterate. There have been quite a few calls related to the intended and applied datastore discussions that are not taking place in I2RS land and as I said above we need to come up with a common architectural model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 31 07:57:11 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AAB12D5DC; Tue, 31 May 2016 07:57:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531145710.18668.45847.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 07:57:10 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-09.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:57:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-09.txt Pages : 14 Date : 2016-05-31 Abstract: This document covers requests to the NETMOD and NETCONF Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 08:12:32 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5675412B026 for ; Tue, 31 May 2016 08:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1a8MluZ8j3w for ; Tue, 31 May 2016 08:12:29 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 046D112D5D2 for ; Tue, 31 May 2016 08:12:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> In-Reply-To: <20160531142540.GA22420@elstar.local> Date: Tue, 31 May 2016 11:12:13 -0400 Message-ID: <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJdaenpM7ljbP1C/TwjkI20GPnldwI0uYM8AiAGwTkCHPlBS56IL/WQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Benoit Claise' , 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:12:31 -0000 Juergen: Thank you for your quick response. See my comments below. I believe as you said " I may be ignorant but we have to look at how things fit together" - so I have provided more information. I believe the I2RS model is workable, and I look forward to your informed review of this information. Version -09 of Ephemeral-state is released to make it clear ephemeral state has ephemeral configuration and ephemeral operational state. Click below for the draft: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, May 31, 2016 10:26 AM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Benoit Claise'; 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote: >> Juergen: >> >> >> >> Thank you for the second response. The questions were on version 8 of the >> draft. Jeff wanted to review version 8 before posting - so I delayed >> posting of version 8 until this morning. I've answered your questions >> based on version 08. >> >> I think you understood that the ephemeral datastores defined by i2RS >> are not what you defined in draft-schoenw-netmod-revised-datastores-00: >> >> o The model foresees ephemeral datastores that are by definition not >> part of the persistent configuration of a device. These ephemeral >> datastores are considered to interact with the rest of the system >> like any other control-plane mechanisms (e.g., routing protocols, >> discovery protocols). [XXX Note that this is different from what >> is described in some of the I2RS documents. XXX] >> >> The difference is that I2RS defines ephemeral configuration and >> ephemeral operational state. You see this in all of the I2RS data >> modules. I have augmented your diagram with the proposed I2RS datastore. >> >> >> +------------+ >> | | // Subject to validation >> | (ct, ro) | // e.g., missing resources or delays >> +------------+ // Here I2RS ephemeral configuration fits >> | // so missing resources/delays can be handled >> v >> +------------+ >> | | - here I2RS defines ephemeral >> | (ct, ro) | configuration data store >> +------------+ >> | // e.g., autodiscovery of values >> v >> +--------------------------------+ >> | |<-- control plane and >> | (ct + cf, ro) | ephemeral datastores >> +--------------------------------------------------+ >> >> >> Your definitions ignored the WG requirements and the existing discussions. >> Is there a reason why? I2RS follows the break between operational >> state and configuration data store. > >There needs to be _one_ architectural model. > I may be ignorant but we have to look at how things fit together. >What you are drawing is ignoring for instance the fact that is the subject of configuration > validation while I2RS explicitly states that ephemeral is not part of configuration validation. >So your model is not a workable solution either. Not really, the ephemeral configuration is a part of the configuration validation. The ephemeral validates as either a stand-alone modules (I2RS-RIB), or as a validation of an augmentation (see examples in the interim presentation). It is validated at the intended stage of configuration. Therefore, the proposal discussed by I2RS is workable. Your opinion goes against years of NETCONF people suggesting to I2RS that ephemeral configuration and ephemeral operational state is possible. >> o configuration datastore: When modeled with YANG, a configuration >> datastore is realized as an instantiated data tree with >> configuration data. >> >> o Operational state data is a set of data that has been obtained by >> the system at runtime and influences the system's behavior similar >> to configuration data. In contrast to configuration data, >> operational state is transient and modified by interactions with >> internal components or other systems via specialized protocols. >> >> This document is proposed on May 12, 2016 and we have been working on >> I2RS for over 3 years. You provided something that does not satisfy >> the requirements of the existing I2RS data models (prepared for over 18 months). > > Which I2RS requirements? Please be specific. ================== Ephemeral-REQ-01 to Ephemeral-REQ-04 cover both configuration and operational state. If that's not clear, then I guess we need to add them. Here's the Ephemeral-REQ-01 for version -09 of the text. Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does not persist across reboots. If state must be restored, it should be done solely by replay actions from the I2RS client via the I2RS agent. Ephemeral state may consist of ephemeral configuration or ephemeral operational state, or both. ======== > There needs to be _one_ architectural model for all the datastores people to introduce in various places > and it does not help to complain. One model for data stores people is reasonable. However, your model does not work for I2RS. You have not explained why technically the i2RS model does not work for you. >Please get down to the I2RS requirements that the above proposal does not address. See Above. > Make a better proposal. Iterate. There have been quite a few calls related to the intended and applied > data store discussions that are not taking place in I2RS land and as I said above we need to come up with a > common architectural model. Been iterating for a while in I2RS. Love to hear technical reasons why the ephemeral datastore architecture does not work for you. If mention a few NETCONF calls/ your individuals draft, you must compare it against the i2RS WG 3 years plus 3 WG drafts to IESG (pub/sub, traceability, protocol-security), and 2 in final review (protocol-security environment, ephemeral state). May I suggest suggesting your draft has precedence or personal behaviors is not a fruitful discussion. Let's keep on the technical discussion. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 31 09:33:48 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F30B12D621 for ; Tue, 31 May 2016 09:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxawF2FzyxxO for ; Tue, 31 May 2016 09:33:46 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 3DBF612D816 for ; Tue, 31 May 2016 09:33:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 246A61C0B82 for ; Tue, 31 May 2016 09:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464712426; bh=p2h3uOLJwp6h/Lfiehtma42E+A1qasLUDA4rgKEVLSU=; h=To:From:Subject:Date:From; b=Z7WozHT6yoBUM2YtxvBdnaoI0dZBF4z2h8DqWUAIO1nyCTtmAQ6eQ/TvOLuGMz/XF QnTuLwju4HqrzPdDDeTD2oFrnVDEMgsLY9LtgXZia+IpZr8MsgL3CpiPmsogAdejAQ QR2jzeiqjOG8SArScWKXn+V7YoQkz7Oph98JUOq8= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C6D651C0076 for ; Tue, 31 May 2016 09:33:45 -0700 (PDT) To: "i2rs@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Tue, 31 May 2016 12:33:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [i2rs] ephemeral RPC? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:33:47 -0000 We have agreed that non-ephemeral data must not reference ephemeral data. However, we have, up till now, not had the notion of ephemeral RPCs. I see that the recent ephemeral requirements draft, as a side-effect of improving clarity, creates the notion of an ephemeral RPC. What is an ephemeral RPC, and why do we have it? We have been, up till now, assuming that we could use normal NetConf RPCs to set and get the ephemeral information. Thank you, Joel From nobody Tue May 31 10:13:30 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0532112D864 for ; Tue, 31 May 2016 10:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jjgiv3_4iNM for ; Tue, 31 May 2016 10:13:24 -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 9CDDB12D861 for ; Tue, 31 May 2016 10:13:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5E42E732; Tue, 31 May 2016 19:13:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SczQ6lzmtKbM; Tue, 31 May 2016 19:13:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 31 May 2016 19:13:09 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E05252004E; Tue, 31 May 2016 19:13:08 +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 D1LLIL7Nt2aM; Tue, 31 May 2016 19:13:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87F7020047; Tue, 31 May 2016 19:13:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9F79B3AFEA32; Tue, 31 May 2016 19:13:04 +0200 (CEST) Date: Tue, 31 May 2016 19:13:04 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160531171304.GA22857@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org, 'Benoit Claise' , 'Alia Atlas' References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Benoit Claise' , 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 17:13:28 -0000 On Tue, May 31, 2016 at 11:12:13AM -0400, Susan Hares wrote: > Juergen: > > Thank you for your quick response. See my comments below. I believe as > you said " I may be ignorant but we have to look at how things fit together" > - so I have provided more information. I believe the I2RS model is > workable, and I look forward to your informed review of this information. > > Version -09 of Ephemeral-state is released to make it clear ephemeral state > has ephemeral configuration and ephemeral operational state. Click below > for the draft: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, May 31, 2016 10:26 AM > To: Susan Hares > Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Benoit Claise'; 'Alia Atlas' > Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am > - Topic: Ephemeral State Requirements > > On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote: > >> Juergen: > >> > >> > >> > >> Thank you for the second response. The questions were on version 8 of > the > >> draft. Jeff wanted to review version 8 before posting - so I delayed > >> posting of version 8 until this morning. I've answered your questions > >> based on version 08. > >> > >> I think you understood that the ephemeral datastores defined by i2RS > >> are not what you defined in draft-schoenw-netmod-revised-datastores-00: > >> > >> o The model foresees ephemeral datastores that are by definition not > >> part of the persistent configuration of a device. These ephemeral > >> datastores are considered to interact with the rest of the system > >> like any other control-plane mechanisms (e.g., routing protocols, > >> discovery protocols). [XXX Note that this is different from what > >> is described in some of the I2RS documents. XXX] > >> > >> The difference is that I2RS defines ephemeral configuration and > >> ephemeral operational state. You see this in all of the I2RS data > >> modules. I have augmented your diagram with the proposed I2RS datastore. > >> > >> > >> +------------+ > >> | | // Subject to validation > >> | (ct, ro) | // e.g., missing resources or delays > >> +------------+ // Here I2RS ephemeral configuration > fits > >> | // so missing resources/delays can > be handled > >> v > >> +------------+ > >> | | - here I2RS defines ephemeral > >> | (ct, ro) | configuration data store > >> +------------+ > >> | // e.g., autodiscovery of values > >> v > >> +--------------------------------+ > >> | |<-- control plane and > >> | (ct + cf, ro) | ephemeral datastores > > >> +--------------------------------------------------+ > >> > >> > >> Your definitions ignored the WG requirements and the existing > discussions. > >> Is there a reason why? I2RS follows the break between operational > >> state and configuration data store. > > > > >There needs to be _one_ architectural model. > > I may be ignorant but we have to look at how things fit together. > >What you are drawing is ignoring for instance the fact that is > the subject of configuration > > validation while I2RS explicitly states that ephemeral is not part of > configuration validation. > >So your model is not a workable solution either. > > Not really, the ephemeral configuration is a part of the configuration > validation. The ephemeral validates as either a stand-alone modules > (I2RS-RIB), or as a validation of an augmentation (see examples in the > interim presentation). It is validated at the intended stage of > configuration. Therefore, the proposal discussed by I2RS is workable. Your > opinion goes against years of NETCONF people suggesting to I2RS that > ephemeral configuration and ephemeral operational state is possible. I understand YANG validation rules and I understand YANG's notion of configuration datastores. I do not think this matches your ephemeral configuration validation. > >> o configuration datastore: When modeled with YANG, a configuration > >> datastore is realized as an instantiated data tree with > >> configuration data. > >> > >> o Operational state data is a set of data that has been obtained by > >> the system at runtime and influences the system's behavior similar > >> to configuration data. In contrast to configuration data, > >> operational state is transient and modified by interactions with > >> internal components or other systems via specialized protocols. > >> > >> This document is proposed on May 12, 2016 and we have been working on > >> I2RS for over 3 years. You provided something that does not satisfy > >> the requirements of the existing I2RS data models (prepared for over 18 > months). > > > > > Which I2RS requirements? Please be specific. > ================== > Ephemeral-REQ-01 to Ephemeral-REQ-04 cover both configuration and > operational state. If that's not clear, then I guess we need to add them. > Here's the Ephemeral-REQ-01 for version -09 of the text. > > Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does > not persist across reboots. If state must be restored, it should be > done solely by replay actions from the I2RS client via the I2RS > agent. Ephemeral state may consist of ephemeral configuration > or ephemeral operational state, or both. > ======== So how is this broken? This is the only time 'ephemeral operational state' shows up in -09. So please elaborate whether this is by intention in order to express that 'ephemeral operational state' is something different than a subset of 'operational state' or even better please explain how you think 'ephemeral operational state' relates to 'operational state'. In fact, it would help if terminology would be clearly defined. How do - ephemeral operational state - ephemeral state - ephemeral config - derived state (ephemeral) - derived state (opstate) - ephemeral configuration - mixed ephemeral config (ephemeral + config) relate to each other? Let me check draft-ietf-i2rs-architecture-15.txt: - ephemeral state - ephemeral configuration - ephemeral data - is data which does not persist across a reboot (software or hardware) or a power on/off condition. Ephemeral data can be configured data or data recorded from operations of the router. - ephemeral static state (?) So is my interpretation right that 'ephemeral data' is the union of 'ephemeral configuration' and 'ephemeral state'? (If my interpretation of these terms is correct the probably not all usages of the terms are correct in draft-ietf-i2rs-architecture-15.txt; so more likely my interpretation is incorrect.) Given the operational state is by its nature ephemeral, is there a distinction between 'operational state' and ephemeral state? Or is 'ephemeral state' just a subset of 'operational state' that has been influenced by 'ephemeral configuration'? > > There needs to be _one_ architectural model for all the datastores people > to introduce in various places > > and it does not help to complain. > > One model for data stores people is reasonable. However, your model does > not work for I2RS. You have not explained why technically the i2RS model > does not work for you. > > >Please get down to the I2RS requirements that the above proposal does not > address. > See Above. > > > Make a better proposal. Iterate. There have been quite a few calls related > to the intended and applied > > data store discussions that are not taking place in I2RS land and as I > said above we need to come up with a > > common architectural model. > > Been iterating for a while in I2RS. Love to hear technical reasons why the > ephemeral datastore architecture does not work for you. There are many datastores being proposed and at the end they all need to work together. Implementations can't support N different datastore models that are not aligned. I understand that this concern is not your prime problem since your focus is I2RS but please understand that other people are proposing other datastores and I do believe NETMOD/NETCONF needs to find agreement on a bigger architectural picture that addresses the various requirements and enables implementations that work in a predictable manner. > If mention a few NETCONF calls/ your individuals draft, you must compare it > against the i2RS WG 3 years plus 3 WG drafts to IESG (pub/sub, > traceability, protocol-security), and 2 in final review (protocol-security > environment, ephemeral state). May I suggest suggesting your draft has > precedence or personal behaviors is not a fruitful discussion. Let's keep > on the technical discussion. I just tried to make you aware that some people think we need a common and consistent architectural model within NETMOD and NETCONF. I pointed to one proposal. There can be others. But at the end, there needs to be a single unifying architectural model if we want implementations being able to address requirements coming from different communities and still behave in a predictable manner. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 31 11:27:18 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C09E12D8AD for ; Tue, 31 May 2016 11:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymK9iOZKJ1LE for ; Tue, 31 May 2016 11:27:15 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 98D1812D891 for ; Tue, 31 May 2016 11:27:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 6148D42162D; Tue, 31 May 2016 11:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464719235; bh=xjtJmE3uBQ0vsHdrcA4nkBZLGGw6l445QfJrF04MZ9g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pibvI5oYv6dCdXreRTmwgW5b+2VskfHMqzKCE4kthqb8somRGV2Kyuwsj9Ego3XoJ 1J0cTuwRVNDa7iRWOWaSfJ46m8pCeYBE8kSrN36LGSTbH4EvkZOzACNRbITL8uWPMZ CGL6LZP8K7ijhLAazlxRuJIhlNLEu+BZ6lxIxv6I= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E919742096E; Tue, 31 May 2016 11:27:14 -0700 (PDT) To: Juergen Schoenwaelder , i2rs@ietf.org References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> From: "Joel M. Halpern" Message-ID: <026df5be-4a60-f340-60aa-d713a0e75c48@joelhalpern.com> Date: Tue, 31 May 2016 14:27:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160531063840.GA21289@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Ephemeral State Requirements discussion X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 18:27:17 -0000 If I understood you correctly Juergen, you are suggesting using your document: https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 as a basis for addressing the I2RS requirements. I am having trouble understanding how the approach in your document would work for ephemeral configured information. 1) The document says that such information is treated like other control protocols. 1a) How would one use NetConf or RestConf to write this? 1b) How would the controllable relationship with conventional configuration be realized 1c) How would the descriptions of this information be provided? (Arguably, this last is not a requirements question, but it would help in understanding your proposal. 2) Similarly, since operations have been segregated by datastore, how would an I2RS client read the configured information to tell what was being applied? 3) How would the I2RS requirement for priority of operation be applied? 4) How would the requirement for reversion to configured values upon removal of an I2RS modification be done? It is very hard as a reader to tell if your approach is acceptable, better than, or worse than, the one we have on the table. As far as I can tell, in terms of a consistent architecture for data stores, both approaches consist of creating extra data stores when needed. Yours, Joel From nobody Tue May 31 11:42:05 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855BA12D5A1 for ; Tue, 31 May 2016 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOQ-5XNHwAX0 for ; Tue, 31 May 2016 11:42:00 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A559712D562 for ; Tue, 31 May 2016 11:42:00 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id o16so197936782ywd.2 for ; Tue, 31 May 2016 11:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=tdkhRk4D4glOmYwCcFab5PzpRsx4PCWvsA21ZtLIdYM=; b=xGOslyInDDVx2ytUtk4zDovMEIeNb2ETNE5pwV30X5aA1u5YSM/w4dTPBQ4mt1jIz2 wmbUNylXvjNdKCGgWmsEmbjfJ8oMulfWA8IlsmY5lTq4vzd12eWEPgtsTF+QP1lf/NGr 1ARVf/H4uREDVd5etaXnsi+XpX3SeFCH+bGMzNAZL6u8Tg7XTlySIPmb49cXKUzhxBnR tkvVEd8hfkm8hpiaA0TejuuGRH2FTNMc3Ec18dQ3TDLBqobmwdmKVtwTdPtyP3LqxZ/7 v0SHq9+BWnhzw2VvLTBuk2J7+gJOiP/aW6vEOiH60xjTjvRcBDVzR5uVJw2E3ny73/RP gxgw== 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; bh=tdkhRk4D4glOmYwCcFab5PzpRsx4PCWvsA21ZtLIdYM=; b=TRclE/YDm2v5z7FgqMzEELb1h7aAA4W75kdvFqsps1mApG6uEzyUjDfmc6KBJt14FQ PkWKpcQeNK5uqzgeC7kXaXw7ZT4ve1oPHyn/Pgb5sZeuOUVVhWheWQfQe8p28ImSduVY BPRYlfCwAjPdE2Bp2jp+xLICFaSZOOh9YB5qKumdL9LT+vPSe9CBdSmk/DPRPa1Ra0+y aBkVbIZmxrb++t/iglaEXY4Xop7PZ2uJUCfiTYThYjyK6ubD8CRk34VFyHHlMs1rT1mG zGUd+QsQnL9MU5OooVI9bbwPOvqT/0fyqLV64KwwvvzbukLzL6AkAdUCUUlkrzc6G8nh p50A== X-Gm-Message-State: ALyK8tJ7egiXBtejV3dZIUTLg4PMuU6l58RfQmYsF03QHubG636ktOnFedDO1lsJjJt01qpzOyYd2CCsFBDK1w== MIME-Version: 1.0 X-Received: by 10.37.4.216 with SMTP id 207mr19612056ybe.17.1464720119773; Tue, 31 May 2016 11:41:59 -0700 (PDT) Received: by 10.37.115.208 with HTTP; Tue, 31 May 2016 11:41:59 -0700 (PDT) In-Reply-To: <20160531171304.GA22857@elstar.local> References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local> Date: Tue, 31 May 2016 11:41:59 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Susan Hares , Jeffrey Haas , "i2rs@ietf.org" , Benoit Claise , Alia Atlas Content-Type: multipart/alternative; boundary=001a11c066306f7bad053427ba3d Archived-At: Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 18:42:05 -0000 --001a11c066306f7bad053427ba3d Content-Type: text/plain; charset=UTF-8 Hi, I agree with your concerns. The opstate design team should not be ignoring ephemeral state and the I2RS WG should not be ignoring the opstate work. I prefer to see 1 RFC on datastores that defines a coherent and cost-effective framework that works for years to come. New implementations should opt-in to using new datastores. Old implementations must continue to work even if the new datastores are ignored. Isn't all operational state ephemeral by definition? Doesn't proper management of a system with ephemeral data require just 1 view of operational data which reflects current system behavior? At some point the WG needs to agree on normative text instead of iterating on requirements forever. Some of them will fall out as important vs. irrelevant if there is an actual protocol spec to review. E.g. secondary ID cannot be "may keep" and "SHOULD report". Either the standard protocol has an official use for secondary client ID or it doesn't. Andy On Tue, May 31, 2016 at 10:13 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, May 31, 2016 at 11:12:13AM -0400, Susan Hares wrote: > > Juergen: > > > > Thank you for your quick response. See my comments below. I believe as > > you said " I may be ignorant but we have to look at how things fit > together" > > - so I have provided more information. I believe the I2RS model is > > workable, and I look forward to your informed review of this information. > > > > Version -09 of Ephemeral-state is released to make it clear ephemeral > state > > has ephemeral configuration and ephemeral operational state. Click > below > > for the draft: > > > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > > Sent: Tuesday, May 31, 2016 10:26 AM > > To: Susan Hares > > Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Benoit Claise'; 'Alia Atlas' > > Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - > 11:00am > > - Topic: Ephemeral State Requirements > > > > On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote: > > >> Juergen: > > >> > > >> > > >> > > >> Thank you for the second response. The questions were on version 8 > of > > the > > >> draft. Jeff wanted to review version 8 before posting - so I delayed > > >> posting of version 8 until this morning. I've answered your > questions > > >> based on version 08. > > >> > > >> I think you understood that the ephemeral datastores defined by i2RS > > >> are not what you defined in > draft-schoenw-netmod-revised-datastores-00: > > >> > > >> o The model foresees ephemeral datastores that are by definition > not > > >> part of the persistent configuration of a device. These > ephemeral > > >> datastores are considered to interact with the rest of the > system > > >> like any other control-plane mechanisms (e.g., routing > protocols, > > >> discovery protocols). [XXX Note that this is different from > what > > >> is described in some of the I2RS documents. XXX] > > >> > > >> The difference is that I2RS defines ephemeral configuration and > > >> ephemeral operational state. You see this in all of the I2RS data > > >> modules. I have augmented your diagram with the proposed I2RS > datastore. > > >> > > >> > > >> +------------+ > > >> | | // Subject to validation > > >> | (ct, ro) | // e.g., missing resources or > delays > > >> +------------+ // Here I2RS ephemeral > configuration > > fits > > >> | // so missing resources/delays > can > > be handled > > >> v > > >> +------------+ > > >> | | - here I2RS defines ephemeral > > >> | (ct, ro) | configuration data store > > >> +------------+ > > >> | // e.g., autodiscovery of values > > >> v > > >> +--------------------------------+ > > >> | |<-- control plane and > > >> | (ct + cf, ro) | ephemeral datastores > > > > >> +--------------------------------------------------+ > > >> > > >> > > >> Your definitions ignored the WG requirements and the existing > > discussions. > > >> Is there a reason why? I2RS follows the break between operational > > >> state and configuration data store. > > > > > > > >There needs to be _one_ architectural model. > > > I may be ignorant but we have to look at how things fit together. > > >What you are drawing is ignoring for instance the fact that > is > > the subject of configuration > > > validation while I2RS explicitly states that ephemeral is not part of > > configuration validation. > > >So your model is not a workable solution either. > > > > Not really, the ephemeral configuration is a part of the configuration > > validation. The ephemeral validates as either a stand-alone modules > > (I2RS-RIB), or as a validation of an augmentation (see examples in the > > interim presentation). It is validated at the intended stage of > > configuration. Therefore, the proposal discussed by I2RS is workable. > Your > > opinion goes against years of NETCONF people suggesting to I2RS that > > ephemeral configuration and ephemeral operational state is possible. > > I understand YANG validation rules and I understand YANG's notion of > configuration datastores. I do not think this matches your ephemeral > configuration validation. > > > >> o configuration datastore: When modeled with YANG, a configuration > > >> datastore is realized as an instantiated data tree with > > >> configuration data. > > >> > > >> o Operational state data is a set of data that has been obtained by > > >> the system at runtime and influences the system's behavior > similar > > >> to configuration data. In contrast to configuration data, > > >> operational state is transient and modified by interactions with > > >> internal components or other systems via specialized protocols. > > >> > > >> This document is proposed on May 12, 2016 and we have been working on > > >> I2RS for over 3 years. You provided something that does not satisfy > > >> the requirements of the existing I2RS data models (prepared for over > 18 > > months). > > > > > > > > Which I2RS requirements? Please be specific. > > ================== > > Ephemeral-REQ-01 to Ephemeral-REQ-04 cover both configuration and > > operational state. If that's not clear, then I guess we need to add > them. > > Here's the Ephemeral-REQ-01 for version -09 of the text. > > > > Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does > > not persist across reboots. If state must be restored, it should be > > done solely by replay actions from the I2RS client via the I2RS > > agent. Ephemeral state may consist of ephemeral configuration > > or ephemeral operational state, or both. > > ======== > > So how is this broken? This is the only time 'ephemeral operational > state' shows up in -09. So please elaborate whether this is by > intention in order to express that 'ephemeral operational state' is > something different than a subset of 'operational state' or even > better please explain how you think 'ephemeral operational state' > relates to 'operational state'. > > In fact, it would help if terminology would be clearly defined. How do > > - ephemeral operational state > - ephemeral state > - ephemeral config > - derived state (ephemeral) > - derived state (opstate) > - ephemeral configuration > - mixed ephemeral config (ephemeral + config) > > relate to each other? Let me check draft-ietf-i2rs-architecture-15.txt: > > - ephemeral state > - ephemeral configuration > - ephemeral data - is data which does not persist across a reboot > (software or hardware) or a power on/off condition. Ephemeral > data can be configured data or data recorded from operations of > the router. > - ephemeral static state (?) > > So is my interpretation right that 'ephemeral data' is the union of > 'ephemeral configuration' and 'ephemeral state'? (If my > interpretation of these terms is correct the probably not all usages > of the terms are correct in draft-ietf-i2rs-architecture-15.txt; so > more likely my interpretation is incorrect.) > > Given the operational state is by its nature ephemeral, is there a > distinction between 'operational state' and ephemeral state? Or is > 'ephemeral state' just a subset of 'operational state' that has been > influenced by 'ephemeral configuration'? > > > > There needs to be _one_ architectural model for all the datastores > people > > to introduce in various places > > > and it does not help to complain. > > > > One model for data stores people is reasonable. However, your model does > > not work for I2RS. You have not explained why technically the i2RS model > > does not work for you. > > > > >Please get down to the I2RS requirements that the above proposal does > not > > address. > > See Above. > > > > > Make a better proposal. Iterate. There have been quite a few calls > related > > to the intended and applied > > > data store discussions that are not taking place in I2RS land and as I > > said above we need to come up with a > > > common architectural model. > > > > Been iterating for a while in I2RS. Love to hear technical reasons why > the > > ephemeral datastore architecture does not work for you. > > There are many datastores being proposed and at the end they all need > to work together. Implementations can't support N different datastore > models that are not aligned. I understand that this concern is not > your prime problem since your focus is I2RS but please understand that > other people are proposing other datastores and I do believe > NETMOD/NETCONF needs to find agreement on a bigger architectural > picture that addresses the various requirements and enables > implementations that work in a predictable manner. > > > If mention a few NETCONF calls/ your individuals draft, you must compare > it > > against the i2RS WG 3 years plus 3 WG drafts to IESG (pub/sub, > > traceability, protocol-security), and 2 in final review > (protocol-security > > environment, ephemeral state). May I suggest suggesting your draft has > > precedence or personal behaviors is not a fruitful discussion. Let's > keep > > on the technical discussion. > > I just tried to make you aware that some people think we need a common > and consistent architectural model within NETMOD and NETCONF. I > pointed to one proposal. There can be others. But at the end, there > needs to be a single unifying architectural model if we want > implementations being able to address requirements coming from > different communities and still behave in a predictable manner. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c066306f7bad053427ba3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


I agree with your co= ncerns.=C2=A0 The opstate design team should not be ignoring ephemeral stat= e
and the I2RS WG should not be ignoring the opstate work.=C2=A0 = I prefer to see 1 RFC on datastores
that defines a coherent and c= ost-effective framework that works for years to come.
New impleme= ntations should opt-in to using new datastores.=C2=A0 Old implementations m= ust
continue to work even if the new datastores are ignored.

Isn't all operational state ephemeral by definitio= n?
Doesn't proper management of a system with ephemeral data = require
just 1 view of operational data which reflects current sy= stem behavior?

At some point the WG needs to agree= on normative text instead of iterating
on requirements forever.= =C2=A0 Some of them will fall out as important vs. irrelevant
if = there is an actual protocol spec to review.=C2=A0 E.g. secondary ID cannot<= /div>
be "may keep" and "SHOULD report".=C2=A0 Eith= er the standard protocol has an
official use for secondary client= ID or it doesn't.


Andy


On Tue, May 31, 2016 at 10:13 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, May 31, 2016 at 11:12:13AM -0400, Susan Hares= wrote:
> Juergen:
>
> Thank you for your quick response.=C2=A0 See my comments below.=C2=A0 = =C2=A0I believe as
> you said " I may be ignorant but we have to look at how things fi= t together"
> - so I have provided more information.=C2=A0 I believe the I2RS model = is
> workable, and I look forward to your informed review of this informati= on.
>
> Version -09 of Ephemeral-state is released to make it clear ephemeral = state
> has ephemeral configuration and ephemeral operational state.=C2=A0 =C2= =A0Click below
> for the draft:
>
> https://datatracker.ietf.org/d= oc/draft-ietf-i2rs-ephemeral-state/
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounc= es@ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, May 31, 2016 10:26 AM
> To: Susan Hares
> Cc: 'Jeffrey Haas'; i2rs@ietf= .org; 'Benoit Claise'; 'Alia Atlas'
> Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11= :00am
> - Topic: Ephemeral State Requirements
>
> On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote:
> >> Juergen:
> >>
> >>
> >>
> >> Thank you for the second response.=C2=A0 =C2=A0 The questions= were on version 8 of
> the
> >> draft.=C2=A0 Jeff wanted to review version 8 before posting -= so I delayed
> >> posting of version 8 until this morning.=C2=A0 =C2=A0 I'v= e answered your questions
> >> based on version 08.
> >>
> >> I think you understood that the ephemeral datastores defined = by i2RS
> >> are not what you defined in draft-schoenw-netmod-revised-data= stores-00:
> >>
> >>=C2=A0 =C2=A0 o=C2=A0 The model foresees ephemeral datastores = that are by definition not
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0part of the persistent configuratio= n of a device.=C2=A0 These ephemeral
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0datastores are considered to intera= ct with the rest of the system
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0like any other control-plane mechan= isms (e.g., routing protocols,
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0discovery protocols).=C2=A0 [XXX No= te that this is different from what
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0is described in some of the I2RS do= cuments.=C2=A0 XXX]
> >>
> >> The difference is that I2RS defines ephemeral configuration a= nd
> >> ephemeral operational state.=C2=A0 You see this in all of the= I2RS data
> >> modules.=C2=A0 I have augmented your diagram with the propose= d I2RS datastore.
> >>
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0+------------+
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0| <intended> |=C2=A0 //=C2=A0 Subject to validation
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0| (ct, ro)=C2=A0 =C2=A0| //=C2=A0 =C2=A0e.g., missing resourc= es or delays
> >>=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// Here I2RS ephemeral configurati= on
> fits
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//=C2= =A0 so missing resources/delays can
> be handled
> >>=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=A0v
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0+------------+
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0| <applied>=C2=A0 |=C2=A0 =C2=A0 - here I2RS defines ep= hemeral
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0| (ct, ro)=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 configuration da= ta store
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0+------------+
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// e.= g., autodiscovery of values
> >>=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=A0v
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------------= ------------+
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <operational-sta= te>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-- control plane and > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (ct + cf, ro)=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 eph= emeral datastores
>
> >> +--------------------------------------------------+
> >>
> >>
> >> Your definitions ignored the WG requirements and the existing=
> discussions.
> >> Is there a reason why?=C2=A0 I2RS follows the break between o= perational
> >> state and configuration data store.
> >
>
> >There needs to be _one_ architectural model.
> > I may be ignorant but we have to look at how things fit together.=
> >What you are drawing is ignoring for instance the fact that <in= tended> is
> the subject of configuration
> > validation while I2RS explicitly states that ephemeral is not par= t of
> configuration validation.
> >So your model is not a workable solution either.
>
> Not really, the ephemeral configuration is a part of the configuration=
> validation.=C2=A0 The ephemeral validates as either a stand-alone modu= les
> (I2RS-RIB), or as a validation of an augmentation (see examples in the=
> interim presentation).=C2=A0 It is validated at the intended stage of<= br> > configuration.=C2=A0 =C2=A0Therefore, the proposal discussed by I2RS i= s workable. Your
> opinion goes against years of NETCONF people suggesting to I2RS that > ephemeral configuration and ephemeral operational state is possible.
I understand YANG validation rules and I understand YANG's notion of configuration datastores. I do not think this matches your ephemeral
configuration validation.

> >> o=C2=A0 configuration datastore: When modeled with YANG, a co= nfiguration
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0datastore is realized as an instant= iated data tree with
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration data.
> >>
> >> o=C2=A0 Operational state data is a set of data that has been= obtained by
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0the system at runtime and influence= s the system's behavior similar
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0to configuration data.=C2=A0 In con= trast to configuration data,
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0operational state is transient and = modified by interactions with
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0internal components or other system= s via specialized protocols.
> >>
> >> This document is proposed on May 12, 2016 and we have been wo= rking on
> >> I2RS for over 3 years.=C2=A0 You provided something that does= not satisfy
> >> the requirements of the existing I2RS data models (prepared f= or over 18
> months).
> >
>
> > Which I2RS requirements? Please be specific.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Ephemeral-REQ-01 to Ephemeral-REQ-04 cover both configuration and
> operational state.=C2=A0 If that's not clear, then I guess we need= to add them.
> Here's the Ephemeral-REQ-01 for version -09 of the text.
>
>=C2=A0 =C2=A0 =C2=A0Ephemeral-REQ-01: I2RS requires ephemeral state; i.= e. state that does
>=C2=A0 =C2=A0 not persist across reboots.=C2=A0 If state must be restor= ed, it should be
>=C2=A0 =C2=A0 done solely by replay actions from the I2RS client via th= e I2RS
>=C2=A0 =C2=A0 agent.=C2=A0 Ephemeral state may consist of ephemeral con= figuration
>=C2=A0 =C2=A0or ephemeral operational state, or both.
> =3D=3D=3D=3D=3D=3D=3D=3D

So how is this broken? This is the only time 'ephemeral operational
state' shows up in -09. So please elaborate whether this is by
intention in order to express that 'ephemeral operational state' is=
something different than a subset of 'operational state' or even better please explain how you think 'ephemeral operational state' relates to 'operational state'.

In fact, it would help if terminology would be clearly defined. How do

- ephemeral operational state
- ephemeral state
- ephemeral config
- derived state (ephemeral)
- derived state (opstate)
- ephemeral configuration
- mixed ephemeral config (ephemeral + config)

relate to each other? Let me check draft-ietf-i2rs-architecture-15.txt:

- ephemeral state
- ephemeral configuration
- ephemeral data - is data which does not persist across a reboot
=C2=A0 =C2=A0 =C2=A0 (software or hardware) or a power on/off condition. Ep= hemeral
=C2=A0 =C2=A0 =C2=A0 data can be configured data or data recorded from oper= ations of
=C2=A0 =C2=A0 =C2=A0 the router.
- ephemeral static state (?)

So is my interpretation right that 'ephemeral data' is the union of=
'ephemeral configuration' and 'ephemeral state'?=C2=A0 (If = my
interpretation of these terms is correct the probably not all usages
of the terms are correct in draft-ietf-i2rs-architecture-15.txt; so
more likely my interpretation is incorrect.)

Given the operational state is by its nature ephemeral, is there a
distinction between 'operational state' and ephemeral state? Or is<= br> 'ephemeral state' just a subset of 'operational state' that= has been
influenced by 'ephemeral configuration'?

> > There needs to be _one_ architectural model for all the datastore= s people
> to introduce in various places
> > and it does not help to complain.
>
> One model for data stores people is reasonable.=C2=A0 However, your mo= del does
> not work for I2RS.=C2=A0 You have not explained why technically the i2= RS model
> does not work for you.
>
> >Please get down to the I2RS requirements that the above proposal d= oes not
> address.
> See Above.
>
> > Make a better proposal. Iterate. There have been quite a few call= s related
> to the intended and applied
> > data store discussions that are not taking place in I2RS land and= as I
> said above we need to come up with a
> > common architectural model.
>
> Been iterating for a while in I2RS.=C2=A0 =C2=A0Love to hear technical= reasons why the
> ephemeral datastore architecture does not work for you.

There are many datastores being proposed and at the end they all need
to work together. Implementations can't support N different datastore models that are not aligned. I understand that this concern is not
your prime problem since your focus is I2RS but please understand that
other people are proposing other datastores and I do believe
NETMOD/NETCONF needs to find agreement on a bigger architectural
picture that addresses the various requirements and enables
implementations that work in a predictable manner.

> If mention a few NETCONF calls/ your individuals draft, you must compa= re it
> against the i2RS WG 3 years plus=C2=A0 3 WG drafts to IESG (pub/sub, > traceability, protocol-security), and=C2=A0 2 in final review (protoco= l-security
> environment, ephemeral state).=C2=A0 May I suggest suggesting your dra= ft has
> precedence or personal behaviors is not a fruitful discussion.=C2=A0 L= et's keep
> on the technical discussion.

I just tried to make you aware that some people think we need a common
and consistent architectural model within NETMOD and NETCONF. I
pointed to one proposal. There can be others. But at the end, there
needs to be a single unifying architectural model if we want
implementations being able to address requirements coming from
different communities and still behave in a predictable manner.

/js

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

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

--001a11c066306f7bad053427ba3d-- From nobody Tue May 31 11:48:55 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9056612D5B5 for ; Tue, 31 May 2016 11:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcGnmGOSorNc for ; Tue, 31 May 2016 11:48:50 -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 9C18212D5A1 for ; Tue, 31 May 2016 11:48: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 6402CB8C; Tue, 31 May 2016 20:48: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 sQ_ItvOcsMnq; Tue, 31 May 2016 20:48:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 31 May 2016 20:48:47 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F53B2004E; Tue, 31 May 2016 20:48:47 +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 TbPUypmVfWvy; Tue, 31 May 2016 20:48:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EA7720047; Tue, 31 May 2016 20:48:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C63A23AFED5C; Tue, 31 May 2016 20:48:44 +0200 (CEST) Date: Tue, 31 May 2016 20:48:44 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20160531184844.GB22928@elstar.local> Mail-Followup-To: "Joel M. Halpern" , i2rs@ietf.org References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <026df5be-4a60-f340-60aa-d713a0e75c48@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <026df5be-4a60-f340-60aa-d713a0e75c48@joelhalpern.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Ephemeral State Requirements discussion X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 18:48:53 -0000 On Tue, May 31, 2016 at 02:27:12PM -0400, Joel M. Halpern wrote: > If I understood you correctly Juergen, you are suggesting using your > document: > https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > as a basis for addressing the I2RS requirements. No. All I am saying is that there are discussions underway basically triggered by openconfig ideas and that we need to find a common architectural model for the various datastores different groups like to have. The I-D cited above is input to this discussion. The discussion goes beyond I2RS concerns but still I2RS concerns should be considered by this discussion. > I am having trouble understanding how the approach in your document would > work for ephemeral configured information. > 1) The document says that such information is treated like other control > protocols. > 1a) How would one use NetConf or RestConf to write this? Via an ephemeral datastore. The difference is that this ephemeral datastore primarily interacts with operational state. This actually seems consistent since I2RS tends to favor to relate to state more than to config. > 1b) How would the controllable relationship with conventional configuration > be realized The ephemeral datastore overwrite, right? So an implementation pulls from the config datastore and the ephemeral datastore and the (+) function gives content from the ephemeral datastore preference. > 1c) How would the descriptions of this information be provided? (Arguably, > this last is not a requirements question, but it would help in understanding > your proposal. A YANG module. Perhaps I do not understand the question. > 2) Similarly, since operations have been segregated by datastore, how would > an I2RS client read the configured information to tell what was being > applied? Be careful with 'applied' since there now is an 'applied' datastore with very specific meaning. But in general, a client that wants to read one of the configuration datastores simply reads that datastore. > 3) How would the I2RS requirement for priority of operation be applied? It is the magic (+) function that merges config with config leading to operational state. > 4) How would the requirement for reversion to configured values upon removal > of an I2RS modification be done? The magic (+) function would have to take care of it. > It is very hard as a reader to tell if your approach is acceptable, better > than, or worse than, the one we have on the table. I understand. The alternative model is to have somewhere between and . But then it seems people want really behave more like other control plane protocols that also typically interact directly with . > As far as I can tell, in terms of a consistent architecture for data stores, > both approaches consist of creating extra data stores when needed. Yes. But details matter. For example, and YANG configuration datastore validation are one thing, I tend to believe that I2RS validation really means something different. Hence I am pointing out that we need the I2RS requirements but then we (NETMOD/NETCONF people) also need to come up with an architectural model that considers things that are beyond I2RS' scope. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 31 12:07:10 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9078E12D872 for ; Tue, 31 May 2016 12:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS160dv_0e4J for ; Tue, 31 May 2016 12:07:06 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 93A8D12D638 for ; Tue, 31 May 2016 12:07:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7F5CC9A00A3 for ; Tue, 31 May 2016 12:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464721626; bh=Vwg8v0d1zDaJS0W55lmK/vkQUS0nKXI5rVXbILd5xE0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=o5iD7/lWWsr9jYy9a/tpTMhiQi1JSfKvkBtF6qs0vZ2RBh52WR40+ILbdOf1UK1m3 7ufv5M+ZKJNCWnYLhl9X7pGWdTuFITyQKEQVWfQivnz/LSK2vuhFkIrc91LaYJHHCz K2zcZVx5LClgIsqTXGgQoAqdWPMD+tBGMwMmt3TM= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 15DC41C0B82 for ; Tue, 31 May 2016 12:07:06 -0700 (PDT) To: i2rs@ietf.org References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <026df5be-4a60-f340-60aa-d713a0e75c48@joelhalpern.com> <20160531184844.GB22928@elstar.local> From: "Joel M. Halpern" Message-ID: <413ef504-49a8-2ba2-7fd4-582a41bd0ad0@joelhalpern.com> Date: Tue, 31 May 2016 15:07:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160531184844.GB22928@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Ephemeral State Requirements discussion X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:07:08 -0000 Would a fair paraphrase of the point you are making here be that the data store could sit next to the data stored rather than either below or combined with it? Yours, Joel On 5/31/16 2:48 PM, Juergen Schoenwaelder wrote: > On Tue, May 31, 2016 at 02:27:12PM -0400, Joel M. Halpern wrote: > >> If I understood you correctly Juergen, you are suggesting using your >> document: >> https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 >> as a basis for addressing the I2RS requirements. > > No. All I am saying is that there are discussions underway basically > triggered by openconfig ideas and that we need to find a common > architectural model for the various datastores different groups like > to have. The I-D cited above is input to this discussion. The > discussion goes beyond I2RS concerns but still I2RS concerns should be > considered by this discussion. > >> I am having trouble understanding how the approach in your document would >> work for ephemeral configured information. >> 1) The document says that such information is treated like other control >> protocols. >> 1a) How would one use NetConf or RestConf to write this? > > Via an ephemeral datastore. The difference is that this ephemeral > datastore primarily interacts with operational state. This actually > seems consistent since I2RS tends to favor to relate to state more > than to config. > >> 1b) How would the controllable relationship with conventional configuration >> be realized > > The ephemeral datastore overwrite, right? So an implementation pulls > from the config datastore and the ephemeral datastore and > the (+) function gives content from the ephemeral datastore > preference. > >> 1c) How would the descriptions of this information be provided? (Arguably, >> this last is not a requirements question, but it would help in understanding >> your proposal. > > A YANG module. Perhaps I do not understand the question. > >> 2) Similarly, since operations have been segregated by datastore, how would >> an I2RS client read the configured information to tell what was being >> applied? > > Be careful with 'applied' since there now is an 'applied' datastore > with very specific meaning. But in general, a client that wants to > read one of the configuration datastores simply reads that datastore. > >> 3) How would the I2RS requirement for priority of operation be applied? > > It is the magic (+) function that merges config with > config leading to operational state. > >> 4) How would the requirement for reversion to configured values upon removal >> of an I2RS modification be done? > > The magic (+) function would have to take care of it. > >> It is very hard as a reader to tell if your approach is acceptable, better >> than, or worse than, the one we have on the table. > > I understand. The alternative model is to have somewhere > between and . But then it seems people > want really behave more like other control plane protocols > that also typically interact directly with . > >> As far as I can tell, in terms of a consistent architecture for data stores, >> both approaches consist of creating extra data stores when needed. > > Yes. But details matter. For example, and YANG > configuration datastore validation are one thing, I tend to believe > that I2RS validation really means something different. Hence I am > pointing out that we need the I2RS requirements but then we > (NETMOD/NETCONF people) also need to come up with an architectural > model that considers things that are beyond I2RS' scope. > > /js > From nobody Tue May 31 12:27:37 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4F712D8AD for ; Tue, 31 May 2016 12:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKlnhWj-pbHW for ; Tue, 31 May 2016 12:27:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D4312D7F5 for ; Tue, 31 May 2016 12:27:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0F311AFD; Tue, 31 May 2016 21:27:33 +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 eN2LXJw-2u_W; Tue, 31 May 2016 21:27:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 31 May 2016 21:27:32 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B08920050; Tue, 31 May 2016 21:27:32 +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 ExJDYOcTk-JB; Tue, 31 May 2016 21:27:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD8BE2004E; Tue, 31 May 2016 21:27:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DE41E3AFEECC; Tue, 31 May 2016 21:27:29 +0200 (CEST) Date: Tue, 31 May 2016 21:27:29 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20160531192729.GA23116@elstar.local> Mail-Followup-To: "Joel M. Halpern" , i2rs@ietf.org References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <026df5be-4a60-f340-60aa-d713a0e75c48@joelhalpern.com> <20160531184844.GB22928@elstar.local> <413ef504-49a8-2ba2-7fd4-582a41bd0ad0@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413ef504-49a8-2ba2-7fd4-582a41bd0ad0@joelhalpern.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Ephemeral State Requirements discussion X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:27:36 -0000 On Tue, May 31, 2016 at 03:07:03PM -0400, Joel M. Halpern wrote: > Would a fair paraphrase of the point you are making here be > that the data store could sit next to the data stored > rather than either below or combined with it? > Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 31 12:30:08 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011B512D56D for ; Tue, 31 May 2016 12:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNbxrEWkvpH6 for ; Tue, 31 May 2016 12:30:05 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 CB19712D0CA for ; Tue, 31 May 2016 12:30:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local> In-Reply-To: <20160531171304.GA22857@elstar.local> Date: Tue, 31 May 2016 15:29:55 -0400 Message-ID: <004801d1bb72$d0129680$7037c380$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJdaenpM7ljbP1C/TwjkI20GPnldwI0uYM8AiAGwTkCHPlBSwI0/t9yATo5ZLmebQT3gA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Benoit Claise' , 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:30:07 -0000 Juergen: >I understand YANG validation rules and I understand YANG's notion of configuration datastores. I do not >think this matches your ephemeral configuration validation. This does not provide a technical discussion of: a) what you understand the ephemeral configuration validation rules to be, b) why you do not the model matches the configuration validation rules. 1 Data Model is a great idea for NETCONF/NETMOD. However, it should encompass Ephemeral data:== ephemeral state ::== Ephemeral configuration + Ephemeral operational state Cheers, Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Tuesday, May 31, 2016 1:13 PM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Benoit Claise'; 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements [snip] > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, May 31, 2016 10:26 AM > To: Susan Hares > Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Benoit Claise'; 'Alia Atlas' > Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - > 11:00am > - Topic: Ephemeral State Requirements > > On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote: > >> Juergen: > >> > >> > >> > >> Thank you for the second response. The questions were on version 8 of > the > >> draft. Jeff wanted to review version 8 before posting - so I delayed > >> posting of version 8 until this morning. I've answered your questions > >> based on version 08. > >> > >> I think you understood that the ephemeral datastores defined by > >> i2RS are not what you defined in draft-schoenw-netmod-revised-datastores-00: > >> > >> o The model foresees ephemeral datastores that are by definition not > >> part of the persistent configuration of a device. These ephemeral > >> datastores are considered to interact with the rest of the system > >> like any other control-plane mechanisms (e.g., routing protocols, > >> discovery protocols). [XXX Note that this is different from what > >> is described in some of the I2RS documents. XXX] > >> > >> The difference is that I2RS defines ephemeral configuration and > >> ephemeral operational state. You see this in all of the I2RS data > >> modules. I have augmented your diagram with the proposed I2RS datastore. > >> > >> > >> +------------+ > >> | | // Subject to validation > >> | (ct, ro) | // e.g., missing resources or delays > >> +------------+ // Here I2RS ephemeral configuration > fits > >> | // so missing resources/delays can > be handled > >> v > >> +------------+ > >> | | - here I2RS defines ephemeral > >> | (ct, ro) | configuration data store > >> +------------+ > >> | // e.g., autodiscovery of values > >> v > >> +--------------------------------+ > >> | |<-- control plane and > >> | (ct + cf, ro) | ephemeral datastores > > >> +--------------------------------------------------+ > >> > >> > >> Your definitions ignored the WG requirements and the existing > discussions. > >> Is there a reason why? I2RS follows the break between operational > >> state and configuration data store. > > > > >There needs to be _one_ architectural model. > > I may be ignorant but we have to look at how things fit together. > >What you are drawing is ignoring for instance the fact that > > is >> the subject of configuration >> > validation while I2RS explicitly states that ephemeral is not part > > of >> configuration validation. >> >So your model is not a workable solution either. >> >> Not really, the ephemeral configuration is a part of the configuration > validation. The ephemeral validates as either a stand-alone modules >> (I2RS-RIB), or as a validation of an augmentation (see examples in the >> interim presentation). It is validated at the intended stage of >> configuration. Therefore, the proposal discussed by I2RS is workable. Your >> opinion goes against years of NETCONF people suggesting to I2RS that >> ephemeral configuration and ephemeral operational state is possible. >[Juergen]: I understand YANG validation rules and I understand YANG's notion of configuration datastores. I do not think this matches your ephemeral configuration validation. [sue:] This is not a technical response. Please provide: a) what is the understand you have of the I2RS ephemeral validation rules, b) Why you think it does not match Yang validation rules or Yang's notion of configuration datastores. > >> o configuration datastore: When modeled with YANG, a configuration > >> datastore is realized as an instantiated data tree with > >> configuration data. > >> > >> o Operational state data is a set of data that has been obtained by > >> the system at runtime and influences the system's behavior similar > >> to configuration data. In contrast to configuration data, > >> operational state is transient and modified by interactions with > >> internal components or other systems via specialized protocols. > >> > >> This document is proposed on May 12, 2016 and we have been working > >> on I2RS for over 3 years. You provided something that does not > >> satisfy the requirements of the existing I2RS data models (prepared > >> for over 18 > months). > > > > > Which I2RS requirements? Please be specific. > ================== > Ephemeral-REQ-01 to Ephemeral-REQ-04 cover both configuration and > operational state. If that's not clear, then I guess we need to add them. > Here's the Ephemeral-REQ-01 for version -09 of the text. > > Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does > not persist across reboots. If state must be restored, it should be > done solely by replay actions from the I2RS client via the I2RS > agent. Ephemeral state may consist of ephemeral configuration > or ephemeral operational state, or both. > ======== Juergen: >So how is this broken? This is the only time 'ephemeral operational state' shows up in -09. Sue: The inclusion of operational state has been in the I2RS RIB data model for over 18 months. The I2RS WG had assumed that the I2RS Data models would be examined when creating ephemeral datastore models. So, the inclusion in -09.txt is for your benefit and for others who do not read the I2RS ephemeral-only data models. Juergen: >So please elaborate whether this is by intention in order to express that 'ephemeral operational state' is >something different than a subset of 'operational state' or even better please explain how you think >'ephemeral operational state' >relates to 'operational state'. Ephemeral comes in two varieties: configuration and operational state. The examples in my interim presentation provide you with an example of configuration state. The operational state can also be see by BGP using the node-type as an operational state variable. >In fact, it would help if terminology would be clearly defined. How do >- ephemeral operational state >- ephemeral state >- ephemeral config >- derived state (ephemeral) >- derived state (opstate) >- ephemeral configuration >- mixed ephemeral config (ephemeral + config) The problems with the definitions come to the fact the netmod WG has not settle on a definition of operational state. - ephemeral operational state - ephemeral state which is operational (Node-type as operational state in the examples in my presentation) >- ephemeral state - the combination of I2RS ephemeral configuration and I2RS ephemeral operational state >- ephemeral config - configurations which are ephemeral (see the requirements). Ephemeral configuration only - would be I2RS RIB. >- derived state (ephemeral) - derived state = operational state that exists which is defined by ephemeral object in an I2RS data model. Derived state is a NETMOD's term. >- derived state (opstate) - derived state = operational state that is not ephemeral >- mixed ephemeral config (ephemeral + config) - see the BGP examples in my interim slide Juergen: >relate to each other? Let me check draft-ietf-i2rs-architecture-15.txt: >- ephemeral state >- ephemeral configuration >- ephemeral data - is data which does not persist across a reboot > (software or hardware) or a power on/off condition. Ephemeral > data can be configured data or data recorded from operations of > the router. > ephemeral static state (?) >So is my interpretation right that 'ephemeral data' is the union of 'ephemeral configuration' and 'ephemeral >state'? (If my interpretation of these terms is correct the probably not all usages of the terms are correct in >draft-ietf-i2rs-architecture-15.txt; so more likely my interpretation is incorrect.) Ephemeral data = ephemeral state = ephemeral = ephemeral configuration + ephemeral operational state >Given the operational state is by its nature ephemeral, is there a distinction between 'operational state' and >ephemeral state? Or is 'ephemeral state' just a subset of 'operational state' that has been influenced by >'ephemeral configuration'? See above. To answer your question, no it is not. Snip to next technical discussion >> Been iterating for a while in I2RS. Love to hear technical reasons why the >> ephemeral datastore architecture does not work for you. Juergen: >There are many datastores being proposed and at the end they all need to work together. Implementations >can't support N different datastore models that are not aligned. I understand that this concern is not your >prime problem since your focus is I2RS but please understand that other people are proposing other >datastores and I do believe NETMOD/NETCONF needs to find agreement on a bigger architectural picture >that addresses the various requirements and enables implementations that work in a predictable manner. The fact that the NETCONF/NETMOD people are proposing one model is great. The I2RS work has been existing for 2 years and I2RS should be considered as one of the key requirements for NETCONF datastore definitions. > If mention a few NETCONF calls/ your individuals draft, you must > compare it against the i2RS WG 3 years plus 3 WG drafts to IESG > (pub/sub, traceability, protocol-security), and 2 in final review > (protocol-security environment, ephemeral state). May I suggest > suggesting your draft has precedence or personal behaviors is not a > fruitful discussion. Let's keep on the technical discussion. >I just tried to make you aware that some people think we need a common and consistent architectural model >within NETMOD and NETCONF. I pointed to one proposal. There can be others. But at the end, there needs to >be a single unifying architectural model if we want implementations being able to address requirements >coming from different communities and still behave in a predictable manner. Excellent technical point on 1 model. The problem is your model does not support: Ephemeral data == ephemeral state == ephemeral configuration + ephemeral operational-state /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 31 12:31:11 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3874012D636 for ; Tue, 31 May 2016 12:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK7vJQfkdMn6 for ; Tue, 31 May 2016 12:31:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5C47612D0CA for ; Tue, 31 May 2016 12:31:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 185591E335; Tue, 31 May 2016 15:36:41 -0400 (EDT) Date: Tue, 31 May 2016 15:36:40 -0400 From: Jeffrey Haas To: Susan Hares , i2rs@ietf.org, 'Alia Atlas' Message-ID: <20160531193640.GL17462@pfrc.org> References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160531063840.GA21289@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:31:10 -0000 [Note that I'm answering messages in thread order to the originator of a point rather than necessarily to responses. This is intentional.] On Tue, May 31, 2016 at 08:38:42AM +0200, Juergen Schoenwaelder wrote: > I read: > > Ephemeral-REQ-05: The ability to augment an object with appropriate > YANG structures that have the property of being ephemeral. An object > defined as Yang module, schema tree, a schema node, submodule or > components of a submodule (derived types, groupings, data node, RPCs, > actions, and notifications". > > I have trouble to parse this since the 1st sentence does not seem to > make sense for each element that you consider an object. That said, > the real issue here are lifetimes. The lifetime of a config true > object is determined by config changes, the lifetime of config false > objects is determined by operational state changes. What happens to > an ephemeral augmentation of objects if their lifetime expires? I agree that your observation covers the general intent. The requirements language above is attempting to be a bit too specific for a given implementation detail, namely instantiation of ephemeral behaviors in a data tree. Could you please supply alternative text? > The revised datastore model I have described in > draft-schoenw-netmod-revised-datastores-00 links the ephemeral state > only to operational state, not at all to configuration. Does this > model not satisfy the I2RS requirements and make things much simpler? I've been unable to follow netmod/netconf recently, so thanks for pointing out this document. It does seem to do a nice job in attempting to summarize a number of discussions on the various datastore concepts we've been seeing the last year. There are a few things I find slightly problematic in your hierarchy with respect to what I2RS likely needs for ephemeral configuration state, but I think it might be solvable. Here are some observations: If ephemeral configuration state were to be treated as a datastore that feeds into running, would you expect that the resulting running state should be writable? (I.e. running = candidate, startup + ephemeral?) It would be helpful to see how an ephemeral datastore is intended to interact in this diagram. A detail that would need to be clarified is what happens when there is overlaps in portions of the schemas. > 2. Does Ephemeral-REQ-06 provide the Yang requirements in > > a clear fashion? Do you have any suggestions for alternative text? > > I think it is clear but broken. In particular the part about > indicating secure/non-secure transport. The text relating to transport is applied to generally and needs clarifying. Let's provide a specific goal: For Yang notifications, there may be some desire for the information to be sent across alternative transports, potentially with specific encodings. draft-ietf-netconf-yang-push covers I2RS use cases wherein the data may be sent via alternative transports. Should we have some sort of markup in the Yang language to identify what transports might be utilized? What about security requirements? Obviously we can spell out transport security considerations as part of the description clause within a notification. However, since a significant amount of feedback has been given from individuals with a security background that many objects we're likely to use in I2RS may be security sensitive - but not all! - some way to indicate the sensitivity may be required. The motivation for this is that for insecure and high speed transports and ecodings such as IPFIX (e.g.) it may be fine to expose some data (e.g. interface statistics) but the same may not be true for other data and a secured transport may be required. > > > 3. Do you think any of the Ephemeral-REQ-07 NETCONF Changes > > are not necessary? If so, what changes would you leave out? > > Do the "policy-knobs" seem useful to you? > > > > 4. Do you think any of the Ephemeral-REQ-08 RESTCONF changes > > are not necessary? If so, what changes would you leave out? > > Do we need all the features (yang module library, call-home, > > server)? > > I think this needs to be trimmed down. I think it should be avoided to > create I2RS specific solutions for things that are already in place > (e.g., NETCONF has a mechanism for protocol capability discovery and > negotiation, NETCONF already supports multiple (secure) transports). > > I think that having a clear architectural view is essential. I am not > sure the 'single pane of glass' model is the way to go. I think the > decision on the architectural model is key because it impacts many of > the other requirements and solutions. > > You want both NC and RC to support XML and JSON and SSH and TLS and > (plaintext) TCP? Does this maximum of variability and flexibility > really help interoperability? Perhaps things should be reorganized > into things that are protocol agnostic (and should not be repeated) > and things that are protocol specific - if there is indeed a need to > work with multiple protocols. I agree we're being overly specific here, although as noted above we need some discussion about what to do about insecure transports for some operations, such as subscriptions. (I think that's covered by the yang-push doc in particular.) Item 6 about precedence of local configuration vs. ephemeral configuration requires discussion, including in the revised-datastore document if it chooses to address ephemeral configuration. > I also think that it is not needed to write down requirements to > NETCONF for things that are already solved or being worked on. I think we're happy to subtract these, or at the least call out the existing work in progress. As noted in some earlier drafts, the goal of the I2RS drafts should be to not have drafts in I2RS, but solution space documents in netconf and netmod. > > 5. Do you think the pub/sub requirements are sufficient? > > > > (PUB-SUB-REQ-01, PUB-SUB-REQ-02) > > I would hope that draft-ietf-i2rs-pub-sub-requirements-09 covers > everything that is needed. Again, this is linked to architectural > question. The text, for example, assumes that there is an 'operational > data stores'. As of today, this is not really the case. See > draft-schoenw-netmod-revised-datastores-00 for more details. I think converging on the concept of an conceptional operational datastore would address many of these considerations. (Note that I believe you'll want either additional filtering capabilities to select whether the configuration state in the operational store originates in local configuration or ephemeral configuration. This was in an earlier version of the ephemeral state requirements draft.) I believe the remainder of the configuration state considerations are covered by the yang-push draft in the on-change behavior. -- Jeff From nobody Tue May 31 12:39:34 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193B212D7F2 for ; Tue, 31 May 2016 12:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT8yQ0gVFOnm for ; Tue, 31 May 2016 12:39:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 986BB12D7F5 for ; Tue, 31 May 2016 12:39:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6E9F51E335; Tue, 31 May 2016 15:45:04 -0400 (EDT) Date: Tue, 31 May 2016 15:45:04 -0400 From: Jeffrey Haas To: Susan Hares , i2rs@ietf.org, 'Benoit Claise' , 'Alia Atlas' Message-ID: <20160531194504.GM17462@pfrc.org> References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160531171304.GA22857@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:39:33 -0000 On Tue, May 31, 2016 at 07:13:04PM +0200, Juergen Schoenwaelder wrote: > I understand YANG validation rules and I understand YANG's notion of > configuration datastores. I do not think this matches your ephemeral > configuration validation. Prior working group discussion had suggested that bypassing validation (e.g. constraints) may be required for sufficiently fast operations. Obviously this point has remained contentious. The functional desire is sufficient speed out of configuration operations in the ephemeral elements of the datastore. If that can be done without compromising on validation - or imposing certain considerations on the structure of i2rs/ephemeral modules - I suspect that would satisfy the working group. > > Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does > > not persist across reboots. If state must be restored, it should be > > done solely by replay actions from the I2RS client via the I2RS > > agent. Ephemeral state may consist of ephemeral configuration > > or ephemeral operational state, or both. > > ======== > > So how is this broken? This is the only time 'ephemeral operational > state' shows up in -09. So please elaborate whether this is by > intention in order to express that 'ephemeral operational state' is > something different than a subset of 'operational state' or even > better please explain how you think 'ephemeral operational state' > relates to 'operational state'. I would suggest that we avoid talking about "ephemeral operational state". While it's possible to discuss the context of such a thing existing as a result of schema rules that config false nodes may be under nodes that are both config true and ephemeral true (using our example keyword modifications), I don't think calling it ephemeral operational state brings too much to the conversation. The one case for possible concern is that in the event the ephemeral datastore is off-line is that such config false nodes may not be present. However, this may be covered by other existing netconf mechanisms depending on how the ephemeral datastore and related modules are instantiated in the protocol. > There are many datastores being proposed and at the end they all need > to work together. Implementations can't support N different datastore > models that are not aligned. I understand that this concern is not > your prime problem since your focus is I2RS but please understand that > other people are proposing other datastores and I do believe > NETMOD/NETCONF needs to find agreement on a bigger architectural > picture that addresses the various requirements and enables > implementations that work in a predictable manner. Some of the frustration comes from the discussion for ephemeral state having been ongoing while the current operational state discussions have been somewhat new. We agree that we need to have a unified datastore architecture. -- Jeff From nobody Tue May 31 12:45:53 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9ECC12D124 for ; Tue, 31 May 2016 12:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6swrjauWFx6p for ; Tue, 31 May 2016 12:45:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5A69712D115 for ; Tue, 31 May 2016 12:45:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 37B9E1E335; Tue, 31 May 2016 15:51:23 -0400 (EDT) Date: Tue, 31 May 2016 15:51:23 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20160531195123.GN17462@pfrc.org> References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Benoit Claise , "i2rs@ietf.org" , Juergen Schoenwaelder , Susan Hares , Alia Atlas Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:45:52 -0000 Andy, On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote: > At some point the WG needs to agree on normative text instead of iterating > on requirements forever. IMO, it would be in I2RS's best interests if netconf/netmod provided drafts in appropriately normative language covering I2RS requirements. However, we've been in a pathological cycle of: "We don't understand, please give us requirements" "We don't understand your requirements" "You provided examples with your requirements that appear to be attempts to change our protocol - don't do that." The most recent revised-datastore draft would be a good place to document where netmod(/netconf) believes ephemeral datastores (if that's the instantiation) could live, and also how ephemeral configuration state could interact with candidate, startup and running configuration. yang-push covers much of our desired pub-sub behavior. (Yay!) Discussion is required for how to tag security considerations impacting transport into the yang model, in particular for notification. Proposals for secondary identity and priority are also needed. -- Jeff From nobody Tue May 31 13:06:20 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CCE12D0C5 for ; Tue, 31 May 2016 13:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olFW-P67N7iT for ; Tue, 31 May 2016 13:06:18 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 8FF6212D640 for ; Tue, 31 May 2016 13:06:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 784249A0287 for ; Tue, 31 May 2016 13:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464725178; bh=VqoW3aOygj9taRrT2njdUPNym/qkEHEq0zn7AlZOSnI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GyorBI1irkD50Hgbw1kFDc0GRGNxtjrQJFaRPZkVhaxDARtlI06fUeSrEzip0NGvu El6SwqG7y7qpmiD1LqF3U6ldsotnN3cVczBt9WAq7h211N2egKPOIRIXI3f6tuMXPk 2IWSlD4AfpVO9+/v3ZFq2uDuL3+9EeOPNJiUrR0U= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 25DB59A0285 for ; Tue, 31 May 2016 13:06:18 -0700 (PDT) To: i2rs@ietf.org References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <026df5be-4a60-f340-60aa-d713a0e75c48@joelhalpern.com> <20160531184844.GB22928@elstar.local> <413ef504-49a8-2ba2-7fd4-582a41bd0ad0@joelhalpern.com> <20160531192729.GA23116@elstar.local> From: "Joel M. Halpern" Message-ID: Date: Tue, 31 May 2016 16:06:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160531192729.GA23116@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Ephemeral State Requirements discussion X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:06:20 -0000 Thanks. That makes sense to me. Yours, Joel On 5/31/16 3:27 PM, Juergen Schoenwaelder wrote: > On Tue, May 31, 2016 at 03:07:03PM -0400, Joel M. Halpern wrote: >> Would a fair paraphrase of the point you are making here be >> that the data store could sit next to the data stored >> rather than either below or combined with it? >> > > Yes. > > /js > From nobody Tue May 31 13:10:10 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9084512D652 for ; Tue, 31 May 2016 13:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm5fh6kjhnKR for ; Tue, 31 May 2016 13:10:08 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 5332E12D641 for ; Tue, 31 May 2016 13:10:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3FE7A9A0382; Tue, 31 May 2016 13:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464725408; bh=ENJmEWcMMkZCaZoW+kZ4ZRBsQKEZ89vI+0oFi1lUuQE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Nj/Uz3d9aBKYWZ3poJPqmDsIRd0WS9zZsWou0QzrCNRnmi7JIWma/7y99yfrLmtId e8/ta4rf2OLGUW5a/cHky2VarR2iYLaGaVWqskMJ2TsIuq/hHKnV5Nfywd5yglPqwZ z1U7P4Njg5wB/s1Yy342VeKMvWrcQeQ7UuabZL1k= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C71A11C0B82; Tue, 31 May 2016 13:10:07 -0700 (PDT) To: Susan Hares References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local> <004801d1bb72$d0129680$7037c380$@ndzh.com> From: "Joel M. Halpern" Message-ID: <7026105d-6695-c001-ab91-a566bcf8405e@joelhalpern.com> Date: Tue, 31 May 2016 16:10:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <004801d1bb72$d0129680$7037c380$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:10:09 -0000 Can you clarify something for me? What is ephemeral operational state? The only thing I can think of is operational state like statistics related to ephemeral leaves or constructs? Is that what you mean by "ephemeral operational state"? The reason i ask is that such state does not seem to need any special handling or labeling. Yours, Joel On 5/31/16 3:29 PM, Susan Hares wrote: > Juergen: > > >> I understand YANG validation rules and I understand YANG's notion of > configuration datastores. I do not >think this matches your ephemeral > configuration validation. > > This does not provide a technical discussion of: > a) what you understand the ephemeral configuration validation rules to be, > b) why you do not the model matches the configuration validation rules. > > 1 Data Model is a great idea for NETCONF/NETMOD. However, it should > encompass > > Ephemeral data:== ephemeral state ::== Ephemeral configuration + Ephemeral > operational state > > Cheers, > > Sue From nobody Tue May 31 13:17:57 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712EA12D64A for ; Tue, 31 May 2016 13:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epVSuJ_yqfDD for ; Tue, 31 May 2016 13:17:53 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 DFB4A12D0E9 for ; Tue, 31 May 2016 13:17:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CCA5C9E000F; Tue, 31 May 2016 13:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464725873; bh=JV2qjavC3v/qlv7w0rbeOUoV8SyXg6Ttaf7Fupm4d60=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dwJ0YE50PgwVvwLL0MLHfWp8aHlVn62mLC9/fqWqXwhp7jLp3sdKk6h5H8QXCUKfi nFWvwSUyz9lCw2OaxjrSN6n0sl9508wPhO9XHbQQiyzQFIvMtRL/0m/XbmrEOv5630 2pJTxkc7gO6j29A83vEonSSPZRO7iDVUfPF5m2r4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4E5861C0B82; Tue, 31 May 2016 13:17:53 -0700 (PDT) To: Jeffrey Haas , Susan Hares , i2rs@ietf.org References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <20160531193640.GL17462@pfrc.org> From: "Joel M. Halpern" Message-ID: <92905b12-3422-316c-67e9-1aefbbebc035@joelhalpern.com> Date: Tue, 31 May 2016 16:17:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160531193640.GL17462@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] I2RS Requriements - secure transfer X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:17:55 -0000 The more I read the text about marking secure or insecure transports, the I wonder whether it is an I2RS requirement at all. that is, I2RS requires the ability to send notifications via an insecure channel. I don't think I2RS cares what granularity this is marked at. There are security reasons for wanting to restrict the usage. Equally, one needs any definition of some usage to be done by the entity which actually knows what is needed. I2RS as a system does not know or care how to resolve that tension. So lets not state a requirement on it? Jeff, you allude to using a protocol like IPFIX. Given that IPFix won't be reading these YANG models at all, it seems that the requirement as stated (marking in the YANG which nodes are allowed to be transferred insecurely) won't help solve the problem. I also wonder if the very notion of an I2RS protocol is getting in the way. If the insecure transfer we envision is some protocol other than NetConf / RestConf, then we seem to be stating the requirement in the wrong place. Yours, Joel On 5/31/16 3:36 PM, Jeffrey Haas wrote: > ... > On Tue, May 31, 2016 at 08:38:42AM +0200, Juergen Schoenwaelder wrote: ... >> 2. Does Ephemeral-REQ-06 provide the Yang requirements in >>> a clear fashion? Do you have any suggestions for alternative text? >> >> I think it is clear but broken. In particular the part about >> indicating secure/non-secure transport. > > The text relating to transport is applied to generally and needs clarifying. > Let's provide a specific goal: > > For Yang notifications, there may be some desire for the information to be > sent across alternative transports, potentially with specific encodings. > draft-ietf-netconf-yang-push covers I2RS use cases wherein the data may be > sent via alternative transports. Should we have some sort of markup in the > Yang language to identify what transports might be utilized? What about > security requirements? > > Obviously we can spell out transport security considerations as part of the > description clause within a notification. However, since a significant > amount of feedback has been given from individuals with a security > background that many objects we're likely to use in I2RS may be security > sensitive - but not all! - some way to indicate the sensitivity may be > required. > > The motivation for this is that for insecure and high speed transports and > ecodings such as IPFIX (e.g.) it may be fine to expose some data (e.g. > interface statistics) but the same may not be true for other data and a > secured transport may be required. ... From nobody Tue May 31 13:23:57 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC71212D652 for ; Tue, 31 May 2016 13:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbLyZKbYg1OI for ; Tue, 31 May 2016 13:23:54 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 9923C12D64A for ; Tue, 31 May 2016 13:23:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Joel M. Halpern'" , References: In-Reply-To: Date: Tue, 31 May 2016 16:23:54 -0400 Message-ID: <005601d1bb7a$5aacbfd0$10063f70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIhcry/DffX1766+S6/UC1Jb9Ue0Z80Dr3A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] ephemeral RPC? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:23:56 -0000 Joel: I2RS data model is a ephemeral-only data model, and uses an rpc to do rib add/delete, route add/delete, nexthop add/delete. Therefore, we need ephemeral rpc support. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, May 31, 2016 12:34 PM To: i2rs@ietf.org Subject: [i2rs] ephemeral RPC? We have agreed that non-ephemeral data must not reference ephemeral data. However, we have, up till now, not had the notion of ephemeral RPCs. I see that the recent ephemeral requirements draft, as a side-effect of improving clarity, creates the notion of an ephemeral RPC. What is an ephemeral RPC, and why do we have it? We have been, up till now, assuming that we could use normal NetConf RPCs to set and get the ephemeral information. Thank you, Joel _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 31 13:27:23 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E715C12D7F4 for ; Tue, 31 May 2016 13:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NImTNOAoNPsV for ; Tue, 31 May 2016 13:27:20 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 606A512D652 for ; Tue, 31 May 2016 13:27:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 494799E017A; Tue, 31 May 2016 13:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464726440; bh=vEu0QrPqSHBRxsvq+SZFgLzvWi5PTq7nK+cfEiX4cps=; h=Subject:To:References:From:Date:In-Reply-To:From; b=okyr4+uQUDk0Bc3eQ9wgN59dAEFQTA+g2K8f5Ox0Q0KF183M8k5ugmN4IO4+IGpsM 77toJ/lIZkQ5jz7de/Y598IUJMk/CU0287mVCxTuUcDekCpLlu924zKXkzkLFwLTxT 5O/JiPA2Wpuu9iSLEjHxHpSm1f4DK5R/juwyPR3U= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D36D19E004F; Tue, 31 May 2016 13:27:19 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <005601d1bb7a$5aacbfd0$10063f70$@ndzh.com> From: Joel Halpern Direct Message-ID: <7147944e-fe4d-4ea2-47af-1264188f426c@joelhalpern.com> Date: Tue, 31 May 2016 16:27:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <005601d1bb7a$5aacbfd0$10063f70$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] ephemeral RPC? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:27:22 -0000 This may well be just me leaping to assumptions about function structuring. My apologies for raising a red herring if so. I think this may be following the paradigm in Juergen's draft, where accessing data and in different data stores uses different RPCs? Is that your intent? Until I read Juergen's draft, it had never occurred to me that one would do it that way. I had expected that one would perform an operation, and target it at a data store. But if indeed we use different RPCs for the different data stores, then I guess we do need versions of and that point at ephemeral. Yours, Joel On 5/31/16 4:23 PM, Susan Hares wrote: > Joel: > > I2RS data model is a ephemeral-only data model, and uses an rpc to do rib > add/delete, route add/delete, nexthop add/delete. Therefore, we need > ephemeral rpc support. > > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, May 31, 2016 12:34 PM > To: i2rs@ietf.org > Subject: [i2rs] ephemeral RPC? > > We have agreed that non-ephemeral data must not reference ephemeral data. > > However, we have, up till now, not had the notion of ephemeral RPCs. I see > that the recent ephemeral requirements draft, as a side-effect of improving > clarity, creates the notion of an ephemeral RPC. > > What is an ephemeral RPC, and why do we have it? > We have been, up till now, assuming that we could use normal NetConf RPCs to > set and get the ephemeral information. > > Thank you, > Joel > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue May 31 13:28:00 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2AE12D8C1 for ; Tue, 31 May 2016 13:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC-6xHj3cxM4 for ; Tue, 31 May 2016 13:27:57 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 DBF0E12D652 for ; Tue, 31 May 2016 13:27:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Joel M. Halpern'" References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <026df5be-4a60-f340-60aa-d713a0e75c48@joelhalpern.com> <20160531184844.GB22928@elstar.local> <413ef504-49a8-2ba2-7fd4-582a41bd0ad0@joelhalpern.com> <20160531192729.GA23116@elstar.local> In-Reply-To: <20160531192729.GA23116@elstar.local> Date: Tue, 31 May 2016 16:27:51 -0400 Message-ID: <005801d1bb7a$e7b2e440$b718acc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJdaenpM7ljbP1C/TwjkI20GPnldwI0uYM8ArQFymECLv3ehAG5Y7N3Ajn3nEieY8iZYA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Ephemeral State Requirements discussion X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:27:58 -0000 Juergen: How does ephemeral sitting next to the data store provide the ability to augment configuration with ephemeral configuration or operational state with ephemeral operational state? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, May 31, 2016 3:27 PM To: Joel M. Halpern Cc: i2rs@ietf.org Subject: Re: [i2rs] Ephemeral State Requirements discussion On Tue, May 31, 2016 at 03:07:03PM -0400, Joel M. Halpern wrote: > Would a fair paraphrase of the point you are making here be that the > data store could sit next to the data stored > rather than either below or combined with it? > Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 31 14:00:31 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABF812D8E5 for ; Tue, 31 May 2016 14:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75vXH5yDD1Dx for ; Tue, 31 May 2016 14:00:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B99FC12D8CC for ; Tue, 31 May 2016 14:00:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 670791E335; Tue, 31 May 2016 17:06:00 -0400 (EDT) Date: Tue, 31 May 2016 17:06:00 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20160531210600.GN10531@pfrc.org> References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <20160531193640.GL17462@pfrc.org> <92905b12-3422-316c-67e9-1aefbbebc035@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92905b12-3422-316c-67e9-1aefbbebc035@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org, Susan Hares Subject: Re: [i2rs] I2RS Requriements - secure transfer X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 21:00:29 -0000 Joel, On Tue, May 31, 2016 at 04:17:50PM -0400, Joel M. Halpern wrote: > The more I read the text about marking secure or insecure > transports, the I wonder whether it is an I2RS requirement at all. > that is, I2RS requires the ability to send notifications via an > insecure channel. The requirements have been getting written in a very proscriptive manner for the cases when security *is* required. We have had numerous discussions about other transports, which *might not* be secured. If your argument is that because we MUST support the secured cases that we don't need to cover the insecure cases, I strongly disagree. > I don't think I2RS cares what granularity this is marked at. I2RS doesn't give a darn. Models and security folk reviewing the models do. > So lets not state a requirement on it? Let's not try to brush it off. > Jeff, you allude to using a protocol like IPFIX. Given that IPFix > won't be reading these YANG models at all, it seems that the > requirement as stated (marking in the YANG which nodes are allowed > to be transferred insecurely) won't help solve the problem. Please try to have paid attention to the discussion the last two years about pub-sub mechanisms for telemtry data. We have more than one vendor which has implemented some form of telemetry state coverable by yang modeling with alternate presentation or transport layers. The most common example regularly cited has been GRPC with protobufs encoding. Discussion has happened in-hallway, on-list and between vendors about the potential programmatic mapping layers between things like protobufs, thrift and even IPFIX and yang although to my knowledge only protobufs and thrift had gotten more than a smattering of attention. > I also wonder if the very notion of an I2RS protocol is getting in > the way. If the insecure transfer we envision is some protocol > other than NetConf / RestConf, then we seem to be stating the > requirement in the wrong place. IMO, calling it an "I2RS protocol" was mistaken. The minute we decided we were going to attempt to leverage existing mechanisms such as netconf and restconf, the framing should have simply been "extensions to support i2rs cases". If netconf proved intransigent against the changes in question, it was likely at some point that the vendor set implementing i2rs mechanisms would eventually chosen to have forked netconf protocol behaviors to support their code and use cases for ephemeral state. Thus far, it appears that each has chosen to stay with their own internal forms of ephemeral configuration and avoid exposing netconf mappings until these issues have resolved. -- Jeff From nobody Tue May 31 14:07:17 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95F012D8CC for ; Tue, 31 May 2016 14:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-QPS1US17v8 for ; Tue, 31 May 2016 14:07:14 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD7912D56C for ; Tue, 31 May 2016 14:07:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DDDBE267891; Tue, 31 May 2016 14:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464728833; bh=bFTg9esvDfyQIcogiCCtD3WpZyE2yPkj+A9dwCFMot4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=OWYlzJvGNk1F89UZuN1jQEE9DQ1QrKq5pFDixEj7MpDnGLJbJq55BO90mIRrQ4hca cwbz7GqYztalR8igoznbYgP3k0uxzkcsfUeA+JsB+4W0SL1VoqZH/3kQkqOHlvh5Mj CXB26RJ5xnDmvUnKXqE5NiFE910fCp2mPWQDp3F4= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 5C20B258B0E; Tue, 31 May 2016 14:07:13 -0700 (PDT) To: Jeffrey Haas References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <20160531193640.GL17462@pfrc.org> <92905b12-3422-316c-67e9-1aefbbebc035@joelhalpern.com> <20160531210600.GN10531@pfrc.org> From: "Joel M. Halpern" Message-ID: Date: Tue, 31 May 2016 17:07:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160531210600.GN10531@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, Susan Hares Subject: Re: [i2rs] I2RS Requriements - secure transfer X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 21:07:15 -0000 All I was saying was that we as I2RS should focus on our requirement that it be possible to ship some data in a non-secure transport. While I am tempted to argue against the requirement, it is the WG consensus, so it stands. But when it comes to declaring requirements on marking which pieces of data may be shipped insecurely, and specifically marking that in AYNG, I think we are overstating the requirement. Yours, Joel On 5/31/16 5:06 PM, Jeffrey Haas wrote: > Joel, > > On Tue, May 31, 2016 at 04:17:50PM -0400, Joel M. Halpern wrote: >> The more I read the text about marking secure or insecure >> transports, the I wonder whether it is an I2RS requirement at all. >> that is, I2RS requires the ability to send notifications via an >> insecure channel. > > The requirements have been getting written in a very proscriptive manner for > the cases when security *is* required. > > We have had numerous discussions about other transports, which *might not* > be secured. > > If your argument is that because we MUST support the secured cases that we > don't need to cover the insecure cases, I strongly disagree. > >> I don't think I2RS cares what granularity this is marked at. > > I2RS doesn't give a darn. Models and security folk reviewing the models do. > >> So lets not state a requirement on it? > > Let's not try to brush it off. > >> Jeff, you allude to using a protocol like IPFIX. Given that IPFix >> won't be reading these YANG models at all, it seems that the >> requirement as stated (marking in the YANG which nodes are allowed >> to be transferred insecurely) won't help solve the problem. > > Please try to have paid attention to the discussion the last two years about > pub-sub mechanisms for telemtry data. We have more than one vendor which > has implemented some form of telemetry state coverable by yang modeling with > alternate presentation or transport layers. The most common example > regularly cited has been GRPC with protobufs encoding. Discussion has > happened in-hallway, on-list and between vendors about the potential > programmatic mapping layers between things like protobufs, thrift and even > IPFIX and yang although to my knowledge only protobufs and thrift had gotten > more than a smattering of attention. > >> I also wonder if the very notion of an I2RS protocol is getting in >> the way. If the insecure transfer we envision is some protocol >> other than NetConf / RestConf, then we seem to be stating the >> requirement in the wrong place. > > IMO, calling it an "I2RS protocol" was mistaken. The minute we decided we > were going to attempt to leverage existing mechanisms such as netconf and > restconf, the framing should have simply been "extensions to support i2rs > cases". > > If netconf proved intransigent against the changes in question, it was > likely at some point that the vendor set implementing i2rs mechanisms would > eventually chosen to have forked netconf protocol behaviors to support their > code and use cases for ephemeral state. Thus far, it appears that each has > chosen to stay with their own internal forms of ephemeral configuration and > avoid exposing netconf mappings until these issues have resolved. > > -- Jeff > > From nobody Tue May 31 14:08:45 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141BB12D56C for ; Tue, 31 May 2016 14:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yef4lomUHlQb for ; Tue, 31 May 2016 14:08:42 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B702512D8F0 for ; Tue, 31 May 2016 14:08:35 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id c127so201981165ywb.1 for ; Tue, 31 May 2016 14:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=olnnSLywaVLxARqbbZt2iSEPQWVMjwQeLkalqGRvLdw=; b=pwLW+64FGfcQxyZWBEgIod/qoguGfGHvxCvNtVcdp0XGpbBCh0D+JbOwxhkWEHn+es IivmYmGwC2q1CPB3SUuefREz9o82nWNQbARIcpjyBLwq9ft+sboOEJksX2my3jZpHpUU GynEBsbxGQrZ5Kf8VzKYQ6opSYUU4dxR8LJax3m+qtDYXvxHUI+jdVNq4srd+FiKtDpm xEvSiCzT8MyIkeaan9PBa2swQXE539ARD3osJzxi9M4adtrjyjlO/E09QHD6z59ZiUKI Y3WnM7kc3hY1G3+dBbue5wpN6GGJh2vt4Fbfgor5MOoA6J61Vt66e0Zq05nqlVryZUN1 3pFw== 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; bh=olnnSLywaVLxARqbbZt2iSEPQWVMjwQeLkalqGRvLdw=; b=Cay4TlXzqGfbUk4ajwsOqhx90GehuhrqGEV8rgVnxizuCzGWeXJtD/UOTp32F1aRIG FN3mXe5kGQq6GEQJ4DrjrN7FIE3B8Ukzu++k9Ja59FnfHRTWPyih0J4AAQ6JSaGJ5qYF Y44w5rAsz5pmvjPvZVjdTiJqQJVFSJYn62zPucuBdv9u4MVtNC9z5mUOlo/qpax8WYKZ 1tWdtzw2P60NZMyEsrypkbReUasDXZDEjUabKsHKWpldNwrQWXsEjSWe2hRErpLGn7qC lQlu6SxVfuUjkFHYSbs+ylbdC1OFw76OOaf9uc1vzrzA1ueihPNJ5YT9I+lH4tPQP6lr 4PXQ== X-Gm-Message-State: ALyK8tI8i2cNjDO41V+mQRzNEhVty8+2lnNfkQhr3om7iGh1qVtjPCB3zvDonSx7hdEi0kmntvtrZMadEaVm8w== MIME-Version: 1.0 X-Received: by 10.13.215.149 with SMTP id z143mr89670ywd.166.1464728914925; Tue, 31 May 2016 14:08:34 -0700 (PDT) Received: by 10.37.115.208 with HTTP; Tue, 31 May 2016 14:08:34 -0700 (PDT) In-Reply-To: <20160531195123.GN17462@pfrc.org> References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local> <20160531195123.GN17462@pfrc.org> Date: Tue, 31 May 2016 14:08:34 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=94eb2c07621eaae63e053429c60d Archived-At: Cc: Benoit Claise , "i2rs@ietf.org" , Juergen Schoenwaelder , Susan Hares , Alia Atlas Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 21:08:44 -0000 --94eb2c07621eaae63e053429c60d Content-Type: text/plain; charset=UTF-8 Hi, I am not convinced the IETF can be forced to function as if it were a dev-group in some corporation. This is a volunteer organization so usually solution proposals come from people who have created a solution and they want the WG to standardize it. Andy On Tue, May 31, 2016 at 12:51 PM, Jeffrey Haas wrote: > Andy, > > On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote: > > At some point the WG needs to agree on normative text instead of > iterating > > on requirements forever. > > IMO, it would be in I2RS's best interests if netconf/netmod provided drafts > in appropriately normative language covering I2RS requirements. However, > we've been in a pathological cycle of: > "We don't understand, please give us requirements" > "We don't understand your requirements" > "You provided examples with your requirements that appear to be attempts to > change our protocol - don't do that." > > The most recent revised-datastore draft would be a good place to document > where netmod(/netconf) believes ephemeral datastores (if that's the > instantiation) could live, and also how ephemeral configuration state could > interact with candidate, startup and running configuration. > > yang-push covers much of our desired pub-sub behavior. (Yay!) > > Discussion is required for how to tag security considerations impacting > transport into the yang model, in particular for notification. > > Proposals for secondary identity and priority are also needed. > > -- Jeff > --94eb2c07621eaae63e053429c60d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am not convinced the IETF can be = forced to function as if it were
a dev-group in some corporation.= =C2=A0 This is a volunteer organization so
usually solution propo= sals come from people who have created a solution
and they want t= he WG to standardize it.


Andy
=


On Tue, May 31, 2016 at 12:51 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Andy,

On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote:
> At some point the WG needs to agree on normative text instead of itera= ting
> on requirements forever.

IMO, it would be in I2RS's best interests if netconf/netmod provided dr= afts
in appropriately normative language covering I2RS requirements.=C2=A0 Howev= er,
we've been in a pathological cycle of:
"We don't understand, please give us requirements"
"We don't understand your requirements"
"You provided examples with your requirements that appear to be attemp= ts to
change our protocol - don't do that."

The most recent revised-datastore draft would be a good place to document where netmod(/netconf) believes ephemeral datastores (if that's the
instantiation) could live, and also how ephemeral configuration state could=
interact with candidate, startup and running configuration.

yang-push covers much of our desired pub-sub behavior. (Yay!)

Discussion is required for how to tag security considerations impacting
transport into the yang model, in particular for notification.

Proposals for secondary identity and priority are also needed.

-- Jeff

--94eb2c07621eaae63e053429c60d-- From nobody Tue May 31 14:52:33 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9212D671 for ; Tue, 31 May 2016 14:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GILuad3HgkT for ; Tue, 31 May 2016 14:52:30 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8424612D676 for ; Tue, 31 May 2016 14:52:30 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9CAC21E335; Tue, 31 May 2016 17:58:02 -0400 (EDT) Date: Tue, 31 May 2016 17:58:02 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20160531215802.GO17462@pfrc.org> References: <005601d1bb7a$5aacbfd0$10063f70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005601d1bb7a$5aacbfd0$10063f70$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" Subject: Re: [i2rs] ephemeral RPC? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 21:52:32 -0000 Sue, Rather than saying "ephemeral RPC", I suspect you mean an RPC that has impact on ephemeral configuration or operational state. Arguably, if the RPC in question only manifests as operational state for that case the idea of ephemeral configuration in yang may become moot. -- Jeff On Tue, May 31, 2016 at 04:23:54PM -0400, Susan Hares wrote: > Joel: > > I2RS data model is a ephemeral-only data model, and uses an rpc to do rib > add/delete, route add/delete, nexthop add/delete. Therefore, we need > ephemeral rpc support. > > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, May 31, 2016 12:34 PM > To: i2rs@ietf.org > Subject: [i2rs] ephemeral RPC? > > We have agreed that non-ephemeral data must not reference ephemeral data. > > However, we have, up till now, not had the notion of ephemeral RPCs. I see > that the recent ephemeral requirements draft, as a side-effect of improving > clarity, creates the notion of an ephemeral RPC. > > What is an ephemeral RPC, and why do we have it? > We have been, up till now, assuming that we could use normal NetConf RPCs to > set and get the ephemeral information. > > Thank you, > Joel > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 31 15:17:13 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79B712D66B for ; Tue, 31 May 2016 15:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2aRalFy-rUe for ; Tue, 31 May 2016 15:17:10 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 236FD12D66A for ; Tue, 31 May 2016 15:17:10 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Jeffrey Haas'" References: <005601d1bb7a$5aacbfd0$10063f70$@ndzh.com> <20160531215802.GO17462@pfrc.org> In-Reply-To: <20160531215802.GO17462@pfrc.org> Date: Tue, 31 May 2016 18:17:09 -0400 Message-ID: <007b01d1bb8a$2c7e4a10$857ade30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIhcry/DffX1766+S6/UC1Jb9Ue0QFfwZxbAuhMHnefEe5SsA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" Subject: Re: [i2rs] ephemeral RPC? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 22:17:12 -0000 Jeff: Yes, this could be another way to look at it. Sue -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Tuesday, May 31, 2016 5:58 PM To: Susan Hares Cc: 'Joel M. Halpern'; i2rs@ietf.org Subject: Re: [i2rs] ephemeral RPC? Sue, Rather than saying "ephemeral RPC", I suspect you mean an RPC that has impact on ephemeral configuration or operational state. Arguably, if the RPC in question only manifests as operational state for that case the idea of ephemeral configuration in yang may become moot. -- Jeff On Tue, May 31, 2016 at 04:23:54PM -0400, Susan Hares wrote: > Joel: > > I2RS data model is a ephemeral-only data model, and uses an rpc to do > rib add/delete, route add/delete, nexthop add/delete. Therefore, we > need ephemeral rpc support. > > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, May 31, 2016 12:34 PM > To: i2rs@ietf.org > Subject: [i2rs] ephemeral RPC? > > We have agreed that non-ephemeral data must not reference ephemeral data. > > However, we have, up till now, not had the notion of ephemeral RPCs. > I see that the recent ephemeral requirements draft, as a side-effect > of improving clarity, creates the notion of an ephemeral RPC. > > What is an ephemeral RPC, and why do we have it? > We have been, up till now, assuming that we could use normal NetConf > RPCs to set and get the ephemeral information. > > Thank you, > Joel > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 31 16:09:33 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A4312D8FD for ; Tue, 31 May 2016 16:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxn6YCBbxCIo for ; Tue, 31 May 2016 16:09:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC9C12D8F5 for ; Tue, 31 May 2016 16:09:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPY93567; Tue, 31 May 2016 23:09:19 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 1 Jun 2016 00:09:17 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Tue, 31 May 2016 16:09:10 -0700 From: Linda Dunbar To: Andy Bierman , Jeffrey Haas Thread-Topic: Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"? Thread-Index: AQHRuwdHMrGy2rZxuUWS355zkiS+h5/TiV6AgAAGiQCAAA0BgIAAIcQAgAAY2ICAABNkgIAAFZAA//+mzqA= Date: Tue, 31 May 2016 23:09:10 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657EACE6D@dfweml501-mbb> References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local> <20160531195123.GN17462@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.71] Content-Type: multipart/related; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F657EACE6Ddfweml501mbb_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.574E19A0.00F7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1d341fef6ca7966102422d52821189ac Archived-At: Cc: Benoit Claise , "i2rs@ietf.org" , Juergen Schoenwaelder , Susan Hares , Alia Atlas Subject: [i2rs] Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 23:09:32 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F657EACE6Ddfweml501mbb_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657EACE6Ddfweml501mbb_" --_000_4A95BA014132FF49AE685FAB4B9F17F657EACE6Ddfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SUVURiBoYXMgYmVlbiBzdWNjZXNzZnVsIGZvciBwYXN0IDIwIHllYXJzICBpbiBmb2N1c2luZyBv biDigJxPdmVyIHRoZSBXaXJl4oCdIGRhdGEgc3RydWN0dXJlLiAgSXQgd291bGQgYmUgc28gbXVj aCBjbGVhbmVyIGFuZCBzdHJhaWdodCBmb3J3YXJkIGlmIHRoZSBZQU5HIG1vZHVsZXMgZGV2ZWxv cGVkIGJ5IEkyUlMgIGZvY3VzaW5nIG9uIHRoZSDigJxPdmVyIHRoZSBXaXJl4oCdIGRhdGEgc3Ry dWN0dXJlIChhbmQgd2l0aCBORVRNT0QgdG8gZm9jdXMgb24gb3RoZXIgYXNwZWN0cykuDQpUaGUg 4oCcSTJSUyBlcGhlbWVyYWwgU3RhdGXigJ0gaGFzIHRoZSBuZWVkZWQgZGVzY3JpcHRpb24gZm9y IHRoZSBkZXNpcmVkIGJlaGF2aW9yICBvZiB0aGUgZGF0YSByZWNlaXZlZCBvdmVyIEkyUlMgaW50 ZXJmYWNlLiBJZiB3ZSBmb2xsb3cgdGhlIElFVEYgcHJhY3RpY2UsICBpdCBpcyBnb29kIGVub3Vn aC4NCkludGVybmFsIGltcGxlbWVudGF0aW9uIGZyYW1ld29yayBpcyBhbHdheXMgY29udHJvdmVy c2lhbCwgaGFyZCB0byBjb252ZXJnZSwgdXN1YWxseSBlbmRpbmcgdXAgd2l0aCBhIGRvY3VtZW50 IChpZiBjb21wbGV0ZWQpIHRoYXQgaXMgdG9vIGJpZyBhbmQgZGlmZmljdWx0IHRvIHJlYWQuDQoN ClByb3ZpZGluZyBzb21lIHNvdXJjZSBjb2RlIHRvIHNob3cgdGhlIGludGVybmFsIGltcGxlbWVu dGF0aW9uIHdvdWxkIGJlIG11Y2ggbW9yZSB1c2VmdWwgYXMgYSByZWZlcmVuY2UgaW1wbGVtZW50 YXRpb24uDQoNClRoZSBkcmFmdC1zY2hvZW53LW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDAg aXMgb24gdGhlIGFyY2hpdGVjdHVyYWwgZnJhbWV3b3JrIGZvciBkYXRhc3RvcmVzIGFzIHRoZXkg YXJlIHVzZWQgYnkgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scy4gSU1ITywgaG93IGRhdGEg c3RvcmVzIGFyZSB1c2VkIGFyZSBpbnRlcm5hbCB0byB0aGUgZW5kIHBvaW50cy4NCg0KW2h0dHA6 Ly93d3cudXJiYW5ibGlzc2xpZmUuY29tL3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDEyLzEwL0RvbmUt aXMtQmV0dGVyLVRoYW4tUGVyZmVjdC5qcGddPGh0dHA6Ly93d3cuZ29vZ2xlLmNvbS91cmw/c2E9 aSZyY3Q9aiZxPSZlc3JjPXMmc291cmNlPWltYWdlcyZjZD0mY2FkPXJqYSZ1YWN0PTgmdmVkPTBh aFVLRXdqNTBLV2F0NFhOQWhVTHhHTUtIUmhxRFBRUWpSd0lCdyZ1cmw9aHR0cCUzQSUyRiUyRnd3 dy51cmJhbmJsaXNzbWVkaWEuY29tJTJGZW50cmVwcmVuZXVyLXJ1bGVzLWRvbmUtaXMtYmV0dGVy LXRoYW4tcGVyZmVjdCUyRiZwc2lnPUFGUWpDTkdLRWlQQjJpSFNxeUJpRjU2MDlwZDcySDBMN3cm dXN0PTE0NjQ4MjI1MDM4NjU3Nzc+DQoNCkxpbmRhIER1bmJhcg0KDQpGcm9tOiBpMnJzIFttYWls dG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50 OiBUdWVzZGF5LCBNYXkgMzEsIDIwMTYgNDowOSBQTQ0KVG86IEplZmZyZXkgSGFhcw0KQ2M6IEJl bm9pdCBDbGFpc2U7IGkycnNAaWV0Zi5vcmc7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgU3VzYW4g SGFyZXM7IEFsaWEgQXRsYXMNClN1YmplY3Q6IFJlOiBbaTJyc10gSTJSUyBJbnRlcmltIE1lZXRp bmcgLSBKdW5lIDEsIDIwMTYgLSAxMDowMGFtIC0gMTE6MDBhbSAtIFRvcGljOiBFcGhlbWVyYWwg U3RhdGUgUmVxdWlyZW1lbnRzDQoNCkhpLA0KDQpJIGFtIG5vdCBjb252aW5jZWQgdGhlIElFVEYg Y2FuIGJlIGZvcmNlZCB0byBmdW5jdGlvbiBhcyBpZiBpdCB3ZXJlDQphIGRldi1ncm91cCBpbiBz b21lIGNvcnBvcmF0aW9uLiAgVGhpcyBpcyBhIHZvbHVudGVlciBvcmdhbml6YXRpb24gc28NCnVz dWFsbHkgc29sdXRpb24gcHJvcG9zYWxzIGNvbWUgZnJvbSBwZW9wbGUgd2hvIGhhdmUgY3JlYXRl ZCBhIHNvbHV0aW9uDQphbmQgdGhleSB3YW50IHRoZSBXRyB0byBzdGFuZGFyZGl6ZSBpdC4NCg0K DQpBbmR5DQoNCg0KT24gVHVlLCBNYXkgMzEsIDIwMTYgYXQgMTI6NTEgUE0sIEplZmZyZXkgSGFh cyA8amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj4gd3JvdGU6DQpBbmR5LA0K DQpPbiBUdWUsIE1heSAzMSwgMjAxNiBhdCAxMTo0MTo1OUFNIC0wNzAwLCBBbmR5IEJpZXJtYW4g d3JvdGU6DQo+IEF0IHNvbWUgcG9pbnQgdGhlIFdHIG5lZWRzIHRvIGFncmVlIG9uIG5vcm1hdGl2 ZSB0ZXh0IGluc3RlYWQgb2YgaXRlcmF0aW5nDQo+IG9uIHJlcXVpcmVtZW50cyBmb3JldmVyLg0K DQpJTU8sIGl0IHdvdWxkIGJlIGluIEkyUlMncyBiZXN0IGludGVyZXN0cyBpZiBuZXRjb25mL25l dG1vZCBwcm92aWRlZCBkcmFmdHMNCmluIGFwcHJvcHJpYXRlbHkgbm9ybWF0aXZlIGxhbmd1YWdl IGNvdmVyaW5nIEkyUlMgcmVxdWlyZW1lbnRzLiAgSG93ZXZlciwNCndlJ3ZlIGJlZW4gaW4gYSBw YXRob2xvZ2ljYWwgY3ljbGUgb2Y6DQoiV2UgZG9uJ3QgdW5kZXJzdGFuZCwgcGxlYXNlIGdpdmUg dXMgcmVxdWlyZW1lbnRzIg0KIldlIGRvbid0IHVuZGVyc3RhbmQgeW91ciByZXF1aXJlbWVudHMi DQoiWW91IHByb3ZpZGVkIGV4YW1wbGVzIHdpdGggeW91ciByZXF1aXJlbWVudHMgdGhhdCBhcHBl YXIgdG8gYmUgYXR0ZW1wdHMgdG8NCmNoYW5nZSBvdXIgcHJvdG9jb2wgLSBkb24ndCBkbyB0aGF0 LiINCg0KVGhlIG1vc3QgcmVjZW50IHJldmlzZWQtZGF0YXN0b3JlIGRyYWZ0IHdvdWxkIGJlIGEg Z29vZCBwbGFjZSB0byBkb2N1bWVudA0Kd2hlcmUgbmV0bW9kKC9uZXRjb25mKSBiZWxpZXZlcyBl cGhlbWVyYWwgZGF0YXN0b3JlcyAoaWYgdGhhdCdzIHRoZQ0KaW5zdGFudGlhdGlvbikgY291bGQg bGl2ZSwgYW5kIGFsc28gaG93IGVwaGVtZXJhbCBjb25maWd1cmF0aW9uIHN0YXRlIGNvdWxkDQpp bnRlcmFjdCB3aXRoIGNhbmRpZGF0ZSwgc3RhcnR1cCBhbmQgcnVubmluZyBjb25maWd1cmF0aW9u Lg0KDQp5YW5nLXB1c2ggY292ZXJzIG11Y2ggb2Ygb3VyIGRlc2lyZWQgcHViLXN1YiBiZWhhdmlv ci4gKFlheSEpDQoNCkRpc2N1c3Npb24gaXMgcmVxdWlyZWQgZm9yIGhvdyB0byB0YWcgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgaW1wYWN0aW5nDQp0cmFuc3BvcnQgaW50byB0aGUgeWFuZyBtb2Rl bCwgaW4gcGFydGljdWxhciBmb3Igbm90aWZpY2F0aW9uLg0KDQpQcm9wb3NhbHMgZm9yIHNlY29u ZGFyeSBpZGVudGl0eSBhbmQgcHJpb3JpdHkgYXJlIGFsc28gbmVlZGVkLg0KDQotLSBKZWZmDQoN Cg== --_000_4A95BA014132FF49AE685FAB4B9F17F657EACE6Ddfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMg MSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJ cGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMjA1MCIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JRVRGIGhhcyBiZWVuIHN1Y2Nlc3NmdWwgZm9yIHBhc3Qg MjAgeWVhcnMgJm5ic3A7aW4gZm9jdXNpbmcgb24g4oCcT3ZlciB0aGUgV2lyZeKAnSBkYXRhIHN0 cnVjdHVyZS4mbmJzcDsgSXQgd291bGQgYmUgc28gbXVjaCBjbGVhbmVyIGFuZCBzdHJhaWdodCBm b3J3YXJkIGlmIHRoZSBZQU5HIG1vZHVsZXMgZGV2ZWxvcGVkIGJ5DQogSTJSUyAmbmJzcDtmb2N1 c2luZyBvbiB0aGUg4oCcT3ZlciB0aGUgV2lyZeKAnSBkYXRhIHN0cnVjdHVyZSAoYW5kIHdpdGgg TkVUTU9EIHRvIGZvY3VzIG9uIG90aGVyIGFzcGVjdHMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUg4oCcSTJSUyBlcGhlbWVyYWwgU3RhdGXigJ0gaGFzIHRoZSBuZWVkZWQgZGVzY3Jp cHRpb24gZm9yIHRoZSBkZXNpcmVkIGJlaGF2aW9yICZuYnNwO29mIHRoZSBkYXRhIHJlY2VpdmVk IG92ZXIgSTJSUyBpbnRlcmZhY2UuIElmIHdlIGZvbGxvdyB0aGUgSUVURiBwcmFjdGljZSwgJm5i c3A7aXQgaXMgZ29vZCBlbm91Z2guDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkludGVybmFsIGltcGxlbWVudGF0 aW9uIGZyYW1ld29yayBpcyBhbHdheXMgY29udHJvdmVyc2lhbCwgaGFyZCB0byBjb252ZXJnZSwg dXN1YWxseSBlbmRpbmcgdXAgd2l0aCBhIGRvY3VtZW50IChpZiBjb21wbGV0ZWQpIHRoYXQgaXMg dG9vIGJpZyBhbmQgZGlmZmljdWx0IHRvIHJlYWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+UHJvdmlkaW5nIHNvbWUgc291cmNlIGNvZGUgdG8gc2hvdyB0aGUgaW50ZXJuYWwg aW1wbGVtZW50YXRpb24gd291bGQgYmUgbXVjaCBtb3JlIHVzZWZ1bCBhcyBhIHJlZmVyZW5jZSBp bXBsZW1lbnRhdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXIiPmRyYWZ0LXNjaG9lbnctbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wMA0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aXMgb24gdGhlIGFyY2hpdGVjdHVyYWwgZnJh bWV3b3JrIGZvciBkYXRhc3RvcmVzIGFzIHRoZXkgYXJlIHVzZWQgYnkgbmV0d29yayBtYW5hZ2Vt ZW50IHByb3RvY29scy4gSU1ITywgaG93IGRhdGEgc3RvcmVzIGFyZSB1c2VkIGFyZSBpbnRlcm5h bCB0byB0aGUgZW5kIHBvaW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5nb29nbGUu Y29tL3VybD9zYT1pJmFtcDtyY3Q9aiZhbXA7cT0mYW1wO2VzcmM9cyZhbXA7c291cmNlPWltYWdl cyZhbXA7Y2Q9JmFtcDtjYWQ9cmphJmFtcDt1YWN0PTgmYW1wO3ZlZD0wYWhVS0V3ajUwS1dhdDRY TkFoVUx4R01LSFJocURQUVFqUndJQncmYW1wO3VybD1odHRwJTNBJTJGJTJGd3d3LnVyYmFuYmxp c3NtZWRpYS5jb20lMkZlbnRyZXByZW5ldXItcnVsZXMtZG9uZS1pcy1iZXR0ZXItdGhhbi1wZXJm ZWN0JTJGJmFtcDtwc2lnPUFGUWpDTkdLRWlQQjJpSFNxeUJpRjU2MDlwZDcySDBMN3cmYW1wO3Vz dD0xNDY0ODIyNTAzODY1Nzc3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSI0MzAiIGhl aWdodD0iNTU4IiBpZD0iaXJjX21pIiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEMUJCNjcuODc3 ODlGQjAiIGFsdD0iaHR0cDovL3d3dy51cmJhbmJsaXNzbGlmZS5jb20vd3AtY29udGVudC91cGxv YWRzLzIwMTIvMTAvRG9uZS1pcy1CZXR0ZXItVGhhbi1QZXJmZWN0LmpwZyI+PC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW5k YSBEdW5iYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBNYXkgMzEsIDIwMTYgNDowOSBQTTxicj4NCjxiPlRvOjwvYj4gSmVmZnJleSBIYWFzPGJy Pg0KPGI+Q2M6PC9iPiBCZW5vaXQgQ2xhaXNlOyBpMnJzQGlldGYub3JnOyBKdWVyZ2VuIFNjaG9l bndhZWxkZXI7IFN1c2FuIEhhcmVzOyBBbGlhIEF0bGFzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbaTJyc10gSTJSUyBJbnRlcmltIE1lZXRpbmcgLSBKdW5lIDEsIDIwMTYgLSAxMDowMGFtIC0g MTE6MDBhbSAtIFRvcGljOiBFcGhlbWVyYWwgU3RhdGUgUmVxdWlyZW1lbnRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IGNvbnZpbmNlZCB0aGUgSUVURiBj YW4gYmUgZm9yY2VkIHRvIGZ1bmN0aW9uIGFzIGlmIGl0IHdlcmU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEgZGV2LWdyb3VwIGluIHNvbWUgY29y cG9yYXRpb24uJm5ic3A7IFRoaXMgaXMgYSB2b2x1bnRlZXIgb3JnYW5pemF0aW9uIHNvPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj51c3VhbGx5IHNv bHV0aW9uIHByb3Bvc2FscyBjb21lIGZyb20gcGVvcGxlIHdobyBoYXZlIGNyZWF0ZWQgYSBzb2x1 dGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YW5kIHRoZXkgd2FudCB0aGUgV0cgdG8gc3RhbmRhcmRpemUgaXQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXkgMzEs IDIwMTYgYXQgMTI6NTEgUE0sIEplZmZyZXkgSGFhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoYWFz QHBmcmMub3JnIiB0YXJnZXQ9Il9ibGFuayI+amhhYXNAcGZyYy5vcmc8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHksPGJyPg0KPGJyPg0KT24g VHVlLCBNYXkgMzEsIDIwMTYgYXQgMTE6NDE6NTlBTSAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3Rl Ojxicj4NCiZndDsgQXQgc29tZSBwb2ludCB0aGUgV0cgbmVlZHMgdG8gYWdyZWUgb24gbm9ybWF0 aXZlIHRleHQgaW5zdGVhZCBvZiBpdGVyYXRpbmc8YnI+DQomZ3Q7IG9uIHJlcXVpcmVtZW50cyBm b3JldmVyLjxicj4NCjxicj4NCklNTywgaXQgd291bGQgYmUgaW4gSTJSUydzIGJlc3QgaW50ZXJl c3RzIGlmIG5ldGNvbmYvbmV0bW9kIHByb3ZpZGVkIGRyYWZ0czxicj4NCmluIGFwcHJvcHJpYXRl bHkgbm9ybWF0aXZlIGxhbmd1YWdlIGNvdmVyaW5nIEkyUlMgcmVxdWlyZW1lbnRzLiZuYnNwOyBI b3dldmVyLDxicj4NCndlJ3ZlIGJlZW4gaW4gYSBwYXRob2xvZ2ljYWwgY3ljbGUgb2Y6PGJyPg0K JnF1b3Q7V2UgZG9uJ3QgdW5kZXJzdGFuZCwgcGxlYXNlIGdpdmUgdXMgcmVxdWlyZW1lbnRzJnF1 b3Q7PGJyPg0KJnF1b3Q7V2UgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIHJlcXVpcmVtZW50cyZxdW90 Ozxicj4NCiZxdW90O1lvdSBwcm92aWRlZCBleGFtcGxlcyB3aXRoIHlvdXIgcmVxdWlyZW1lbnRz IHRoYXQgYXBwZWFyIHRvIGJlIGF0dGVtcHRzIHRvPGJyPg0KY2hhbmdlIG91ciBwcm90b2NvbCAt IGRvbid0IGRvIHRoYXQuJnF1b3Q7PGJyPg0KPGJyPg0KVGhlIG1vc3QgcmVjZW50IHJldmlzZWQt ZGF0YXN0b3JlIGRyYWZ0IHdvdWxkIGJlIGEgZ29vZCBwbGFjZSB0byBkb2N1bWVudDxicj4NCndo ZXJlIG5ldG1vZCgvbmV0Y29uZikgYmVsaWV2ZXMgZXBoZW1lcmFsIGRhdGFzdG9yZXMgKGlmIHRo YXQncyB0aGU8YnI+DQppbnN0YW50aWF0aW9uKSBjb3VsZCBsaXZlLCBhbmQgYWxzbyBob3cgZXBo ZW1lcmFsIGNvbmZpZ3VyYXRpb24gc3RhdGUgY291bGQ8YnI+DQppbnRlcmFjdCB3aXRoIGNhbmRp ZGF0ZSwgc3RhcnR1cCBhbmQgcnVubmluZyBjb25maWd1cmF0aW9uLjxicj4NCjxicj4NCnlhbmct cHVzaCBjb3ZlcnMgbXVjaCBvZiBvdXIgZGVzaXJlZCBwdWItc3ViIGJlaGF2aW9yLiAoWWF5ISk8 YnI+DQo8YnI+DQpEaXNjdXNzaW9uIGlzIHJlcXVpcmVkIGZvciBob3cgdG8gdGFnIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIGltcGFjdGluZzxicj4NCnRyYW5zcG9ydCBpbnRvIHRoZSB5YW5nIG1v ZGVsLCBpbiBwYXJ0aWN1bGFyIGZvciBub3RpZmljYXRpb24uPGJyPg0KPGJyPg0KUHJvcG9zYWxz IGZvciBzZWNvbmRhcnkgaWRlbnRpdHkgYW5kIHByaW9yaXR5IGFyZSBhbHNvIG5lZWRlZC48YnI+ DQo8YnI+DQotLSBKZWZmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657EACE6Ddfweml501mbb_-- --_004_4A95BA014132FF49AE685FAB4B9F17F657EACE6Ddfweml501mbb_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=38477; creation-date="Tue, 31 May 2016 23:09:10 GMT"; modification-date="Tue, 31 May 2016 23:09:10 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAIuAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDzPgDA OaU8dRzTenfil96ADNKAaAOOcU7NACDvijGKd26jNGB9aAG+w4zSYOfSnkHGe1JtHWgBoXvzx1pc ZGacRjnrTSKAEwc8UYH40oGPenAUACgE0YwMCn/hTT/kUAN/ClA7nH1oAz9KdtGMUAIR64FJgdO3 sKUgn60cDpQA3/I9qXjHJOad0pOvagBuPfH1pvPWnE9u1JQAmMCjJJznrSkHGf1ppz/kUAHfPSkx Sj3FKF9eMetADe5o+ozSkAck0oHFACdDkfrSHPQCpMf/AFvrTcAA+vtQA3HH9aTHHsKdjGATik/H igBCB16ZpeBxQMevNKRk5/nQADP0/Cjv1/SkINKB70AJ/Km+lPOMdaY1ADTilPI4o4A6Uh5NAB+H /wBagdD70bcGlC4HSgBpoxxzSt79aaB3oAKUYNHf0o6UAOOO9IPekxmnAZ96ADHvRTtuKMUAIOlL n8qCMijn0oAOnNTQk4wTUFSwd6AI+lOUHOOTSDryM/Wl5yetADhgMMjIpRzzScU4AfhQAcUY4FHA pwGPpQAY7H9aQcAnvS9uehoPHNACFQD1B46g0mAccUtJ7jpQAY9/xpePUCkI/wDr0Zx3470AKCTQ fboKb35pwycYFADgB2H4UYI46UZwOKTNAATg4/KjPajHXjmk5/GgBT7UjHjFAPTikxnt+NABj1pD 9P1peOopPzFABg4+lJjvSgYHHb1oOD/9agBvU5p2cY65pOCeKOpPPSgAH3uaOc80in16UE5FADg2 CaTO5sZpOnBox7cfSgA7fWk4pwpMZHT8aAEx7UHrk08D/wCvSY5oAOnamnH4079aYSeuKAF9vSms MHApwzjmmetAAemBSqMc0g68/hQTQAvUn0pODyaTOTjpSEkkA8UAB5APrSDkUpP5UhycUAKPUUnp RgntS4OeaAAcmnDikxzS9aAF70tJinKOOaAExRingDvSEYFADB1qSPAyKZ0p0fU9KAGqBT8+/FID nFLj8PegBQOMA04DnOOtA5PXHrS9T7UAIOn0oP8AKl9fWkwSaAFAOfejHUGnFW5yaQDnjjmgBCAe 4AApCP8AIpepFIeTQAhHHAOKD9BmlJ9OlBAzkAc0AIACP/rdacOxHHpSdPalyNox19KAF6c03rQT R0PvQAvHbP1pueen50ZFHfPrQAYz2+tBOBRnHFA5OOOKAE7ZpcA04jHemFsd8E0AKcL0pMZ5zRn3 /Ck3Z5/KgBcYGSKbjOMnpS7iTR7elABjjFABXnjFB7UtADDzyTS84xnj0pcdxRigAAGBTgKAOad3 FACkAL0pmKkbpjpTfy4oAQjt2ph6/wAqkI45qMigBADg8Uw8808nIwKTGetAEZpDxT2FMA9aAFC+ 9IFyafjsKMcUAMC5+lLjJ6dKcFOKApxgUANAyc9akCY5xk/ShRgc0bj0FACke2M0nQ4pck0AE0AJ jkCne3alHWlxQA32FGKfjAoIwKAIiKRRz0pxHNJigBQM072707+HGB60qD5sYzQAgB+uaeMHrS/h zS7cDjoKAG7fbrS7No5HNPAPb8aRsdaAGsCTjNM788U8jIHNIR2zQA+0t2u7uC1VwjTyLGGboNxx n9a6yP4a6pLNJFHe2rtGSCQGxxnvj2rmdPkS11O1uJOEhnjkb6BgT/Kuzvtct9W8a6LFp10WskmV zgFQZC5JJB7gYxQBRj+GmpyxuyX1qSoDAEN8wJ9cfU/hWXrXhW50Kxhu5ru3nE8hQJFklTjPNdT4 uXyfC811DLLukvIlV9/JxvPBHv8A5FR2nia21B/DqGUT6iLnNzmLJ+4V78Me9AHn3G4DmkJwK9I8 YWmoaxo1nDBpzzzi5YrKqY2pt6E4GOcdf1rg9S0XVNKkRdQsprbf91nX5W+h6GgCkTmk4Puav6Zo WqaxuGm2E1zsOGKDhfqasX/hLX9Nt2nu9LmSJBlnGGCj1ODwPegDH747+lSRQzTkpDE8hHJCKSR+ VRZwc11Xw6d18QyhJCmbV8ndgADHXPagDmpree3IWeCSIsMgOpXI9RmkT5frXYfEA3Gp+JrG2gR7 iQ2qJEqqdzkknp+NYN74b1rTbZrm9sJIIVIBkbGBk9KAMw8jNNwSxrU03w9q+sxmTTtPmuI1O0uo +UH0yeKfqPhjXNJtzLe6bNFEv334YJ9cdPxoAyTwOlMwM9a1rXw7rN9bx3FppV1cQy5CPFGWBwcH ke9Q2Wj6jqMsyWdpJM8H+sVRynOOfxoAzyCPrTgAeRU17ZXWn3jWt5C0Ey4JRuoB6GruhaFe69qK 2tnbPMqFWn2EAohYAnmgCh5E5t/tPlOYC2wS7Tt3emfWm84wPxr07xRoM99oNrpeg2KSLZ3BLRQn pkYyScAnI5PrXnmo6deaVevZX0DQ3CY3RkgkZ6dKAKZ6dqOfatv/AIQvxK0Hn/2NcCPGckDp6461 k3FrPaXDQXUEkEyfejkUqw/A0AMHA6iheT06Upz0q5p2k6hqsnk6fZy3D99i5C/U9BQBSz3pQD35 FbN34N8RWELS3GkzrGmSzLhsfkTVfT9E1LVIXlsLOSeONtrMo4UnnBoAz2BIqNuuK0joupNqcmmL ZyG8iBLw/wASgDJ/Sor/AEi+0uSOO+tngeRdyhu46UAUAn4CnFcL1roIfBPiOeJZY9In2kZG7C5H ryazNQ0y+0qYQ39pJbuy7lDjG4eoPcUAUCo9O1NxW1Y+E/EGq263Nlpc0sDDKScBW+marap4f1bR lR9QsJYEclVdhlSR1GRxmgDNHH1pw56dK0dL8O6xrMbPp+ny3CqcF1HyqeOCTx3qTUPDGvaTAZ73 TJool+8+AwX646UAZgAowAKnsNPvNUuVtbC2luJm52Rrk49fateXwP4nhjaV9GnKqMnbhj+QNAGC 3TFM/GpkgllnWFIneVm2iNVJYn0x61tr4E8TvGJBo8+D0BKg/lmgDnwO9SBT6VJPaT2Vy0FzDJDM h+ZHXBB+lCjPbr3oAQDig1Jt9s00jnFADccYpCMn2qXHGBSbe1AEJHpxTG6+lTMPSo2GPegBQckj 1pwbH8s00e1PIA4oAcvJp+BnjmmAY4qVBwfX+VACZIPFNIyc4HWpMdqTGTQAzaSeaXHNOA55o464 70ANIGOa0/C67vE+mg5/4+E6fWs08k8ZzWr4WIHirTOSB9pTOPrQB1fjDDeF57aJEGy7ichSNxOH ycfT15rkvCDxR+LNNMygoZ8dcAHBwc+1dn44Eq+FJmwqwm7iCqqkdn5yev8AngVx/g2LzfGGmKCf 9dn5Rk8A0Adf4s1PVPDGj2X2S+/fS3Bd2Pz7AFGF/Hv+VWNdv1utGv7Ly/OgazM4DD7rFA4Yf3cH 04xxWb8RIHHh2yZbaWKNbxlJc5wSn9fy+tbOsWUseh6jH9iZY4LDEk7kjc3lADA7nnr+tAF3Q9Pv NK0GCw09UX/QTIzjhpJXjJz7YJUfgKq+GdE1210QQa0rfa4pisayMJWKsO/JyM5GD61Ho7zeKPDT XFq+66exe3k3S/6lwu0YGeAeDWR4c8IXsVjdXHiKO4ilSVVjeS+ePYmDuOQcY6UAcR4ksk0/xJqN pGuxIrh1Vf7ozwK1PAIeTXZVTqLWTncRjp6Vja1Naz61eSWO77KZmMO8kkrn1PNb3w6tzca5dZRp EFm+5BgFuRxzxQB3UWiJ/aMeqN/pExt0giZRhYefmLP0BIOMj9K4Hxprz6lqI0u3kY2lnIUGRgyy ZwWIH5D2HvXcXmtbfE9poFwCkNxbIbdbgk+VNkgZ5yQRxjPpXN+OtAmSUa1bxN5kZC3hC8bh0fgA Dngj2BoA7M6dqen6BcaLpMMa+VZmGMKdrmRgMvnsc5/Tmo/D2g6nHolvDrCM96C0TxufMLRls/Me Qfl45/wqvi48UeG7y+09t9xe2g3N5pDRS5HydeMlePr1rK8O+F2ttKa+8SpcQSxznc8l68ZWJQD0 Bwc88d6ALfhq0NlbwQIrStFdzRwrvwBtf+7nk/Wuf8EIZr7XVDlHMYIG7b/Gc5NdB4MlttT04HT0 ldLS/lkMJY52MQyswzz04PYiqnhjw1qOnatrsuo2EgtyuE2sNspL5BBz6c/yoA5jxvH5fiZgTv8A 9Gh+bH3vk61m6JNPBrNl9mlkid7iNT5TlSw3Dg47VrfEBt3ixiQ64tYeGPI+SsKxmEF/bTHICTIx wcHAIPWgDvfGs15YaNvtryaEvfEERSsuBt9Qc/gawfBSLfeJJNQ1CUTNZwNP++bPmOMKmSfcj8q7 rU/D8WpQWkPkrLYi8W4kcS482IggNn64zjHWqEsWm6Brtin2eLTpdRjeB1hfbsQ7SrN6fMMZ7jNA DfEviK/tNd8OxyzTBX3Ge3TKCRXcqMjvxVTx3pccmlG9kcfa7KRYwAclomJxu989PrV7X/CWo3+s 6FcxWm22hASUo4+QBy4OeeCOnWsnx/qFvbRSaVCSbmaUST4fcFUE7QT655NAHBgZOK9V8G3os/CF u1r9yR3S4bjKvk8n3xtxn0rywDAzXovg6xtX0BLzT/tSXbo8c7RTEgSA/JuToVPHGPWgDX0SK/sN LWC/ae+NtM0qXFu2+Roz0XaTkc+xHOKxfCEguYtUuVhEccmpbo4DJsCtgkA+uP6VueH28W3Nld/2 1YRwvGUMVwUVWznJPHGMc5NVdFmtNW1LXLfT3Mr/AGlJPlOPPG3a5wMBhkZ/HNAGJp0SzfFDUjIG iceeVGcEME9j/WtafT4pfE+lT3RjkisrB5zu6MwdgoJ74YinWfhzUV+It/qUtk4spI5ZA4K4cMmN vJ9eOadqmojTfFGjxyiW1t7qxe3YsxDR5kODn2IH4GgCHxN4q1HStQ0N5ndYSHe5RFx5se7GCv0z +dZuqajpPiq80jRLSSR0a63zSvHt2r3VcnPQdKveMfCmq6mNKksbESRwoyShG6AtkNnPQjNQa5Bo fgua0ubeyC6il0rIqzs+Ih94nJ4znj/61AGh4r1+9sPC5lsJPskf2qNLVoRgbV3HAPcYA/LFYniL xlpOq+H7m2t1la7vdo8tosCI5BLZz147dc1ueJ/D93rnhY/2RD9rzcrcRv5gZpV2kHnPUZGelZOo +G9E8P8AhcXeo2GzUDbAR/6QxYznH8PTAwc9qAOri0zULDw9c6TpKonlaeY4Sp2u8rAZbPYlievt zVfw9oWrQ6Fb2+tRlrtS0RjciQtEWyN3JyMZHNQRpc+KPDF1e6exee7s8HM3zRSgj5OvGSvH161m eH/Cctrpcl54kjuIZ0mPzSXzxlYgAT0ODznA70AS+DHj0Oy1cWcaPc2968cqk9Iwflz6DqM9M1e0 y3v4xex3c0l7by3JubeRH/eRDuuwke33cjisfwXbaTc/bL+0S7WdLpwxhuGVxbt93jPPf1zxWz4f bxhPe31tq9hFLbJG/l3LRKDuzhSMdRjsaAMXw5exXXxF1e8jtTDc+WxhikXD5BG447MVBP51trJq V14hOoGUSWs0HkT2Yk27Gzw65wDzzzg9RWM8elar47nglaSe9htlCSRS7C0ynkBlIydvH4VrLL4s TxNbw2Vm17pMroHNyisUB+/lz82cgnP0oA5H4g3CSalaWv2WeJ7aDaZJ02s+T29VHrXLL0967v4k SRpBbWkzD7WszukYx+6i9PUZPY/WuEUe/SgBzNgdqap56UjHnikAoAeDjmlJ7dzTR1+lIcCgBCaj bJNPb9KjPBoAkQDrT8c5pEHHXmpE6+1ADQOc1KuTgDrTPp19akU4H160AB5JHUUAYHpSkYGTSKCa AEPH40mcjmlb1HOKci55oAZiljlkgmWWF2jdDlWU4INO2k5PemFCDzigC1e6xqd/EY7vULidGYMU kckZ7HFU7e4ns7hJ7aRopYzlXU4IpzL8vXmkEY5Ynj+dAElzqWoXFqLa4vZ5oQ+8I7lhuxjPPtTn 1nVplKSaldyAjbtaZiMelQ7MkcUBT1/KgBIJ7mzk862nkgk/vxsVP6Ut5qepXyLFeahcXCjkLLKW A/A01/wxUB6knqaAGlegFWLe6uLFi9rPJC5BUmNiDg9qgBGcnrStk9f1oAmnu7m7dZLm4kmkQYDu xJA69afLfXkqv5t1PJ5gAfdITuA6A1BGpJx6UjjccYoAfb313YsZLO6lt3bq0TlSfypLvUdQ1DaL 29uLkJ90SyFsfnUZRtuffFCIO9AHfeALXR59PMj2jSahDKwkZbho5DGRwVCsCcEHjB61qeG/Dvim 31C/fU5pZIPIaKFpJy4GWGCADxwO/SvM1d4XWWJ3jdfuspwQfrVx9Y1iZGjm1a+dGGCrXDkH6jNA FvxhLFP4ovPIk82OHbCJAwYNtUAnI4POelYw9+1OMeD97gelGB2oAsw6vqdtGIoNQuYowMBUlIGP TFQXE81zK0txK80r/ekkYkn6k1GeuB0oHvQBdg1fU7e38mPUrqOLGAiysAPwzVTBZzzksc5PWkAO Rx9PenqD97vQAFfmx2FTWl5cWM3n2lxJBIOjRsVNRBW20eWaAL15r+r38RjutSuplf8AgaQ4P4VS hmlt5lkt5XidPuuhII/Gjb379BQEx9aALz61qr436ndsV6Zmaq1xeXd3tNzcSz7eE8xi2Ppmo9p6 c04rtA5I/pQBJDq+qWkQgt9RuoYx/AkzAD8KpPudi7szOxyWY5JqXb+fWmsAW4oAktNRvrFGFnez 2ynqsUpXP5VFdXNzeS+ddTyTyHjfIxY/rTH9MYxSbc5yenrQA+1u7qylMtpcy27ngtE5U/pU91qV /qAUXd7cXAX7olkLY/OqyJlgAalCcUAJDPNbyLLBK8UinhkJBH41dufEet3URjn1a7kjbOVMpGfr jrVJkPI9e9NMbfhQAxcj5hkEHIPetSPxLrohEI1i8EYGABKeB9azSvPXNSooUZxzQANvlcvIzOzH JZjkk/WkKkdOtO3DPA4FGQBkd6AI8EEdfrTiuKUEZFBbj0oAacdOlIMZ57Ubufam7sUAK2PwqJhk 08t2qNjigCccDFOVsHCimdSB3qQKFA45oAaCc4AqaMZ57VECMcHvU4PygCgBGBI/lTwAq/UYprMA oA60dSADQAKuW9u9S7cDAXrSKQPrTlZn69KAGldp5qMnqc/hT3PJyePWomPb09KANfwvZ6fqHiC3 tdTcC3k3ZG/Zk4O0ZHTJxWt480jT9KFs8EcNrcuxBtoZC22MAYZgeh/nWb4HaM+KIRNDDNG0UuVn Xcp+Qnp+FbninSbO71fSLaKzjsmupnjkKjaWHGCfTjp1oA4UNxywWlJGOD+NetXt1p2hWtpFpWjw SQRTrHeZh3sqEffz1P19qw/Hljpf9jver9lSfzlW3eDaPNXuCF6juDQB54wyaibBPWpAflxnmvR/ BnlPolik1lbTxmSVZd8ILFc5Iyepwe2OlAHmgC5607GOcdK9R8OanousWF6raFZwQWcgDLIoYSI2 QMED5WBHWsmHwtpr+MlCJL/ZcUC3bxtyQCcBM9wT+lAHEptAx/EafHbvNNHChAeRggz0yTivVr3V NMg1jT9Ej0myjgvYAzNJAAYyScDA9ccj3rKu4j4c1q31jTbC2FreSC3khkQssLFuqjPGR0/GgDL8 UeG7LQPC9qqAy3TXJ864dME/L0U/3a45VGc5yO9ep69rt3o1hLd/ZILl5LvZ/pSl14B7Z6/4151q +qy6vqMl9LHDC0mP3cK7VXHoKAKgU7vX6igHPcelW9LkMWp2cgPKToRnkfeFej61qVnpdjPqF/pM F28VyEgUgKQTnd+g/XrQB5USD0ORTN2O2PrXqOt6TpGu6VG0UEVtdy25ubV1UK2NpbY4HDZx26VX 8BaPptjpsGoanaC4nvh5iKyBxHEDwcHuSCc/SgDzQEHuPwqXbgbtuQOp7V6boOoDxbY3ZudKs9lv MVZEgGChB2++7tkVD4Zs4tG1HXbCa3jmtoWidTNtztO4gk9+D+dAHnW4A9hXaeCvDtpf2zX93brc /vfLSN1JRQBkkgdTyOK626WyuZ5TptvaROspjl/dpndwQx3diMnB9KSDU/7VmxawxC3hvmjUQDar 7QvzcHBPX8KAMPxboOif2CNY0+0htF8tDC0L/LKS2GUr2YZ/SuALBTzgVqa7q15r1/GkkcMZhJij jhXapy3HHrXffZtP8J+GLz7Pp0VxfWka+ZPcRAgykgEeuBn9KAPK0w3Qj8KHwASTgV6munQeLPD8 FzJYwwG4ixG8MQUpICRwf7uRyD6/SqHgXRLGKGK+1C1FzJdzeXAjKGUIrAFsH37+1AHnKsM/eBre 8JaCmvai3nystvblTIFXLOSeAPT3PpXd6fq2n+IBd2j6bYxSW1w0LI0aYkjyQG55HTH1NU9N1JQu o6RYRwi0spQkciDDSISeGYHDAdM0AcR4oit7bxLqEUEaQosuEjQYAGB2rpvBnh3SNR0BrmSCG5vP MdZvOlZVhQdDx0yMnPrUXiHxfdQX1/pS6bYiPb5XmvETKowP4ievvWj4Lt7O58MxLPpdtdH7Q6ln jy23I6n0oA891S2toNUuorOXzbeOVlicHIZc8c96pggvgEcV33hnRLA6rqOo3tqJba1naGCALuVn JPY9QB/MVuPqelah4gv9IbSdPEFrGJIN0PzSnA3Lx9ePpQB5SPlxk4+tSAgDJP4131hoqaL4gu/K gje1urTzrdZU3lMSKCvtjJ/DHWr7alpUXiu20x9DtvtF3Agkn2qArsvynGPu9M/XpQB5jigpgf55 rt/GmmaU9m2oWMC29xFIscqxDEb5zzj+E8fjXGhR+H8qAK4TGSKceBwMVI7BTwOTTGPG3vQAwjP3 e9DEgdaeBtUgjntTWHIGM0AMGfWlJzRt5xSkAcUAM5pOtLnFJ04oAa2cVE3BqU896iNAEqv+JNO3 HP6VEGOOlOViO1AEoPQVMvUd6rjPpU8ec+woAcRwM/nSgjpTW+7nvQpx9TQBIG/SnqwVTjqarljS o3HWgBztxio2B9ad/EQeaaWwpGaANzwWHbxPAsezPlS5L8ADy2ya3vEVoLrUtCt7O9SJ5LmRVuWU ja/ynJzyef8ACuT0TVm0XURepbRXHyNGY5c4IYYPSreteKrvWhZiSCK3ayYtC0OQVyQcfgRQB3Go 69H4fW2utTtluGuGKNNZOyYZcZJVuhOc4zjvSeKrTTtY0B7pYOVtRcxXTgI44+7j+LPQg+oxXOW3 xAuRDs1DS7G9c4/eOgGce2Mf/rNUfEPjHUvEMS28qw29sMEQQLtUkdCT7elAHOKvGR1r1LwMpPhy wZpURPMm/dk4MmD7c4/SvLGJxgZrq9F8c3WiWFlZpYW0yWrFsyjkknPHp6UAWfA8UU41rzXWONVj Jbngb27f5xW9bTwtr01lD8zXGnwvDyy7grHd7k4JPJ5xzXD6R4ln0aS7eGytZRdOHZJFOEwTjHPQ ZpNW8V6jqeswax+7truFFRGhHAx7H60AdTrMUsvj7QVg2ktDFtJG1cKTnp06GpfFd95MljFNLG0l xepIE5wkaN3Hbk/z+tZS/E/VzGpexsHnQcT+WQwOAOg6dOg4rl77Ur3U71727mMs74JYjGMdMAdM UAei+J9NuNUs7XT5LhVnm1JYyxU7YgQeR7dewzXH+I/DUWi20F3a3r3MEjmM+ZHtYNjOR2K1etvi TrFvbRxSW1tO0aBRIwIZiOjHHf3rH1zxFf8AiK5je72RxxDEUMQwiep9yfU0AQaQrPrFkqpvLXEY C9Nx3Diu7+IMYj0B90yyst6OVOdgw3Hp7cAVxWhsE17TwUEn+kxjbjr8wr0fxdrL6VpklxDaWk4k uwkkU8QZX4PXNAFXTIEttBsLxmHmWumhnUgjaArZJPTPPv8AhV3w1qX2nw/pT24iEcVn5TDDMxlR cYPIxyFx9a4rWfGmpazaNa+VBaQSriVIE/1g7Ak9h2AqroPifUvDm4Wbo0LnLQSLlScYyD1B9xQB 1GgeI/EPiI3SrLp9oloFeQfZHIkJJABw3tV2KKWfW9eju7iN5z9m3S26FU+63y7fx5/CsGb4iam0 cgtbKys5JcbpYo+T74PGeetUdF8XXeiLemK3iupbqRZHecbuRnJ+pzQAzxiiw+LL9Iy2N4yCec7R nNdd4Di/4p+1YyCJTeScbsGT7vTHP9K4bWtWl13UpNQmt4YJJFAZYRgEgYzWno3i+70bTobOKytZ EhlMgZ1O4k/196AMhJo7bXlnkX93FdbmX2DV6frmtXmn6RqF9bLBIxKOilGZPLYjnk+mPoa8nceZ K74wWYn866TR/G2raTZCyKwXVqBtVJ0yQPTPcexoA6vQdV8Q6tZW+o/bNOt0eRo0ia1fCY6kHOKj 8KTJcaVpzq6EQSNHJnJ2vvzwucDgjB61zOqeN9VvrI2USQWFsylWjtlxuB7c9B9Kz9B8Rah4fmZr KRQjnMkcihlbHT6fUUAS6V4bk1i+vYvtItmtySxkQsT82McV0nh/S30i81bTob2OVoRC7yIhyAfQ e2cHkVnXPxF1SZH+zWlnZyv96aKPLn8+p+tYmma3faTqf9owSbpXJ8wSDKy56hvXnmgDo77w1FrH iDVbue7a3jWdI1WOPc7koDnB6itLQdOGn2As7ydAIb9kBAJEmCOo/EcH8jWFL8RtV8jYlnaLJt2i TaSQf72CcZFQaX441HTLSKP7JbzzRTPKLiXJclzls/WgDe8PSRyW2pWoCh7bUZJJAckBGwAduQDy vfpVSyEo+JmqtGAdqSsS6nG07cHHvkYrmbTW7+w1mbVLJkglmcsybQykE52kHqM1tXHxG1eRWaG0 sra4ZdpnSPLY/H6/hQB0cU7vr0tobiMyx6e0kk7HIUtKhA59h0/LFYWuKH+JOlxKVJ22437j8xx1 JJz+tYWj+I7rRrq9uVjS5lvE2uZecncGJP5GpbzxRPe63Y6uLK2ins0VFVVO1tueSPxoA6LxFZpP pE1lYkTXEt5EmApGCWOBnp1Pt64rn9Y8J3ui2TXElzbTtGwWeOFiWjJJA6jkcdanvPG2oXtilnHb W1pHDOlxEYVIKspz/Wo9d8Y3+tWItHgt4Ii2+URrzIw7knp9KAOcGckk9KafXjNPBxwPzpnIoAB1 9cUuOOOaPugetNDEEEcnpQApHHOKaQMdaUtxxx+NNJ445JoAYelJz704/e9aGxtoAYePrTDwKe20 gAZzTG5NACZyc09fT0qNc09WJ4FAEoOOe1ShgDnBAPQVXBJPNLvyRzmgC1kkFjzSKcn1pN2Iz7Uw OMdPqc0APPzHNOQDPpUYbApyMOmaAJNuTxx2qNxzjtUm4VE33s9z6UAIpxjPamsxHPqeeOK67wLZ Wl218LuziuQixlRJHuxyc49Kg8TaM0/iuOw0zT0iaS3iYQxAhQSuSTnp9TQBzKDLe1ObPbkn2ra8 Q6F/wj95FZmbznaBJJDjADHOQPasdV/OgBoX04xSMeM5zV/SdLm1jVbfToHVHnbaHbJC9yeK0/EP hI6JbLcxXRuIRIIZC0Rjw+CeM9RxQBzPU0wBs8mp2GB6ZqLGTxQA4HJAH40/GDxjNNHyAnHJpFz1 oAaxyeOgpQcD3+tIfx9uaAMjH8qALWm3rafqttfhFkNvKsuwnAbBzW9rfji48Q2T2tzptrEnmiSN otwKH8+fxrmiFwcjk9z2pyKWOSCQP1oAXJJwetTRpuBYin2tus93DBI3liSRULgZ25OM4711Wv8A hCLQ9Ie8j1H7QY5ljMZi25znn9KAOSbAbaPxpcBQffrTcgtk8+ldHoHhNtY02XUri6MFrGxRVjiM juwA6Y+tAHPL82DzzT3YAYXOR1qxqenyaVqU9jM6s9u+0sowG79O1VSNxzkUAOUe/vUcjnsetPC7 V6/gKb5ZPUcmgBqnceeamA+UADmmIuCOMelSEbRk5zQAnHHenAEk9T9aanK9OaeZf3SoFA5znHJ/ GgCu5ycDHFSAbgDxgU0jH1p65HbnHFABghulNYbRjGKkUhmJJOKgmkJJOeKAGs3YHA+lOAwOv4el NQ8jdjGeRnrS5zkL60AKTtO3OPpQVJGMjnk8UwYL+op6kr159KAHFMLmkYevHrgUgYE5IyP50u4E 9/pQBE4Ocen6U3AwCetKx+b/ADzSA5yfWgBG5GBSAYpx4ppOc4P40AIeCcd6Y5z0pd2e+aaTn6Cg Bh9KbketK2SfrTD14PNADt35mnLUY57mnK3OT2oAkYgADufemrwc0nXLHmlAoAs9QaiJxx+tPUjH HWo9vzYoAUmnKT0zRt/SlCdzxQA8DIyaMHGeD6U5OlPUbuaAOo8Bs6NqIVd3yRkHBIBBOM4+v0rq o5NJ/wCEjkmkW6k1b+zlPzriJk2DqAcg+1c/4BVW/tNDwdkbZyezH8O9X5CB8QJd0Zk/4lajYoyC Sg/Ie9AB4hfwtNdwPrZvTdNbgg2igIRk479a8/fAkITIUn5QewrtPFekXuqa/bw2dszOtijsGIAj G5gCzZx6c561yN5Y3FhdyW15EYZkxuU/ofcUAXfCkCT+KrCN5poB5nEkBG4HBwRmuk8dw3l2umxr qct2ks3lR25hWNUbgA4Xuc8/0rnfCuE8TWB+b/WcFQSeh9K6TxYL23TS5Utz9oW73RRKuAxAGB6k 57980AOm8FeHNG0+1l1u+uJZbiVYcwsFRGPt6e5rO8TeCrPTLO5u9Oe4UWzYkiuCCSM4yCPT0rpr mTTrw79YP2OK6Pz2+oRsmXB4Ct0JHPIPHcUzxhpklxoTR22pOFWMTrAZBIs6rnnf14A7+lAHlTDA Hc12Pg/wno+t6ULrUbieNzcGICNwMgY6DGT1rjyeCwH0r0T4fW3n6Lbor7XN6xY47AKf5/SgCta+ E/CN89zBa6hczy2shWVlbaVUZBODwQD3/wAajHhHwrpTQRarrM08t0x8oovloFzjk84Pv0ql4HZz rmoqkRaVoTiPkgnzAcHFS+M45V1bTBM+X8nJwoQL+9boOwoAl17wLb2liLzSppHdXWOS3mIJO47Q VP16g1cuvBOh+H9Njutc1G53SOsW2BQVViOffArpPEFtLNp90trva8laLyyWwVbcMN+Hqay9TSxs 9LS58RalfassMnyrKPkaXHRV4yMdcn8OaAMfUvCNrpywXmnXzzmGWNpYnAJCkrypHXqM+xrX8deb f2H2WCNWka/VEjH3icMMk59fwrS1GSKTTL+4Fu0cc8URDY4+YpgDpjGQPp3q86xRyv5gW3lNyRBJ syxfDfcJ4BIyOnWgDjbjwn4f07TJbm9ubpmgjUuUdQJHP8Kj0J/kc1b8BL5eh3E8Woz2rfaSuPKR 0HyjDDPQ8/8A1qpePUuntbN42YWcRKyxZJKSnoz+5HbtzVjwUsraBMsCbm+1NnKbguUXnHTNAEVp 4f06/ur+XVbi9nmjvmhMwYKXGM7j71YtPBvhue6urRdTuLi4tX2usQG5RnGcYwQO9X9DTOo6owia ZhqZGSOV+XqQP6Vh6AJR421qC3JOY51BC/MfnH5daAKOp+Frqy1q3062mjuxdk+RKpwGwcHcO2O9 b7fD7S7byo73W2jlnfZEqBfnIHIAP+eRV6GDy9dsIbgM87Wtx5Zxzuz29TjP1rN8VwyNd6IkKyAG UqoJJAcyDkH8R+FAFHXPD2jaPoEdwkl3JdvJsDkAISOSCO3FcjIS7Drj616V4xhSLw5diQIM3ChC Scu2c5A6YxXnKoScCgDs9C8N6PqmlWDzJNFPcb1aQSfLkMRnH9Kmi8HaDfWjfYNUlklQlGmAyqMB /EOwOOCOtaPhOL/inbFlQn5J8yBc7TluD/SsPwUk81jqUMW48xscDk4z/ntQBlaf4Wu7rxC+kTFY vJJaaTsEH8Q+vGPrXR3Xhjwraalb6UZ72a5nh81GEgVW68Z6DpWtZm1XUdXaUvJN5NvHIFXLNwef YZA/rVXVL/QNP8TWrz2F7NqcUUZhSIDacj5VI3e9AHLal4RuItYtLKwkMsV622NpCAyEctux2xz7 itO/8FeHNJltLW/1K8a5vWYQsoVUGDjk9uT1Na+qS6hqaWMVlZ32mXa3Bc3M0QQRqEO7HJzwf0qO +l0rTLvTrvVZ7zVbvdttjcYPGRlgOABkjk5NAHI+JPCkOlCObTrtruBpBE4ZfmRz0HHUH1roY/A2 gaVpKXGvX8om3IkqxONsbN0Hrx6+1b93HCjWyTQeUrarFtLDgkbiDn09sdawPGKMfDXmbSDJeqGZ l2g/Kx4BOevrQBR8R+C7LT7G4u9OnmX7L8zpMysrpkYKkc55GRUuieCdPl0JtV1y6ljzE06wwsAR GBnJ75OCeKoSS+LNS0dYp4rmTTtgd3EQwyDHJPfFd5qh0xLbUnlhmkto7YrI0a4yhAAC5Ydscjg0 AcgfCWi6rpa3ehzXUbSKxiM7qVLA42sP4eeM1xMgKOytwykg89/SvUNA1jTUso7TRdF1WWyjkJMn lB2EhI4zu4HevOtaG7WL5hE0QM7ny2ADLz0IoAzevHH407oMY+lNYAcYINLgHk/jQAYBBPp3pGXA we9OIGev1pp5+c9M0AMOBxjFMJwvTApxPXAyKY3XBFACAgimketLyBSHPY8+9ACfSk780mcN607e eV7GgBwxjB6U7HFMJwcU4ucbQeD1oAnDHaDUYOHpUOQD36YpMYbnoKAJhzRuBIGeKZv+U0Jy2euD QBPng1IGAY7CSo6EjrUGe3SnKflzzQB0vhfVrDTTfJfSyRecieWyR7+VJPPp1qzN4ls7TxbbapZO 9zbrapBMHUoWG3a3H0rk+i00PwaAPS/+Eu8KhzIrXikxiFvkO4oDuXvjOSR9DXE67qi6zqj3UcAg h2rHHH12KOn49fzrL7cnrSqRnAoA2fDd9a6br9teXUrxRRbiHRdxU4IHH1rV1/X9Ols7H+yJZvtV nc+aWlUgN6EDt9K5bjPtTCRk56CgDuLzXvC3iOyMerz3dmyyeaqD5iHPBwwHTGOMfrVbWvGGjwaE mj+HIrlgsH2fz5+MJzuwO+c/hXFSYIOD1/SmKuSB+tADieM/oK7Lwd4n0nR9OS1vbi6ika68x9i7 k28AZFcawG4EZA7UzyyRzjAPHvQB03hXWNM0691WS+uZIkuE2xtHFu3AvkjHbgCneKda0nUbywk0 xZfIt4dsgl5YtvLE89c5rmViIGacw455xQB6DeeNtFSGWWwkuZbwsHQSx7U6gkAdB9aiv9e8K6vp yw302oKA4k2pGNwOMbc9MY71wO05J/pUgXp6UAei3XjXQJ7OWFTdlTHGiRSLwoUr0PqAv44qj4u8 Wadqti6aZdXBnF4sy+YuNoGcFT9TmuK8vDcdqVI8jJ4zQB3MvjHRL/T4oL+C4Xz02XaRINue7Ln1 OD2PFQ+H9c0PT9G+zXU11lLtpSiR/wCsU4A5HQ4BrkRECw9PSpQo288CgDubHxTo1nLfM09youdQ M6eXHn5MDGR+dZNhq+lWPi3Vbvz5/slyJEikWPcSGYE5H0Fc0VPJ9aUYzjP1oA6rVNW0a/1PRvsF zdW0VvJ++mfIdSWHzAmvQ0uZLqFV8lX2OTHKq+aM44IxjnGD1ryrwzqcWj6wtxOGMDxtFIyLlgD3 HuDiup1CDSNXmt72HxEtkVQRtg4yB/EADxxxigCr400nVHtf7Qub0XCQHaIvKEXlhj1Azzz1rjQC FGenau28XeILCaCS10+4N284VZp3THygDoT1JwK4xFDNnsKAPTvDSxjwxphMkhVYpSUUgBvmOQf8 etYWn6x4V0exlFp9ud5mEjROoBJA4Xd0wMnmrek+ItDsdFsIJ7mZZkgdHCQ5VSSeSc+9cHLsRmCP vA4DEY3D1oA1YPFM8HiSfV3g3R3O5ZIFbHyHooOO3GOO1bs+t+C72/tdTmW9juLYLtQoWDBegb1/ OuHJDZOOKbxjGOlAHW33jwS6tHPbWsiWa7/MRmBdywILegOD/wDXqxdax4TvJbW5uZL+aS1YsgWM LuJIPzZ47VxABZufu0rkE9cZ60Adn4m8UafqOkvFZy3D3JuUkRplxtxnkevOKnfxR4c1zS3t9bt7 uCUsru0R3bmAxkenU9u9cJuy2ckYHFHGM5xQB1mr+K9P/sv+ydEgmRPKELXEpwWTuMe/HP6VY0fx bpLaR/Z2uwTttg8jzYzu3J6EdQRxjr0ri+g96TewPykD2oA7hPFHhzQNNa30WC6uXeTzVab5drY4 J9cegFcNcSSTyyTzEvJIxdj6k0jZLZ/KmsSGLA44oAix19vXvQCAB0pGJ4zSe/b0oAa44OD/APXp DyMA9BzzQSPy6VGTzmgAOAeuQOlMbrkjjvS5IOSM+1IeBQAh6/WmH8qUcknikYZ6cUANGSC2QMUA 9aQkgdKAPwoAdkY65pc03g0vQfyoAmRsIBQ5IIHX1oQdSaVl70AITk1IpAwB61GvX2FPXk8mgCYD PfrQPmOTkUucKPXrQDkcdKAB+cAU4Jt9frSgcZp/HAPbv60ARleM9jTo128963dM8J32rWS3sE1q kTSFMSSbSuOufbkVVt9Gup9Z/shFUXJmMPzHA3A4P4cUAZvOOKaQSPQVuaz4av8ARLQT3Elu8fm+ UfJk3YbBI/kfypdP8J32q6bFeQz2sSzSFIlllw74OCQPTNAFDTvD2q6tC9xY2UksMeQ0uMLkdge5 9qrRWc0l2tkkLtOz7PLx827OMfnXpHhe2u7fw8LR9Pg1KO2uJVi8m5RN7Bhwd3OM9x680vh+wayk vdevJLZri8lDqluQ7x5LFkOfu9sn2oA81vLSWzvZrS4ASWBijgEEAj3HWrMeh6pPbi5j026eDbuE ixEqR659K6LxN4Ru1utS1dtQsfK3mby2lAlOe20d/aui8JPey6LpTxszFInVVZxh8FsLg/5+lAHm BHGOMdzSY6Hjjp9a6qXwDrzwGVFt3lIL+QsnzEZ7dj7YrlZFkhlMciMkiHaVYYIPuKAE25575q4d PuotOj1B49ttLIYo3/vEDnA/rVvwzor65qyQCe3jSIq8gnfG9dwyB6n2rvPEejtr2nwWtpdQQpaT nBnKxJgjgL9MdKAPOLawur2byrW2luHA3MsaliB6067sbqxlEV5bS274yElQqcV03hyxuNK8VXWn CdJ5BayK7QSfK3yhhz+VafiPw7q2uGw8ow+TBasTO7j++eDjPQY/OgDgQ43YAGBUv3lyelWtX8Pa loDol9CAsn3JUIZH+h/pWppfg3VdV04X6tBBa4yXnfbx649PegDnzk8nHtmlQbupBzW1q/hTUdNg a4eS2mhjAMhgkyVz046ke44rDBwfSgCbjgelPDA4q9o2hTazFPJFcwQmEqGWXPOc8jA9q1D4A1pZ Gz5CgNtRmfAfPQj6+/pQBgRRTXMqwwRPJI/CogyT+FSXOnXlhs+1Wc1up6GVCu41paTa32k+LLO2 uYXiuFmA25xkHjIPcV1Gs6Lqms6VDaQBHIu2Ls7AlAF4HHPXP/1qAPPGPB4zmoXYDHBP41tax4Z1 PRoFup0SS2c4E0T7kB9/T8auf8K91maJbi3kt5kaJZBtbHUA/TjPX2oA5YnaMDn2oAxxnitu88Ja hZ27TedbzmJd0kcT5ZRnGcdxmrcPgHXZIvNlW3gz91ZJRuJxk8CgDmcjk8+wpjg/mPzrW1bw5qWi RxtexhVlzsdGDL9M+taFl4E1e9slvJGgtI5BmP7RJtLe+O340AczjC4zz0xSg8dOlbur+ENR0aIz S+TNFGcO8L7thPqOopmieFtT8Qh2sUjEcRw0krbRn29aAMTr3APvS9AM9a6O68DalbQmVLiyuAAT silySB1x6nPGOtc0+B1yGoACRgqKjZsdufTtTsg8k89qYwzzigCInAOD35NNzn8P5UOcEAUoIAGM 0AMYZByKQJxmnsRnioTJ83H4UABPPPbrTWGaM5bHNIzZ6UAJj0zSEU7nGc9u9MPI64oAO2e9IeeS frS43HP5UHigBPTJ/Kng5PTIFM5B4NOCk9Mce9AEkfU5I5p8jZHAqND8xzTj8319KAEBH/6qkTlq jH0xUicHjmgCTJPJ6VKv3Qc/hUWPmA7DrUrcdKAHq21SfyPpSodzZz171H2AFPUbRQB13gi+Yz3O lKcvMvmwKCBl164z3K5/Kugj0Qw+JpNZlaJYWt8kqSwWU/Lj1ztya87sbiawu4byBtssDBlNelGe y+ziVpIFtCn2jY0gckbc/d7tjg54/GgBmu6TLf6dd2FtDLI0sSyQBn3bmGGXp8oJHHAB+tRXc8Hh /wANzBIpN9pCIIndgB5h4yo65zuJrP8ADWuzaul21y6rPBKZocyBPLRzyFzxwf0JrN8bXcDfZbOB 4nIzNK0XIyeFGerYGevTNAGr4OcR+GrXcHLNczbSvGTuTO4noO5qHwyi+ZrZd1hH28c575fjNaXg y1aPwzp8ge3jjmnkLzSkEL8wwMHoeKyvC1xax+INY0+d4oLl7lpLd5SAvysxZcnjkY+tAHMeJY1j 8VapgAf6Q31xXofhcRzeHNNuG/dzW9u4RFUgOQWIPv8A4+lW2sbfTze381xaxRXNwbqW4ZRnyiAA hzkHnIx70zQ0tJdOsBYiCOKUSPF5kgygZnwMdhz25GKAOd8J6tez6VfiWSSeaO4TYzndt37twHpk gVz3jF5H8RySykb5IY2c5BOdo647+tdB4CtJhpWqOhg3i5SNjI67UAVssfUcisXx1H5fiiZC6yER RgyJwG+UcigDK0cF9asen/HzGRn13Cuz8aRRf2NCUcSYvG3ZxwSOmPX8BXD2UgtryC4ddyxSqxB7 4INetmytNXSyltZ7aW0guBdiMjdlCMbSOvHHBoA4zwMQdauIXA2S2jqzbc7Rwc/pWn4lvJdN8TaF b2k832UKpIDY8wtIQ2eeQRgc9q31e0Ot/Z2kglvYbeVnYMAIgcYQkdR145Irn/E1oJvEvhxgYVSU qo2upC4lJ7duaALuspNqltLYSAJbyXkSIOmPnx8o9cHtW1rtg1zo2pact9BbLtjjjEjhUjUMODz3 AxWR4s+02mi3dwrwJLFPE8ccZBdNrEhjj6iniC08YeHLmDT7u1hluRG7QMeY5AdzAjH3TzzzzQBe 02OwtdOtdNn1S0nmgi8uVknXYV5GBzzwenPSvLGRUlZQRwxAIPBFegW2n6X4Q0SJdWWwmvkLv5fl q7yZ4Cg9ce5wOa4HgsWwMbjwOlAHVeCow1vqJZxGN0PJHf58CtAXtynxHntWMjQeWYhEWyCoTK5H rnn60zwFC0ljqbLGkhDRjY5x2bn/APXxWlDoEsvjW51VLi2kjXO6ISDesm0DBHp3z0oArXO+41bQ 7uZB5n2louc8qVzkew59ah8XyPpej2radcyrvuS0sisVzhRtHXtzUk93aXni3SbWCeKXyJGaZ0IC lvToOgHv1NQ+NovN0O2K+TtF4QRHICASgGfXtQBp6nczzWd6ip5UD2RLL0BJQNz7554psmoT6doo +z5U22mxORuJAwqHaD/X3q5qUEn9mXuHt1RLJgoypaQhAMj24qPULXPhS5RLiEk6aiopmXcw2r+O OvegDAXxsrzrJaaU7TyyqxV5c7jnOAAOcmtjVLa+1sWM+rtDpUVnKZXEdxvfJx1JwAePUmuI8NXV vYa/a3Ny2IkJBPHy5UgH8CQa7DXdCudXsLMrcWtvBFKZHaSYbSpAIO7v0IFAE/iNYE0fUZ5pDOI7 iJyCcjO/37kfoasapbyeIbEwJK7WcxWWGaEBtrA5B6+/IPpUHiqaCPQbp/3DqksJCI4YygP0Ppxm q93YHWdN3+GJ7a1fzfMWWCTy8L3RsAEdjjFAEniZtQh0K6MVrHcyPCFnmjY/KvdthGff2zV/RrJ7 HRrG0juVgzZmQqSBl2UkueegJH5VT1W8k0XQLf8AtvUY7q/SBh5SSZMpJOMgdcDqTx+NUvCGo2uq 6WlrNdxRXsdu1s6yEBpUxtRhnqQCBjPagCbw3Y22h6U1pd61YzSTTeZCIp1AQkfMTk8Hp3rh/FyW 8fim/S1kR4Wl3BlIIyQCenuTXXaN4StfDVpdS+IJ9OKSFVhaRQ4wOSQCM5OcYA7VxGs3UN/q11d2 tusEEj/u0VQAABjoPXGfxoAo4G7GeKRnA6YIFLjjjJPfFROAcL7daAIXOWOD3ppfjqKlMZBwBz3z UeB0FADGbI7Co8EknsKsNgLj1pm09AOtAEXzU05z/SpyAB61G3H1oAQKTzj601lJ6rTvYUbtnpn3 oAaPmHbFB5bOaRfx5p23saAG4zg9T2p6gg5FOSIjBbv055pxxxz09KAEQfxE9afg4LDI+lMzlQKm IGAuePWgCHhRxyakXjmmEHeenFSRDnJ/GgCROGHepSMkjFOs7O5u5fLtLeWeT+7EpY/pVuTRdVhj Ek2m3aqf4vKbFAFNUIqVFzzTCQeMfiKlBAWgAkYKoA69qgYA4FTQ21xeT+TbwyTOf4Y0LH9KmuNI 1K1jWWfT7qNG6M0RwaAKR5HPWhRkgYp5QgUgX5T+tAELksxxkAdBSgEfMec9aeACeAeeAAOtXBoO sPF5q6XdmPbuyIW6euKAM1gCfx/OnMSgBBYMv3SDgintE8LESRshHZlIP60gVnYAAkk4AAoAjjHO TzUgHQ9j0q4mias0vlDSr3eTjH2d/wDCj+ytSBI/s283L1H2d/l/SgCsRnj06UgXPGBmnmJ0O1lZ G9GBBoAJ696AJl+Xgccc018kgZPHQegpyr0JJK1NDBJPMIYI3llfoqAkn8KAKjJ0AFJIMYUdq0Dp epbj/wAS28GP+nd/8KaNJ1FzvXT7s+mLd/8ACgCoiNwKsx8dunSpJNN1G3iaSawuY0TlneFlAH1I qX+zdQEUcgsbkpKMxsImO78h7UAdd4GSWTTNRCyKsfmx7g7BQDhuck/SsTxjbyQeK755Ewsjh0w2 QykDBrHmhuLceVcQyw78EpIhXOOhwfqalgtLm6DGGGWdlAzsQsR2FAFclt24Er9DSFm27csVznGe M/Srj2F3DGZZbOeNAcFpImUfmRUJAxwPwoAYEbBJA4o2yMvzOT0GSau2+n3l2pa3tZZvdEJA/Gor u0ubFtt1aTQkY4kjIoAqlQM4NMCAH1oaQZ9SelSw2d5cLutrO4mXOMpEzD9BQBGD8zeh4PNM+ZPu sVJ6kHFT3FtdWpxcWs0JJxiSMrn86jihuLmXyreCSWUgkpGhZsD2FAERHOScsepprBSxGDgdB6Va fS9SWJpXsbpI1GXdoWAA+pFU1GSc5560AL2IVR9e9MYgDGcEVat7K6uSy21tNOyjJESFsflRdaNq lqgefTbqNCN24xHGPXPagCmXAUio2I9KkIyM8EA461Ium37J5kdjcyKeQyQsQc9DkCgCoz4B4yaj DH0q1PbT2knl3NvJBIQDskQqcdjg02DT766QPa2VxOrNtDRRMwLemQKAKzHP4U0uQM561LdWd3Zl Rc2s8G7p5sbJn8xVcruOAKAE3E89frR9aeF9aaRmgBvJ6U3GOoz+NSnAFMOOtADkXB6Z/pT9hIzg 4p+3BpxOPlzgUARhG9P1pSp/OnDkjkf4UoIzuNADUi4weDUjoFwOtJvVQTnpSeZkZ/ioAYRtPtXQ eFfD/wDblyxmcw2cIzLIeAx7ID6n+QNYJXmvSfDiiz8N6faC1mnafdcuIyccnClhwOAOrH8KAL41 LTfDultcJAiQx/u44YQUSeXHTefmfjqemD9Kj0nxFeappR1BoUtJba4VBIpPlSDHoeMr/XtXNeOJ HS9tLBtqtBFvkVW3fO/OSe5xtH4Va8Oag+nWi6XqWk3hjaQzxTRwkyISMHCngjjtigB3iaxs77Tp dbtYZIriKRVnIjKxzbs4dR65HPbmsjw7ob63qAhZzFbRjdNP2Udhn1PQV0HiXVpZtEm0+z0/UjHM weSa4t9gXac9s5J7k+lSeGkW08O20X2eW4kvZGmkjjJ4UHC5A4PTPJxz0NAGpBeab4f0t7lIligg GPLt8qLiQ9AZD8zH6YHWqWi+NZta1BbC4SO08zIh8jhXPaNweMH14/WsbxpPtaxsmVUlVGmlAbcS znK5PQnbjpnGTXNwFo3WRDh1IZfYjmgDs/EvhaA2pvdOheKdF3T25QhWHdkz0x3H5VxKRSzzpBBG 0sjkKqKMkk+g716rLqG27inyWeZI5pYIUJYhlGd7HgDrxnoa5fR9Nj0vxjqbtEfL0+N2iVTg5c4T BGex7ZoA19I0Cz0R4490Ut7IoLThN7xN32g/KgH94571SvviKLa/8jTrRJbNQEed3YyyY/iVu2Oc Crer3BtdBvLtrVrffH5UfnMSS79WA5OcA8nFebjjtQB6dqmj6d4isVuriSUtLCHtr9VyxH/TTHBH bHUV59cWVzpepC1mHkzwyKCQenQg5/I11nhO+VfC8nnSCIWdziJ2UsSXXOFUfxZHXHGar+LLdpYt M1WSOTcx8iXzeGJU5GfTg4/CgDuby8LarJG93IHllA8tH+VOinnGPz9fwrlrvx3Db6rcWVxpbfZo bhlPl3Lbmw3Ug8H1xW/MXuNbkKrIFWfP3vLUtuwNzDnp2HOPQV5hrpJ1/UM8f6TJ3/2jQB6DczWG oaWkk5N9p9wPMV5VCPnJBxjiPHrk571w2v6I+iaobYOZYZEEsEpUjfGenXv610PhB7lvDEpgaQ7b s7WwCsXyg55yASe+CfSovHaFINKd5Gkk2SqXZixPzDqT160Acmv3sZPHQVu+D55YPFli0LFWyxIz jeNp+X8awI+p5rb8JuieKrBpeUDPnOePkbnA6/SgDvNP1e5llmaSXzI4raRwikqCQuccd+nf8BXN H4jTKpVdLQBs/wDL1J1PU+/4101nKZo57W0tpUEtpIqeYoQkbTjI7D0H44FeWG1uFi8w28wTO3cY zjPp9aAO3XxPa6t4W1qOf/RroxYRZLguJckdAe4xUum37RaDoqBpTOsDsgUkhfnbBOeB9c9hXAGK VMF43TPTepGfzrvtNnnm0DRYY2d3WFiFXGR87DOewGOpwB79KAIvEqT6p4fF1IXllsJdzO33ij8H Jx2OPTrVXwXMRb6qY22SqkZDFtoQB+Tn/P1FdKloVuFsZWLW91CFkYfLEqOCPlwPmbPcjFc34Ts7 iz1HWLQqolgURsZFB24kAzgkDPegCz4hkY+G5SXZwbteck54Jyc8/qap+G9BjuYG1LUAogUjyYpC VWbnk8ckDpx1NaXiCDy/Dbxgm5nuLqMGViOOvTAArTMe6WOwtbWVhbqsCS7yEXoG68DPPTJ5/CgC HVfEkOg6fGIIVe4lGYYHXZHEgJw2we/TPNRaTraeKrKWO6iDGMgz2mCybf76jqDn06VxviW7ju9c uni2iJX2RhegUcACpfB8zweJ7MBSwnYxMqkgkMMdR+FAEniTw6ulTi5tDK9jIcAS/fibrtb19QRW 94Wkuk8MEwTPCDdOMhsAZVep9P0q26/2nZXenI5njaBhEUTbEsi/MME9TxjIznNUvDhj/wCEWjd0 Vtt3Jyf4TtXnb3Pp6UAQ+NCw0zTo/tbXBLyMxLk4ICjnPfn2+lZ3ggGPxFv3HItpcHOACV7+1aXi 9mfTNLZoTGu6YIpAzj5OoHQ/rVTwVGW1/KeZ8lvKSI/vH5egNAGzMztpWrGFpGRrJhLcSkpkZGER OwPqetcz4b8O/wBqySz3LeVawKSXY7Q79kB/U+grrJ1K6Lqj7cKbVgdw5PzD/Oev1pLBRZ6VZWCW 807rF5z7CQEdueei5HHJJ6UASXGsWHh/SmuEgXaR5dvbRqY45Hx8x/vMPUnrUGn+ILu/0mHVWiFp Kk5jZySYpQF+/g9x06+mPSuZ8Zyj+2ktY8A2sKxuqEn94eX7cnJxn2FW9D1RrK0h0jUdJv4/KLSR XFvCWlTdz90/TggigCt4qsbKW0GtWVtJbs0vlTpsKxsxGQ6A8jOD7Z6VsWeqS2vhnSYlvJEBtWYh ScJ87AE46dwPy5rP8W6pLd6Qtlb6dqC2/m+aZriDYMgHsPrya0LKeKPw5okXnKrLAzMwBwm5yFPt zkf40Ac347fztRsJcyEvYR5Mo2sfmbquARWn4LmaHw1IVluBtvTiKJtgfKKOWHOPZeT7VW8d6Xez a1am2s7qaP7FGquse7JBbPQYrQ8MRzaf4WeK9hubX/Ti2wptMp2LgFj90fQEntzQBQ+IFzdT2ulL cSu+POC5XaoGVACj0HTv9TXF4xwOtdn8QJJZbbSHlWRCyykBzyBkfl64PPrXFk98n0oAQjIxnFIT 6fhQTn14pCe/pQA0nPem89qXOT1pcY+tAEm8/hSfMx5JpVXOD2pc8lRjmgBrcnGOKUGlbpinKCBg jmgBmCT15FPRdxyRnFOx27U6P72O2KAFdQOn4CvVYty6Vo/2Z2NvJZxiSbzcNN6pkfNgYx1AGK8v GCuD0rvfD5S68O2t28hDW26z2RxgserLyOSSD06cE9qAMfxqgHi2eRUIBSNlAbIxtGMe1bum+Mbz XtUh0y7tF2XGVVoHYMr7TggE4PQcHiqfjeyZG0+/248yHyWGclXTs2CcHBHFUPBaM3i7TyAchy3A 6YU9fagDp7S4ureLUWlnkllWzlLNPMWzx1J/wAH1pmneeuhaQLcGOL7Ioe4EoDOcnMYx83HTggc0 57Yw2Gou295Ps0rFmACg4x0HHfvz71W8PmKfw9bzyPg2LPDsjjyxDHcuT16kgDv3oAwvGceNf+6E X7NFgKcgfKOBWGowDjqfWuw8bW7iw0q6KFdqNDIGwWVs5G7BOCRXJwRPcXEcSZ3SOFXHqTQB6I09 zFYWSLJ5EX2RNpA+Zjt7ADr78n0FQKpGu615MZubhra2YxuQoU4GXO7jj1I79K0ZLcXusPGCZY4U CSSAjBVRhiSD+OM/hXK6RqEet+LdTRiscepROkOUDEbSCgCngk4xigC34pEr+FS0jeY/2lGkkLkl uoHXt6dPpXBk816ZPbfbdD1W2gaQZtv3cjjAdk5KqDgsTz0H+FeYnI6Hr3oA7Dwc86aLqbWp+fzo tzfdCja2ctjv7c1d1oNe6ParNLJKG1KFEwuBgqchfQD2zUOgRtH4OiiHzvd3LSKmATtUbRgcnrnt +IqPxbqE2l3Wl6dBmK4t3F3ISQxDtwoPXPAzyT1oA6i/Mq6u0cR2MLnCn7wTnnaOmeeteY66d3iH UB63Un/oRr0S/gT+3ZHkknJa5LY3HLfN047ewx75rzvXgV8Qalkhm+1SZK9PvHpQB1fhCMT+HZYm nljX7ZnEeAW+X17VF48jhhtNHihhWABJSY1J4O4c885PvVrwlbyx+E0csYhc3ZZNrAMVAwcE9Oc9 B+VV/HYVNO0VTAschErgI+4bCRjJPU570AceHO7oPwrofBEIk8UwMMloYpZlx6hDiubydwJroPBc rxeK7NFziYsjjA5Uo3HNAHY6bfTG5ec/aF+VnJhxvGFJ69OMdOn1NZ5+INk0Loy6q2T8pkmVgOcj gjnnn8q17eNPKn5WANbyhUXlVHlnknHPH0/Ht5WASgA69h60AdJ4t8TJ4g+xrF9oC24YZuGUsScd wK3Ipnbw1pCkfZoWtSrKqklyGbBAxyTjPOevArmdE8NXGt288yzLbxxAhWdSRI+Cdo98CuhsxJJo mjGOcq32YqEC7ivzuCx9vQEgfXpQBt6jfefYC1Qyxy2kUXJ+WQo6nG7r3B6A9aj+xCa3u9a2Ddd2 ypKrr0kR1G7v1HP4c4rGluvsXjuG0NxL5F5bQ287ygBjuX5WORxg4roFlNrDdaZExkL43GRT5aFS M/8A1+fSgDJv3D6YksspCDUID5vI474PTj/JrWQ3H9tYlhEEQlYrAXGM54dgO/cbsmsbxQEt/DLt 9sluZReIw3hQqcHGAB+nSrzCI3MF3bmSf7dtuFWBMAf3ufQHIJJHpQB55c5S5lRgS6yNkE+561b8 PYbxFpwPT7Sh6Z71P4xtzB4ovG+Xy5286Nl5Uqwzwe9SeCgP+EkinJ2rbxvMxOMcLwDkgdcd6AOz s5ruXVY45pGjJk+aJDkhTnhsDGPbAHvWN4elVPC8arlcXkoDjqflXB/L/wDUauiZtN0i71d4yAiM sJJGPMbgY9epOcdutZ3hVpD4e2xbzIl0w3BRhAVXnofQ+vSgCLxSHi0jS8rMu95mIlz833MNg/4D 6CovBO4a+BsZgbeUNtyMDaeSRzirfiqJv7L0ydifnaUhSc/3evoeOmag8GhzrbbB922lJ46fLj+t AG/fiNdG1Xy3ztsyojRCFXBHb/Hmp7sOslv5R/0aS3jLnzcG4yo645x9TjjpVW+huLPRdRFwGCNa ldwYbdxZcD1z16ADioLOVbvR7a+ZnaZohahIohncgwOR1OMH0FAHK+KZPs3jC8ljTaY5w4DHcDjB zn0rd07xje+I702FxabHkjd4WtpGDrIBuBAY4Ocd6zvHdmV1a3vQPlubZA+DnEijawJGRngVB4Ki c+J4vKxuSGUgkEgHYevtQB0DXE6eHNeWWaV3FmSzSSEnJYDOTznn0UegNQ2CxRaDpEkokKx24ZWG SAS7nCgc5+lTXlqIvDurbi7utufnOMZLAEYHA6n3qK3YLoGk7Mxk2xAbAOPnbpnvnt+hoAbrfitN JnghexuTLJbJKG+1GPywSeAoyB09e/NT22rjxBpUd6EvYWiumRAZDMFG0EncRxyfqffpXNeNQ41C yQu7AWEePM68s2eoH8q2fBwZvC0kRkYFb4lQWITGxe38Xfp0z2oAyPHECwWekoFlDsJXYyvudiSv J9Pp2rkGGOnNdt46Crb6YRJ5mfOOePVeOP8A6/1rjDgZOOT0oAjP4UwqT8vapiCelNOB0oAhAoOO hGaXPNNIPY4oAfvwuO/YU4Z3HpzUYHOelSKdo6HmgBeCenA609fvcdaRFzTlGDt/WgBDzjg49KkQ DcKaFyRtyT0FKMgkcg0AT4z2/St3w1rB0a5kModra4XZKqnkejD3H+NYsY3YA6npUrkbljXoO9AH pCadDcWD28pk1SxnIZWsgMrJg4K8/LxnOfxNXtC8O6focqS2rM9xcxMiy3LYdiQTtRB7Dk89OK8u ikdG2pKyDuFbGalF5c+cky3EokXhH3ncPoe1AHoMtjeXVheSXENy7RW0mxAuyOJiMY2j+Ij6n6Vy Oiat/Y195xDNbyKUmjU8sp7j3HUVTW5nbdmeQ7vvZc81A7Ek0Aegx2EVzp00QuJL3T7pAWNmgZkf +HCk/KfUnr3NQaX4NXRmTULgSXEoI8ncoRIiR945POPrjPrXDRySRZ2u6A/3SRmiae4ePY9xIy9w zkigDpvEXie2gtX0vSpWfcpSadflTHcIB692rjY3eJ1kjZkdTuVlOCp9RQ3Tkf8A6qXnHuKAPQNM 1D+3ZI760uFi1GIKGtiQHd+7LyMoeu0e+c1Xl8BQ6rqT3kP2yC1PzPE8AVicdVPQKccZGenBrhSx jO8EhuxHBpv2q7X5RdTc8HEh6UAeiahrGmeHrNSYyLgRiO2s4iAyqDkeYw5A55HU+1efyXFzqusG 6nBmnuJgSo7knoPbtVfHUkk88mmnJYYoA9avNKu11Wa5ltrqdVmOxcHaw3cZxkkfUge1Y2reA5NU 1e7v4r1o4LicvsNq5kXJ6HtmuH+33pyz3k7E8cytz+tMOoXh/wCXyfA6jzW/xoA9NuLCLToYIHdr GztotiSTgAhc8nJ6liScY/DiuB8Sax/bGqGWIOsESCGBZDlti9M+56msuS6nnYNcTSTMOhdixH51 FuO7OaAJgRkAdAa6HwbE0vimzVIjJjexx2Gw81zanAxk9amhmkWUSROyMv3WUkEfjQB6zZWk7XMg urW6EDo8W7yj8oK7eB0xz7fiK5qL4eTiaN/tzyw7zgwWz7mA7gngfU1xv228LEi8nOTn/Wn/ABqb 7feqv/H5cAnuJm/xoA9YhtJba2jsYbB7eygikyGXPO05LN/e96y9Mtb648N6StrvRBAd0ohzt+Zs cfxfiffGK87+3XIBAupvm6/vDz+tN+2XKJ5a3MyqRjaJDjH0oA3vHULW/iJFWTLC1iIY4DZA6kDo faupikk1yzttUijupvtEQWRETKrIvysB6k4zzwPavM2ZnfcxLsepJyafDcTx7RHNKgU5AViADQB3 ni+0urbwzL9otxCBdphcZbGCMs3f+nvWN4a1dPsx0a9nEEUr7oJpPmSEnqGH90/lnrXPyzSyn95K 745+Zif50g69Bn9KAPQ9S8PSavYW9lI9w8sZItblEEkflk87mB5Gc4x+AqSx0Cy8NWrR3TFBIm+5 uLhV5A5CKh9+3OeOlee+dMgVVuJVA6BXIA/Ch5XkZWkld8dNzFsfnQBueJfEQ1hktoFkWzhYlRK2 WcnjcfT2HameG9YSxkuLO4Ypb3QA3gf6tx91j3xycgdqw3OAD/EelOVTjbge/FAHpD6QLnTZrF3m uYpnDQXFsiuoYcFuDgLg4xx+NP0jw1J4eZ7h5GM7xsGnPyLGmccZ9euT6dK88jmmQbI5HUdNqsRT 5rieVcPcSv2IZyc0AdD4n8SRXsZsbGSSSAMDJNJj5yOgUDov1rJ8P66dPnnt7gubS5Xa23/lm3Zw P547Vkyk8KpHPpSKSOMAEd/WgD0aTSYrjTjaXCzajZM2+CWy2/K+OSD0UY6g4+pNWtL0Kz8PxXCW W6Se5tjskm5llwC2FQdB09c15is80alUldQ3ZWIFOFzcLIJVnlEuNu8Od2PTNAHeajY3M2harc3M Vw7x2+IwRtjiJYbgqjgcfX603Sra7bQ9LeC1md1tTiRYc7QXbGG555rg3nnZGVpZGDckM5OahN7c qAiXUyoDgBZCAPpQBv8AjuGSHWLZbjeJRZRhlkOWU5bqe9aHhO3ubjwrN5ELyAXrFgoJ48te3pn2 P0rjJ5nlkzLK8jAYy7ZOPxqPz7iAkJJJF3O1iv0oA6rx3Ddx6dpDXMEsXEoCyRFcAkY/l359hXEE 888Cpprq4uiPPnkk28Lvctj6ZqA9fagBS38qaxyOhoODx60hPP8AKgBMEnP50YHcUh54oY7fr6UA Ljvk04cn8KD7UoGBnFAEq4Xk805QP8ajB4FPB5wO9ADgzL8yttYdCOtEYy/OcUuBj0xTkHUmgCzC u1d2elP25+ZsZNMjOc5PFSE4UEj6YoAb07cU9evbimMwzk0K3HtQBZV/lA7dqUDJ69ajj569anBw McUAIOp7AU1xuOMdaUn+EHOKcgGST2oArunz5pgQB8ZOOxPpUrgk5APPtTfLZshFZsDLYGcCgCvJ yxwOnSmquTn8qkKnJ4Ofam4+bB49aABumV+7TDx6fnUrqzDAzx1FeieH7LTpfDVtcy2FrI32aUu7 W672YBsYb1wKAPNTnGKjI44wcVIpzQ0bt91GbnHA70AV84AOee1ABLA449akeCUqXWKQhThjtOAf T2ohR3k2xqzt6KMmgBJBgDH481JCPkBI5NNkV1bEish9GXFTWyNJgKpY5wAOaAGBMNyD1608LlsE 8DmpJYzHJiQMrD+EjBpcFV4Ukn0oAZsxknmoxy20Hn1qdwW2xxozM3QAZNanhKGz/t+1Oq25a0fc MyKdhYDjPtnrQBjkDHBBI96RFKsCecV2XjaDTQlqlmbeS+yd6WaDCR4GAdvB71xgLMQOc46UASZB bn86VfbgUsaE8H0/KpQmCfXt9KAGep44/WgAuwHTJp6wvISqIWIGcKM8UDAFACYBYe1SIpA6jJpU X2HTpUgikMRkCMVB+ZgDgUARAkHIP0prMSD6e9PVTIwRQWYnAAGSaVk2Agg56cigCumWYt057U49 ufwpwG1SDx6+9RZyTQA4ct/KgsOBTA2OQfamFiSfrQA5myOc1A7AckHPYVIcnjvUEpOaAGl89O3N MkZnbcWLE9c0qoeRzz3pCGbBx7UAMOF4BqPtUjdOvFNXbuywJUdhQA0jjHSmkc89KkPrTDjH160A Mz1phOakdSOvQjPWmA/X8KALGMjngfSlYDPSk3HP+FKR270AIDx34/nUqcsB3NMCknGKljTLYBH1 oAeE+XPYfrQBn8TUxXCBegHpUZxyfXjigCRB83XAqXPbHHaoFP4mnq2W60ABJY8fQDNSINpzg4po AOTjFP6DHc9aAJEPU/lUhbauajUgD+dOJzz6dKAHhsD61r+GG0tNXSTVZljgiQuu5SQz9gcA+5/C sQkEZ610vg62tnvJ7i4RXeCLfCkgBUknGcHrj+ZoA6v+3brUNdit9Ktkm0pYh5kiQkBWAP3Tgc9B gVXkUx6za38MP2eaeCWF/KG3cAAQ2cdffFR3Gt6iPFmm6dDMEtZAskkixj5wQc89gOmKvmJW1C0i juCUAuA7MvKnavQdef60AZ2o+JbrStY062e2ikecDz5SSrkMxAGfbrzVbxZb2upWUo8pG1C3mWNL hVwZMttIOOwyOvIqh4rRH8QaTFDlwY0UFuufMOQfxrc1qeCxhvbqFZHFtdI0h2YDYlBIz6+2R06d 6AJL+4Twj4YuYtOtws9qEjFw6ZLyEgE+4znr7UsV9Lqel2t8YVUS2EpkEYwA21wzDHqRVXxVbSXH hm+MCvIrvFKgReNm7OcDrw3Wp9CiSLwxYtNMVkFpMFjK8chyM/UUAeVKuPc13HgC6+yaffsF581M HJweD1xyelcXxj3Pf0rtPADxLYXomI2LcROcoTkYP5etAGjZeLZ7nxbqWmvHDDBHveOSNfmQpzjn ghqZ4j8TTeGxFJY2OnpPdys9wNinzFHZsdDWPo0QPxF1JRNsQfaGZ8biV/ziovHSx/2ZpxhjZIy0 u0uuM9OnqPfn60AdV4iWHUPDl2k8AnZbU3Nu+MmAlQ2A3XHUZPWjw5Bb+HtCVFgUXf2N7uWZuobY cAcdsgYo1S5Enh28tIg4ddJy2F4GYx3H8zTY8apoT3VsjOlxYMqoowdwXDDI6nKngnj8aAGWt6fG GhI2oBZZJQYpiqAeUwPyuo6jrnjrijQ9Rmt9K+xXbgDTZGtJsN8rJ1BPHcZx6kYqt4Ttni8LCW5l +zwNO8km9MbUAAySexNYega+/wDwldxKMLFqLFf3n3UOcox+h/maALfhnS7iy8TahcK6xNY/u4Hl BAy/3Tz/ALOTWuusTR+NLTT1vGkitoZGkJYOC7JkgHHTAGKv3EylGe42ubYGS5k8rIfb03dAOMAH nOfWuQ8LmW98WLdSylHl8ySRgMnBU9vxoA6W7nYeJtHMSCNis6kQ4BwVPXHQ/wAvem6n4mutIn0w PaRSzSEtJNISH2bsBc/mfT2qZYon1/RGh3JEwuOWTGBsPI9R+f1rH8aInm6ZHGxfAdcsMHO/kUAa 3iiK0vdNvRLGJLm0UvHcAYbgj5D6jB71Y0+207w7orTGw864hg86SR485kI4Gew5xxSa6kMenasI A7OsHzybAFXleM//AKs+9Wo9nibQrj7HdRl54drBzgpJxn6gkde1ABpGpyanDHdWkS2811GyEJCC EdTgEnGSM88+teYXbSy3czzEGVpCXIH8Wea9G09LbwtoUB1GeFpICzmOOQFnJOQo9R79q87mcyTS SHguxY+2TmgDS8Maamo6zFHcKzW8KmWUeoHb8TgV2Op+K30670q2gjW3gu3dZ1C5+UttBHoRXKeD p0j1loHAJvIjChIHDZBHXg5xj8a1PEun3NxqmgiOJyM7PM2cKRJu/AYI4oAuanp7jVLHV4k8qeG6 WKQ4CtKC2A2B37H61PrviG60fToZjAk8zTlY3mzuVQOeeKNWujb6jaQNKGuLy7Qqm3GIw27OPc9K y/HQRNIt0jmaTF2+4suMHbx+YoA19aks9Ysngu4VkeSATxP/ABQEruADd/5GvL+q4HHHrXpmyFLO IIjtMNODfKgIj/ddz6e/HcZ7VzkPgaWbS4Zftf8ApdxCJo4UTIC4J+ZvoO3rQByZ54HYdqTIGDjp SfNgttx/SlCsTkjigBGz0qAjLEZ6VOwbJ96jkRhwv40ARtjGFGKYevHB6U/b655phU4PXHagCN+T zwAOtNIHTPFSbSajKksR2oAae7dKTrx3NOYdBTOf/rUAI36U38RTiMnmgIM8g0ATBSDjqaevpzim qAW45/pUoHB9aAEA5APQ+tTIAGAHWogMDPT/ABqVSQPfNAEhOFqJRluPzpXzsA/P2pBxz6UAPPA9 xT0UHjIFR54xT0YA8Dp0HrQBJkZ680oPc8f1qInNLvBIGfpzQBJvxk85PFKHzxxx2pm4NyO3Q04D Ax3oAcGyeh96vWV7PYTLcW0myRePUY75B6iqZAUAqck9KcTtGPXrQBvSePNe3LtuIlAPRYV59vpT D411oqjSTRu8auqMUHyhsf4Vz7feHT8aYzbjk9KANW98S6lqF5Z3lxIjT2ePLfYB0OQT2qzfeLdX 1a1e0u5ojBIQxRYlXBHOciufBJbHapRydoPHU0AbVl4s1vTLdbe1vSIl+4kihwmfTPSrH/Cba6Yy kl0siujRuDGPmU5H9eMVzrsemT+dLnCjjk/rQBE+MkA9f5VpaZ4g1TRYjHp9wsSmQOfkByQMDk+3 86pFQcYBPrn1pQhxwP8A69AFy0129stXn1SFYBPchg4MYK4brgUzVtb1HWbeGHUJVlFuWKEIFIz1 6VD5WBkjk1EyAnofwoA05/GOt3Ng1g8kRt3jETIIV+YYxkn1wKZo2u6voq+XZ3bRxFtzRN8yE/Q1 TSIAjj8qlCLwBzQBe1bxJrGsxeVd3X7k8mKJQisfcDrWdAnlbWBwynIPv1pzkBiB2puflzngUAat 34j1W/hlt57hWil++qxqpPOe1RaXqc+k3gurZYzJtKkOu4EHrxVAED2JqRSMZNAG2PFuqGeKaSSO SSAP5ZMQBXcMY+neoL/xBqOqrai7kRzaEmNgoB655/Ksz7wOMDPpUioQMcUAbFz4u1e8tZrWaaIw zpsdREozznP1rqYp38OaLF/aKjbZgRh7WQMWDZIO09OepHWvPiuQOwroLXxlcW9qltdWcN7GibAH +XI9+CD07igDqLa60fWLdLtYUulL+S4a2CODgfxE+/WvOr23W3vp7dH3JFIyg56gGt658aXb2Jsr CztdPiOQfJUZ569gP0rm3CqOTzjNAEZkMbhkYqynIIOMfStyHx1r8UBRrtZeAA8sYZuOnNc27ktk VEznJUk468etAGkNZvBq0WqTTGa5jbcGlOenb6VLf+KNT1fTlsb6ZJIUlMikIAV9uO3NY5DAZxSK cKfc9+9AHRDxtrgtxbrNDsMZiI8lcsu3byfpTIPFms2uk/2bDdBIdojDBRvCf3d3XHNYQ+UjNIrb WBBoAnWNcY49adgRrxz61EJccL1pS5c4H0oAdGm4ljSTRqB1zSecBjBpjyjpuoARolAOWHSomRSw Awc05plx1yPfvUSOcFu5oAkkAUY4GO9V8fxcc/pRJJuBA5FNLDbxmgBjgUgQ45/Gj7zZH5VIpx17 UANMYHB+pqNjjpzUjsAM569Ki3Y5FAEwBXk96kGB9e9ISOODxQpwc/rQA/vjHHrUkabeoznqKah+ bOeKsJxjHJNAETrwcdAOtNyKll4JAPaogCeQMgdfSgAPC4FKp2sKQr754pB+nagB5OPrSAn7oHJ9 qTqck0+NfmyTgeooAlUDP0p3BbFMHXlvrSgjJHp70ATRfM2TwBTmXdk8HP6VCsoGRnvzUgbKZzzQ BFIRt49fSos9f1p8hBbHGB6UnAHy9+woAQDnFSAYzz1PamrgdeTT8ZOaAFVOM9qcME9PwNMyx5wS KchOckjHvQA/aeg5JqdECjBNNiI4bOcDjjpTfM3Ev2PT6UASPhsgNwKgLAc/1pd5bp+OPSoZGweT yf0oAeJBu60eacFh06Cq4JbpT3IUCNeg60ASoMkZwaVmG7A6CmocIMEml47ZPoKAFAbfg8EjPNOU 54/yaaxxgAfXmgEEZFAFqMDNSBuTnt3qruOOOppyvgc5NAE7YP0ppQscmmq5PQmrGRjA6+tAEGDz xxUMx46/Wp2ZaqTSgnHXH60ARg/Nk49800npgD8qb5meM896Qk4xnHpigBZGIHH0qMEFselD5PTg /WgLhQBkHuT6UAPLDP1pu4AYyKTOD7dqYRlsUAPUk5B/MUjHnOeaMkcAfl3pjZ6YzQAoJz7dvahv lO48DNOQBTuzn0psh565oAiYhjwO/pTCT24Hc08jHNIcA+vrigBre/Wmt2/U04ZJz69sUjcGgBhJ 7cZoHPA//XQR27/yoJxwOlADZMk45HbFMJOaceeSaQDjigCbfk+oBqQH/PpUCkgdaeGJ/wDrUASo cOOOtWkYfjVOM88Zq4gJHTNACnGDu/GmElR/QU44+vbpUbAjgAZ6UAIcc+vam5xwOacRgdKURk88 elADRn0/+tUwyAMdTSLGA2XOAe/pTwCeR0/nQA0kjGcUgJOSPyoIyfp/nNKFBGOmetACISGB754q dmKxjA57VEpXdgL7ZNSjBHPOOKAIc4yQCM9/SlJzj24NK4zwM5700gHA9KAFyOnan9V+XFR98dc1 LjPH50AMJJ7cnpilBydoxgUrAKp706FVDDcOvNAFhELxCM8Z5J9BTH+bpwDx+FSSS7VKrgFup9KZ wF/xoAYcA4x09KgkY5x781PgdQP/ANdRBQX56CgBIxgg4o56t61IBlPr0puOmOc0ACZIIFSlWIz0 9KSJBvI9uKlkwqADrQBCV5xkUqgDt3o5yDSZOMcc/wAqAHs+1e1MB75OTSAbj83QU7gnntQAolZe c4FOackDqBnmoiAeaRjz1oAdJMSCO9ROflB4obg0x2yOtADc4OMfWnbsA9BmomOABnrShhkDOaAH YBOTRnueh6mkPAIx0ppyAOntQA/OSfUUhA6YJ/xoXjt2ppJB4xmgBT8qVH1PpjvUnJGAKQrjIYfk aAED89B7c00kk8455yaOCQMHHekYAn+ZoANwqMnJz096exC1ExJ5oAcjYIx29e1ITyT6HikH86YW oAU9eO9NbAozikOMnuBQAhPQcikyDSHOTQBnpQBJn5c8GnAHjNNxlvWpO/096AJYRkAEcn9KuLgc DjjpVRGIbP4VOj44zzQBM3CggYqIBs47mnbiODgnNO29T3oAjcgHjt1pc4QHA60jAk4/OmOOSM/l 60AP3fNjt6GlyCeuMCmKPkxk/WkJAO0du9ADywH9M0zzDn7vB9qYxOBkfSlUZOTn8+lAD1IBzgmp g3qAOOtR5BUAD8aQHP4/pQBISMHBzjv2NNU447mkyMcnkUA7qAHAgEn/ACafu28E81COTnj2qUDP XvQAgOX5HSnI+WPHAoYYGB1NCjAHr2oAkGWOSP1oZiTgZxRkfdGM/wBaVBnOO3NACscDbjHrTCvy +/8ASn45yetJt5IwRigBrHGAOgpqAE+h7U8gAYHWk2YGR3oAkjwWFPfBB56etQqTuA6VLwfpigCM 57/hxSMMZJ5NOBOc0x3OSevYGgBcjAUce/vQCcn5sgdxUOc8ZqUfd57UABIUD1NNG0Et1FIzcH3q PIJxu5oAVmByPWm4JOTjrxSsORn8aXaMZJ/+tQBAwbI5HNOXPoMdqfjJyRyaXnk9BQA3BPJ4pABk 9T6U8ZxknpS4+bJ7deKAG42gfyqMcv8AyqRm3Dp0qPdtyduSf0oAAeccUMQRx07Uh4H9aTvnt6UA HqAKXsB3o5JyOnvSnjtyaAIpAcdOnf1qIjCk+tSuvGe31qLknp0H5UAA+6c9aiPfFTNwB0z2qE9e c0AGe3ekpCRngYB9aPfPHU5oARuDTcn6/SnHJOTSc0ATKuBkd6lUe3NNAz2xUqDk5NADguTn0qWM beT1HakRMfMRT+pxigBY+malJwuc571GvTAOAOtEhLAKKAAYILZ+lIwCg4pFIZuBwKGPfqBQAzoO tNIGSF/EmlxuGaNuf60AIAWySfwowAepOaeeM4pjYyQDxnrigBzHOTnimbiO/XrTiB0GOlOEREau 3RiQp9cUANHH3qXOAOOtJwOTSjJbPpQA4HrxUqep6Colyc8VITtXAGaAE8zLnPpSkndk96I07t07 09kCjPU0ALHwDkj0qbGEGcY716Jp+laXLpGmTS6VasZbdTJI6H72T6HuKbqj+GbO6X7dBZQ3EkIc R/ZG2pkcE4PPrjFAHnTPg4HWlQ9yPzrvbjw/oc4EgtoZYJlCRz2bnLvjkhRkDHvXJa1os2jSR/vB PbT5MU6jAbHUH0YdxQBQVRguTQTgE1c0rTbjWLl4oFxHEu+WTaWCL+HOewHc13Fnomh6RaTXNzED FCgMk93GGck9lj6D8eaAPOF5OetPJPI6Zr0Bn8N+JUdrPTkQQofM2xiOVM9GAXhh/WuS17QLnRJV cuJ7WT5UmAxg9drDs3tQBk9TgdKjkYEBFUdev9K67whbW9xpOqCa3hkZTGVaWIvjrnoevH/66vy6 XpWo2s9nbWFtFOYibeaMHcZAM4645wRjk/SgDgTw2QAOenpQX7ZxVvRohNrdnDIFKNOgcMOMZ5zX d21lps2sRxjSrMRCYrzbN8/zHnJPTj0A96APNZHzwTg01CN2RjjpXc+GItJbRLq4v9MhuGN+yK5i 3cYyF6gKvvn86vXEPhW202G9u9PtrJJZmRB9mdiduDxyPXqRQB5yzA85pd2eOvc13h1bwWvzRR2Q kycbrByq5+rc1R8cafYWmn6Pc2MUAS6WVhJboVR1yuOvOee/vQByAY45/Ogndx2puCenFSADseBQ AgyozjpQWz24HX3oI3HGaFPzHFADWOO3NIOeo4qXGTu4oK/jQBAFyeKdjPHp61Inc9KMAnPGKAGK tOwAuc4zS9Tz0HWmvk8dM8igCFxkZPamYGOlOZSTj0pSOBQBC+Tj1NQkZ+lWJewHXvUezFAERSlw F6dqc3JNMOegoATtnFMJ9c5p7A/So2P40AW1Y8Z7e9TR5dulVQenvVqLp1oAs4BH0oWmEjgDHqea XORntQAuccUOePekV/myRnjikL7m5HPtQA4AYx1pH6egpRmhhk9OlADQoAz6UpXA5x60DI7ZpccZ PNADdp69j+lJt4zUh5xk8nrTSADtoAZtx14zSFzyKccjPPSmgc5PIFAAcY5GKUKeMHj3pcbvQCno CPQ0AL0HNOUZHpQFzz6UooAduA+nah2ycfypmMHOenTikPHOfwoA9QtSg0bR084vm1QkNJtRRzkn vj6CuS8azLJrUBVgx+xxfNgjJx711EO2y0vTQzJv+yxc7NxHUjA7n8DXKeNpnn1mCVwys1nF97Ge nfBNAFvwTNJ519Zsc2rwefIB1DKRgj88Vpa2yXHhK8EcGyKCVJkZn3kEnaeegyCOFGOOprG8DMRq l2BCJ/8AQpDsIBBII7E81v6stxN4V1Vpp4X3eUohjXhcyDq/GT2wBgUAP0aCDSfD9sFuFt554fPn cNtZi33VLZAAA6fU1g+L7rbPbWMcjNGkQmk+Xbuduc+pwMDJz3rqZ3so9QNuBA9zAEjkdlLCAYAw B6+5Iz6Vw/imVpPFWps7Fj9pcZPpmgCPRNQ/svV7e6Ybk3bZV/vIeCK9Auoo7kT6XcqwgnLR+cQI 4w3YqO+OPmJ79TXlyj5gT6ivTL+azXVZJBE09xHJGW3HKxfKvAxwv0HPsaAMHwxHGNH1u3niL7ZY l2q+MkFuDzyOOnOfQ1s2z/ZybuCNFWBlBkdgscfcA9yfRf5Uy3hgtb7xL5ysp+1xusSnbkEEjoM4 OegGa1LJku9KME8KK3nB7WMIMIyLuwFA+XjPcn3oA4TXLOPT/GcEkPy213NHcw5GMKzZI/A5rsLJ 2ufEGQZEVpyzSXEq8kE5wi57fT3rL1SFtctbG9SMPcWF6u8g5LRMQSSe+CPU4z1rUs7pzrXkrL5i +cwUmIBfvHOABwPfHP8Ae7UAZXhiziuPDlz++ZYo9Tc7lITaNvB3Hp+BzVTxubY6Dp0dsSQt1IXy c4yo7dv69an8PrbReF5Li4RCo1Vlj3jIQhepHGT6VrXIsLrQha30cAtzdM/72Xyju+o68H/HFAHl ecnjp7VZlvbq4t4oJrmSSKEYjRmyEHsK71tE8JG6jaRLMIyneIb4hRj365/n7VxWuR2aa7ex6aB9 kWZhDhsgr2wfSgChuwPrTgCAKVYyTk0jgsNo6UAJnqaVevNCxsB0zikw+eKAJM5HXimFieg5pGJ4 pwVuPU/yoAQZxTh6Y/8A10Ecevao2LY47etADwecUHpjjNQKWY5Pbj61Jkjn1oAYTjNN3ZOFH/1q RmyR3+lORSwPA/CgCu5JY5oUHB4qZkwT7UhBC8dTQBCUzSBe/apTkCmMOMCgCCTrgVHjPNTlfXmm bMDJ/CgB6KM9eKnU47CoVOOacnTOTQBPkkYp/Tjmo17DFSBs9qAHDpx1p6R84FNQe1TjCrnv7UAR nK9OxpGwB3604nHJP/16iLbiT2FACjJb3NPHPTnFNU46H60E546mgBrvg/SgN3GaQrz9KjIOcmgC QfMf6UA5OKYoIHFOXOOg+tAEvAHPWncegzUIYlssPrSlxuxQBM3C49KeuAOahWTj1pwb1oAeMHLd vSo3IBxyaGYDIz9KYSM/1oA9QurmS7tNNazixbtZxogJ5zz8p49ge59B3rkvGW6TVrZnYF/scYYr nBOOcZJrpYjIdI0qJUXmyQh92F6t1JH6AGsjxnp13Jf2MsUM1xG1ig3xqzrwSDjuOfWgCv4IQDUr x8tlbKQgrjPUevFdFrAaXwvrCGVVaJInEe4ll+YY3N0z6CqXhqyutG0y4lniMFzfYWMOvzJGOSSO 2TjHfjoaTxPqf2Pw2LE7BJfOHCtyyxr/ABY7ZP8AKgDVEt1P5VzC7eU9vFKrqgUOzKATkclsg5J4 +tcj4ygWPxLLKA2LlEnLEghiwySPbOfyrR8N6quo6W2l3WJJbKMvbRsTiZc5KEDrt6gd+as67YXG v6d58dtK19ZAjy1AUeT1xt9Rz8oOcGgDkLWAXN7bwLG0nmSKoRWwWyeme1ej3Sm/1l4IXZYfOEIX gYAwDnB5JwTgkfQ1y3hnRLyK+TUbuM20VuN8ayjDSN/DhT1APOTgcVt61qMPhzTZ0cK+pXaFI9xG 9AfvNtHCD09e9AEdhfLdDxNdQozebdx42dQuWAzngDjv+VQX14+lWNrfi2ZRDqCM7lvmm+Q5HPOM euOvQVW8GPEui6r5nmqokhGUIXP3uMnp+HNO8Uhj4djc2skKfawFMhI3/IegPb3I5oA6awiitNUW 4MObG4QFpJG+9G3K5P5cdMjoKbawu/iPdFa3M6Ccu0z/ACRx9ecHlu3P6isXQL2XUvCsUQ8yeawk MLIH2qsbcoxPoDkVq6ddP9vtYy4j3suyOLv15x6epP6UAUNAW3ufC0cQYxyw6lJ5jLyXdgc7e/TH TmqPjC18vw1YuLcqGu2yzLyvyDA9s/0q14Uk2eHbh2A/5ChwM8sdp49h+dR+JrPUL7wtbTQRySql 43miLLY+UAce3Pp16UAcIACccVa+wXUdkt49tKtu52pKUIRj6A9K0NG8MX+pXiJPE9pbBgZp5l2h V9s9T7Cum8YNCPC629kCLa3njVBIfujDYx7+tAHB49O9IF5/nSE7V68mkBIHXnvQA9wAtMOOxprM c9+lN/h579KAHAFzk4wKeB3qIt2oDckk9KAJicD3qF8E4HSkZyw60nUYHXvQA3vxwOgpHYgAeneh mwOOtNOevpQAgBJ+tTq+1M9+1VjnGfzqRMlQaAFYk5phJzx+NSHHTv3ppyBg9TQAxuKb3x1NP24G TUZJ3Z/GgAYDp0ApjYJ6YpSScUxmwaADt6YqRGA5qLOBinLzQBOhJBPTPSpEyeT+dRjPTHtT93PP agCZGBIqXdk9KqqakMmVoAV268/So+4x2p2Mn6UHCigB4AA9cUDk5pgJI4pUOWJ6CgBz52/Woscj sKdI2enXpSc7en40AKfQUoXK5P0FCoTgnrUgAGCOvpQBHt2j1pNp/HtT+pweKQcE+lAACfWnD60w nAzTTIT0oAC3z7vSkLZ60wHJz1FIzACgDr4vHvl2Nvaf2JaN5EIh37mBKj+XrViP4kXMHCaeigjo LmQAdhjntXChsdjj607O5hx0oA7Sfx5NcQgRaZapKCG8xmZ+R7E89O9c3eXlxqF09zdSmSVurH9A B2A9Kphv16UpbHFAEiySRSo6MVdGDKw6gjoa6ZfHF5P5bX1la3dwjbhOwKMemM7SAcf1rlgec44q RflXd3NAHWXvxFv5nDwWVtbyqMLJy5+vzd/T0rlZZ5biZ555Gkkc5Luckn1qEjLYJpRxyOgoA3tA 8QvosE8K2Udwk7Kx8x2GCucYwfepda8WXOr2TWTWkFvC0olITJORnuenWufGAAc59qN2WxQBpaJr LaLcTOtulzHPHskikJCsM5Gcelb1v4+ktVVrfR7NJF/5aFmJP156e3QVxxI/EU8EtxQBv6f4rGna W1kdMgn3XDT7y7KckYxxV+L4gTRKEt9MigQHJWKaRQec469K5BhxkDpQoO7GfrQB2Z+IM0haSTSo ZJGJIaSZ2xkYxyay9Z8Utqum/YRp0FqhkEjGNmJJGfU+9YmO/YdvemkY69aAE6tS9vYUg/lRkscA YFADcFmz1FEhHb0/Kn88gdKiY5bHYdaAEB4znr7U1jwBS9D/ADprLxnr9KAELfjS7j0z2prdgKVS M5POOlAD9uBk8k1G7ZGPypWdmzxTMnGT07e1ACc5x+Zp4bH/ANem4FKeF5oAXJ3c8UjvSM5IBYkn 3qFyetAEhcnvTGPOPamr60vbrg+tACEnsajY88Zp56YqNumeKAHfhT1P5dqYOvsKenv3oAlU4pQf amZ4oXGeaAJQak3HI9RUS46mgP3oA67w74PGsaS2pT3jxQ+Y0SJDCZHZgByfbJHua57VrGbS9TuN PnIMtu5RiDwa73wJGq+GxNb39zaSy3LK7BEdARj7uQdrYPWsTSPCj+IfEmoLe30i29vdOktw2DJK 2Wx7AkLnNAHKj7uKfxjj8a9D/wCET8JXEl5Z2jXxuNPcJcN5o6noQCMYzXHeINIOham1n5hmQoJI 3I2kqfUdj1H4UAZ8UavIqtkBmAJHaur1vwbbaVpM97HfyTPCyLseLZnJ9c1ykR/epj++P516trUO n3+mXcOoXTWlrAySsyjJbGB155JNAHlQIHvQO5rtNS8E2Euni80S9Zgyb4xI25ZRgnCnA54PX6VR 8I+E49eikur24a3tFcRIVIDSOeoGfQUAcu3A96ksrK61K8S0tI/MlfpzgAdyT2A9a7hPDfhXUpru 0sVvlntJhCzmYZJ55UEYIyD6Uzw1p1ho+o31nNHJLqccblW3funhOMH6+1AHL+JdHTQNTjshK0h+ zo8hbGN5649uOKi0LQr3X9QW3tlwisPOlPAQH+ZPOB3rr/EM3hSTU421sXcl2YF+a2OE25OPxHNP 8JS6THossumRSrcbo/tRnbKo2GwV9RQBw2r2SabrF5YxszJbzNGGcDcQPXFUCc8Z4rsvFD+E/tGo bY7w6rvbJziLfxyB6Ung7wZb67bC81K5a3tnk8uEIQGkI+917DNAHHqMLggdc037x716BbeHPCeu W8x0wXsDQTGN2aYEjHQhSOQfwql4d8K6fcz6pp+teZHcWjptmjkwu0+nBzng/SgDj+AoDEgY4xTF OSeenWvStQ8BaFZzEo9zdKzlAqzBShwOORyeRXC65p0Wla3c2EMpmjiYAOevIBwfpmgCOytbi/uo 7W2jaSWQ4Cj/AD+taviTRF8Pz2lq0pklktlll5BUNkghSOo461oeAjpQvJvPimfUljlMOGxGU2c5 569a2PEM3hd7y0bX1unnMGF+y/Kqrvbg+4OfwxQBy2ieHpNdhmlivYLcRMFIkBJORntVTV9Jn0bU 3sLhlZkCsHQ5VgRkEV0vgtLVrLVXZnjtjOgQEZOOSMn6Vu3fh7w3qms3RmvZpr6WNJPs6SbWhXaB jG3nA5oA8zwRye3Sm967C58CSjXLays7xJ7W4LHziQDGF+8GHqOPrmr954N8MafqMGmT6neG7uED oxKhCO4JA46H16UAcCPvVajTanTk11Ufg/TbfWoImnnurOaGQrg7HSVF3YJxjG3ketXm8MeGY7m2 WfU7iE3JKxxORnIJGSduB264oA4YoMHNAjIOeldZ4h8JQ6fZG/sLlpI48edDNw6ZOAR0yM/lXKs3 zbRyPagAIPQCh49oAPHeu00HwzpOp6TYSzJKk9wWVpVk4BDEfd/Cpl8KaDf2rmw1GVpYmKNKTlQR 3K4GB6etAHn7AnikVSBgV0Fh4ZubnxC2kykR+SS00o+6sY/iHrkYx9a6Gbw34UtNQttJdrue5uYT IkgmCpnnAzjHY0AefEDGajIAPQ11t34atdO8QadFL5s1heSBCNwDqfQkDpznI7VuXHw/0AxeZFeT ltznyxKPmC4zgkY4z+tAHAaXpsuqahFZwYDyHqeigDJJ+grrX+Htu9puj1SRJuAqyRDaSc4zg5AO DWppWkaBpkiXEFvc/bpUmESPNuUqEGfTjk1X8QeKotGhItzKNSnhBjdVBhADHGQe45GaAPOLmKS3 uJIJRiSNyrAHoRxUZOBx3rqPCfhYeJnuL7UbpobYSBPMDANLKxzgZ9uv1Fa8XhrwjqN1fWFgl+Li xmETuZhljkjKgjB5HtQB5+OScmn47kda24/Cl0/isaIrLyd/ndvK67/y7etdh/whvhG3ngsJbq4m u7mNpIj521WxxgEDGe/foaAPNY43lkWONGd2OFVRkknsK2td8NSaHpGn3F07C6uncPGCCqAAEcjv zzXUWvhnRdD8QafNNJcyrczItohYZSUH+Ijqp459qm8QT6A9jZjX0n8sTSCFLXqnyrncc85G39aA PMnOTioiCauaqbBtTnOmLILPd+6Epy2Md6qZ9BzQAAZOKDwKM8009aAEJzwKaeT2FO/CmkUAIDxU iGolGT6CnjoaAHlsU4HFMC9zUoUd6ADGB6mgjmjOfp2pdv8A9agD0PwKksvh+MRR7tl0+7egYDIX 7ueM8f8A66g0K6uF1nXbT7FcS2txeODJDHvMT7m4IHUEdqr+HPEWiaZ4ft7W+lumljuXleKNCAwO MfNn2qLTPFsGm6vqo/0iSwv7kzq0Z2PG24nOPocfgKAO008aVdXMhtLm3k1BYysxgm8uTaOzqfvY x3Bxj8a4TxpZTW2s/aZL5r5LpdySseRjgr+HqOK3bXVPBFlq0mueffveOGYIkeAHYYJ6cf8A165f xDrZ1q9SRUaK3iXZDGzZKjqcn1NAGZHgugPQsB+tej+MIzF4YvQIvJUyxAbT9/kcn06enpzXnELq s8bPnYGBOBnjNd5q3i7w5qthc2s/2+RZWTgADaAR8y56EY6dKALvhyOVtA0WbBEUaNu2r281uPf3 /lV3w09nHpek+RD5gMkjhsYVW8znqRk45x7VgzeMdD03SIrTRY7i4kjhaGJpQY/KyDl++Tkk4HFZ PhPxbFokUlpfwSz2rSebG0bYaJ/UeoNAG9oWr6TFqd5HpGiajc3c7MZ1BRgF3HJALDHXrTp5Ul8a ySPp9xCf7LyIrhQCT68ZGPz6VUtfEHgzSLi71KyivZrq5XHkmMqi5OWAJPANYMPi+ZfFo1qSH9yV MJtw5OISMYz3I6+5oA0PFej32r6/Etlb/MLKN5fnGyEZPVskY981Z8J2dxpkeoWtzZE3STw/KSAo GGwQ2cc545GfWro8Z+FWeS4P22NpUELKEbJRTuUcHGc5H0NZFj44t1127nu7Fl0+6jSMRRH5ogmd hHvyfzoAqa14c1bVfE2ryWNtvjS7aPezqgZ8A7Rk8n2rvNB+y2mn6NHHbszxWoJYqFCtzv6nkg5z 6ZrCk8a+GYIpZYorqeR5TcGFkZVeUgDnnGOAe/I4rK8PePYbMzRaxbSypJO88ckTf6pm6rjupoA0 /CusaTELq30LQdTuXkUNc/cfaBnBGWAHWroeSTXtbliga3leO1XyLnCv905IwcD2OaybHxD4J8Pr dzaXDfXctzgNDIhRQuckBs9M49elV9B8XWKXOrX+s+aZrpo/KjiXPyrnA+g4oAr6/wCINY0TxBe2 lpeGOPer4ADBW2jkZHFczPPNdXEtxO7STTMXd2PLEnJJrT8V39hqniCe/wBOaUxThWIkTbhtoyAP TNZKkAFvSgDe8GbP+EjVWj8wLbTEJj7x2GtbxZpd5q+qaclja5l+wl3RXBWNBI3zFsnjmuW0XVZd D1q31BED+UTuQkjcpGCPyNd2vjPwo05uD9thcxmDARifLJ3YyD2PT6mgA8E2FzpcepW9/ab5Flid EzuVuCQwIOCPQ+1RwmT/AIWlfqo+d45Mjb0/c9KitfHmlFr1p47i2ikeNIYYB8wRQeT25JPHTmqc fiDSIfHc+q+dcfZZoSokCZYMYwp4oA6O50u/kaxSC9ksvLaR5p48ZVMKMAd8nA/oKkVtDsPEFgty Lq/1C62pFJcNvZFPG7PAGcnGATWXN4z0W3Fumni7MbGRboyL87A7drKc8HK9Bilk1/wo2r2eqNJf yXNvgKwj2jAJwTnuMnp1xQBuGELJp8clsEO+5KIOjHyf6/Tt0rA8XoyappGYxEwjHydQv70+/NXh 4z0cvBMkl3uj87d5g3MCyADB68msfxBrWl6lqOl3Vu1w6wn98so+YL5m78TyaAN/xPBLFpOqSSA4 fG3kYGWHX/8AV+JrztFwQO9dn4i8S6He2F/FZtdPcXOCjSx7VAyDtxn261xsRycmgD0jwrDt8PWT JHuyk5aTupy3H+fyrE8ICW5sdRhgGSDGSfz6/wCR9RXTeHBC3hnTZDJI6rFISiHAOCxIPb2z1rmd M1/wnpOnzG2S/eSZhI0LrjJA4TcP4eTz1oA3rJ7Majq8j75Jlito5FAyxAzz14HTnPpzVDV9R0bT /FNnJNpt5LqEcMXkrAy7SSOBjdz1rl7bxVND4nn1t4NyXBKy24fAKEY2g47YGPpW3ceIPBl7qNtq lwt9FcWpGyPyy4YLyAxzzg0AaurXD3dxo6z6Xd6ew1RMvOiKg+U/LlSetZPiq/1LSrO01C3lWGb7 TIoKYYFSvTHPHtVC78aWuqeI9OkaF7XTrafzpdxLM7cjcfTjt9aZ4s8RaJrukRW9mbhJ4LgugeMB WUjqTQA3wxq19rniJf7QnNwYbOYQxlQByvI4H17VD8RAyapYBk8tvsYyn935246nP1qj4R1mz0TV prq8aUI1u8Q8ockn36j6ijxjq9lrd/az2LzNFHb7D5wAcHcTg4+tAHceDTbR+HNGAhMztK7k4AVX 3jqSRk4wce1U9E1bSIdcv10jRNRur6d388KUZdu4liAWHfvXO+EPFUWhJLaX0Es9nI4kXy3w0Tju P0z9K27TXvBelXt3qtlHey3dwpHkmMqg3HLYJPGaANcyCXxDdzfYZ7WT+zIxsuIgX2+YASApx04z mub8YTXseuaT9l3JcJbIIAhUsGLtjkcHOf1qkfFdwPE6a0IMRoPLW2Ehx5WMbN39a3rnX/Bmo3Fp fXceoQXFowMaKm/IB3YJz0zmgDOMPiifX9Hn8RW84t471I03qoVWJyVwp4zVjxdY3Gpadpdta2Z+ 0SXciRwoQS3yrn6dPQYxWZr/AIwbUr21k0+3a1gtZvPVWckvIP4j6cDpW+vjjw7dyQ3d1DcW9xCx lCqrModhhgCD0I/kKAOGu/D2q2M8VvJaPJJMCY/I/eBsdcbfTvVG7tbmxuHt7uB4J0OGR1wRXoVt 8QNKh1ZoUt5YrARFFuNpMpYkEuRnPQY65rmfGGs2Gs6hbtp8Uyw20PlCSY5eXknJ9OvAoA50jikH vTyvrxTSOKAGnGeaaTTyuBTSDmgBB6U44HFMB60ufWgCQGpF5qAGpVY4AoAlH6Ud+eKaOBk9B+tI SSfegBWbinISKZ1P0p6DAz3oAfuJ49KaTk0E4HPemBuaAJcgD3NNLcAU3fnpTTnmgBd/OAadu/So 1Xml6n2oAXfz7Uu3dgmmKvzU5229OgoAkVe/+RSHHU/hUYkJ79aQye9ADmIHvUf40E5prN2/OgBc 88d6fu596iJwPc0gYg5zQBNuB4PSnb8YAHAGTUanqcimBicngelAD2bLUdjn60zqc04tkUALnvin xtgkkjmoiSRScj3NAFsS846+lTKcsKpx5yParUTYXPr3xQBaACjBpw4+lVw/HrUgfI5NAEuSVLE9 acq46dKYrZxSvIEXA5P86AO90nxN4fsdCsLa4uZY7hIHRhHBuAJLdT+NedOVBKI25VOFYjGaaX3H PvSsVVQQSXPUdgKAI2btxUch43E49qVjzUbZY45NACEngetB4GPWnAc018g5PegBDnABB56Um3pT lXJ9u5p+DkjjFADUGe1SjH1xUYHPWnLQBKGBP0pjvnjuaQHAxnPrSYJ5x+NAEbNzxTSelPZOaaRn 8KAAFQM0mQTSYpKAHMQOAaZkdfSg+ppp4oAUtTM+9B4pBmgAI+bFOC560Y+fmplAoAYE7kfSnqtK MM3A4pWx90dKAGM2TgdB0pVpMYpc88UAL04zxS7sUxjQvPNAEmeCc1Hj9afweKcBmgBgGBmlxgY6 0opCw3UAOI+XryaTAApAecUo5PHSgBPpUb5xUh6+lNb5m9hQBEODntS85zTiO3500CgBf6U3pmpd vy9PrSbO5FAERyOaTp71NszTQmTQAzkLj160D0pxXLZpwHPTmgBm0k0pGBnNOKgHjtQ2MUAMHJzz SgZJ9KMjOOgoB4oAkBwPapFfjOeKrjLHJ6U4N0HpQBZWTA6nFSB8kMTVZWJ4Hanq+ByaALW/byaj Z8nOaiYk96QmgCVGA68UjOOtR7+Oabuzz0oAUkd6X0wPwqPPOc09emc0AKOKQrk/yFLwKQfezQAv TAozQQc0oHOaADGOnU0uBilRQcls+2PWjac4oAZUqqMUwLz7U/B6UAMcVGwAqV+tQvknAoAbjJ4p Gp4HH86Y3JoAafWkA96dik9qAGlc0Be9OxRQAw/f5p+7PSmtw1Ln0oAeGCjFJupnWgdaAHFsjNJu xSNwKjzzQBLnPX8aFbJph6daVCKAJhTt/GKhZ8dKTfntQBNu60000HmjPegBwJFSA4GaizSg5NAD +1LjimqcU5WoAay//XpB16UrHNMZsGgCTI6dqQtzTM5HWgHFAEuPl+tNb5U9zSbieKZI27pQAmaV Wx8x60zPFNDYOTQBK7gcenWmM9MJPrzSE0ASFgTwAB1xSEkCmg0E55oAkHAx3NKKjBzx+FPTngUA SKOMkU5QCfQelMLdhSqQPbNAEucU1mGBiml8HkUjNg4BHSgBc5zntTsjGaizkjFKW4oAcMA8mn5q HzPTtQGwMnj60ATgg9evbFOB59arh/zp/mHHGPagCU+gPNL2xUQbHNPVzz+tAEoGMU8D06VBvNSB sAjPNADsfNk0VGXNJvPU0ADnnFRE5pGf0phJ6UAKWNG47QPxpuf0oDY4zw3WgBen40nGfak3At1w KQt6UAKSKXNMpScUAJJ9+kyAPrSzcNUJbJzQBNuwKUcdajU8ZpSfSgBxOajzznFLyRTSDQAE5pVO Kb/kUvTigBS2aVT3pvvSj1NADyxBx3oznvTDmlxjAoAfu7U5SMVGRjAJoJ460ASl80m/9Kb260h9 TQA/fxnuaiLc04cnP5U1jg5/KgB5YBdo696bupv9aAaAJAxx9aDxTQc0pJPSgBO30pOp4pevFLgd KAG7aaeuKkbimYz7UAHUd8UDJpwyBjOAe1IMUAOUDbmnL7nnrTc5xikzjv1oAeTk0ueKjD8euaN/ HvQA/Oe9HQ/WmBsjFKG5A6UAO6UjHHpSbuQMY96CNxOOR2NABn1pc89eaaflwCOKUfzoAcPwNOB/ XtTR096Ut60AOJ4pwPHWo+cA804GgCXdgZ60qknFRZOc04NgCgCTAx7UpOFpnmdSO1Nd80AN7800 sO560Z4phoAWjJNNJ7elLkqCOOfagBDSjNNJFGeP5UAOB4pMnPFIWAphc44FAEtyOagqxcDJqDH5 UAOX0p+MmmIcU7OKAHnAGKjY5OB+NHJpCO2KAEzThxyaaRg0u0nAyKAFHcnr2pByetHU9aQrxxmg BSc/QU5Dxu71Htp6jPPb1oADy1KCM0iryTS5GfSgBScgVo6Doza7ftbrMIYo03ySEZwPQD1rLLfr V/SdXuNEvPtNttYldro4OGHpx/OgC3q2i21lFBcafqCXttNJ5W8DBRuuD+FTr4Ulub/VbO2m8ybT 3jjiUrjzmdwo5zx1qprHiGfVlhQwQ20UJ3LFCuBu9T71fPje4E73MOmWkNzPJHJdSoX/AH5Q5AwT hRkAnFAENz4N1KGzSdWt5ZNspkhSdCw2HDbQD82BycdKYfB+tLsby7fYyM5cXCbUCgFtxzgEBgaL XxTLaWccUen2rXEHmiG5bcWQSEluM4PU4yKtX/ji61CymtTYW0SSo6fIz/LvABwCcAfKMAcCgCrp vhqa58QS6TeGSKSGJ5WECiVmCpuAXkBsjGOe9aU3gfy51jS5uF3xRyCKWEJKu9mGGG7A+7nr0NZc PiKZNWOoyWsUu62+yvFuZQyeWI+oOQcDtVpPG11AYo7eyt4oIAoii3O23DFjliSTksaAIR4O1xXj jMEIeVC+DOvyKF3EtzxwQayp7Oe01BrKYIJlcIQHBXJ/2hxjnrW6PG9ysdvENPttsOejuCDt2/Kc 5T1wOM1h6rqMmr6lPfyxxxPM2SkYwo4A/p19aANH/hENdd0T7Iq73kQF5VVcxkBuSeOSMeueKSLw hrkzRqtkFMqsy75FUEK2w9T13cAd+KsX/jbVNQ0+azkWFFlSFN6AhlMfce7EAn6Cnaj451TUYTGy wxA3Ec6mMEFSgAAHsSoY+9AGZeaDqdjYm8uLby4hCk24uOVckL+JIPFXD4cI1W6sEuNzQWi3Cnbj eSqsF9vvYzUmp+MrnWIjBfWVtJAZml8sblHKhVXg9FxkD1pD4wnCb1061W8eGOCW7G7c8aEYGM4B IUAkDNAEsvgfVoLQPvt/tguJIWtxcJuBVQ2F5+ZuTwOeKqp4Q1uWOGSOCFxL0xOmV+Uv83Py/KCe akt/F0sId2061lm+2S3kMrlswyOADgA4IGOhzVl/Hd3JZPamwtQHQqWDOMExlCQucDgnoOtAEmme BZri2kku2ud6zRRotjEs4dXXIfO4Db9KhuPBF0E22k32udpWiVVUKpIlaPqT/s5qK38XOunpY3Gm QXEMQi2ZlkQ5jBAPykZ68ipH8c38x33FrbSkyea2QQD85fHB45OOOeKAKp8H6yI5ZBHAUhxlxcJt YlS2FOeTgHitWPwFJL4gtdO+3AW89mLprjZwnyjKYz13FR+NQHx7eCWSQ6fa7mjEYJZySACPn5/e df4s9BUcfjrUkBVYbcqZ45iMH+FAu3PocBiPWgCnH4S12eOCZbMMs+0hfMXcgYEgsM/KCAeTV6Tw bdpY28qTxTTXCqyiORDEMuyj5846LmiLx1qMcFvGbe3do0WORm3HzUUFdpXOBkHkjBOBTovGklrH BDbaXZxW9uoVIRuYYBY9Sc5+c80AZEugakmsRaWYUa6mUOgWQFWUjO7d0xgHn2q3H4R1aR9qpbMp KhJBdJslLAlVRs4ZjjoKln8XSz6jDqA062FzEgi3sztujCspU5POQxyetJb+KxbhY49HsRbxSLNb w/PiKVRgPndlj65znAoASLwfrM0SSiO2jDqjYluUUqG4XIJ4yeB71jzRvBNJDKhWSJirr6EdRWnJ 4mu5pBJLFEW2wAnn5vKbcD+J61m3dw15dzXLKA00jOwHQEnJFAEY96XPtTc0meOnFAEgOaXNR570 E+9ADtxB60m7J64pnXvS0AOJphIzTiMcmmnpQAg5b1oJ54o9+lGD09aAE5zxSkH/AOvScdBwKOp9 BQAhHQ+tGO3elPX29KaTzzQBZuO9V+1WrjvVPvzQA4dcU6mBueBS5zQA/PPpQBk+1Mz096XNAC8E 8mkJHT1ppPFJnIoAeDgD86Mn86YCcelKSfWgBc4pdwC9aYf1o7ZoAeGyMD9aYTn6UucLx3ptAC5p w45NMFLnJ4oAdSnikHIyKTk96AFDAE8UA8UmMnFJ3oAcZD0zRnuaTbzRjAzQAoP60uR0puacBQAn Wgmjb82PXmhsA8Dp60AGcmjGDSgYHP1pcYWgBoznIFLjmlPBxScAGgA+lN+op3HcU4YIJ/SgBg7+ 9O4z0pWAVc+tJgADIoATuBzntTsccDmlA9epppz0oAU/KcdaOg9zSYzzikOP60APB4x+dISNvoab uwvPOaO/JoAXIx7+1L7c00dTyfel685OKAAn86XcQu0AYznpzTQf1oB5oAecEdaTIx9KZnJ+tHv6 UAPLhueB3ppOR70ntSZwaAHbsUmetITyOBSjOPegA444xSnJ96QLzQTk0ABJpCeeaUkjvSE896AP /9k= --_004_4A95BA014132FF49AE685FAB4B9F17F657EACE6Ddfweml501mbb_-- From nobody Tue May 31 19:04:53 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FF512D09C for ; Tue, 31 May 2016 19:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIZwvEawwhwd for ; Tue, 31 May 2016 19:04:49 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2323128874 for ; Tue, 31 May 2016 19:04:48 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id o16so5562905ywd.2 for ; Tue, 31 May 2016 19:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PdafmPiwrdW7eR1WCETadKZlVgXglRz1DeZ3h/iM1jE=; b=HBY479OHW/pbSlWqY8cfeHhRgjj7P/x169dZVfWfUDJ4/mL0Iy+pQu5VZjBYtSQ388 OnPEpwbEk0254TYHbpdnCkyLT8pwqyPjsyLD1GArXliVL5t02UYPn4rj/1HzfQuvOeIm 0dCWQrP6kFU95JJZXo+01XgG184hY+IEqcc4/RJU7YPKXzuzSPLOKnMc0kFtgO/Hurf2 gE+TyLWpS2n6xkpnwKul1FKxwF/NGxhti93XQWWFQjNWwCrPYiiGHW/A3aVon7ZqEewb 68ggf0OUZb6eO1nPPtiPl6hhePYNZryXrKQjqi6U5c6UvPh4fIrC6nnQd9BipHYLIZio z3TQ== 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; bh=PdafmPiwrdW7eR1WCETadKZlVgXglRz1DeZ3h/iM1jE=; b=j/RUM0cJOIwx7EHleN7cTctS3P+i7T8vu9NUDodxpmfVcxCuI/7Bz87pDKmvXeXJLO A5Sw6RCg1B3qdvRp2VLTrVxS3ELHx0BN3x/dgVNmyMkYr9GqIhLqtl/c19PPeAvhGFay 2mtfMY6WERIIY1nmUCpPLHOlOHJ/7oijQogykpBZm9yKzmHqY6gCz5uCsIN4tLvV2Fia Hl0Q503k1i9ontx0aMFjpkWjy35lEvSgvc5VvcOHxJgkHSYybrN+0+/ddqhhcJLwSPWA 7XWpXUBxgOzHkWtXs5fbHtavRKPjV5HoAe2Q9+yGL/Huu7pZ7piQ531ILL8O0xsagwL9 AXSw== X-Gm-Message-State: ALyK8tJDlQp3drKCcR44wI6S7ugOfD+khI13lLsfvs9QHr56dlXGogC9gf9CVZvk+JgKVPSYE+OONdfnOfUyjA== MIME-Version: 1.0 X-Received: by 10.129.101.137 with SMTP id z131mr849032ywb.88.1464746687879; Tue, 31 May 2016 19:04:47 -0700 (PDT) Received: by 10.37.115.208 with HTTP; Tue, 31 May 2016 19:04:47 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657EACE6D@dfweml501-mbb> References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local> <20160531195123.GN17462@pfrc.org> <4A95BA014132FF49AE685FAB4B9F17F657EACE6D@dfweml501-mbb> Date: Tue, 31 May 2016 19:04:47 -0700 Message-ID: From: Andy Bierman To: Linda Dunbar Content-Type: multipart/related; boundary=001a114c6d8c04ad2105342dea40 Archived-At: Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , Alia Atlas , Benoit Claise , Jeffrey Haas , Susan Hares Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 02:04:52 -0000 --001a114c6d8c04ad2105342dea40 Content-Type: multipart/alternative; boundary=001a114c6d8c04ad1e05342dea3f --001a114c6d8c04ad1e05342dea3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, If your graphic advice means "the requirements are good enough, move on" then I agree. The datastore framework would be nice to have, but it is very close to the implementation details. It is also attempting to be a superset of all "accepted" implementation choices. By "on the wire" we usually mean a protocol specification. IMO, all that is needed (for editing) is a set of RESTCONF extensions. Some people want to describe the I2RS desired behavior wrt/ how it interacts with the local config. (and many more features...) Perhaps a good first step would be ephemeral data models that do not interact with the local config at all. I2RS is the only protocol of concern and the highest priority client. I2RS just needs to support read/write/notify of ephemeral data. If this is not acceptable then be prepared to wait until all the framework stuff is settled and standardized. Andy On Tue, May 31, 2016 at 4:09 PM, Linda Dunbar wrote: > IETF has been successful for past 20 years in focusing on =E2=80=9COver = the Wire=E2=80=9D > data structure. It would be so much cleaner and straight forward if the > YANG modules developed by I2RS focusing on the =E2=80=9COver the Wire=E2= =80=9D data > structure (and with NETMOD to focus on other aspects). > > The =E2=80=9CI2RS ephemeral State=E2=80=9D has the needed description for= the desired > behavior of the data received over I2RS interface. If we follow the IETF > practice, it is good enough. > > Internal implementation framework is always controversial, hard to > converge, usually ending up with a document (if completed) that is too bi= g > and difficult to read. > > > > Providing some source code to show the internal implementation would be > much more useful as a reference implementation. > > > > The draft-schoenw-netmod-revised-datastores-00 is on the architectural > framework for datastores as they are used by network management protocols= . > IMHO, how data stores are used are internal to the end points. > > > > [image: > http://www.urbanblisslife.com/wp-content/uploads/2012/10/Done-is-Better-T= han-Perfect.jpg] > > > > > Linda Dunbar > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, May 31, 2016 4:09 PM > *To:* Jeffrey Haas > *Cc:* Benoit Claise; i2rs@ietf.org; Juergen Schoenwaelder; Susan Hares; > Alia Atlas > *Subject:* Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - > 11:00am - Topic: Ephemeral State Requirements > > > > Hi, > > > > I am not convinced the IETF can be forced to function as if it were > > a dev-group in some corporation. This is a volunteer organization so > > usually solution proposals come from people who have created a solution > > and they want the WG to standardize it. > > > > > > Andy > > > > > > On Tue, May 31, 2016 at 12:51 PM, Jeffrey Haas wrote: > > Andy, > > On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote: > > At some point the WG needs to agree on normative text instead of > iterating > > on requirements forever. > > IMO, it would be in I2RS's best interests if netconf/netmod provided draf= ts > in appropriately normative language covering I2RS requirements. However, > we've been in a pathological cycle of: > "We don't understand, please give us requirements" > "We don't understand your requirements" > "You provided examples with your requirements that appear to be attempts = to > change our protocol - don't do that." > > The most recent revised-datastore draft would be a good place to document > where netmod(/netconf) believes ephemeral datastores (if that's the > instantiation) could live, and also how ephemeral configuration state cou= ld > interact with candidate, startup and running configuration. > > yang-push covers much of our desired pub-sub behavior. (Yay!) > > Discussion is required for how to tag security considerations impacting > transport into the yang model, in particular for notification. > > Proposals for secondary identity and priority are also needed. > > -- Jeff > > > --001a114c6d8c04ad1e05342dea3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

If your graphic advice means "= the requirements are good enough, move on"
then I agree.

The datastore framework would be nice to have, but it= is very close
to the implementation details.=C2=A0 It is also at= tempting to be a superset of all
"accepted" implementat= ion choices.

By "on the wire" we usually= mean a protocol specification.
IMO, all that is needed (for edit= ing) is a set of RESTCONF extensions.
Some people want to describ= e the I2RS desired behavior wrt/ how it
interacts with the local = config. (and many more features...)

Perhaps a good= first step would be ephemeral data models that do not
interact w= ith the local config at all.=C2=A0 I2RS is the only protocol of concern and= the
highest priority client.=C2=A0 I2RS just needs to support re= ad/write/notify of ephemeral data.
If this is not acceptable then= be prepared to wait until all the framework stuff is settled
and= standardized.


Andy

<= /div>



On Tue, May 31, 2016 at 4:09 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

IETF has been successful for past 20 years= =C2=A0in focusing on =E2=80=9COver the Wire=E2=80=9D data structure.=C2=A0= It would be so much cleaner and straight forward if the YANG modules devel= oped by I2RS =C2=A0focusing on the =E2=80=9COver the Wire=E2=80=9D data structure = (and with NETMOD to focus on other aspects).

The =E2=80=9CI2RS ephemeral State=E2=80=9D= has the needed description for the desired behavior =C2=A0of the data rece= ived over I2RS interface. If we follow the IETF practice, =C2=A0it is good = enough.

Internal implementation framework is alway= s controversial, hard to converge, usually ending up with a document (if co= mpleted) that is too big and difficult to read.

=C2=A0

Providing some source code to show the int= ernal implementation would be much more useful as a reference implementatio= n.

=C2=A0

The draft-schoenw-netmod-revised-dat= astores-00 is on the architectural framework for datastores as they a= re used by network management protocols. IMHO, how data stores are used are= internal to the end points.

=C2=A0

=C2=A0

Linda Dunbar

=C2=A0

From: i2rs [ma= ilto:i2rs-bounce= s@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, May 31, 2016 4:09 PM
To: Jeffrey Haas
Cc: Benoit Claise; i2rs@ietf.org; Juergen Schoenwaelder; Susan Hares; Alia Atlas
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - = 11:00am - Topic: Ephemeral State Requirements

=C2=A0

Hi,

=C2=A0

I am not convinced the IETF can be forced to functio= n as if it were

a dev-group in some corporation.=C2=A0 This is a vol= unteer organization so

usually solution proposals come from people who have= created a solution

and they want the WG to standardize it.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

On Tue, May 31, 2016 at 12:51 PM, Jeffrey Haas <<= a href=3D"mailto:jhaas@pfrc.org" target=3D"_blank">jhaas@pfrc.org> w= rote:

Andy,

On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote:
> At some point the WG needs to agree on normative text instead of itera= ting
> on requirements forever.

IMO, it would be in I2RS's best interests if netconf/netmod provided dr= afts
in appropriately normative language covering I2RS requirements.=C2=A0 Howev= er,
we've been in a pathological cycle of:
"We don't understand, please give us requirements"
"We don't understand your requirements"
"You provided examples with your requirements that appear to be attemp= ts to
change our protocol - don't do that."

The most recent revised-datastore draft would be a good place to document where netmod(/netconf) believes ephemeral datastores (if that's the
instantiation) could live, and also how ephemeral configuration state could=
interact with candidate, startup and running configuration.

yang-push covers much of our desired pub-sub behavior. (Yay!)

Discussion is required for how to tag security considerations impacting
transport into the yang model, in particular for notification.

Proposals for secondary identity and priority are also needed.

-- Jeff

=C2=A0


--001a114c6d8c04ad1e05342dea3f-- --001a114c6d8c04ad2105342dea40 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 18b6caaab687f54b_0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAIuAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDzPgDA OaU8dRzTenfil96ADNKAaAOOcU7NACDvijGKd26jNGB9aAG+w4zSYOfSnkHGe1JtHWgBoXvzx1pc ZGacRjnrTSKAEwc8UYH40oGPenAUACgE0YwMCn/hTT/kUAN/ClA7nH1oAz9KdtGMUAIR64FJgdO3 sKUgn60cDpQA3/I9qXjHJOad0pOvagBuPfH1pvPWnE9u1JQAmMCjJJznrSkHGf1ppz/kUAHfPSkx Sj3FKF9eMetADe5o+ozSkAck0oHFACdDkfrSHPQCpMf/AFvrTcAA+vtQA3HH9aTHHsKdjGATik/H igBCB16ZpeBxQMevNKRk5/nQADP0/Cjv1/SkINKB70AJ/Km+lPOMdaY1ADTilPI4o4A6Uh5NAB+H /wBagdD70bcGlC4HSgBpoxxzSt79aaB3oAKUYNHf0o6UAOOO9IPekxmnAZ96ADHvRTtuKMUAIOlL n8qCMijn0oAOnNTQk4wTUFSwd6AI+lOUHOOTSDryM/Wl5yetADhgMMjIpRzzScU4AfhQAcUY4FHA pwGPpQAY7H9aQcAnvS9uehoPHNACFQD1B46g0mAccUtJ7jpQAY9/xpePUCkI/wDr0Zx3470AKCTQ fboKb35pwycYFADgB2H4UYI46UZwOKTNAATg4/KjPajHXjmk5/GgBT7UjHjFAPTikxnt+NABj1pD 9P1peOopPzFABg4+lJjvSgYHHb1oOD/9agBvU5p2cY65pOCeKOpPPSgAH3uaOc80in16UE5FADg2 CaTO5sZpOnBox7cfSgA7fWk4pwpMZHT8aAEx7UHrk08D/wCvSY5oAOnamnH4079aYSeuKAF9vSms MHApwzjmmetAAemBSqMc0g68/hQTQAvUn0pODyaTOTjpSEkkA8UAB5APrSDkUpP5UhycUAKPUUnp RgntS4OeaAAcmnDikxzS9aAF70tJinKOOaAExRingDvSEYFADB1qSPAyKZ0p0fU9KAGqBT8+/FID nFLj8PegBQOMA04DnOOtA5PXHrS9T7UAIOn0oP8AKl9fWkwSaAFAOfejHUGnFW5yaQDnjjmgBCAe 4AApCP8AIpepFIeTQAhHHAOKD9BmlJ9OlBAzkAc0AIACP/rdacOxHHpSdPalyNox19KAF6c03rQT R0PvQAvHbP1pueen50ZFHfPrQAYz2+tBOBRnHFA5OOOKAE7ZpcA04jHemFsd8E0AKcL0pMZ5zRn3 /Ck3Z5/KgBcYGSKbjOMnpS7iTR7elABjjFABXnjFB7UtADDzyTS84xnj0pcdxRigAAGBTgKAOad3 FACkAL0pmKkbpjpTfy4oAQjt2ph6/wAqkI45qMigBADg8Uw8808nIwKTGetAEZpDxT2FMA9aAFC+ 9IFyafjsKMcUAMC5+lLjJ6dKcFOKApxgUANAyc9akCY5xk/ShRgc0bj0FACke2M0nQ4pck0AE0AJ jkCne3alHWlxQA32FGKfjAoIwKAIiKRRz0pxHNJigBQM072707+HGB60qD5sYzQAgB+uaeMHrS/h zS7cDjoKAG7fbrS7No5HNPAPb8aRsdaAGsCTjNM788U8jIHNIR2zQA+0t2u7uC1VwjTyLGGboNxx n9a6yP4a6pLNJFHe2rtGSCQGxxnvj2rmdPkS11O1uJOEhnjkb6BgT/Kuzvtct9W8a6LFp10WskmV zgFQZC5JJB7gYxQBRj+GmpyxuyX1qSoDAEN8wJ9cfU/hWXrXhW50Kxhu5ru3nE8hQJFklTjPNdT4 uXyfC811DLLukvIlV9/JxvPBHv8A5FR2nia21B/DqGUT6iLnNzmLJ+4V78Me9AHn3G4DmkJwK9I8 YWmoaxo1nDBpzzzi5YrKqY2pt6E4GOcdf1rg9S0XVNKkRdQsprbf91nX5W+h6GgCkTmk4Puav6Zo WqaxuGm2E1zsOGKDhfqasX/hLX9Nt2nu9LmSJBlnGGCj1ODwPegDH747+lSRQzTkpDE8hHJCKSR+ VRZwc11Xw6d18QyhJCmbV8ndgADHXPagDmpree3IWeCSIsMgOpXI9RmkT5frXYfEA3Gp+JrG2gR7 iQ2qJEqqdzkknp+NYN74b1rTbZrm9sJIIVIBkbGBk9KAMw8jNNwSxrU03w9q+sxmTTtPmuI1O0uo +UH0yeKfqPhjXNJtzLe6bNFEv334YJ9cdPxoAyTwOlMwM9a1rXw7rN9bx3FppV1cQy5CPFGWBwcH ke9Q2Wj6jqMsyWdpJM8H+sVRynOOfxoAzyCPrTgAeRU17ZXWn3jWt5C0Ey4JRuoB6GruhaFe69qK 2tnbPMqFWn2EAohYAnmgCh5E5t/tPlOYC2wS7Tt3emfWm84wPxr07xRoM99oNrpeg2KSLZ3BLRQn pkYyScAnI5PrXnmo6deaVevZX0DQ3CY3RkgkZ6dKAKZ6dqOfatv/AIQvxK0Hn/2NcCPGckDp6461 k3FrPaXDQXUEkEyfejkUqw/A0AMHA6iheT06Upz0q5p2k6hqsnk6fZy3D99i5C/U9BQBSz3pQD35 FbN34N8RWELS3GkzrGmSzLhsfkTVfT9E1LVIXlsLOSeONtrMo4UnnBoAz2BIqNuuK0joupNqcmmL ZyG8iBLw/wASgDJ/Sor/AEi+0uSOO+tngeRdyhu46UAUAn4CnFcL1roIfBPiOeJZY9In2kZG7C5H ryazNQ0y+0qYQ39pJbuy7lDjG4eoPcUAUCo9O1NxW1Y+E/EGq263Nlpc0sDDKScBW+marap4f1bR lR9QsJYEclVdhlSR1GRxmgDNHH1pw56dK0dL8O6xrMbPp+ny3CqcF1HyqeOCTx3qTUPDGvaTAZ73 TJool+8+AwX646UAZgAowAKnsNPvNUuVtbC2luJm52Rrk49fateXwP4nhjaV9GnKqMnbhj+QNAGC 3TFM/GpkgllnWFIneVm2iNVJYn0x61tr4E8TvGJBo8+D0BKg/lmgDnwO9SBT6VJPaT2Vy0FzDJDM h+ZHXBB+lCjPbr3oAQDig1Jt9s00jnFADccYpCMn2qXHGBSbe1AEJHpxTG6+lTMPSo2GPegBQckj 1pwbH8s00e1PIA4oAcvJp+BnjmmAY4qVBwfX+VACZIPFNIyc4HWpMdqTGTQAzaSeaXHNOA55o464 70ANIGOa0/C67vE+mg5/4+E6fWs08k8ZzWr4WIHirTOSB9pTOPrQB1fjDDeF57aJEGy7ichSNxOH ycfT15rkvCDxR+LNNMygoZ8dcAHBwc+1dn44Eq+FJmwqwm7iCqqkdn5yev8AngVx/g2LzfGGmKCf 9dn5Rk8A0Adf4s1PVPDGj2X2S+/fS3Bd2Pz7AFGF/Hv+VWNdv1utGv7Ly/OgazM4DD7rFA4Yf3cH 04xxWb8RIHHh2yZbaWKNbxlJc5wSn9fy+tbOsWUseh6jH9iZY4LDEk7kjc3lADA7nnr+tAF3Q9Pv NK0GCw09UX/QTIzjhpJXjJz7YJUfgKq+GdE1210QQa0rfa4pisayMJWKsO/JyM5GD61Ho7zeKPDT XFq+66exe3k3S/6lwu0YGeAeDWR4c8IXsVjdXHiKO4ilSVVjeS+ePYmDuOQcY6UAcR4ksk0/xJqN pGuxIrh1Vf7ozwK1PAIeTXZVTqLWTncRjp6Vja1Naz61eSWO77KZmMO8kkrn1PNb3w6tzca5dZRp EFm+5BgFuRxzxQB3UWiJ/aMeqN/pExt0giZRhYefmLP0BIOMj9K4Hxprz6lqI0u3kY2lnIUGRgyy ZwWIH5D2HvXcXmtbfE9poFwCkNxbIbdbgk+VNkgZ5yQRxjPpXN+OtAmSUa1bxN5kZC3hC8bh0fgA Dngj2BoA7M6dqen6BcaLpMMa+VZmGMKdrmRgMvnsc5/Tmo/D2g6nHolvDrCM96C0TxufMLRls/Me Qfl45/wqvi48UeG7y+09t9xe2g3N5pDRS5HydeMlePr1rK8O+F2ttKa+8SpcQSxznc8l68ZWJQD0 Bwc88d6ALfhq0NlbwQIrStFdzRwrvwBtf+7nk/Wuf8EIZr7XVDlHMYIG7b/Gc5NdB4MlttT04HT0 ldLS/lkMJY52MQyswzz04PYiqnhjw1qOnatrsuo2EgtyuE2sNspL5BBz6c/yoA5jxvH5fiZgTv8A 9Gh+bH3vk61m6JNPBrNl9mlkid7iNT5TlSw3Dg47VrfEBt3ixiQ64tYeGPI+SsKxmEF/bTHICTIx wcHAIPWgDvfGs15YaNvtryaEvfEERSsuBt9Qc/gawfBSLfeJJNQ1CUTNZwNP++bPmOMKmSfcj8q7 rU/D8WpQWkPkrLYi8W4kcS482IggNn64zjHWqEsWm6Brtin2eLTpdRjeB1hfbsQ7SrN6fMMZ7jNA DfEviK/tNd8OxyzTBX3Ge3TKCRXcqMjvxVTx3pccmlG9kcfa7KRYwAclomJxu989PrV7X/CWo3+s 6FcxWm22hASUo4+QBy4OeeCOnWsnx/qFvbRSaVCSbmaUST4fcFUE7QT655NAHBgZOK9V8G3os/CF u1r9yR3S4bjKvk8n3xtxn0rywDAzXovg6xtX0BLzT/tSXbo8c7RTEgSA/JuToVPHGPWgDX0SK/sN LWC/ae+NtM0qXFu2+Roz0XaTkc+xHOKxfCEguYtUuVhEccmpbo4DJsCtgkA+uP6VueH28W3Nld/2 1YRwvGUMVwUVWznJPHGMc5NVdFmtNW1LXLfT3Mr/AGlJPlOPPG3a5wMBhkZ/HNAGJp0SzfFDUjIG iceeVGcEME9j/WtafT4pfE+lT3RjkisrB5zu6MwdgoJ74YinWfhzUV+It/qUtk4spI5ZA4K4cMmN vJ9eOadqmojTfFGjxyiW1t7qxe3YsxDR5kODn2IH4GgCHxN4q1HStQ0N5ndYSHe5RFx5se7GCv0z +dZuqajpPiq80jRLSSR0a63zSvHt2r3VcnPQdKveMfCmq6mNKksbESRwoyShG6AtkNnPQjNQa5Bo fgua0ubeyC6il0rIqzs+Ih94nJ4znj/61AGh4r1+9sPC5lsJPskf2qNLVoRgbV3HAPcYA/LFYniL xlpOq+H7m2t1la7vdo8tosCI5BLZz147dc1ueJ/D93rnhY/2RD9rzcrcRv5gZpV2kHnPUZGelZOo +G9E8P8AhcXeo2GzUDbAR/6QxYznH8PTAwc9qAOri0zULDw9c6TpKonlaeY4Sp2u8rAZbPYlievt zVfw9oWrQ6Fb2+tRlrtS0RjciQtEWyN3JyMZHNQRpc+KPDF1e6exee7s8HM3zRSgj5OvGSvH161m eH/Cctrpcl54kjuIZ0mPzSXzxlYgAT0ODznA70AS+DHj0Oy1cWcaPc2968cqk9Iwflz6DqM9M1e0 y3v4xex3c0l7by3JubeRH/eRDuuwke33cjisfwXbaTc/bL+0S7WdLpwxhuGVxbt93jPPf1zxWz4f bxhPe31tq9hFLbJG/l3LRKDuzhSMdRjsaAMXw5exXXxF1e8jtTDc+WxhikXD5BG447MVBP51trJq V14hOoGUSWs0HkT2Yk27Gzw65wDzzzg9RWM8elar47nglaSe9htlCSRS7C0ynkBlIydvH4VrLL4s TxNbw2Vm17pMroHNyisUB+/lz82cgnP0oA5H4g3CSalaWv2WeJ7aDaZJ02s+T29VHrXLL0967v4k SRpBbWkzD7WszukYx+6i9PUZPY/WuEUe/SgBzNgdqap56UjHnikAoAeDjmlJ7dzTR1+lIcCgBCaj bJNPb9KjPBoAkQDrT8c5pEHHXmpE6+1ADQOc1KuTgDrTPp19akU4H160AB5JHUUAYHpSkYGTSKCa AEPH40mcjmlb1HOKci55oAZiljlkgmWWF2jdDlWU4INO2k5PemFCDzigC1e6xqd/EY7vULidGYMU kckZ7HFU7e4ns7hJ7aRopYzlXU4IpzL8vXmkEY5Ynj+dAElzqWoXFqLa4vZ5oQ+8I7lhuxjPPtTn 1nVplKSaldyAjbtaZiMelQ7MkcUBT1/KgBIJ7mzk862nkgk/vxsVP6Ut5qepXyLFeahcXCjkLLKW A/A01/wxUB6knqaAGlegFWLe6uLFi9rPJC5BUmNiDg9qgBGcnrStk9f1oAmnu7m7dZLm4kmkQYDu xJA69afLfXkqv5t1PJ5gAfdITuA6A1BGpJx6UjjccYoAfb313YsZLO6lt3bq0TlSfypLvUdQ1DaL 29uLkJ90SyFsfnUZRtuffFCIO9AHfeALXR59PMj2jSahDKwkZbho5DGRwVCsCcEHjB61qeG/Dvim 31C/fU5pZIPIaKFpJy4GWGCADxwO/SvM1d4XWWJ3jdfuspwQfrVx9Y1iZGjm1a+dGGCrXDkH6jNA FvxhLFP4ovPIk82OHbCJAwYNtUAnI4POelYw9+1OMeD97gelGB2oAsw6vqdtGIoNQuYowMBUlIGP TFQXE81zK0txK80r/ekkYkn6k1GeuB0oHvQBdg1fU7e38mPUrqOLGAiysAPwzVTBZzzksc5PWkAO Rx9PenqD97vQAFfmx2FTWl5cWM3n2lxJBIOjRsVNRBW20eWaAL15r+r38RjutSuplf8AgaQ4P4VS hmlt5lkt5XidPuuhII/Gjb379BQEx9aALz61qr436ndsV6Zmaq1xeXd3tNzcSz7eE8xi2Ppmo9p6 c04rtA5I/pQBJDq+qWkQgt9RuoYx/AkzAD8KpPudi7szOxyWY5JqXb+fWmsAW4oAktNRvrFGFnez 2ynqsUpXP5VFdXNzeS+ddTyTyHjfIxY/rTH9MYxSbc5yenrQA+1u7qylMtpcy27ngtE5U/pU91qV /qAUXd7cXAX7olkLY/OqyJlgAalCcUAJDPNbyLLBK8UinhkJBH41dufEet3URjn1a7kjbOVMpGfr jrVJkPI9e9NMbfhQAxcj5hkEHIPetSPxLrohEI1i8EYGABKeB9azSvPXNSooUZxzQANvlcvIzOzH JZjkk/WkKkdOtO3DPA4FGQBkd6AI8EEdfrTiuKUEZFBbj0oAacdOlIMZ57Ubufam7sUAK2PwqJhk 08t2qNjigCccDFOVsHCimdSB3qQKFA45oAaCc4AqaMZ57VECMcHvU4PygCgBGBI/lTwAq/UYprMA oA60dSADQAKuW9u9S7cDAXrSKQPrTlZn69KAGldp5qMnqc/hT3PJyePWomPb09KANfwvZ6fqHiC3 tdTcC3k3ZG/Zk4O0ZHTJxWt480jT9KFs8EcNrcuxBtoZC22MAYZgeh/nWb4HaM+KIRNDDNG0UuVn Xcp+Qnp+FbninSbO71fSLaKzjsmupnjkKjaWHGCfTjp1oA4UNxywWlJGOD+NetXt1p2hWtpFpWjw SQRTrHeZh3sqEffz1P19qw/Hljpf9jver9lSfzlW3eDaPNXuCF6juDQB54wyaibBPWpAflxnmvR/ BnlPolik1lbTxmSVZd8ILFc5Iyepwe2OlAHmgC5607GOcdK9R8OanousWF6raFZwQWcgDLIoYSI2 QMED5WBHWsmHwtpr+MlCJL/ZcUC3bxtyQCcBM9wT+lAHEptAx/EafHbvNNHChAeRggz0yTivVr3V NMg1jT9Ej0myjgvYAzNJAAYyScDA9ccj3rKu4j4c1q31jTbC2FreSC3khkQssLFuqjPGR0/GgDL8 UeG7LQPC9qqAy3TXJ864dME/L0U/3a45VGc5yO9ep69rt3o1hLd/ZILl5LvZ/pSl14B7Z6/4151q +qy6vqMl9LHDC0mP3cK7VXHoKAKgU7vX6igHPcelW9LkMWp2cgPKToRnkfeFej61qVnpdjPqF/pM F28VyEgUgKQTnd+g/XrQB5USD0ORTN2O2PrXqOt6TpGu6VG0UEVtdy25ubV1UK2NpbY4HDZx26VX 8BaPptjpsGoanaC4nvh5iKyBxHEDwcHuSCc/SgDzQEHuPwqXbgbtuQOp7V6boOoDxbY3ZudKs9lv MVZEgGChB2++7tkVD4Zs4tG1HXbCa3jmtoWidTNtztO4gk9+D+dAHnW4A9hXaeCvDtpf2zX93brc /vfLSN1JRQBkkgdTyOK626WyuZ5TptvaROspjl/dpndwQx3diMnB9KSDU/7VmxawxC3hvmjUQDar 7QvzcHBPX8KAMPxboOif2CNY0+0htF8tDC0L/LKS2GUr2YZ/SuALBTzgVqa7q15r1/GkkcMZhJij jhXapy3HHrXffZtP8J+GLz7Pp0VxfWka+ZPcRAgykgEeuBn9KAPK0w3Qj8KHwASTgV6munQeLPD8 FzJYwwG4ixG8MQUpICRwf7uRyD6/SqHgXRLGKGK+1C1FzJdzeXAjKGUIrAFsH37+1AHnKsM/eBre 8JaCmvai3nystvblTIFXLOSeAPT3PpXd6fq2n+IBd2j6bYxSW1w0LI0aYkjyQG55HTH1NU9N1JQu o6RYRwi0spQkciDDSISeGYHDAdM0AcR4oit7bxLqEUEaQosuEjQYAGB2rpvBnh3SNR0BrmSCG5vP MdZvOlZVhQdDx0yMnPrUXiHxfdQX1/pS6bYiPb5XmvETKowP4ievvWj4Lt7O58MxLPpdtdH7Q6ln jy23I6n0oA891S2toNUuorOXzbeOVlicHIZc8c96pggvgEcV33hnRLA6rqOo3tqJba1naGCALuVn JPY9QB/MVuPqelah4gv9IbSdPEFrGJIN0PzSnA3Lx9ePpQB5SPlxk4+tSAgDJP4131hoqaL4gu/K gje1urTzrdZU3lMSKCvtjJ/DHWr7alpUXiu20x9DtvtF3Agkn2qArsvynGPu9M/XpQB5jigpgf55 rt/GmmaU9m2oWMC29xFIscqxDEb5zzj+E8fjXGhR+H8qAK4TGSKceBwMVI7BTwOTTGPG3vQAwjP3 e9DEgdaeBtUgjntTWHIGM0AMGfWlJzRt5xSkAcUAM5pOtLnFJ04oAa2cVE3BqU896iNAEqv+JNO3 HP6VEGOOlOViO1AEoPQVMvUd6rjPpU8ec+woAcRwM/nSgjpTW+7nvQpx9TQBIG/SnqwVTjqarljS o3HWgBztxio2B9ad/EQeaaWwpGaANzwWHbxPAsezPlS5L8ADy2ya3vEVoLrUtCt7O9SJ5LmRVuWU ja/ynJzyef8ACuT0TVm0XURepbRXHyNGY5c4IYYPSreteKrvWhZiSCK3ayYtC0OQVyQcfgRQB3Go 69H4fW2utTtluGuGKNNZOyYZcZJVuhOc4zjvSeKrTTtY0B7pYOVtRcxXTgI44+7j+LPQg+oxXOW3 xAuRDs1DS7G9c4/eOgGce2Mf/rNUfEPjHUvEMS28qw29sMEQQLtUkdCT7elAHOKvGR1r1LwMpPhy wZpURPMm/dk4MmD7c4/SvLGJxgZrq9F8c3WiWFlZpYW0yWrFsyjkknPHp6UAWfA8UU41rzXWONVj Jbngb27f5xW9bTwtr01lD8zXGnwvDyy7grHd7k4JPJ5xzXD6R4ln0aS7eGytZRdOHZJFOEwTjHPQ ZpNW8V6jqeswax+7truFFRGhHAx7H60AdTrMUsvj7QVg2ktDFtJG1cKTnp06GpfFd95MljFNLG0l xepIE5wkaN3Hbk/z+tZS/E/VzGpexsHnQcT+WQwOAOg6dOg4rl77Ur3U71727mMs74JYjGMdMAdM UAei+J9NuNUs7XT5LhVnm1JYyxU7YgQeR7dewzXH+I/DUWi20F3a3r3MEjmM+ZHtYNjOR2K1etvi TrFvbRxSW1tO0aBRIwIZiOjHHf3rH1zxFf8AiK5je72RxxDEUMQwiep9yfU0AQaQrPrFkqpvLXEY C9Nx3Diu7+IMYj0B90yyst6OVOdgw3Hp7cAVxWhsE17TwUEn+kxjbjr8wr0fxdrL6VpklxDaWk4k uwkkU8QZX4PXNAFXTIEttBsLxmHmWumhnUgjaArZJPTPPv8AhV3w1qX2nw/pT24iEcVn5TDDMxlR cYPIxyFx9a4rWfGmpazaNa+VBaQSriVIE/1g7Ak9h2AqroPifUvDm4Wbo0LnLQSLlScYyD1B9xQB 1GgeI/EPiI3SrLp9oloFeQfZHIkJJABw3tV2KKWfW9eju7iN5z9m3S26FU+63y7fx5/CsGb4iam0 cgtbKys5JcbpYo+T74PGeetUdF8XXeiLemK3iupbqRZHecbuRnJ+pzQAzxiiw+LL9Iy2N4yCec7R nNdd4Di/4p+1YyCJTeScbsGT7vTHP9K4bWtWl13UpNQmt4YJJFAZYRgEgYzWno3i+70bTobOKytZ EhlMgZ1O4k/196AMhJo7bXlnkX93FdbmX2DV6frmtXmn6RqF9bLBIxKOilGZPLYjnk+mPoa8nceZ K74wWYn866TR/G2raTZCyKwXVqBtVJ0yQPTPcexoA6vQdV8Q6tZW+o/bNOt0eRo0ia1fCY6kHOKj 8KTJcaVpzq6EQSNHJnJ2vvzwucDgjB61zOqeN9VvrI2USQWFsylWjtlxuB7c9B9Kz9B8Rah4fmZr KRQjnMkcihlbHT6fUUAS6V4bk1i+vYvtItmtySxkQsT82McV0nh/S30i81bTob2OVoRC7yIhyAfQ e2cHkVnXPxF1SZH+zWlnZyv96aKPLn8+p+tYmma3faTqf9owSbpXJ8wSDKy56hvXnmgDo77w1FrH iDVbue7a3jWdI1WOPc7koDnB6itLQdOGn2As7ydAIb9kBAJEmCOo/EcH8jWFL8RtV8jYlnaLJt2i TaSQf72CcZFQaX441HTLSKP7JbzzRTPKLiXJclzls/WgDe8PSRyW2pWoCh7bUZJJAckBGwAduQDy vfpVSyEo+JmqtGAdqSsS6nG07cHHvkYrmbTW7+w1mbVLJkglmcsybQykE52kHqM1tXHxG1eRWaG0 sra4ZdpnSPLY/H6/hQB0cU7vr0tobiMyx6e0kk7HIUtKhA59h0/LFYWuKH+JOlxKVJ22437j8xx1 JJz+tYWj+I7rRrq9uVjS5lvE2uZecncGJP5GpbzxRPe63Y6uLK2ins0VFVVO1tueSPxoA6LxFZpP pE1lYkTXEt5EmApGCWOBnp1Pt64rn9Y8J3ui2TXElzbTtGwWeOFiWjJJA6jkcdanvPG2oXtilnHb W1pHDOlxEYVIKspz/Wo9d8Y3+tWItHgt4Ii2+URrzIw7knp9KAOcGckk9KafXjNPBxwPzpnIoAB1 9cUuOOOaPugetNDEEEcnpQApHHOKaQMdaUtxxx+NNJ445JoAYelJz704/e9aGxtoAYePrTDwKe20 gAZzTG5NACZyc09fT0qNc09WJ4FAEoOOe1ShgDnBAPQVXBJPNLvyRzmgC1kkFjzSKcn1pN2Iz7Uw OMdPqc0APPzHNOQDPpUYbApyMOmaAJNuTxx2qNxzjtUm4VE33s9z6UAIpxjPamsxHPqeeOK67wLZ Wl218LuziuQixlRJHuxyc49Kg8TaM0/iuOw0zT0iaS3iYQxAhQSuSTnp9TQBzKDLe1ObPbkn2ra8 Q6F/wj95FZmbznaBJJDjADHOQPasdV/OgBoX04xSMeM5zV/SdLm1jVbfToHVHnbaHbJC9yeK0/EP hI6JbLcxXRuIRIIZC0Rjw+CeM9RxQBzPU0wBs8mp2GB6ZqLGTxQA4HJAH40/GDxjNNHyAnHJpFz1 oAaxyeOgpQcD3+tIfx9uaAMjH8qALWm3rafqttfhFkNvKsuwnAbBzW9rfji48Q2T2tzptrEnmiSN otwKH8+fxrmiFwcjk9z2pyKWOSCQP1oAXJJwetTRpuBYin2tus93DBI3liSRULgZ25OM4711Wv8A hCLQ9Ie8j1H7QY5ljMZi25znn9KAOSbAbaPxpcBQffrTcgtk8+ldHoHhNtY02XUri6MFrGxRVjiM juwA6Y+tAHPL82DzzT3YAYXOR1qxqenyaVqU9jM6s9u+0sowG79O1VSNxzkUAOUe/vUcjnsetPC7 V6/gKb5ZPUcmgBqnceeamA+UADmmIuCOMelSEbRk5zQAnHHenAEk9T9aanK9OaeZf3SoFA5znHJ/ GgCu5ycDHFSAbgDxgU0jH1p65HbnHFABghulNYbRjGKkUhmJJOKgmkJJOeKAGs3YHA+lOAwOv4el NQ8jdjGeRnrS5zkL60AKTtO3OPpQVJGMjnk8UwYL+op6kr159KAHFMLmkYevHrgUgYE5IyP50u4E 9/pQBE4Ocen6U3AwCetKx+b/ADzSA5yfWgBG5GBSAYpx4ppOc4P40AIeCcd6Y5z0pd2e+aaTn6Cg Bh9KbketK2SfrTD14PNADt35mnLUY57mnK3OT2oAkYgADufemrwc0nXLHmlAoAs9QaiJxx+tPUjH HWo9vzYoAUmnKT0zRt/SlCdzxQA8DIyaMHGeD6U5OlPUbuaAOo8Bs6NqIVd3yRkHBIBBOM4+v0rq o5NJ/wCEjkmkW6k1b+zlPzriJk2DqAcg+1c/4BVW/tNDwdkbZyezH8O9X5CB8QJd0Zk/4lajYoyC Sg/Ie9AB4hfwtNdwPrZvTdNbgg2igIRk479a8/fAkITIUn5QewrtPFekXuqa/bw2dszOtijsGIAj G5gCzZx6c561yN5Y3FhdyW15EYZkxuU/ofcUAXfCkCT+KrCN5poB5nEkBG4HBwRmuk8dw3l2umxr qct2ks3lR25hWNUbgA4Xuc8/0rnfCuE8TWB+b/WcFQSeh9K6TxYL23TS5Utz9oW73RRKuAxAGB6k 57980AOm8FeHNG0+1l1u+uJZbiVYcwsFRGPt6e5rO8TeCrPTLO5u9Oe4UWzYkiuCCSM4yCPT0rpr mTTrw79YP2OK6Pz2+oRsmXB4Ct0JHPIPHcUzxhpklxoTR22pOFWMTrAZBIs6rnnf14A7+lAHlTDA Hc12Pg/wno+t6ULrUbieNzcGICNwMgY6DGT1rjyeCwH0r0T4fW3n6Lbor7XN6xY47AKf5/SgCta+ E/CN89zBa6hczy2shWVlbaVUZBODwQD3/wAajHhHwrpTQRarrM08t0x8oovloFzjk84Pv0ql4HZz rmoqkRaVoTiPkgnzAcHFS+M45V1bTBM+X8nJwoQL+9boOwoAl17wLb2liLzSppHdXWOS3mIJO47Q VP16g1cuvBOh+H9Njutc1G53SOsW2BQVViOffArpPEFtLNp90trva8laLyyWwVbcMN+Hqay9TSxs 9LS58RalfassMnyrKPkaXHRV4yMdcn8OaAMfUvCNrpywXmnXzzmGWNpYnAJCkrypHXqM+xrX8deb f2H2WCNWka/VEjH3icMMk59fwrS1GSKTTL+4Fu0cc8URDY4+YpgDpjGQPp3q86xRyv5gW3lNyRBJ syxfDfcJ4BIyOnWgDjbjwn4f07TJbm9ubpmgjUuUdQJHP8Kj0J/kc1b8BL5eh3E8Woz2rfaSuPKR 0HyjDDPQ8/8A1qpePUuntbN42YWcRKyxZJKSnoz+5HbtzVjwUsraBMsCbm+1NnKbguUXnHTNAEVp 4f06/ur+XVbi9nmjvmhMwYKXGM7j71YtPBvhue6urRdTuLi4tX2usQG5RnGcYwQO9X9DTOo6owia ZhqZGSOV+XqQP6Vh6AJR421qC3JOY51BC/MfnH5daAKOp+Frqy1q3062mjuxdk+RKpwGwcHcO2O9 b7fD7S7byo73W2jlnfZEqBfnIHIAP+eRV6GDy9dsIbgM87Wtx5Zxzuz29TjP1rN8VwyNd6IkKyAG UqoJJAcyDkH8R+FAFHXPD2jaPoEdwkl3JdvJsDkAISOSCO3FcjIS7Drj616V4xhSLw5diQIM3ChC Scu2c5A6YxXnKoScCgDs9C8N6PqmlWDzJNFPcb1aQSfLkMRnH9Kmi8HaDfWjfYNUlklQlGmAyqMB /EOwOOCOtaPhOL/inbFlQn5J8yBc7TluD/SsPwUk81jqUMW48xscDk4z/ntQBlaf4Wu7rxC+kTFY vJJaaTsEH8Q+vGPrXR3Xhjwraalb6UZ72a5nh81GEgVW68Z6DpWtZm1XUdXaUvJN5NvHIFXLNwef YZA/rVXVL/QNP8TWrz2F7NqcUUZhSIDacj5VI3e9AHLal4RuItYtLKwkMsV622NpCAyEctux2xz7 itO/8FeHNJltLW/1K8a5vWYQsoVUGDjk9uT1Na+qS6hqaWMVlZ32mXa3Bc3M0QQRqEO7HJzwf0qO +l0rTLvTrvVZ7zVbvdttjcYPGRlgOABkjk5NAHI+JPCkOlCObTrtruBpBE4ZfmRz0HHUH1roY/A2 gaVpKXGvX8om3IkqxONsbN0Hrx6+1b93HCjWyTQeUrarFtLDgkbiDn09sdawPGKMfDXmbSDJeqGZ l2g/Kx4BOevrQBR8R+C7LT7G4u9OnmX7L8zpMysrpkYKkc55GRUuieCdPl0JtV1y6ljzE06wwsAR GBnJ75OCeKoSS+LNS0dYp4rmTTtgd3EQwyDHJPfFd5qh0xLbUnlhmkto7YrI0a4yhAAC5Ydscjg0 AcgfCWi6rpa3ehzXUbSKxiM7qVLA42sP4eeM1xMgKOytwykg89/SvUNA1jTUso7TRdF1WWyjkJMn lB2EhI4zu4HevOtaG7WL5hE0QM7ny2ADLz0IoAzevHH407oMY+lNYAcYINLgHk/jQAYBBPp3pGXA we9OIGev1pp5+c9M0AMOBxjFMJwvTApxPXAyKY3XBFACAgimketLyBSHPY8+9ACfSk780mcN607e eV7GgBwxjB6U7HFMJwcU4ucbQeD1oAnDHaDUYOHpUOQD36YpMYbnoKAJhzRuBIGeKZv+U0Jy2euD QBPng1IGAY7CSo6EjrUGe3SnKflzzQB0vhfVrDTTfJfSyRecieWyR7+VJPPp1qzN4ls7TxbbapZO 9zbrapBMHUoWG3a3H0rk+i00PwaAPS/+Eu8KhzIrXikxiFvkO4oDuXvjOSR9DXE67qi6zqj3UcAg h2rHHH12KOn49fzrL7cnrSqRnAoA2fDd9a6br9teXUrxRRbiHRdxU4IHH1rV1/X9Ols7H+yJZvtV nc+aWlUgN6EDt9K5bjPtTCRk56CgDuLzXvC3iOyMerz3dmyyeaqD5iHPBwwHTGOMfrVbWvGGjwaE mj+HIrlgsH2fz5+MJzuwO+c/hXFSYIOD1/SmKuSB+tADieM/oK7Lwd4n0nR9OS1vbi6ika68x9i7 k28AZFcawG4EZA7UzyyRzjAPHvQB03hXWNM0691WS+uZIkuE2xtHFu3AvkjHbgCneKda0nUbywk0 xZfIt4dsgl5YtvLE89c5rmViIGacw455xQB6DeeNtFSGWWwkuZbwsHQSx7U6gkAdB9aiv9e8K6vp yw302oKA4k2pGNwOMbc9MY71wO05J/pUgXp6UAei3XjXQJ7OWFTdlTHGiRSLwoUr0PqAv44qj4u8 Wadqti6aZdXBnF4sy+YuNoGcFT9TmuK8vDcdqVI8jJ4zQB3MvjHRL/T4oL+C4Xz02XaRINue7Ln1 OD2PFQ+H9c0PT9G+zXU11lLtpSiR/wCsU4A5HQ4BrkRECw9PSpQo288CgDubHxTo1nLfM09youdQ M6eXHn5MDGR+dZNhq+lWPi3Vbvz5/slyJEikWPcSGYE5H0Fc0VPJ9aUYzjP1oA6rVNW0a/1PRvsF zdW0VvJ++mfIdSWHzAmvQ0uZLqFV8lX2OTHKq+aM44IxjnGD1ryrwzqcWj6wtxOGMDxtFIyLlgD3 HuDiup1CDSNXmt72HxEtkVQRtg4yB/EADxxxigCr400nVHtf7Qub0XCQHaIvKEXlhj1Azzz1rjQC FGenau28XeILCaCS10+4N284VZp3THygDoT1JwK4xFDNnsKAPTvDSxjwxphMkhVYpSUUgBvmOQf8 etYWn6x4V0exlFp9ud5mEjROoBJA4Xd0wMnmrek+ItDsdFsIJ7mZZkgdHCQ5VSSeSc+9cHLsRmCP vA4DEY3D1oA1YPFM8HiSfV3g3R3O5ZIFbHyHooOO3GOO1bs+t+C72/tdTmW9juLYLtQoWDBegb1/ OuHJDZOOKbxjGOlAHW33jwS6tHPbWsiWa7/MRmBdywILegOD/wDXqxdax4TvJbW5uZL+aS1YsgWM LuJIPzZ47VxABZufu0rkE9cZ60Adn4m8UafqOkvFZy3D3JuUkRplxtxnkevOKnfxR4c1zS3t9bt7 uCUsru0R3bmAxkenU9u9cJuy2ckYHFHGM5xQB1mr+K9P/sv+ydEgmRPKELXEpwWTuMe/HP6VY0fx bpLaR/Z2uwTttg8jzYzu3J6EdQRxjr0ri+g96TewPykD2oA7hPFHhzQNNa30WC6uXeTzVab5drY4 J9cegFcNcSSTyyTzEvJIxdj6k0jZLZ/KmsSGLA44oAix19vXvQCAB0pGJ4zSe/b0oAa44OD/APXp DyMA9BzzQSPy6VGTzmgAOAeuQOlMbrkjjvS5IOSM+1IeBQAh6/WmH8qUcknikYZ6cUANGSC2QMUA 9aQkgdKAPwoAdkY65pc03g0vQfyoAmRsIBQ5IIHX1oQdSaVl70AITk1IpAwB61GvX2FPXk8mgCYD PfrQPmOTkUucKPXrQDkcdKAB+cAU4Jt9frSgcZp/HAPbv60ARleM9jTo128963dM8J32rWS3sE1q kTSFMSSbSuOufbkVVt9Gup9Z/shFUXJmMPzHA3A4P4cUAZvOOKaQSPQVuaz4av8ARLQT3Elu8fm+ UfJk3YbBI/kfypdP8J32q6bFeQz2sSzSFIlllw74OCQPTNAFDTvD2q6tC9xY2UksMeQ0uMLkdge5 9qrRWc0l2tkkLtOz7PLx827OMfnXpHhe2u7fw8LR9Pg1KO2uJVi8m5RN7Bhwd3OM9x680vh+wayk vdevJLZri8lDqluQ7x5LFkOfu9sn2oA81vLSWzvZrS4ASWBijgEEAj3HWrMeh6pPbi5j026eDbuE ixEqR659K6LxN4Ru1utS1dtQsfK3mby2lAlOe20d/aui8JPey6LpTxszFInVVZxh8FsLg/5+lAHm BHGOMdzSY6Hjjp9a6qXwDrzwGVFt3lIL+QsnzEZ7dj7YrlZFkhlMciMkiHaVYYIPuKAE25575q4d PuotOj1B49ttLIYo3/vEDnA/rVvwzor65qyQCe3jSIq8gnfG9dwyB6n2rvPEejtr2nwWtpdQQpaT nBnKxJgjgL9MdKAPOLawur2byrW2luHA3MsaliB6067sbqxlEV5bS274yElQqcV03hyxuNK8VXWn CdJ5BayK7QSfK3yhhz+VafiPw7q2uGw8ow+TBasTO7j++eDjPQY/OgDgQ43YAGBUv3lyelWtX8Pa loDol9CAsn3JUIZH+h/pWppfg3VdV04X6tBBa4yXnfbx649PegDnzk8nHtmlQbupBzW1q/hTUdNg a4eS2mhjAMhgkyVz046ke44rDBwfSgCbjgelPDA4q9o2hTazFPJFcwQmEqGWXPOc8jA9q1D4A1pZ Gz5CgNtRmfAfPQj6+/pQBgRRTXMqwwRPJI/CogyT+FSXOnXlhs+1Wc1up6GVCu41paTa32k+LLO2 uYXiuFmA25xkHjIPcV1Gs6Lqms6VDaQBHIu2Ls7AlAF4HHPXP/1qAPPGPB4zmoXYDHBP41tax4Z1 PRoFup0SS2c4E0T7kB9/T8auf8K91maJbi3kt5kaJZBtbHUA/TjPX2oA5YnaMDn2oAxxnitu88Ja hZ27TedbzmJd0kcT5ZRnGcdxmrcPgHXZIvNlW3gz91ZJRuJxk8CgDmcjk8+wpjg/mPzrW1bw5qWi RxtexhVlzsdGDL9M+taFl4E1e9slvJGgtI5BmP7RJtLe+O340AczjC4zz0xSg8dOlbur+ENR0aIz S+TNFGcO8L7thPqOopmieFtT8Qh2sUjEcRw0krbRn29aAMTr3APvS9AM9a6O68DalbQmVLiyuAAT silySB1x6nPGOtc0+B1yGoACRgqKjZsdufTtTsg8k89qYwzzigCInAOD35NNzn8P5UOcEAUoIAGM 0AMYZByKQJxmnsRnioTJ83H4UABPPPbrTWGaM5bHNIzZ6UAJj0zSEU7nGc9u9MPI64oAO2e9IeeS frS43HP5UHigBPTJ/Kng5PTIFM5B4NOCk9Mce9AEkfU5I5p8jZHAqND8xzTj8319KAEBH/6qkTlq jH0xUicHjmgCTJPJ6VKv3Qc/hUWPmA7DrUrcdKAHq21SfyPpSodzZz171H2AFPUbRQB13gi+Yz3O lKcvMvmwKCBl164z3K5/Kugj0Qw+JpNZlaJYWt8kqSwWU/Lj1ztya87sbiawu4byBtssDBlNelGe y+ziVpIFtCn2jY0gckbc/d7tjg54/GgBmu6TLf6dd2FtDLI0sSyQBn3bmGGXp8oJHHAB+tRXc8Hh /wANzBIpN9pCIIndgB5h4yo65zuJrP8ADWuzaul21y6rPBKZocyBPLRzyFzxwf0JrN8bXcDfZbOB 4nIzNK0XIyeFGerYGevTNAGr4OcR+GrXcHLNczbSvGTuTO4noO5qHwyi+ZrZd1hH28c575fjNaXg y1aPwzp8ge3jjmnkLzSkEL8wwMHoeKyvC1xax+INY0+d4oLl7lpLd5SAvysxZcnjkY+tAHMeJY1j 8VapgAf6Q31xXofhcRzeHNNuG/dzW9u4RFUgOQWIPv8A4+lW2sbfTze381xaxRXNwbqW4ZRnyiAA hzkHnIx70zQ0tJdOsBYiCOKUSPF5kgygZnwMdhz25GKAOd8J6tez6VfiWSSeaO4TYzndt37twHpk gVz3jF5H8RySykb5IY2c5BOdo647+tdB4CtJhpWqOhg3i5SNjI67UAVssfUcisXx1H5fiiZC6yER RgyJwG+UcigDK0cF9asen/HzGRn13Cuz8aRRf2NCUcSYvG3ZxwSOmPX8BXD2UgtryC4ddyxSqxB7 4INetmytNXSyltZ7aW0guBdiMjdlCMbSOvHHBoA4zwMQdauIXA2S2jqzbc7Rwc/pWn4lvJdN8TaF b2k832UKpIDY8wtIQ2eeQRgc9q31e0Ot/Z2kglvYbeVnYMAIgcYQkdR145Irn/E1oJvEvhxgYVSU qo2upC4lJ7duaALuspNqltLYSAJbyXkSIOmPnx8o9cHtW1rtg1zo2pact9BbLtjjjEjhUjUMODz3 AxWR4s+02mi3dwrwJLFPE8ccZBdNrEhjj6iniC08YeHLmDT7u1hluRG7QMeY5AdzAjH3TzzzzQBe 02OwtdOtdNn1S0nmgi8uVknXYV5GBzzwenPSvLGRUlZQRwxAIPBFegW2n6X4Q0SJdWWwmvkLv5fl q7yZ4Cg9ce5wOa4HgsWwMbjwOlAHVeCow1vqJZxGN0PJHf58CtAXtynxHntWMjQeWYhEWyCoTK5H rnn60zwFC0ljqbLGkhDRjY5x2bn/APXxWlDoEsvjW51VLi2kjXO6ISDesm0DBHp3z0oArXO+41bQ 7uZB5n2louc8qVzkew59ah8XyPpej2radcyrvuS0sisVzhRtHXtzUk93aXni3SbWCeKXyJGaZ0IC lvToOgHv1NQ+NovN0O2K+TtF4QRHICASgGfXtQBp6nczzWd6ip5UD2RLL0BJQNz7554psmoT6doo +z5U22mxORuJAwqHaD/X3q5qUEn9mXuHt1RLJgoypaQhAMj24qPULXPhS5RLiEk6aiopmXcw2r+O OvegDAXxsrzrJaaU7TyyqxV5c7jnOAAOcmtjVLa+1sWM+rtDpUVnKZXEdxvfJx1JwAePUmuI8NXV vYa/a3Ny2IkJBPHy5UgH8CQa7DXdCudXsLMrcWtvBFKZHaSYbSpAIO7v0IFAE/iNYE0fUZ5pDOI7 iJyCcjO/37kfoasapbyeIbEwJK7WcxWWGaEBtrA5B6+/IPpUHiqaCPQbp/3DqksJCI4YygP0Ppxm q93YHWdN3+GJ7a1fzfMWWCTy8L3RsAEdjjFAEniZtQh0K6MVrHcyPCFnmjY/KvdthGff2zV/RrJ7 HRrG0juVgzZmQqSBl2UkueegJH5VT1W8k0XQLf8AtvUY7q/SBh5SSZMpJOMgdcDqTx+NUvCGo2uq 6WlrNdxRXsdu1s6yEBpUxtRhnqQCBjPagCbw3Y22h6U1pd61YzSTTeZCIp1AQkfMTk8Hp3rh/FyW 8fim/S1kR4Wl3BlIIyQCenuTXXaN4StfDVpdS+IJ9OKSFVhaRQ4wOSQCM5OcYA7VxGs3UN/q11d2 tusEEj/u0VQAABjoPXGfxoAo4G7GeKRnA6YIFLjjjJPfFROAcL7daAIXOWOD3ppfjqKlMZBwBz3z UeB0FADGbI7Co8EknsKsNgLj1pm09AOtAEXzU05z/SpyAB61G3H1oAQKTzj601lJ6rTvYUbtnpn3 oAaPmHbFB5bOaRfx5p23saAG4zg9T2p6gg5FOSIjBbv055pxxxz09KAEQfxE9afg4LDI+lMzlQKm IGAuePWgCHhRxyakXjmmEHeenFSRDnJ/GgCROGHepSMkjFOs7O5u5fLtLeWeT+7EpY/pVuTRdVhj Ek2m3aqf4vKbFAFNUIqVFzzTCQeMfiKlBAWgAkYKoA69qgYA4FTQ21xeT+TbwyTOf4Y0LH9KmuNI 1K1jWWfT7qNG6M0RwaAKR5HPWhRkgYp5QgUgX5T+tAELksxxkAdBSgEfMec9aeACeAeeAAOtXBoO sPF5q6XdmPbuyIW6euKAM1gCfx/OnMSgBBYMv3SDgintE8LESRshHZlIP60gVnYAAkk4AAoAjjHO TzUgHQ9j0q4mias0vlDSr3eTjH2d/wDCj+ytSBI/s283L1H2d/l/SgCsRnj06UgXPGBmnmJ0O1lZ G9GBBoAJ696AJl+Xgccc018kgZPHQegpyr0JJK1NDBJPMIYI3llfoqAkn8KAKjJ0AFJIMYUdq0Dp epbj/wAS28GP+nd/8KaNJ1FzvXT7s+mLd/8ACgCoiNwKsx8dunSpJNN1G3iaSawuY0TlneFlAH1I qX+zdQEUcgsbkpKMxsImO78h7UAdd4GSWTTNRCyKsfmx7g7BQDhuck/SsTxjbyQeK755Ewsjh0w2 QykDBrHmhuLceVcQyw78EpIhXOOhwfqalgtLm6DGGGWdlAzsQsR2FAFclt24Er9DSFm27csVznGe M/Srj2F3DGZZbOeNAcFpImUfmRUJAxwPwoAYEbBJA4o2yMvzOT0GSau2+n3l2pa3tZZvdEJA/Gor u0ubFtt1aTQkY4kjIoAqlQM4NMCAH1oaQZ9SelSw2d5cLutrO4mXOMpEzD9BQBGD8zeh4PNM+ZPu sVJ6kHFT3FtdWpxcWs0JJxiSMrn86jihuLmXyreCSWUgkpGhZsD2FAERHOScsepprBSxGDgdB6Va fS9SWJpXsbpI1GXdoWAA+pFU1GSc5560AL2IVR9e9MYgDGcEVat7K6uSy21tNOyjJESFsflRdaNq lqgefTbqNCN24xHGPXPagCmXAUio2I9KkIyM8EA461Ium37J5kdjcyKeQyQsQc9DkCgCoz4B4yaj DH0q1PbT2knl3NvJBIQDskQqcdjg02DT766QPa2VxOrNtDRRMwLemQKAKzHP4U0uQM561LdWd3Zl Rc2s8G7p5sbJn8xVcruOAKAE3E89frR9aeF9aaRmgBvJ6U3GOoz+NSnAFMOOtADkXB6Z/pT9hIzg 4p+3BpxOPlzgUARhG9P1pSp/OnDkjkf4UoIzuNADUi4weDUjoFwOtJvVQTnpSeZkZ/ioAYRtPtXQ eFfD/wDblyxmcw2cIzLIeAx7ID6n+QNYJXmvSfDiiz8N6faC1mnafdcuIyccnClhwOAOrH8KAL41 LTfDultcJAiQx/u44YQUSeXHTefmfjqemD9Kj0nxFeappR1BoUtJba4VBIpPlSDHoeMr/XtXNeOJ HS9tLBtqtBFvkVW3fO/OSe5xtH4Va8Oag+nWi6XqWk3hjaQzxTRwkyISMHCngjjtigB3iaxs77Tp dbtYZIriKRVnIjKxzbs4dR65HPbmsjw7ob63qAhZzFbRjdNP2Udhn1PQV0HiXVpZtEm0+z0/UjHM weSa4t9gXac9s5J7k+lSeGkW08O20X2eW4kvZGmkjjJ4UHC5A4PTPJxz0NAGpBeab4f0t7lIligg GPLt8qLiQ9AZD8zH6YHWqWi+NZta1BbC4SO08zIh8jhXPaNweMH14/WsbxpPtaxsmVUlVGmlAbcS znK5PQnbjpnGTXNwFo3WRDh1IZfYjmgDs/EvhaA2pvdOheKdF3T25QhWHdkz0x3H5VxKRSzzpBBG 0sjkKqKMkk+g716rLqG27inyWeZI5pYIUJYhlGd7HgDrxnoa5fR9Nj0vxjqbtEfL0+N2iVTg5c4T BGex7ZoA19I0Cz0R4490Ut7IoLThN7xN32g/KgH94571SvviKLa/8jTrRJbNQEed3YyyY/iVu2Oc Crer3BtdBvLtrVrffH5UfnMSS79WA5OcA8nFebjjtQB6dqmj6d4isVuriSUtLCHtr9VyxH/TTHBH bHUV59cWVzpepC1mHkzwyKCQenQg5/I11nhO+VfC8nnSCIWdziJ2UsSXXOFUfxZHXHGar+LLdpYt M1WSOTcx8iXzeGJU5GfTg4/CgDuby8LarJG93IHllA8tH+VOinnGPz9fwrlrvx3Db6rcWVxpbfZo bhlPl3Lbmw3Ug8H1xW/MXuNbkKrIFWfP3vLUtuwNzDnp2HOPQV5hrpJ1/UM8f6TJ3/2jQB6DczWG oaWkk5N9p9wPMV5VCPnJBxjiPHrk571w2v6I+iaobYOZYZEEsEpUjfGenXv610PhB7lvDEpgaQ7b s7WwCsXyg55yASe+CfSovHaFINKd5Gkk2SqXZixPzDqT160Acmv3sZPHQVu+D55YPFli0LFWyxIz jeNp+X8awI+p5rb8JuieKrBpeUDPnOePkbnA6/SgDvNP1e5llmaSXzI4raRwikqCQuccd+nf8BXN H4jTKpVdLQBs/wDL1J1PU+/4101nKZo57W0tpUEtpIqeYoQkbTjI7D0H44FeWG1uFi8w28wTO3cY zjPp9aAO3XxPa6t4W1qOf/RroxYRZLguJckdAe4xUum37RaDoqBpTOsDsgUkhfnbBOeB9c9hXAGK VMF43TPTepGfzrvtNnnm0DRYY2d3WFiFXGR87DOewGOpwB79KAIvEqT6p4fF1IXllsJdzO33ij8H Jx2OPTrVXwXMRb6qY22SqkZDFtoQB+Tn/P1FdKloVuFsZWLW91CFkYfLEqOCPlwPmbPcjFc34Ts7 iz1HWLQqolgURsZFB24kAzgkDPegCz4hkY+G5SXZwbteck54Jyc8/qap+G9BjuYG1LUAogUjyYpC VWbnk8ckDpx1NaXiCDy/Dbxgm5nuLqMGViOOvTAArTMe6WOwtbWVhbqsCS7yEXoG68DPPTJ5/CgC HVfEkOg6fGIIVe4lGYYHXZHEgJw2we/TPNRaTraeKrKWO6iDGMgz2mCybf76jqDn06VxviW7ju9c uni2iJX2RhegUcACpfB8zweJ7MBSwnYxMqkgkMMdR+FAEniTw6ulTi5tDK9jIcAS/fibrtb19QRW 94Wkuk8MEwTPCDdOMhsAZVep9P0q26/2nZXenI5njaBhEUTbEsi/MME9TxjIznNUvDhj/wCEWjd0 Vtt3Jyf4TtXnb3Pp6UAQ+NCw0zTo/tbXBLyMxLk4ICjnPfn2+lZ3ggGPxFv3HItpcHOACV7+1aXi 9mfTNLZoTGu6YIpAzj5OoHQ/rVTwVGW1/KeZ8lvKSI/vH5egNAGzMztpWrGFpGRrJhLcSkpkZGER OwPqetcz4b8O/wBqySz3LeVawKSXY7Q79kB/U+grrJ1K6Lqj7cKbVgdw5PzD/Oev1pLBRZ6VZWCW 807rF5z7CQEdueei5HHJJ6UASXGsWHh/SmuEgXaR5dvbRqY45Hx8x/vMPUnrUGn+ILu/0mHVWiFp Kk5jZySYpQF+/g9x06+mPSuZ8Zyj+2ktY8A2sKxuqEn94eX7cnJxn2FW9D1RrK0h0jUdJv4/KLSR XFvCWlTdz90/TggigCt4qsbKW0GtWVtJbs0vlTpsKxsxGQ6A8jOD7Z6VsWeqS2vhnSYlvJEBtWYh ScJ87AE46dwPy5rP8W6pLd6Qtlb6dqC2/m+aZriDYMgHsPrya0LKeKPw5okXnKrLAzMwBwm5yFPt zkf40Ac347fztRsJcyEvYR5Mo2sfmbquARWn4LmaHw1IVluBtvTiKJtgfKKOWHOPZeT7VW8d6Xez a1am2s7qaP7FGquse7JBbPQYrQ8MRzaf4WeK9hubX/Ti2wptMp2LgFj90fQEntzQBQ+IFzdT2ulL cSu+POC5XaoGVACj0HTv9TXF4xwOtdn8QJJZbbSHlWRCyykBzyBkfl64PPrXFk98n0oAQjIxnFIT 6fhQTn14pCe/pQA0nPem89qXOT1pcY+tAEm8/hSfMx5JpVXOD2pc8lRjmgBrcnGOKUGlbpinKCBg jmgBmCT15FPRdxyRnFOx27U6P72O2KAFdQOn4CvVYty6Vo/2Z2NvJZxiSbzcNN6pkfNgYx1AGK8v GCuD0rvfD5S68O2t28hDW26z2RxgserLyOSSD06cE9qAMfxqgHi2eRUIBSNlAbIxtGMe1bum+Mbz XtUh0y7tF2XGVVoHYMr7TggE4PQcHiqfjeyZG0+/248yHyWGclXTs2CcHBHFUPBaM3i7TyAchy3A 6YU9fagDp7S4ureLUWlnkllWzlLNPMWzx1J/wAH1pmneeuhaQLcGOL7Ioe4EoDOcnMYx83HTggc0 57Yw2Gou295Ps0rFmACg4x0HHfvz71W8PmKfw9bzyPg2LPDsjjyxDHcuT16kgDv3oAwvGceNf+6E X7NFgKcgfKOBWGowDjqfWuw8bW7iw0q6KFdqNDIGwWVs5G7BOCRXJwRPcXEcSZ3SOFXHqTQB6I09 zFYWSLJ5EX2RNpA+Zjt7ADr78n0FQKpGu615MZubhra2YxuQoU4GXO7jj1I79K0ZLcXusPGCZY4U CSSAjBVRhiSD+OM/hXK6RqEet+LdTRiscepROkOUDEbSCgCngk4xigC34pEr+FS0jeY/2lGkkLkl uoHXt6dPpXBk816ZPbfbdD1W2gaQZtv3cjjAdk5KqDgsTz0H+FeYnI6Hr3oA7Dwc86aLqbWp+fzo tzfdCja2ctjv7c1d1oNe6ParNLJKG1KFEwuBgqchfQD2zUOgRtH4OiiHzvd3LSKmATtUbRgcnrnt +IqPxbqE2l3Wl6dBmK4t3F3ISQxDtwoPXPAzyT1oA6i/Mq6u0cR2MLnCn7wTnnaOmeeteY66d3iH UB63Un/oRr0S/gT+3ZHkknJa5LY3HLfN047ewx75rzvXgV8Qalkhm+1SZK9PvHpQB1fhCMT+HZYm nljX7ZnEeAW+X17VF48jhhtNHihhWABJSY1J4O4c885PvVrwlbyx+E0csYhc3ZZNrAMVAwcE9Oc9 B+VV/HYVNO0VTAschErgI+4bCRjJPU570AceHO7oPwrofBEIk8UwMMloYpZlx6hDiubydwJroPBc rxeK7NFziYsjjA5Uo3HNAHY6bfTG5ec/aF+VnJhxvGFJ69OMdOn1NZ5+INk0Loy6q2T8pkmVgOcj gjnnn8q17eNPKn5WANbyhUXlVHlnknHPH0/Ht5WASgA69h60AdJ4t8TJ4g+xrF9oC24YZuGUsScd wK3Ipnbw1pCkfZoWtSrKqklyGbBAxyTjPOevArmdE8NXGt288yzLbxxAhWdSRI+Cdo98CuhsxJJo mjGOcq32YqEC7ivzuCx9vQEgfXpQBt6jfefYC1Qyxy2kUXJ+WQo6nG7r3B6A9aj+xCa3u9a2Ddd2 ypKrr0kR1G7v1HP4c4rGluvsXjuG0NxL5F5bQ287ygBjuX5WORxg4roFlNrDdaZExkL43GRT5aFS M/8A1+fSgDJv3D6YksspCDUID5vI474PTj/JrWQ3H9tYlhEEQlYrAXGM54dgO/cbsmsbxQEt/DLt 9sluZReIw3hQqcHGAB+nSrzCI3MF3bmSf7dtuFWBMAf3ufQHIJJHpQB55c5S5lRgS6yNkE+561b8 PYbxFpwPT7Sh6Z71P4xtzB4ovG+Xy5286Nl5Uqwzwe9SeCgP+EkinJ2rbxvMxOMcLwDkgdcd6AOz s5ruXVY45pGjJk+aJDkhTnhsDGPbAHvWN4elVPC8arlcXkoDjqflXB/L/wDUauiZtN0i71d4yAiM sJJGPMbgY9epOcdutZ3hVpD4e2xbzIl0w3BRhAVXnofQ+vSgCLxSHi0jS8rMu95mIlz833MNg/4D 6CovBO4a+BsZgbeUNtyMDaeSRzirfiqJv7L0ydifnaUhSc/3evoeOmag8GhzrbbB922lJ46fLj+t AG/fiNdG1Xy3ztsyojRCFXBHb/Hmp7sOslv5R/0aS3jLnzcG4yo645x9TjjpVW+huLPRdRFwGCNa ldwYbdxZcD1z16ADioLOVbvR7a+ZnaZohahIohncgwOR1OMH0FAHK+KZPs3jC8ljTaY5w4DHcDjB zn0rd07xje+I702FxabHkjd4WtpGDrIBuBAY4Ocd6zvHdmV1a3vQPlubZA+DnEijawJGRngVB4Ki c+J4vKxuSGUgkEgHYevtQB0DXE6eHNeWWaV3FmSzSSEnJYDOTznn0UegNQ2CxRaDpEkokKx24ZWG SAS7nCgc5+lTXlqIvDurbi7utufnOMZLAEYHA6n3qK3YLoGk7Mxk2xAbAOPnbpnvnt+hoAbrfitN JnghexuTLJbJKG+1GPywSeAoyB09e/NT22rjxBpUd6EvYWiumRAZDMFG0EncRxyfqffpXNeNQ41C yQu7AWEePM68s2eoH8q2fBwZvC0kRkYFb4lQWITGxe38Xfp0z2oAyPHECwWekoFlDsJXYyvudiSv J9Pp2rkGGOnNdt46Crb6YRJ5mfOOePVeOP8A6/1rjDgZOOT0oAjP4UwqT8vapiCelNOB0oAhAoOO hGaXPNNIPY4oAfvwuO/YU4Z3HpzUYHOelSKdo6HmgBeCenA609fvcdaRFzTlGDt/WgBDzjg49KkQ DcKaFyRtyT0FKMgkcg0AT4z2/St3w1rB0a5kModra4XZKqnkejD3H+NYsY3YA6npUrkbljXoO9AH pCadDcWD28pk1SxnIZWsgMrJg4K8/LxnOfxNXtC8O6focqS2rM9xcxMiy3LYdiQTtRB7Dk89OK8u ikdG2pKyDuFbGalF5c+cky3EokXhH3ncPoe1AHoMtjeXVheSXENy7RW0mxAuyOJiMY2j+Ij6n6Vy Oiat/Y195xDNbyKUmjU8sp7j3HUVTW5nbdmeQ7vvZc81A7Ek0Aegx2EVzp00QuJL3T7pAWNmgZkf +HCk/KfUnr3NQaX4NXRmTULgSXEoI8ncoRIiR945POPrjPrXDRySRZ2u6A/3SRmiae4ePY9xIy9w zkigDpvEXie2gtX0vSpWfcpSadflTHcIB692rjY3eJ1kjZkdTuVlOCp9RQ3Tkf8A6qXnHuKAPQNM 1D+3ZI760uFi1GIKGtiQHd+7LyMoeu0e+c1Xl8BQ6rqT3kP2yC1PzPE8AVicdVPQKccZGenBrhSx jO8EhuxHBpv2q7X5RdTc8HEh6UAeiahrGmeHrNSYyLgRiO2s4iAyqDkeYw5A55HU+1efyXFzqusG 6nBmnuJgSo7knoPbtVfHUkk88mmnJYYoA9avNKu11Wa5ltrqdVmOxcHaw3cZxkkfUge1Y2reA5NU 1e7v4r1o4LicvsNq5kXJ6HtmuH+33pyz3k7E8cytz+tMOoXh/wCXyfA6jzW/xoA9NuLCLToYIHdr GztotiSTgAhc8nJ6liScY/DiuB8Sax/bGqGWIOsESCGBZDlti9M+56msuS6nnYNcTSTMOhdixH51 FuO7OaAJgRkAdAa6HwbE0vimzVIjJjexx2Gw81zanAxk9amhmkWUSROyMv3WUkEfjQB6zZWk7XMg urW6EDo8W7yj8oK7eB0xz7fiK5qL4eTiaN/tzyw7zgwWz7mA7gngfU1xv228LEi8nOTn/Wn/ABqb 7feqv/H5cAnuJm/xoA9YhtJba2jsYbB7eygikyGXPO05LN/e96y9Mtb648N6StrvRBAd0ohzt+Zs cfxfiffGK87+3XIBAupvm6/vDz+tN+2XKJ5a3MyqRjaJDjH0oA3vHULW/iJFWTLC1iIY4DZA6kDo faupikk1yzttUijupvtEQWRETKrIvysB6k4zzwPavM2ZnfcxLsepJyafDcTx7RHNKgU5AViADQB3 ni+0urbwzL9otxCBdphcZbGCMs3f+nvWN4a1dPsx0a9nEEUr7oJpPmSEnqGH90/lnrXPyzSyn95K 745+Zif50g69Bn9KAPQ9S8PSavYW9lI9w8sZItblEEkflk87mB5Gc4x+AqSx0Cy8NWrR3TFBIm+5 uLhV5A5CKh9+3OeOlee+dMgVVuJVA6BXIA/Ch5XkZWkld8dNzFsfnQBueJfEQ1hktoFkWzhYlRK2 WcnjcfT2HameG9YSxkuLO4Ypb3QA3gf6tx91j3xycgdqw3OAD/EelOVTjbge/FAHpD6QLnTZrF3m uYpnDQXFsiuoYcFuDgLg4xx+NP0jw1J4eZ7h5GM7xsGnPyLGmccZ9euT6dK88jmmQbI5HUdNqsRT 5rieVcPcSv2IZyc0AdD4n8SRXsZsbGSSSAMDJNJj5yOgUDov1rJ8P66dPnnt7gubS5Xa23/lm3Zw P547Vkyk8KpHPpSKSOMAEd/WgD0aTSYrjTjaXCzajZM2+CWy2/K+OSD0UY6g4+pNWtL0Kz8PxXCW W6Se5tjskm5llwC2FQdB09c15is80alUldQ3ZWIFOFzcLIJVnlEuNu8Od2PTNAHeajY3M2harc3M Vw7x2+IwRtjiJYbgqjgcfX603Sra7bQ9LeC1md1tTiRYc7QXbGG555rg3nnZGVpZGDckM5OahN7c qAiXUyoDgBZCAPpQBv8AjuGSHWLZbjeJRZRhlkOWU5bqe9aHhO3ubjwrN5ELyAXrFgoJ48te3pn2 P0rjJ5nlkzLK8jAYy7ZOPxqPz7iAkJJJF3O1iv0oA6rx3Ddx6dpDXMEsXEoCyRFcAkY/l359hXEE 888Cpprq4uiPPnkk28Lvctj6ZqA9fagBS38qaxyOhoODx60hPP8AKgBMEnP50YHcUh54oY7fr6UA Ljvk04cn8KD7UoGBnFAEq4Xk805QP8ajB4FPB5wO9ADgzL8yttYdCOtEYy/OcUuBj0xTkHUmgCzC u1d2elP25+ZsZNMjOc5PFSE4UEj6YoAb07cU9evbimMwzk0K3HtQBZV/lA7dqUDJ69ajj569anBw McUAIOp7AU1xuOMdaUn+EHOKcgGST2oArunz5pgQB8ZOOxPpUrgk5APPtTfLZshFZsDLYGcCgCvJ yxwOnSmquTn8qkKnJ4Ofam4+bB49aABumV+7TDx6fnUrqzDAzx1FeieH7LTpfDVtcy2FrI32aUu7 W672YBsYb1wKAPNTnGKjI44wcVIpzQ0bt91GbnHA70AV84AOee1ABLA449akeCUqXWKQhThjtOAf T2ohR3k2xqzt6KMmgBJBgDH481JCPkBI5NNkV1bEish9GXFTWyNJgKpY5wAOaAGBMNyD1608LlsE 8DmpJYzHJiQMrD+EjBpcFV4Ukn0oAZsxknmoxy20Hn1qdwW2xxozM3QAZNanhKGz/t+1Oq25a0fc MyKdhYDjPtnrQBjkDHBBI96RFKsCecV2XjaDTQlqlmbeS+yd6WaDCR4GAdvB71xgLMQOc46UASZB bn86VfbgUsaE8H0/KpQmCfXt9KAGep44/WgAuwHTJp6wvISqIWIGcKM8UDAFACYBYe1SIpA6jJpU X2HTpUgikMRkCMVB+ZgDgUARAkHIP0prMSD6e9PVTIwRQWYnAAGSaVk2Agg56cigCumWYt057U49 ufwpwG1SDx6+9RZyTQA4ct/KgsOBTA2OQfamFiSfrQA5myOc1A7AckHPYVIcnjvUEpOaAGl89O3N MkZnbcWLE9c0qoeRzz3pCGbBx7UAMOF4BqPtUjdOvFNXbuywJUdhQA0jjHSmkc89KkPrTDjH160A Mz1phOakdSOvQjPWmA/X8KALGMjngfSlYDPSk3HP+FKR270AIDx34/nUqcsB3NMCknGKljTLYBH1 oAeE+XPYfrQBn8TUxXCBegHpUZxyfXjigCRB83XAqXPbHHaoFP4mnq2W60ABJY8fQDNSINpzg4po AOTjFP6DHc9aAJEPU/lUhbauajUgD+dOJzz6dKAHhsD61r+GG0tNXSTVZljgiQuu5SQz9gcA+5/C sQkEZ610vg62tnvJ7i4RXeCLfCkgBUknGcHrj+ZoA6v+3brUNdit9Ktkm0pYh5kiQkBWAP3Tgc9B gVXkUx6za38MP2eaeCWF/KG3cAAQ2cdffFR3Gt6iPFmm6dDMEtZAskkixj5wQc89gOmKvmJW1C0i juCUAuA7MvKnavQdef60AZ2o+JbrStY062e2ikecDz5SSrkMxAGfbrzVbxZb2upWUo8pG1C3mWNL hVwZMttIOOwyOvIqh4rRH8QaTFDlwY0UFuufMOQfxrc1qeCxhvbqFZHFtdI0h2YDYlBIz6+2R06d 6AJL+4Twj4YuYtOtws9qEjFw6ZLyEgE+4znr7UsV9Lqel2t8YVUS2EpkEYwA21wzDHqRVXxVbSXH hm+MCvIrvFKgReNm7OcDrw3Wp9CiSLwxYtNMVkFpMFjK8chyM/UUAeVKuPc13HgC6+yaffsF581M HJweD1xyelcXxj3Pf0rtPADxLYXomI2LcROcoTkYP5etAGjZeLZ7nxbqWmvHDDBHveOSNfmQpzjn ghqZ4j8TTeGxFJY2OnpPdys9wNinzFHZsdDWPo0QPxF1JRNsQfaGZ8biV/ziovHSx/2ZpxhjZIy0 u0uuM9OnqPfn60AdV4iWHUPDl2k8AnZbU3Nu+MmAlQ2A3XHUZPWjw5Bb+HtCVFgUXf2N7uWZuobY cAcdsgYo1S5Enh28tIg4ddJy2F4GYx3H8zTY8apoT3VsjOlxYMqoowdwXDDI6nKngnj8aAGWt6fG GhI2oBZZJQYpiqAeUwPyuo6jrnjrijQ9Rmt9K+xXbgDTZGtJsN8rJ1BPHcZx6kYqt4Ttni8LCW5l +zwNO8km9MbUAAySexNYega+/wDwldxKMLFqLFf3n3UOcox+h/maALfhnS7iy8TahcK6xNY/u4Hl BAy/3Tz/ALOTWuusTR+NLTT1vGkitoZGkJYOC7JkgHHTAGKv3EylGe42ubYGS5k8rIfb03dAOMAH nOfWuQ8LmW98WLdSylHl8ySRgMnBU9vxoA6W7nYeJtHMSCNis6kQ4BwVPXHQ/wAvem6n4mutIn0w PaRSzSEtJNISH2bsBc/mfT2qZYon1/RGh3JEwuOWTGBsPI9R+f1rH8aInm6ZHGxfAdcsMHO/kUAa 3iiK0vdNvRLGJLm0UvHcAYbgj5D6jB71Y0+207w7orTGw864hg86SR485kI4Gew5xxSa6kMenasI A7OsHzybAFXleM//AKs+9Wo9nibQrj7HdRl54drBzgpJxn6gkde1ABpGpyanDHdWkS2811GyEJCC EdTgEnGSM88+teYXbSy3czzEGVpCXIH8Wea9G09LbwtoUB1GeFpICzmOOQFnJOQo9R79q87mcyTS SHguxY+2TmgDS8Maamo6zFHcKzW8KmWUeoHb8TgV2Op+K30670q2gjW3gu3dZ1C5+UttBHoRXKeD p0j1loHAJvIjChIHDZBHXg5xj8a1PEun3NxqmgiOJyM7PM2cKRJu/AYI4oAuanp7jVLHV4k8qeG6 WKQ4CtKC2A2B37H61PrviG60fToZjAk8zTlY3mzuVQOeeKNWujb6jaQNKGuLy7Qqm3GIw27OPc9K y/HQRNIt0jmaTF2+4suMHbx+YoA19aks9Ysngu4VkeSATxP/ABQEruADd/5GvL+q4HHHrXpmyFLO IIjtMNODfKgIj/ddz6e/HcZ7VzkPgaWbS4Zftf8ApdxCJo4UTIC4J+ZvoO3rQByZ54HYdqTIGDjp SfNgttx/SlCsTkjigBGz0qAjLEZ6VOwbJ96jkRhwv40ARtjGFGKYevHB6U/b655phU4PXHagCN+T zwAOtNIHTPFSbSajKksR2oAae7dKTrx3NOYdBTOf/rUAI36U38RTiMnmgIM8g0ATBSDjqaevpzim qAW45/pUoHB9aAEA5APQ+tTIAGAHWogMDPT/ABqVSQPfNAEhOFqJRluPzpXzsA/P2pBxz6UAPPA9 xT0UHjIFR54xT0YA8Dp0HrQBJkZ680oPc8f1qInNLvBIGfpzQBJvxk85PFKHzxxx2pm4NyO3Q04D Ax3oAcGyeh96vWV7PYTLcW0myRePUY75B6iqZAUAqck9KcTtGPXrQBvSePNe3LtuIlAPRYV59vpT D411oqjSTRu8auqMUHyhsf4Vz7feHT8aYzbjk9KANW98S6lqF5Z3lxIjT2ePLfYB0OQT2qzfeLdX 1a1e0u5ojBIQxRYlXBHOciufBJbHapRydoPHU0AbVl4s1vTLdbe1vSIl+4kihwmfTPSrH/Cba6Yy kl0siujRuDGPmU5H9eMVzrsemT+dLnCjjk/rQBE+MkA9f5VpaZ4g1TRYjHp9wsSmQOfkByQMDk+3 86pFQcYBPrn1pQhxwP8A69AFy0129stXn1SFYBPchg4MYK4brgUzVtb1HWbeGHUJVlFuWKEIFIz1 6VD5WBkjk1EyAnofwoA05/GOt3Ng1g8kRt3jETIIV+YYxkn1wKZo2u6voq+XZ3bRxFtzRN8yE/Q1 TSIAjj8qlCLwBzQBe1bxJrGsxeVd3X7k8mKJQisfcDrWdAnlbWBwynIPv1pzkBiB2puflzngUAat 34j1W/hlt57hWil++qxqpPOe1RaXqc+k3gurZYzJtKkOu4EHrxVAED2JqRSMZNAG2PFuqGeKaSSO SSAP5ZMQBXcMY+neoL/xBqOqrai7kRzaEmNgoB655/Ksz7wOMDPpUioQMcUAbFz4u1e8tZrWaaIw zpsdREozznP1rqYp38OaLF/aKjbZgRh7WQMWDZIO09OepHWvPiuQOwroLXxlcW9qltdWcN7GibAH +XI9+CD07igDqLa60fWLdLtYUulL+S4a2CODgfxE+/WvOr23W3vp7dH3JFIyg56gGt658aXb2Jsr CztdPiOQfJUZ569gP0rm3CqOTzjNAEZkMbhkYqynIIOMfStyHx1r8UBRrtZeAA8sYZuOnNc27ktk VEznJUk468etAGkNZvBq0WqTTGa5jbcGlOenb6VLf+KNT1fTlsb6ZJIUlMikIAV9uO3NY5DAZxSK cKfc9+9AHRDxtrgtxbrNDsMZiI8lcsu3byfpTIPFms2uk/2bDdBIdojDBRvCf3d3XHNYQ+UjNIrb WBBoAnWNcY49adgRrxz61EJccL1pS5c4H0oAdGm4ljSTRqB1zSecBjBpjyjpuoARolAOWHSomRSw Awc05plx1yPfvUSOcFu5oAkkAUY4GO9V8fxcc/pRJJuBA5FNLDbxmgBjgUgQ45/Gj7zZH5VIpx17 UANMYHB+pqNjjpzUjsAM569Ki3Y5FAEwBXk96kGB9e9ISOODxQpwc/rQA/vjHHrUkabeoznqKah+ bOeKsJxjHJNAETrwcdAOtNyKll4JAPaogCeQMgdfSgAPC4FKp2sKQr754pB+nagB5OPrSAn7oHJ9 qTqck0+NfmyTgeooAlUDP0p3BbFMHXlvrSgjJHp70ATRfM2TwBTmXdk8HP6VCsoGRnvzUgbKZzzQ BFIRt49fSos9f1p8hBbHGB6UnAHy9+woAQDnFSAYzz1PamrgdeTT8ZOaAFVOM9qcME9PwNMyx5wS KchOckjHvQA/aeg5JqdECjBNNiI4bOcDjjpTfM3Ev2PT6UASPhsgNwKgLAc/1pd5bp+OPSoZGweT yf0oAeJBu60eacFh06Cq4JbpT3IUCNeg60ASoMkZwaVmG7A6CmocIMEml47ZPoKAFAbfg8EjPNOU 54/yaaxxgAfXmgEEZFAFqMDNSBuTnt3qruOOOppyvgc5NAE7YP0ppQscmmq5PQmrGRjA6+tAEGDz xxUMx46/Wp2ZaqTSgnHXH60ARg/Nk49800npgD8qb5meM896Qk4xnHpigBZGIHH0qMEFselD5PTg /WgLhQBkHuT6UAPLDP1pu4AYyKTOD7dqYRlsUAPUk5B/MUjHnOeaMkcAfl3pjZ6YzQAoJz7dvahv lO48DNOQBTuzn0psh565oAiYhjwO/pTCT24Hc08jHNIcA+vrigBre/Wmt2/U04ZJz69sUjcGgBhJ 7cZoHPA//XQR27/yoJxwOlADZMk45HbFMJOaceeSaQDjigCbfk+oBqQH/PpUCkgdaeGJ/wDrUASo cOOOtWkYfjVOM88Zq4gJHTNACnGDu/GmElR/QU44+vbpUbAjgAZ6UAIcc+vam5xwOacRgdKURk88 elADRn0/+tUwyAMdTSLGA2XOAe/pTwCeR0/nQA0kjGcUgJOSPyoIyfp/nNKFBGOmetACISGB754q dmKxjA57VEpXdgL7ZNSjBHPOOKAIc4yQCM9/SlJzj24NK4zwM5700gHA9KAFyOnan9V+XFR98dc1 LjPH50AMJJ7cnpilBydoxgUrAKp706FVDDcOvNAFhELxCM8Z5J9BTH+bpwDx+FSSS7VKrgFup9KZ wF/xoAYcA4x09KgkY5x781PgdQP/ANdRBQX56CgBIxgg4o56t61IBlPr0puOmOc0ACZIIFSlWIz0 9KSJBvI9uKlkwqADrQBCV5xkUqgDt3o5yDSZOMcc/wAqAHs+1e1MB75OTSAbj83QU7gnntQAolZe c4FOackDqBnmoiAeaRjz1oAdJMSCO9ROflB4obg0x2yOtADc4OMfWnbsA9BmomOABnrShhkDOaAH YBOTRnueh6mkPAIx0ppyAOntQA/OSfUUhA6YJ/xoXjt2ppJB4xmgBT8qVH1PpjvUnJGAKQrjIYfk aAED89B7c00kk8455yaOCQMHHekYAn+ZoANwqMnJz096exC1ExJ5oAcjYIx29e1ITyT6HikH86YW oAU9eO9NbAozikOMnuBQAhPQcikyDSHOTQBnpQBJn5c8GnAHjNNxlvWpO/096AJYRkAEcn9KuLgc DjjpVRGIbP4VOj44zzQBM3CggYqIBs47mnbiODgnNO29T3oAjcgHjt1pc4QHA60jAk4/OmOOSM/l 60AP3fNjt6GlyCeuMCmKPkxk/WkJAO0du9ADywH9M0zzDn7vB9qYxOBkfSlUZOTn8+lAD1IBzgmp g3qAOOtR5BUAD8aQHP4/pQBISMHBzjv2NNU447mkyMcnkUA7qAHAgEn/ACafu28E81COTnj2qUDP XvQAgOX5HSnI+WPHAoYYGB1NCjAHr2oAkGWOSP1oZiTgZxRkfdGM/wBaVBnOO3NACscDbjHrTCvy +/8ASn45yetJt5IwRigBrHGAOgpqAE+h7U8gAYHWk2YGR3oAkjwWFPfBB56etQqTuA6VLwfpigCM 57/hxSMMZJ5NOBOc0x3OSevYGgBcjAUce/vQCcn5sgdxUOc8ZqUfd57UABIUD1NNG0Et1FIzcH3q PIJxu5oAVmByPWm4JOTjrxSsORn8aXaMZJ/+tQBAwbI5HNOXPoMdqfjJyRyaXnk9BQA3BPJ4pABk 9T6U8ZxknpS4+bJ7deKAG42gfyqMcv8AyqRm3Dp0qPdtyduSf0oAAeccUMQRx07Uh4H9aTvnt6UA HqAKXsB3o5JyOnvSnjtyaAIpAcdOnf1qIjCk+tSuvGe31qLknp0H5UAA+6c9aiPfFTNwB0z2qE9e c0AGe3ekpCRngYB9aPfPHU5oARuDTcn6/SnHJOTSc0ATKuBkd6lUe3NNAz2xUqDk5NADguTn0qWM beT1HakRMfMRT+pxigBY+malJwuc571GvTAOAOtEhLAKKAAYILZ+lIwCg4pFIZuBwKGPfqBQAzoO tNIGSF/EmlxuGaNuf60AIAWySfwowAepOaeeM4pjYyQDxnrigBzHOTnimbiO/XrTiB0GOlOEREau 3RiQp9cUANHH3qXOAOOtJwOTSjJbPpQA4HrxUqep6Colyc8VITtXAGaAE8zLnPpSkndk96I07t07 09kCjPU0ALHwDkj0qbGEGcY716Jp+laXLpGmTS6VasZbdTJI6H72T6HuKbqj+GbO6X7dBZQ3EkIc R/ZG2pkcE4PPrjFAHnTPg4HWlQ9yPzrvbjw/oc4EgtoZYJlCRz2bnLvjkhRkDHvXJa1os2jSR/vB PbT5MU6jAbHUH0YdxQBQVRguTQTgE1c0rTbjWLl4oFxHEu+WTaWCL+HOewHc13Fnomh6RaTXNzED FCgMk93GGck9lj6D8eaAPOF5OetPJPI6Zr0Bn8N+JUdrPTkQQofM2xiOVM9GAXhh/WuS17QLnRJV cuJ7WT5UmAxg9drDs3tQBk9TgdKjkYEBFUdev9K67whbW9xpOqCa3hkZTGVaWIvjrnoevH/66vy6 XpWo2s9nbWFtFOYibeaMHcZAM4645wRjk/SgDgTw2QAOenpQX7ZxVvRohNrdnDIFKNOgcMOMZ5zX d21lps2sRxjSrMRCYrzbN8/zHnJPTj0A96APNZHzwTg01CN2RjjpXc+GItJbRLq4v9MhuGN+yK5i 3cYyF6gKvvn86vXEPhW202G9u9PtrJJZmRB9mdiduDxyPXqRQB5yzA85pd2eOvc13h1bwWvzRR2Q kycbrByq5+rc1R8cafYWmn6Pc2MUAS6WVhJboVR1yuOvOee/vQByAY45/Ogndx2puCenFSADseBQ AgyozjpQWz24HX3oI3HGaFPzHFADWOO3NIOeo4qXGTu4oK/jQBAFyeKdjPHp61Inc9KMAnPGKAGK tOwAuc4zS9Tz0HWmvk8dM8igCFxkZPamYGOlOZSTj0pSOBQBC+Tj1NQkZ+lWJewHXvUezFAERSlw F6dqc3JNMOegoATtnFMJ9c5p7A/So2P40AW1Y8Z7e9TR5dulVQenvVqLp1oAs4BH0oWmEjgDHqea XORntQAuccUOePekV/myRnjikL7m5HPtQA4AYx1pH6egpRmhhk9OlADQoAz6UpXA5x60DI7ZpccZ PNADdp69j+lJt4zUh5xk8nrTSADtoAZtx14zSFzyKccjPPSmgc5PIFAAcY5GKUKeMHj3pcbvQCno CPQ0AL0HNOUZHpQFzz6UooAduA+nah2ycfypmMHOenTikPHOfwoA9QtSg0bR084vm1QkNJtRRzkn vj6CuS8azLJrUBVgx+xxfNgjJx711EO2y0vTQzJv+yxc7NxHUjA7n8DXKeNpnn1mCVwys1nF97Ge nfBNAFvwTNJ519Zsc2rwefIB1DKRgj88Vpa2yXHhK8EcGyKCVJkZn3kEnaeegyCOFGOOprG8DMRq l2BCJ/8AQpDsIBBII7E81v6stxN4V1Vpp4X3eUohjXhcyDq/GT2wBgUAP0aCDSfD9sFuFt554fPn cNtZi33VLZAAA6fU1g+L7rbPbWMcjNGkQmk+Xbuduc+pwMDJz3rqZ3so9QNuBA9zAEjkdlLCAYAw B6+5Iz6Vw/imVpPFWps7Fj9pcZPpmgCPRNQ/svV7e6Ybk3bZV/vIeCK9Auoo7kT6XcqwgnLR+cQI 4w3YqO+OPmJ79TXlyj5gT6ivTL+azXVZJBE09xHJGW3HKxfKvAxwv0HPsaAMHwxHGNH1u3niL7ZY l2q+MkFuDzyOOnOfQ1s2z/ZybuCNFWBlBkdgscfcA9yfRf5Uy3hgtb7xL5ysp+1xusSnbkEEjoM4 OegGa1LJku9KME8KK3nB7WMIMIyLuwFA+XjPcn3oA4TXLOPT/GcEkPy213NHcw5GMKzZI/A5rsLJ 2ufEGQZEVpyzSXEq8kE5wi57fT3rL1SFtctbG9SMPcWF6u8g5LRMQSSe+CPU4z1rUs7pzrXkrL5i +cwUmIBfvHOABwPfHP8Ae7UAZXhiziuPDlz++ZYo9Tc7lITaNvB3Hp+BzVTxubY6Dp0dsSQt1IXy c4yo7dv69an8PrbReF5Li4RCo1Vlj3jIQhepHGT6VrXIsLrQha30cAtzdM/72Xyju+o68H/HFAHl ecnjp7VZlvbq4t4oJrmSSKEYjRmyEHsK71tE8JG6jaRLMIyneIb4hRj365/n7VxWuR2aa7ex6aB9 kWZhDhsgr2wfSgChuwPrTgCAKVYyTk0jgsNo6UAJnqaVevNCxsB0zikw+eKAJM5HXimFieg5pGJ4 pwVuPU/yoAQZxTh6Y/8A10Ecevao2LY47etADwecUHpjjNQKWY5Pbj61Jkjn1oAYTjNN3ZOFH/1q RmyR3+lORSwPA/CgCu5JY5oUHB4qZkwT7UhBC8dTQBCUzSBe/apTkCmMOMCgCCTrgVHjPNTlfXmm bMDJ/CgB6KM9eKnU47CoVOOacnTOTQBPkkYp/Tjmo17DFSBs9qAHDpx1p6R84FNQe1TjCrnv7UAR nK9OxpGwB3604nHJP/16iLbiT2FACjJb3NPHPTnFNU46H60E546mgBrvg/SgN3GaQrz9KjIOcmgC QfMf6UA5OKYoIHFOXOOg+tAEvAHPWncegzUIYlssPrSlxuxQBM3C49KeuAOahWTj1pwb1oAeMHLd vSo3IBxyaGYDIz9KYSM/1oA9QurmS7tNNazixbtZxogJ5zz8p49ge59B3rkvGW6TVrZnYF/scYYr nBOOcZJrpYjIdI0qJUXmyQh92F6t1JH6AGsjxnp13Jf2MsUM1xG1ig3xqzrwSDjuOfWgCv4IQDUr x8tlbKQgrjPUevFdFrAaXwvrCGVVaJInEe4ll+YY3N0z6CqXhqyutG0y4lniMFzfYWMOvzJGOSSO 2TjHfjoaTxPqf2Pw2LE7BJfOHCtyyxr/ABY7ZP8AKgDVEt1P5VzC7eU9vFKrqgUOzKATkclsg5J4 +tcj4ygWPxLLKA2LlEnLEghiwySPbOfyrR8N6quo6W2l3WJJbKMvbRsTiZc5KEDrt6gd+as67YXG v6d58dtK19ZAjy1AUeT1xt9Rz8oOcGgDkLWAXN7bwLG0nmSKoRWwWyeme1ej3Sm/1l4IXZYfOEIX gYAwDnB5JwTgkfQ1y3hnRLyK+TUbuM20VuN8ayjDSN/DhT1APOTgcVt61qMPhzTZ0cK+pXaFI9xG 9AfvNtHCD09e9AEdhfLdDxNdQozebdx42dQuWAzngDjv+VQX14+lWNrfi2ZRDqCM7lvmm+Q5HPOM euOvQVW8GPEui6r5nmqokhGUIXP3uMnp+HNO8Uhj4djc2skKfawFMhI3/IegPb3I5oA6awiitNUW 4MObG4QFpJG+9G3K5P5cdMjoKbawu/iPdFa3M6Ccu0z/ACRx9ecHlu3P6isXQL2XUvCsUQ8yeawk MLIH2qsbcoxPoDkVq6ddP9vtYy4j3suyOLv15x6epP6UAUNAW3ufC0cQYxyw6lJ5jLyXdgc7e/TH TmqPjC18vw1YuLcqGu2yzLyvyDA9s/0q14Uk2eHbh2A/5ChwM8sdp49h+dR+JrPUL7wtbTQRySql 43miLLY+UAce3Pp16UAcIACccVa+wXUdkt49tKtu52pKUIRj6A9K0NG8MX+pXiJPE9pbBgZp5l2h V9s9T7Cum8YNCPC629kCLa3njVBIfujDYx7+tAHB49O9IF5/nSE7V68mkBIHXnvQA9wAtMOOxprM c9+lN/h579KAHAFzk4wKeB3qIt2oDckk9KAJicD3qF8E4HSkZyw60nUYHXvQA3vxwOgpHYgAeneh mwOOtNOevpQAgBJ+tTq+1M9+1VjnGfzqRMlQaAFYk5phJzx+NSHHTv3ppyBg9TQAxuKb3x1NP24G TUZJ3Z/GgAYDp0ApjYJ6YpSScUxmwaADt6YqRGA5qLOBinLzQBOhJBPTPSpEyeT+dRjPTHtT93PP agCZGBIqXdk9KqqakMmVoAV268/So+4x2p2Mn6UHCigB4AA9cUDk5pgJI4pUOWJ6CgBz52/Woscj sKdI2enXpSc7en40AKfQUoXK5P0FCoTgnrUgAGCOvpQBHt2j1pNp/HtT+pweKQcE+lAACfWnD60w nAzTTIT0oAC3z7vSkLZ60wHJz1FIzACgDr4vHvl2Nvaf2JaN5EIh37mBKj+XrViP4kXMHCaeigjo LmQAdhjntXChsdjj607O5hx0oA7Sfx5NcQgRaZapKCG8xmZ+R7E89O9c3eXlxqF09zdSmSVurH9A B2A9Kphv16UpbHFAEiySRSo6MVdGDKw6gjoa6ZfHF5P5bX1la3dwjbhOwKMemM7SAcf1rlgec44q RflXd3NAHWXvxFv5nDwWVtbyqMLJy5+vzd/T0rlZZ5biZ555Gkkc5Luckn1qEjLYJpRxyOgoA3tA 8QvosE8K2Udwk7Kx8x2GCucYwfepda8WXOr2TWTWkFvC0olITJORnuenWufGAAc59qN2WxQBpaJr LaLcTOtulzHPHskikJCsM5Gcelb1v4+ktVVrfR7NJF/5aFmJP156e3QVxxI/EU8EtxQBv6f4rGna W1kdMgn3XDT7y7KckYxxV+L4gTRKEt9MigQHJWKaRQec469K5BhxkDpQoO7GfrQB2Z+IM0haSTSo ZJGJIaSZ2xkYxyay9Z8Utqum/YRp0FqhkEjGNmJJGfU+9YmO/YdvemkY69aAE6tS9vYUg/lRkscA YFADcFmz1FEhHb0/Kn88gdKiY5bHYdaAEB4znr7U1jwBS9D/ADprLxnr9KAELfjS7j0z2prdgKVS M5POOlAD9uBk8k1G7ZGPypWdmzxTMnGT07e1ACc5x+Zp4bH/ANem4FKeF5oAXJ3c8UjvSM5IBYkn 3qFyetAEhcnvTGPOPamr60vbrg+tACEnsajY88Zp56YqNumeKAHfhT1P5dqYOvsKenv3oAlU4pQf amZ4oXGeaAJQak3HI9RUS46mgP3oA67w74PGsaS2pT3jxQ+Y0SJDCZHZgByfbJHua57VrGbS9TuN PnIMtu5RiDwa73wJGq+GxNb39zaSy3LK7BEdARj7uQdrYPWsTSPCj+IfEmoLe30i29vdOktw2DJK 2Wx7AkLnNAHKj7uKfxjj8a9D/wCET8JXEl5Z2jXxuNPcJcN5o6noQCMYzXHeINIOham1n5hmQoJI 3I2kqfUdj1H4UAZ8UavIqtkBmAJHaur1vwbbaVpM97HfyTPCyLseLZnJ9c1ykR/epj++P516trUO n3+mXcOoXTWlrAySsyjJbGB155JNAHlQIHvQO5rtNS8E2Euni80S9Zgyb4xI25ZRgnCnA54PX6VR 8I+E49eikur24a3tFcRIVIDSOeoGfQUAcu3A96ksrK61K8S0tI/MlfpzgAdyT2A9a7hPDfhXUpru 0sVvlntJhCzmYZJ55UEYIyD6Uzw1p1ho+o31nNHJLqccblW3funhOMH6+1AHL+JdHTQNTjshK0h+ zo8hbGN5649uOKi0LQr3X9QW3tlwisPOlPAQH+ZPOB3rr/EM3hSTU421sXcl2YF+a2OE25OPxHNP 8JS6THossumRSrcbo/tRnbKo2GwV9RQBw2r2SabrF5YxszJbzNGGcDcQPXFUCc8Z4rsvFD+E/tGo bY7w6rvbJziLfxyB6Ung7wZb67bC81K5a3tnk8uEIQGkI+917DNAHHqMLggdc037x716BbeHPCeu W8x0wXsDQTGN2aYEjHQhSOQfwql4d8K6fcz6pp+teZHcWjptmjkwu0+nBzng/SgDj+AoDEgY4xTF OSeenWvStQ8BaFZzEo9zdKzlAqzBShwOORyeRXC65p0Wla3c2EMpmjiYAOevIBwfpmgCOytbi/uo 7W2jaSWQ4Cj/AD+taviTRF8Pz2lq0pklktlll5BUNkghSOo461oeAjpQvJvPimfUljlMOGxGU2c5 569a2PEM3hd7y0bX1unnMGF+y/Kqrvbg+4OfwxQBy2ieHpNdhmlivYLcRMFIkBJORntVTV9Jn0bU 3sLhlZkCsHQ5VgRkEV0vgtLVrLVXZnjtjOgQEZOOSMn6Vu3fh7w3qms3RmvZpr6WNJPs6SbWhXaB jG3nA5oA8zwRye3Sm967C58CSjXLays7xJ7W4LHziQDGF+8GHqOPrmr954N8MafqMGmT6neG7uED oxKhCO4JA46H16UAcCPvVajTanTk11Ufg/TbfWoImnnurOaGQrg7HSVF3YJxjG3ketXm8MeGY7m2 WfU7iE3JKxxORnIJGSduB264oA4YoMHNAjIOeldZ4h8JQ6fZG/sLlpI48edDNw6ZOAR0yM/lXKs3 zbRyPagAIPQCh49oAPHeu00HwzpOp6TYSzJKk9wWVpVk4BDEfd/Cpl8KaDf2rmw1GVpYmKNKTlQR 3K4GB6etAHn7AnikVSBgV0Fh4ZubnxC2kykR+SS00o+6sY/iHrkYx9a6Gbw34UtNQttJdrue5uYT IkgmCpnnAzjHY0AefEDGajIAPQ11t34atdO8QadFL5s1heSBCNwDqfQkDpznI7VuXHw/0AxeZFeT ltznyxKPmC4zgkY4z+tAHAaXpsuqahFZwYDyHqeigDJJ+grrX+Htu9puj1SRJuAqyRDaSc4zg5AO DWppWkaBpkiXEFvc/bpUmESPNuUqEGfTjk1X8QeKotGhItzKNSnhBjdVBhADHGQe45GaAPOLmKS3 uJIJRiSNyrAHoRxUZOBx3rqPCfhYeJnuL7UbpobYSBPMDANLKxzgZ9uv1Fa8XhrwjqN1fWFgl+Li xmETuZhljkjKgjB5HtQB5+OScmn47kda24/Cl0/isaIrLyd/ndvK67/y7etdh/whvhG3ngsJbq4m u7mNpIj521WxxgEDGe/foaAPNY43lkWONGd2OFVRkknsK2td8NSaHpGn3F07C6uncPGCCqAAEcjv zzXUWvhnRdD8QafNNJcyrczItohYZSUH+Ijqp459qm8QT6A9jZjX0n8sTSCFLXqnyrncc85G39aA PMnOTioiCauaqbBtTnOmLILPd+6Epy2Md6qZ9BzQAAZOKDwKM8009aAEJzwKaeT2FO/CmkUAIDxU iGolGT6CnjoaAHlsU4HFMC9zUoUd6ADGB6mgjmjOfp2pdv8A9agD0PwKksvh+MRR7tl0+7egYDIX 7ueM8f8A66g0K6uF1nXbT7FcS2txeODJDHvMT7m4IHUEdqr+HPEWiaZ4ft7W+lumljuXleKNCAwO MfNn2qLTPFsGm6vqo/0iSwv7kzq0Z2PG24nOPocfgKAO008aVdXMhtLm3k1BYysxgm8uTaOzqfvY x3Bxj8a4TxpZTW2s/aZL5r5LpdySseRjgr+HqOK3bXVPBFlq0mueffveOGYIkeAHYYJ6cf8A165f xDrZ1q9SRUaK3iXZDGzZKjqcn1NAGZHgugPQsB+tej+MIzF4YvQIvJUyxAbT9/kcn06enpzXnELq s8bPnYGBOBnjNd5q3i7w5qthc2s/2+RZWTgADaAR8y56EY6dKALvhyOVtA0WbBEUaNu2r281uPf3 /lV3w09nHpek+RD5gMkjhsYVW8znqRk45x7VgzeMdD03SIrTRY7i4kjhaGJpQY/KyDl++Tkk4HFZ PhPxbFokUlpfwSz2rSebG0bYaJ/UeoNAG9oWr6TFqd5HpGiajc3c7MZ1BRgF3HJALDHXrTp5Ul8a ySPp9xCf7LyIrhQCT68ZGPz6VUtfEHgzSLi71KyivZrq5XHkmMqi5OWAJPANYMPi+ZfFo1qSH9yV MJtw5OISMYz3I6+5oA0PFej32r6/Etlb/MLKN5fnGyEZPVskY981Z8J2dxpkeoWtzZE3STw/KSAo GGwQ2cc545GfWro8Z+FWeS4P22NpUELKEbJRTuUcHGc5H0NZFj44t1127nu7Fl0+6jSMRRH5ogmd hHvyfzoAqa14c1bVfE2ryWNtvjS7aPezqgZ8A7Rk8n2rvNB+y2mn6NHHbszxWoJYqFCtzv6nkg5z 6ZrCk8a+GYIpZYorqeR5TcGFkZVeUgDnnGOAe/I4rK8PePYbMzRaxbSypJO88ckTf6pm6rjupoA0 /CusaTELq30LQdTuXkUNc/cfaBnBGWAHWroeSTXtbliga3leO1XyLnCv905IwcD2OaybHxD4J8Pr dzaXDfXctzgNDIhRQuckBs9M49elV9B8XWKXOrX+s+aZrpo/KjiXPyrnA+g4oAr6/wCINY0TxBe2 lpeGOPer4ADBW2jkZHFczPPNdXEtxO7STTMXd2PLEnJJrT8V39hqniCe/wBOaUxThWIkTbhtoyAP TNZKkAFvSgDe8GbP+EjVWj8wLbTEJj7x2GtbxZpd5q+qaclja5l+wl3RXBWNBI3zFsnjmuW0XVZd D1q31BED+UTuQkjcpGCPyNd2vjPwo05uD9thcxmDARifLJ3YyD2PT6mgA8E2FzpcepW9/ab5Flid EzuVuCQwIOCPQ+1RwmT/AIWlfqo+d45Mjb0/c9KitfHmlFr1p47i2ikeNIYYB8wRQeT25JPHTmqc fiDSIfHc+q+dcfZZoSokCZYMYwp4oA6O50u/kaxSC9ksvLaR5p48ZVMKMAd8nA/oKkVtDsPEFgty Lq/1C62pFJcNvZFPG7PAGcnGATWXN4z0W3Fumni7MbGRboyL87A7drKc8HK9Bilk1/wo2r2eqNJf yXNvgKwj2jAJwTnuMnp1xQBuGELJp8clsEO+5KIOjHyf6/Tt0rA8XoyappGYxEwjHydQv70+/NXh 4z0cvBMkl3uj87d5g3MCyADB68msfxBrWl6lqOl3Vu1w6wn98so+YL5m78TyaAN/xPBLFpOqSSA4 fG3kYGWHX/8AV+JrztFwQO9dn4i8S6He2F/FZtdPcXOCjSx7VAyDtxn261xsRycmgD0jwrDt8PWT JHuyk5aTupy3H+fyrE8ICW5sdRhgGSDGSfz6/wCR9RXTeHBC3hnTZDJI6rFISiHAOCxIPb2z1rmd M1/wnpOnzG2S/eSZhI0LrjJA4TcP4eTz1oA3rJ7Majq8j75Jlito5FAyxAzz14HTnPpzVDV9R0bT /FNnJNpt5LqEcMXkrAy7SSOBjdz1rl7bxVND4nn1t4NyXBKy24fAKEY2g47YGPpW3ceIPBl7qNtq lwt9FcWpGyPyy4YLyAxzzg0AaurXD3dxo6z6Xd6ew1RMvOiKg+U/LlSetZPiq/1LSrO01C3lWGb7 TIoKYYFSvTHPHtVC78aWuqeI9OkaF7XTrafzpdxLM7cjcfTjt9aZ4s8RaJrukRW9mbhJ4LgugeMB WUjqTQA3wxq19rniJf7QnNwYbOYQxlQByvI4H17VD8RAyapYBk8tvsYyn935246nP1qj4R1mz0TV prq8aUI1u8Q8ockn36j6ijxjq9lrd/az2LzNFHb7D5wAcHcTg4+tAHceDTbR+HNGAhMztK7k4AVX 3jqSRk4wce1U9E1bSIdcv10jRNRur6d388KUZdu4liAWHfvXO+EPFUWhJLaX0Es9nI4kXy3w0Tju P0z9K27TXvBelXt3qtlHey3dwpHkmMqg3HLYJPGaANcyCXxDdzfYZ7WT+zIxsuIgX2+YASApx04z mub8YTXseuaT9l3JcJbIIAhUsGLtjkcHOf1qkfFdwPE6a0IMRoPLW2Ehx5WMbN39a3rnX/Bmo3Fp fXceoQXFowMaKm/IB3YJz0zmgDOMPiifX9Hn8RW84t471I03qoVWJyVwp4zVjxdY3Gpadpdta2Z+ 0SXciRwoQS3yrn6dPQYxWZr/AIwbUr21k0+3a1gtZvPVWckvIP4j6cDpW+vjjw7dyQ3d1DcW9xCx lCqrModhhgCD0I/kKAOGu/D2q2M8VvJaPJJMCY/I/eBsdcbfTvVG7tbmxuHt7uB4J0OGR1wRXoVt 8QNKh1ZoUt5YrARFFuNpMpYkEuRnPQY65rmfGGs2Gs6hbtp8Uyw20PlCSY5eXknJ9OvAoA50jikH vTyvrxTSOKAGnGeaaTTyuBTSDmgBB6U44HFMB60ufWgCQGpF5qAGpVY4AoAlH6Ud+eKaOBk9B+tI SSfegBWbinISKZ1P0p6DAz3oAfuJ49KaTk0E4HPemBuaAJcgD3NNLcAU3fnpTTnmgBd/OAadu/So 1Xml6n2oAXfz7Uu3dgmmKvzU5229OgoAkVe/+RSHHU/hUYkJ79aQye9ADmIHvUf40E5prN2/OgBc 88d6fu596iJwPc0gYg5zQBNuB4PSnb8YAHAGTUanqcimBicngelAD2bLUdjn60zqc04tkUALnvin xtgkkjmoiSRScj3NAFsS846+lTKcsKpx5yParUTYXPr3xQBaACjBpw4+lVw/HrUgfI5NAEuSVLE9 acq46dKYrZxSvIEXA5P86AO90nxN4fsdCsLa4uZY7hIHRhHBuAJLdT+NedOVBKI25VOFYjGaaX3H PvSsVVQQSXPUdgKAI2btxUch43E49qVjzUbZY45NACEngetB4GPWnAc018g5PegBDnABB56Um3pT lXJ9u5p+DkjjFADUGe1SjH1xUYHPWnLQBKGBP0pjvnjuaQHAxnPrSYJ5x+NAEbNzxTSelPZOaaRn 8KAAFQM0mQTSYpKAHMQOAaZkdfSg+ppp4oAUtTM+9B4pBmgAI+bFOC560Y+fmplAoAYE7kfSnqtK MM3A4pWx90dKAGM2TgdB0pVpMYpc88UAL04zxS7sUxjQvPNAEmeCc1Hj9afweKcBmgBgGBmlxgY6 0opCw3UAOI+XryaTAApAecUo5PHSgBPpUb5xUh6+lNb5m9hQBEODntS85zTiO3500CgBf6U3pmpd vy9PrSbO5FAERyOaTp71NszTQmTQAzkLj160D0pxXLZpwHPTmgBm0k0pGBnNOKgHjtQ2MUAMHJzz SgZJ9KMjOOgoB4oAkBwPapFfjOeKrjLHJ6U4N0HpQBZWTA6nFSB8kMTVZWJ4Hanq+ByaALW/byaj Z8nOaiYk96QmgCVGA68UjOOtR7+Oabuzz0oAUkd6X0wPwqPPOc09emc0AKOKQrk/yFLwKQfezQAv TAozQQc0oHOaADGOnU0uBilRQcls+2PWjac4oAZUqqMUwLz7U/B6UAMcVGwAqV+tQvknAoAbjJ4p Gp4HH86Y3JoAafWkA96dik9qAGlc0Be9OxRQAw/f5p+7PSmtw1Ln0oAeGCjFJupnWgdaAHFsjNJu xSNwKjzzQBLnPX8aFbJph6daVCKAJhTt/GKhZ8dKTfntQBNu60000HmjPegBwJFSA4GaizSg5NAD +1LjimqcU5WoAay//XpB16UrHNMZsGgCTI6dqQtzTM5HWgHFAEuPl+tNb5U9zSbieKZI27pQAmaV Wx8x60zPFNDYOTQBK7gcenWmM9MJPrzSE0ASFgTwAB1xSEkCmg0E55oAkHAx3NKKjBzx+FPTngUA SKOMkU5QCfQelMLdhSqQPbNAEucU1mGBiml8HkUjNg4BHSgBc5zntTsjGaizkjFKW4oAcMA8mn5q HzPTtQGwMnj60ATgg9evbFOB59arh/zp/mHHGPagCU+gPNL2xUQbHNPVzz+tAEoGMU8D06VBvNSB sAjPNADsfNk0VGXNJvPU0ADnnFRE5pGf0phJ6UAKWNG47QPxpuf0oDY4zw3WgBen40nGfak3At1w KQt6UAKSKXNMpScUAJJ9+kyAPrSzcNUJbJzQBNuwKUcdajU8ZpSfSgBxOajzznFLyRTSDQAE5pVO Kb/kUvTigBS2aVT3pvvSj1NADyxBx3oznvTDmlxjAoAfu7U5SMVGRjAJoJ460ASl80m/9Kb260h9 TQA/fxnuaiLc04cnP5U1jg5/KgB5YBdo696bupv9aAaAJAxx9aDxTQc0pJPSgBO30pOp4pevFLgd KAG7aaeuKkbimYz7UAHUd8UDJpwyBjOAe1IMUAOUDbmnL7nnrTc5xikzjv1oAeTk0ueKjD8euaN/ HvQA/Oe9HQ/WmBsjFKG5A6UAO6UjHHpSbuQMY96CNxOOR2NABn1pc89eaaflwCOKUfzoAcPwNOB/ XtTR096Ut60AOJ4pwPHWo+cA804GgCXdgZ60qknFRZOc04NgCgCTAx7UpOFpnmdSO1Nd80AN7800 sO560Z4phoAWjJNNJ7elLkqCOOfagBDSjNNJFGeP5UAOB4pMnPFIWAphc44FAEtyOagqxcDJqDH5 UAOX0p+MmmIcU7OKAHnAGKjY5OB+NHJpCO2KAEzThxyaaRg0u0nAyKAFHcnr2pByetHU9aQrxxmg BSc/QU5Dxu71Htp6jPPb1oADy1KCM0iryTS5GfSgBScgVo6Doza7ftbrMIYo03ySEZwPQD1rLLfr V/SdXuNEvPtNttYldro4OGHpx/OgC3q2i21lFBcafqCXttNJ5W8DBRuuD+FTr4Ulub/VbO2m8ybT 3jjiUrjzmdwo5zx1qprHiGfVlhQwQ20UJ3LFCuBu9T71fPje4E73MOmWkNzPJHJdSoX/AH5Q5AwT hRkAnFAENz4N1KGzSdWt5ZNspkhSdCw2HDbQD82BycdKYfB+tLsby7fYyM5cXCbUCgFtxzgEBgaL XxTLaWccUen2rXEHmiG5bcWQSEluM4PU4yKtX/ji61CymtTYW0SSo6fIz/LvABwCcAfKMAcCgCrp vhqa58QS6TeGSKSGJ5WECiVmCpuAXkBsjGOe9aU3gfy51jS5uF3xRyCKWEJKu9mGGG7A+7nr0NZc PiKZNWOoyWsUu62+yvFuZQyeWI+oOQcDtVpPG11AYo7eyt4oIAoii3O23DFjliSTksaAIR4O1xXj jMEIeVC+DOvyKF3EtzxwQayp7Oe01BrKYIJlcIQHBXJ/2hxjnrW6PG9ysdvENPttsOejuCDt2/Kc 5T1wOM1h6rqMmr6lPfyxxxPM2SkYwo4A/p19aANH/hENdd0T7Iq73kQF5VVcxkBuSeOSMeueKSLw hrkzRqtkFMqsy75FUEK2w9T13cAd+KsX/jbVNQ0+azkWFFlSFN6AhlMfce7EAn6Cnaj451TUYTGy wxA3Ec6mMEFSgAAHsSoY+9AGZeaDqdjYm8uLby4hCk24uOVckL+JIPFXD4cI1W6sEuNzQWi3Cnbj eSqsF9vvYzUmp+MrnWIjBfWVtJAZml8sblHKhVXg9FxkD1pD4wnCb1061W8eGOCW7G7c8aEYGM4B IUAkDNAEsvgfVoLQPvt/tguJIWtxcJuBVQ2F5+ZuTwOeKqp4Q1uWOGSOCFxL0xOmV+Uv83Py/KCe akt/F0sId2061lm+2S3kMrlswyOADgA4IGOhzVl/Hd3JZPamwtQHQqWDOMExlCQucDgnoOtAEmme BZri2kku2ud6zRRotjEs4dXXIfO4Db9KhuPBF0E22k32udpWiVVUKpIlaPqT/s5qK38XOunpY3Gm QXEMQi2ZlkQ5jBAPykZ68ipH8c38x33FrbSkyea2QQD85fHB45OOOeKAKp8H6yI5ZBHAUhxlxcJt YlS2FOeTgHitWPwFJL4gtdO+3AW89mLprjZwnyjKYz13FR+NQHx7eCWSQ6fa7mjEYJZySACPn5/e df4s9BUcfjrUkBVYbcqZ45iMH+FAu3PocBiPWgCnH4S12eOCZbMMs+0hfMXcgYEgsM/KCAeTV6Tw bdpY28qTxTTXCqyiORDEMuyj5846LmiLx1qMcFvGbe3do0WORm3HzUUFdpXOBkHkjBOBTovGklrH BDbaXZxW9uoVIRuYYBY9Sc5+c80AZEugakmsRaWYUa6mUOgWQFWUjO7d0xgHn2q3H4R1aR9qpbMp KhJBdJslLAlVRs4ZjjoKln8XSz6jDqA062FzEgi3sztujCspU5POQxyetJb+KxbhY49HsRbxSLNb w/PiKVRgPndlj65znAoASLwfrM0SSiO2jDqjYluUUqG4XIJ4yeB71jzRvBNJDKhWSJirr6EdRWnJ 4mu5pBJLFEW2wAnn5vKbcD+J61m3dw15dzXLKA00jOwHQEnJFAEY96XPtTc0meOnFAEgOaXNR570 E+9ADtxB60m7J64pnXvS0AOJphIzTiMcmmnpQAg5b1oJ54o9+lGD09aAE5zxSkH/AOvScdBwKOp9 BQAhHQ+tGO3elPX29KaTzzQBZuO9V+1WrjvVPvzQA4dcU6mBueBS5zQA/PPpQBk+1Mz096XNAC8E 8mkJHT1ppPFJnIoAeDgD86Mn86YCcelKSfWgBc4pdwC9aYf1o7ZoAeGyMD9aYTn6UucLx3ptAC5p w45NMFLnJ4oAdSnikHIyKTk96AFDAE8UA8UmMnFJ3oAcZD0zRnuaTbzRjAzQAoP60uR0puacBQAn Wgmjb82PXmhsA8Dp60AGcmjGDSgYHP1pcYWgBoznIFLjmlPBxScAGgA+lN+op3HcU4YIJ/SgBg7+ 9O4z0pWAVc+tJgADIoATuBzntTsccDmlA9epppz0oAU/KcdaOg9zSYzzikOP60APB4x+dISNvoab uwvPOaO/JoAXIx7+1L7c00dTyfel685OKAAn86XcQu0AYznpzTQf1oB5oAecEdaTIx9KZnJ+tHv6 UAPLhueB3ppOR70ntSZwaAHbsUmetITyOBSjOPegA444xSnJ96QLzQTk0ABJpCeeaUkjvSE896AP /9k= --001a114c6d8c04ad2105342dea40-- From nobody Tue May 31 23:34:20 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52AD12D148 for ; Tue, 31 May 2016 23:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlgCXbgxf7ix for ; Tue, 31 May 2016 23:34:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9593F12D114 for ; Tue, 31 May 2016 23:34:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1BD97E75; Wed, 1 Jun 2016 08:34:15 +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 y2HU4ErGVWaf; Wed, 1 Jun 2016 08:34:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Jun 2016 08:34:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FAA42004E; Wed, 1 Jun 2016 08:34:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id C9yvnHVYBRMp; Wed, 1 Jun 2016 08:34:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2DC020047; Wed, 1 Jun 2016 08:34:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D1C053AFFA6E; Wed, 1 Jun 2016 08:34:11 +0200 (CEST) Date: Wed, 1 Jun 2016 08:34:11 +0200 From: Juergen Schoenwaelder To: Joel Halpern Direct Message-ID: <20160601063411.GA23984@elstar.local> Mail-Followup-To: Joel Halpern Direct , Susan Hares , i2rs@ietf.org References: <005601d1bb7a$5aacbfd0$10063f70$@ndzh.com> <7147944e-fe4d-4ea2-47af-1264188f426c@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7147944e-fe4d-4ea2-47af-1264188f426c@joelhalpern.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, Susan Hares Subject: Re: [i2rs] ephemeral RPC? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 06:34:19 -0000 On Tue, May 31, 2016 at 04:27:17PM -0400, Joel Halpern Direct wrote: > > I think this may be following the paradigm in Juergen's draft, where > accessing data and in different data stores uses different > RPCs? Is that your intent? > Joel, which part of my I-D made you believe this is the case? Several core NETCONF RPCs do take a datastore as an argument and this is just fine. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103