From nobody Mon Mar 7 06:39:41 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6511B41DD for ; Mon, 7 Mar 2016 06:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW2RRHNOaZxP for ; Mon, 7 Mar 2016 06:39:38 -0800 (PST) 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 1CB541B394E for ; Mon, 7 Mar 2016 06:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=627; q=dns/txt; s=iport; t=1457361578; x=1458571178; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=mAJBvBGLTlfoXlwaxQrKggraiEes38JkRgRALqmCbpU=; b=XTI2rcWbdSBqB9eZEXiN0afcOEr3WmanbR4kOmFt9uG0hkmw33IIQLkg xcE1Ol1n9mrdIUh+YUQSQ6fpw4OVuv7sTQTlKkZSyDLtmG3/sdelxkBIK /gjPFMr9mT+GS92BcSZFSFoKKOHxBCnHbO/+dh4f+9ryDT4VZVIvWxpV3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQCNkd1W/5NdJa1cgzpSbQa4J4ITA?= =?us-ascii?q?Q2BaSGHGDgUAQEBAQEBAWQcC4RIOlEBLBJCJgEEEwiIGg6gO55YAQEBAQYBAQE?= =?us-ascii?q?BAQEBFQSGF40xBZcqAYViiAOBVI0tjlQBHgEBQoNkaog/fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,551,1449532800"; d="scan'208";a="246636638" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2016 14:39:37 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u27EdbKa029342 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 7 Mar 2016 14:39:37 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 08:39:36 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 08:39:36 -0600 From: "Eric Voit (evoit)" To: "i2rs@ietf.org" Thread-Topic: YANG Subscriptions @ IETF 95 Hackathon Thread-Index: AdF4fh60A3JTmAKSSvSrJtuGkOCEtgAAIHqA Date: Mon, 7 Mar 2016 14:39:36 +0000 Message-ID: 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.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [i2rs] YANG Subscriptions @ IETF 95 Hackathon X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 14:39:40 -0000 OpenDaylight's latest release has a YANG PubSub client: https://wiki.opendaylight.org/view/YANG_PUBSUB:_Beryllium_User_Guide This allows a OpenDaylight to subscribe to existing YANG models as per the = NETCONF WG draft: draft-ietf-netconf-yang-push This NETCONF draft is based in the I2RS requirements: =20 draft-ietf-i2rs-pub-sub-requirements I am hoping to extend these capabilities in the IETF 95 Hackathon https://www.ietf.org/registration/MeetingWiki/wiki/95hackathon If anyone wants to join in, or if anyone wants to know more, let me know. Eric Eric Voit Principal Engineer evoit@cisco.com From nobody Mon Mar 7 11:30:34 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfc.amsl.com Received: from ietfc.amsl.com (localhost [IPv6:::1]) by ietfc.amsl.com (Postfix) with ESMTP id B2DE61CD9D1; Mon, 7 Mar 2016 11:30:33 -0800 (PST) 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.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160307193033.12555.75962.idtracker@ietfc.amsl.com> Date: Mon, 07 Mar 2016 11:30:33 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-03.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, 07 Mar 2016 19:30:33 -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-03.txt Pages : 11 Date : 2016-03-07 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 8 13:24: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 2291B12DB05 for ; Tue, 8 Mar 2016 13:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.439 X-Spam-Level: **** X-Spam-Status: No, score=4.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQIvhOWDgNV6 for ; Tue, 8 Mar 2016 13:24:09 -0800 (PST) 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 4062912DB07 for ; Tue, 8 Mar 2016 13:24:09 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Tue, 8 Mar 2016 16:23:30 -0500 Message-ID: <00bf01d17980$c3256e40$49704ac0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01D17956.DA4F6640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF5gAgOGSz4MPYBQPeCepKETns4KA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' Subject: [i2rs] I2RS interim on 3/9/2016 is cancelled - I2RS will be held on 3/16/2016 at 10-11:30am. 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, 08 Mar 2016 21:24:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C0_01D17956.DA4F6640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS interim on 3/9/2016 is cancelled. There will be an I2RS meeting on 3/16/2016. The agenda for the I2RS interim on 3/16 will include the following: 1) Requirements for Large data flows, special actions (e.g. rebalancing ECMP or re-calculations), and security actions, 2) I2RS protocol strawman, 3) I2RS FB-RIB, 4) I2RS Service Protocol, and 5) I2RS BGP IM/DM. Sue Hares ------=_NextPart_000_00C0_01D17956.DA4F6640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS = interim on 3/9/2016 is cancelled. There will be an I2RS meeting on = 3/16/2016.    The agenda for the I2RS interim on 3/16 = will include the following:

 

1)      = Requirements for Large data flows, special = actions (e.g. rebalancing ECMP or re-calculations), and security = actions,

2)      = I2RS protocol strawman, =   

3)      = I2RS FB-RIB,

4)      = I2RS Service Protocol, and =  

5)      = I2RS BGP IM/DM.

 

Sue Hares =

------=_NextPart_000_00C0_01D17956.DA4F6640-- From nobody Wed Mar 9 10:51: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 775A012D5F4; Wed, 9 Mar 2016 10:51:49 -0800 (PST) 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.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160309185149.26127.76467.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 10:51:49 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-protocol-security-requirements-03.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, 09 Mar 2016 18:51:49 -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-03.txt Pages : 13 Date : 2016-03-09 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-protocol-security-requirements-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 9 10:57: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 9E0D512D915; Wed, 9 Mar 2016 10:57:24 -0800 (PST) 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.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160309185724.28257.67825.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 10:57:24 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-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: Wed, 09 Mar 2016 18:57:24 -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-04.txt Pages : 11 Date : 2016-03-09 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-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-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 Tue Mar 15 06:01: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 3B45D12DA21; Tue, 15 Mar 2016 06:01:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315130123.29388.33945.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 06:01:23 -0700 Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (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, 15 Mar 2016 13:01:23 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some comments; I would consider the first two as significant/major, while the others are minor comments and nits that came up as I was reading (not always linearly). A. There are a couple of places where operations are characterized as "safe" (1.1 and 6.4.1 — see below), but no explanation as to what "safe" means. It seems to me that these mentions of "safe" go beyond authentication and even authorization to perform a specific operation, to the content of the operation itself. I would like to see some discussion about how to achieve it, and/or (at least) what the impact may be. - 1.1: "I2RS will only permit modification of state that would be safe, conceptually, to modify via local configuration; no direct manipulation of protocol-internal dynamically determined data is envisioned." - 6.4.1: "Routing elements may maintain one or more Information Bases. Examples include Routing Information Bases such as IPv4/IPv6 Unicast or IPv4/IPv6 Multicast. Another such example includes the MPLS Label Information Bases, per-platform or per-interface or per-context. This functionality, exposed via an I2RS Service, must interact smoothly with the same mechanisms that the routing element already uses to handle RIB input from multiple sources, so as to safely change the system state. Conceptually, this can be handled by having the I2RS Agent communicate with a RIB Manager as a separate routing source." B. Section 3. (Key Architectural Properties) says that "some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement]". However, as I mentioned in my review of I-D.ietf-i2rs-problem-statement [1], that document has a very, very sparse treatment of performance and scalability to even attempt to call it a "Key Architectural Property". C. Section 1.1. (Drivers for the I2RS Architecture) says: "I2RS is described as an asynchronous programmatic interface, the key properties of which are described in Section 5 of [I-D.ietf-i2rs-problem-statement]." Why isn't I-D.ietf-i2rs-problem-statement a Normative Reference? It is considered to define the properties of the I2RS which are used in building the architecture. D. Section 4 (Security Considerations) mentions the "I2RS security requirements", but there is no reference to draft-ietf-i2rs-protocol-security-requirements. E. s/I2RSS/I2RS F. There's a orphan "In addition, the" in 1.2. G. Systems and sub-systems. The text mentions "routing system", "Internet routing system" and "routing subsystem" many times (obviously!), but there is no description of what these terms mean — I'm sure many/most of the readers have an opinion of what these are, but I think it might be good to add something to the terminology section specially because statements like this are made: "state on a routing element beyond what is contained in the routing subsystem"; that way there is no questions as to what is in the routing system, or sub-system and what is not (at least for this document). H. 3.2. (Extensibility) talks about the initial scope of I2RS (without references). To extend the usability of this document, I would suggest that the statements of this section be made independent of the fact that the initial scope may be narrow. IOW, I think you may want the protocol/data model to be extensible regardless of the size of the initial scope (even if boiling the ocean to start with, there will always be opportunities for extensions later). I. s/an definition/a definition J. If out of scope, I don't really see the value of 5.1. (Example Network Application: Topology Manager). However, Section 5 does say that these types of "models are, at least initially, out of scope for I2RS" -- as I mentioned above, if this architecture is meant for the long run (not just the initial scope of the i2rs WG), then the 3rd architecture is valuable to illustrate. IOW, the WG charter can control the scope, the architecture should be thought out for the long term. K. s/to be to be/to be L. Many protocols (routing-related and otherwise) are mentioned without references. M. I don't think you need both of these references: "Yang 1.1 ([RFC6020]), Yang 1.1 ([I-D.ietf-netmod-rfc6020bis])". [1] https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ballot/#alvaro-retana From nobody Tue Mar 15 09:10:24 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 9A60012D52E; Tue, 15 Mar 2016 09:10:20 -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.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315161020.31261.9202.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 09:10:20 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-usecase-reqs-summary-02.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, 15 Mar 2016 16:10:20 -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 : Summary of I2RS Use Case Requirements Authors : Susan Hares Mach Chen Filename : draft-ietf-i2rs-usecase-reqs-summary-02.txt Pages : 34 Date : 2016-03-15 Abstract: The I2RS Working Group (WG) has described a set of use cases that the I2RS systems could fulfil. This document summarizes these use cases. It is designed to provide requirements that will aid the design of the I2RS architecture, Information Models, Data Models, Security, and protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-reqs-summary/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-usecase-reqs-summary-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-usecase-reqs-summary-02 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 Mar 15 09:12: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 6B3E712DB03 for ; Tue, 15 Mar 2016 09:12:17 -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 TWbDWpAMb3Lp for ; Tue, 15 Mar 2016 09:12:15 -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 44D6012D57A for ; Tue, 15 Mar 2016 09:12:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: References: <20160315161020.31261.90400.idtracker@ietfa.amsl.com> In-Reply-To: <20160315161020.31261.90400.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 12:11:41 -0400 Message-ID: <028f01d17ed5$5cb8be00$162a3a00$@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: AQD0+mQVEDxpWmKjmpvBtWgYV+K5MaETtXUg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] FW: New Version Notification for draft-ietf-i2rs-usecase-reqs-summary-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, 15 Mar 2016 16:12:17 -0000 This version contains 1 addition to protocol independent requirements = based on feedback in I2rs protocol strawman discussion. =20 Sue=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Tuesday, March 15, 2016 12:10 PM To: Mach Chen; Susan Hares Subject: New Version Notification for = draft-ietf-i2rs-usecase-reqs-summary-02.txt A new version of I-D, draft-ietf-i2rs-usecase-reqs-summary-02.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-ietf-i2rs-usecase-reqs-summary Revision: 02 Title: Summary of I2RS Use Case Requirements Document date: 2016-03-15 Group: i2rs Pages: 34 URL: = https://www.ietf.org/internet-drafts/draft-ietf-i2rs-usecase-reqs-summary= -02.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-reqs-summary/ Htmlized: = https://tools.ietf.org/html/draft-ietf-i2rs-usecase-reqs-summary-02 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-usecase-reqs-summary-= 02 Abstract: The I2RS Working Group (WG) has described a set of use cases that the I2RS systems could fulfil. This document summarizes these use cases. It is designed to provide requirements that will aid the design of the I2RS architecture, Information Models, Data Models, Security, and protocols. = =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 Tue Mar 15 11:27: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 324A212D59F; Tue, 15 Mar 2016 11:27:28 -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 cXQobJ2cpLkq; Tue, 15 Mar 2016 11:27: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 0160012D68E; Tue, 15 Mar 2016 11:27:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Alvaro Retana'" , "'The IESG'" References: <20160315130123.29388.33945.idtracker@ietfa.amsl.com> In-Reply-To: <20160315130123.29388.33945.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 14:26:41 -0400 Message-ID: <001b01d17ee8$3a10ff80$ae32fe80$@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: AQKvbXVR5HZhLz3siBCyA1d3hNKPy52e5paA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (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: Tue, 15 Mar 2016 18:27:28 -0000 Alvaro:=20 On your major points, and on "L" - I have a few questions. On the rest, = I will correct in -14. Please see #H to preview the text, and confirm = it works for you. =20 Shall I update to -14.txt tonight even if I have not heard from you?=20 Sue=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >A. There are a couple of places where operations are characterized as = "safe" (1.1 and 6.4.1 =E2=80=94 see below), but no >explanation as to = what "safe" means. It seems to me that these mentions of "safe" go = beyond authentication and even >authorization to perform a specific = operation, to the content of the operation itself. I would like to see = some >discussion about how to achieve it, and/or (at least) what the = impact may be. The definition of "safe" from a security viewpoint was a sufficient = enough discussion that two I2RS requirements documents were created:=20 1) defining "safe" protocol - = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requir= ements/ 2) defining "safe" environment - = https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-req= s/ The definition of "safe" specifically also depends on the protocol(s) = selected to be combined for the I2RS higher level protocol and the = "safe" environment. Do you want these two documents back-fitted to the = architecture or are you looking for something different?=20 B. Section 3. (Key Architectural Properties) says that "some = architecture properties such as performance and scaling are not = described below because they are discussed in = [I-D.ietf-i2rs-problem-statement]".=20 However, as I mentioned in my review of I-D.ietf-i2rs-problem-statement = [1], that document has a very, very sparse treatment of performance and = scalability to even attempt to call it a "Key Architectural Property". Response: I sent you a question about what you wanted for the problem = statement. I am holding the problem statement because you have not = responded to the scaling. We have the following things you can see in = other documents: - The I2RS pub-sub requirements documents look toward the scaling of = large data via the publication and subscription mechanisms. = draft-ietf-i2rs-pub-sub-requirements - Potential ability to allow minimal checking on the upload of the local = RIB (in discussion)=20 draft-ietf-i2rs-usecase-reqs-summary draft-hares-i2rs-dataflow-req=20 These are scaling efforts for the inbound/outbound data flows. Other = reviewers had considered these specifics were not valid in the problem = statement, but perhaps we can work through a compromise where we discuss = the problem of large data inputs/outputs in a constructive manner. Can = you suggest any text?=20 =20 L. Many protocols (routing-related and otherwise) are mentioned without = references. Sue: Do you really want all the protocols lists in the diagrams to be = reference? If so, I am glad to do it. This question is also included in the top. -----Original Message----- From: Alvaro Retana [mailto:aretana@cisco.com]=20 Sent: Tuesday, March 15, 2016 9:01 AM To: The IESG Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org; = mach.chen@huawei.com; i2rs@ietf.org Subject: Alvaro Retana's No Objection on = draft-ietf-i2rs-architecture-13: (with COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some comments; I would consider the first two as = significant/major, while the others are minor comments and nits that = came up as I was reading (not always linearly). A. There are a couple of places where operations are characterized as = "safe" (1.1 and 6.4.1 =E2=80=94 see below), but no explanation as to = what "safe" means. It seems to me that these mentions of "safe" go beyond = authentication and even authorization to perform a specific operation, = to the content of the operation itself. I would like to see some = discussion about how to achieve it, and/or (at least) what the impact = may be. - 1.1: "I2RS will only permit modification of state that would be safe, = conceptually, to modify via local configuration; no direct manipulation = of protocol-internal dynamically determined data is envisioned." - 6.4.1: "Routing elements may maintain one or more Information Bases. Examples include Routing Information Bases such as IPv4/IPv6 Unicast or IPv4/IPv6 Multicast. Another such example includes the MPLS Label = Information Bases, per-platform or per-interface or per-context. This = functionality, exposed via an I2RS Service, must interact smoothly with = the same mechanisms that the routing element already uses to handle RIB = input from multiple sources, so as to safely change the system state.=20 Conceptually, this can be handled by having the I2RS Agent communicate = with a RIB Manager as a separate routing source." [Sue: Please see above]=20 B. Section 3. (Key Architectural Properties) says that "some = architecture properties such as performance and scaling are not = described below because they are discussed in = [I-D.ietf-i2rs-problem-statement]".=20 However, as I mentioned in my review of I-D.ietf-i2rs-problem-statement = [1], that document has a very, very sparse treatment of performance and = scalability to even attempt to call it a "Key Architectural Property". [Sue: Please see above]=20 C. Section 1.1. (Drivers for the I2RS Architecture) says: "I2RS is = described as an asynchronous programmatic interface, the key properties = of which are described in Section 5 of = [I-D.ietf-i2rs-problem-statement]." Why isn't I-D.ietf-i2rs-problem-statement a Normative Reference? It is = considered to define the properties of the I2RS which are used in building the = architecture. [Sue]: We can make it normative. I will release a version with this = change.=20 D. Section 4 (Security Considerations) mentions the "I2RS security = requirements", but there is no reference to = draft-ietf-i2rs-protocol-security-requirements. [Sue]: We will include both = draft-ietf-i2rs-protocol-security-requirements and = draft-ietf-i2rs-protocol-security-environment-reqs in that list.=20 E. s/I2RSS/I2RS [Sue]: Thank you for this error. I will change in -14=20 F. There's a orphan "In addition, the" in 1.2. [Sue]: Thank you. I will change in -14=20 G. Systems and sub-systems. The text mentions "routing system", = "Internet routing system" and "routing subsystem" many times = (obviously!), but there is no description of what these terms mean = =E2=80=94 I'm sure many/most of the readers have an opinion of what = these are, but I think it might be good to add something to the = terminology section specially because statements like this are made: = "state on a routing element beyond what is contained in the routing = subsystem"; that way there is no questions as to what is in the routing = system, or sub-system and what is not (at least for this document). Sue: We will add something in the terminology section in -14.=20 H. 3.2. (Extensibility) talks about the initial scope of I2RS (without = references). To extend the usability of this document, I would suggest = that the statements of this section be made independent of the fact that = the initial scope may be narrow. IOW, I think you may want the = protocol/data model to be extensible regardless of the size of the = initial scope (even if boiling the ocean to start with, there will = always be opportunities for extensions later). Sue: I agree. =20 How about this change:=20 Old / The scope of the I2RS work is being restricted in the interests = of achieving a deliverable and deployable result. The I2RS Working Group is modeling only a subset of the data of interest. It is clearly desirable for the data models defined in the I2RS to be useful in more general settings. It should be easy to integrate data models from the I2RS with other data. Other work should be able to easily extend it to represent additional aspects of the network elements or network systems. This reinforces the criticality of designing the data models to be highly extensible, preferably in a regular and simple fashion./ New / The scope of I2RS work is being designed in phases to provide=20 deliverable and deployable results at every phase. Each=20 phase will have a specific set of requirements, and the I2RS protocol and data models will progress toward these = requirements. Therefore, it is clearly desirable for the I2RS data models to be easily and highly extensible to represent additional = aspects of the network elements=20 or network systems. It should be easy to integrate data models from the I2RS with other data. This reinforces the = criticality of designing the data models to be highly extensible, preferably in = a regular and simple fashion/ I. s/an definition/a definition J. If out of scope, I don't really see the value of 5.1. (Example = Network Application: Topology Manager). However, Section 5 does say that these = types of "models are, at least initially, out of scope for I2RS" -- as I = mentioned above, if this architecture is meant for the long run (not = just the initial scope of the i2rs WG), then the 3rd architecture is = valuable to illustrate. IOW, the WG charter can control the scope, the = architecture should be thought out for the long term. K. s/to be to be/to be Sue: I will correct in version 14.=20 L. Many protocols (routing-related and otherwise) are mentioned without = references. Sue: Do you really want all the protocols lists in the diagrams to be = reference? If so, I am glad to do it. This question is also included in the top.=20 M. I don't think you need both of these references: "Yang 1.1 = ([RFC6020]), Yang 1.1 ([I-D.ietf-netmod-rfc6020bis])". Sue: This is an error: Yang 1.0 [RFC6020] and Yang 1.1 = [I-D.ietf-netmod-rfc-6020bis]. I will correct this -14.txt [1] https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ballot= /#alvaro-retana From nobody Tue Mar 15 12:21: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 0B55512D6F7 for ; Tue, 15 Mar 2016 12:21:36 -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 2mTPZZggkiQs for ; Tue, 15 Mar 2016 12:21:33 -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 7B2A412D70E for ; Tue, 15 Mar 2016 12:21:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Tue, 15 Mar 2016 15:20:55 -0400 Message-ID: <004e01d17eef$cc6a3110$653e9330$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01D17ECE.455B9E50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF+77TcK4JFl5BVRW+VHZXMmFyccw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , "'Joel M. Halpern'" , 'Amit Dass' , 'Alia Atlas' Subject: [i2rs] Call for feedback - I2RS protocol requirements [3 weeks 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, 15 Mar 2016 19:21:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004F_01D17ECE.455B9E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: While working on the I2RS protocol strawman, some of the design team and early reviewers have disagreed on requirements for the data streams. Therefore, the chairs need input on the requirements for the data streams. Currently the approved requirements have the following types of inbound or outbound streams: 1) Read/writes - simple read/writes or rpc requests, 2) Publication/subscription - via the pub-sub requirements (outbound data stream, inbound control) 3) Actions - via rpc requests (rpc, rpc-response) 4) Some unsecured outbound stream (TBD) As chair, I reviewed the use case requirements and found 11 requirements for I2RS data flow in the (IC) in charter requirements in the I2RS use case requirements document (draft-ietf-i2rs-usecase-reqs-summary ). These requirements suggest adding: 1) IPFIX as an outbound data stream for traffic monitoring data, and 2) outbound data streams which are data form agnostic (Any of XML, JSON, MTL, protobufs, etc.) over any transport. I've placed the details on these data flow requirements in (draft-hares-i2rs-dataflow-req-01.txt), and I've listed these requirements below. We plan to do I2RS work in phases so we can include a wide scope of outbound protocols (DF-REQ-02/03/09), IPFIX as outbound stream from I2RS ephemeral statistics (DF-REQ-04/05), handling of large data flows outside of pub/sub push (DF-REQ 06). We also have run into request to make sure OAM/ephemeral actions are tailored to work during the network congestion or high resource requirements for routing system (DF-REQ-07/08/09), and that batch uploads of routes work effectively. The only ones I personal (chair hat off) strongly recommend is DF-REQ-01 and DF-REQ-10 so we can vary the level of checking on large batch uploads of routes for certain applications. Jeff and I would like your feedback. To aid this, Sue will present the issues of this topic at the Interim on 10/16/2016 and IETF along with thoughts on the protocol strawman. Sue Hares ================= DF-REQ-01: Support writing to the ephemeral copy of the Local RIB with three different types of checks: minimal data reception checks (TLVs of data valid), all non-referential checks (e.g. do not do leafref, MUST, instance identifiers), and do referential checks via three different rpcs. [Added due to practical consideration with I2RS RIB uploads]. [any form data and transport] DF-REQ-02: The support of large data transfers in a data format agnostic format. This the I2RS protocol should support transport of data in any format including: XML, JSON, MTL (ALias/Waveformat, .mtl), protobufs, and ascii text. DF-REQ-03: Support of any transport [any data form], [/any form data and transport] [IPFIX] DF-REQ-04: Support for the ability to send traffic monitoring information using IPFIX protocol and IPFIX templates, DF-REQ-05: Support of transmitting traffic statistics for filter-based policies (BGP-FS, I2RS FB-RIB, policy routing), IPPM, SFLOW, and others in yang data model format or IPFIX templates formats over XML or JSON. [/IPFIX] [ large data flows outside pub/sub] DF-REQ-06: I2RS should be able to support an action which allocates internal resources for the I2RS agent (memory, processing time, interrupts) and outbound data flow bandwidth. It is expected that an action would be included in a data model in an "rpc"-like format in yang. [/data flows outside of pub-sub - pub-sub already has this restriction] [OAM and outage flows] DF-REQ-07: The I2RS should be able to support an action that interacts with routing OAM functions. DF-REQ-08: The I2RS Agent must be able signals that it will be using different protocol with different constraints (security, priority of data, or transport) or different constraints on the existing protocol (smaller message sizes, different priorities on data carried, or different security levels). (UDP + security vs. TCP + security) [/OAM and outage flows] [yang] DF-REQ-09: Yang MUST have a way to indicate in a data model has actions which allow: different transports, different resource constraints, or different security. DF-REQ-10: Yang MUST have a way to indicate a data model has different levels of checking where: lowest level is message form only, medium level checks message format plus data syntax, and highest level uses the message format, data syntax and referential check netconf configuration does. The default level for I2RS is message format plus data syntax. [/yang] ------=_NextPart_000_004F_01D17ECE.455B9E50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all: =

 

While working on the I2RS protocol strawman, some of = the design team and early reviewers have disagreed on requirements for = the data streams.   Therefore, the chairs need input on the = requirements for the data streams.

 

Currently = the approved requirements have the following types of inbound or = outbound streams:

1)      = Read/writes – simple read/writes or rpc = requests,

2)      = Publication/subscription – via the pub-sub = requirements (outbound data stream, inbound control)  =

3)      = Actions  - via rpc requests (rpc, = rpc-response)

4)      = Some unsecured outbound stream (TBD) =

 

As chair, I reviewed the use case requirements and = found 11 requirements for I2RS data flow in the (IC) in charter = requirements in the I2RS use case requirements document (draft-ietf-i2rs-usecase-reqs-summary).  These = requirements suggest adding:  1) IPFIX as an outbound data stream = for traffic monitoring data, and 2) outbound data streams which are data = form agnostic (Any of XML, JSON, MTL, protobufs, etc.) over any = transport.   I’ve placed the details on these data flow = requirements in (draft-hares-i2rs-dataflow-req-01.txt), and I’ve = listed these requirements below.

 

We plan to = do I2RS work in phases so we can include a wide scope of outbound = protocols (DF-REQ-02/03/09), IPFIX as outbound stream from I2RS = ephemeral statistics (DF-REQ-04/05), handling of large data flows = outside of pub/sub push (DF-REQ 06).  We also have run into request = to make sure OAM/ephemeral actions are tailored to work during the = network congestion or high resource requirements for routing system = (DF-REQ-07/08/09), and that batch uploads of routes work = effectively.   The only ones I personal (chair hat off) = strongly recommend is DF-REQ-01 and DF-REQ-10 so we can vary the level = of checking on large batch uploads of routes for certain = applications. 

 

Jeff and I = would like your feedback.   To aid this, Sue will present the = issues of this topic at the Interim on 10/16/2016 and IETF along with = thoughts on the protocol strawman.   

 

Sue Hares =

 

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

 

 DF-REQ-01: Support writing to the ephemeral copy = of the Local RIB with three different types of checks:

minimal data reception checks (TLVs of data valid), = all non-referential checks (e.g. do not do leafref, MUST, =

instance identifiers), and do = referential checks via three different rpcs.   [Added due to = practical consideration with I2RS RIB uploads].

 

[any form = data and transport]

DF-REQ-02: The = support of large data transfers in a data format agnostic format.  = This the I2RS protocol should

support = transport of data in any format including: XML, JSON,  MTL = (ALias/Waveformat, .mtl), protobufs, and ascii text.  =

DF-REQ-03: Support of any transport = [any data form],

[/any form data and = transport]

 

[IPFIX]

DF-REQ-04: = Support for the ability to send traffic monitoring information using = IPFIX protocol and IPFIX templates, 

DF-REQ-05: Support of transmitting traffic statistics = for filter-based policies (BGP-FS, I2RS FB-RIB, policy routing), IPPM, = SFLOW, and others in yang data model format or IPFIX templates formats = over XML or JSON. 

 [/IPFIX]

 

[ large data = flows outside pub/sub]

 DF-REQ-06: I2RS should be able to support an = action which allocates internal resources for the I2RS = agent

(memory, processing time, = interrupts) and outbound data flow bandwidth.  It is expected that = an action would be

included in a data = model in an "rpc"-like format in yang.

[/data flows outside of pub-sub -  pub-sub = already has this restriction]

 

[OAM and = outage flows]

 DF-REQ-07: The = I2RS should be able to support an action that interacts with routing OAM = functions.

 DF-REQ-08: The I2RS = Agent must be able signals that it will be using different protocol with = different constraints (security, priority of data, or transport) or = different constraints on the  existing protocol (smaller message = sizes, different priorities on data carried, or different security = levels).   (UDP + security vs. TCP + security) =

[/OAM and outage flows] =  

 

[yang]

DF-REQ-09: = Yang MUST have a way to  indicate in a data model has actions which = allow:

different transports, = different resource constraints, or different security.

 

DF-REQ-10: = Yang MUST have a way to indicate a data model has different levels of = checking where:

lowest level is = message form only, medium level checks message format plus data syntax, = and highest level uses the

message = format, data syntax and referential check netconf configuration does. =  The default level for I2RS is message format plus data syntax. =

[/yang] =

------=_NextPart_000_004F_01D17ECE.455B9E50-- From nobody Tue Mar 15 12:33: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 EE02212DD31 for ; Tue, 15 Mar 2016 12:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.638 X-Spam-Level: *** X-Spam-Status: No, score=3.638 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 dAMnKHTeYhpy for ; Tue, 15 Mar 2016 12:33:24 -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 48C6B12DD2F for ; Tue, 15 Mar 2016 12:33:24 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Tue, 15 Mar 2016 15:32:45 -0400 Message-ID: <007301d17ef1$740e3000$5c2a9000$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01D17ECF.ECFFC450" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF+8W4F07/E796IS7Wq+BxpmHkQ3g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , "'jmh.direct'" , 'Alia Atlas' Subject: [i2rs] feedback on I2RS use case requirements document 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, 15 Mar 2016 19:33:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0074_01D17ECF.ECFFC450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The draft-ietf-i2rs-use-case-reqs-summary has not received many reviews the last year. This is a living document that indicates what are valid use cases. As we work on the I2RS protocol, it is important to consider the requirements. Please note that (OC) means out of charter, and (IC) means in-Charter. The chairs are looking for feedback on this document: draft-ietf-i2rs-usecase-reqs-summary/ on whether: a) IC requirements are need for phase 1 of the protocol? Other options are to put the requirements in a later phase or dropping the requirement. b) OC-requirements should be "In-charter" in a later phase? Or dropped? c) We are missing any urgent requirements for phase 1 protocol. Jeff and I would appreciate your feedback as we consider the I2rs protocol strawman. Sue Hares ------=_NextPart_000_0074_01D17ECF.ECFFC450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = draft-ietf-i2rs-use-case-reqs-summary has not received many reviews the = last year.  This is a living document that indicates what are valid = use cases.  As we work on the I2RS protocol, it is important to = consider the requirements.   Please note that (OC) means out = of charter, and (IC) means in-Charter.   The chairs are = looking for feedback on this document: draft-ietf-i2rs-usecase-reqs-summary/  on = whether:

 

a)      = IC requirements are need for phase 1 of the = protocol? Other options are to put the requirements in a later phase or = dropping the requirement.

  

b)      = OC-requirements should be = “In-charter” in a later phase?  Or dropped? =

 

c)       We = are missing any urgent requirements for phase 1 = protocol.

 

Jeff = and I would appreciate your feedback as we consider the I2rs protocol = strawman.

 

Sue Hares

 

 

------=_NextPart_000_0074_01D17ECF.ECFFC450-- From nobody Tue Mar 15 12:40: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 A878512D753 for ; Tue, 15 Mar 2016 12:40:27 -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 qgPfIyEL7_fq for ; Tue, 15 Mar 2016 12:40:25 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60FBF12D740 for ; Tue, 15 Mar 2016 12:40:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 38ACE24EA8B; Tue, 15 Mar 2016 12:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1458070825; bh=52dEqa7SRtwXo6h1O9SlDkxzkKUh038cjRbtWx/tfEs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=mhIkhzJO2Omk9p6GZYGnvy8WlK7wv2qQGeuO4+bOhb1bbD8U0QArp8RZOmSkpTJm1 uszkz/heEt0UthbP61Rxuy4fqe2GGn2wak0KUjz15BRc6qcU9oBtS+rioMuXhFtdKO ji2UzfDuytOwSflfKMHd1bcu5X6QfCU3cVstUUMY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [46.189.28.83]) (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 7355D24EB15; Tue, 15 Mar 2016 12:40:23 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <004e01d17eef$cc6a3110$653e9330$@ndzh.com> From: "Joel M. Halpern" Message-ID: <56E8652F.8020603@joelhalpern.com> Date: Tue, 15 Mar 2016 15:40:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <004e01d17eef$cc6a3110$653e9330$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 'Jeffrey Haas' , 'Amit Dass' , 'Alia Atlas' Subject: Re: [i2rs] Call for feedback - I2RS protocol requirements [3 weeks 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, 15 Mar 2016 19:40:27 -0000 Thank you for your work on this Sue. I disagree with some of the requirements. I will comment on them in-line below, eliding you summary. I hope and expect to be on the call tomorrow to participate in the discussion. Yours, Joel On 3/15/16 3:20 PM, Susan Hares wrote: > Hi all: > > While working on the I2RS protocol strawman, some of the design team and > early reviewers have disagreed on requirements for the data streams. > Therefore, the chairs need input on the requirements for the data streams. ... > > DF-REQ-01: Support writing to the ephemeral copy of the Local RIB with > three different types of checks: > > minimal data reception checks (TLVs of data valid), all non-referential > checks (e.g. do not do leafref, MUST, > > instance identifiers), and do referential checks via three different > rpcs. [Added due to practical consideration with I2RS RIB uploads]. I don't know that we have clarity on the details of this requirement, but there clearly is a need here. Expecting a device to handle absolute nonsense without checking is clearly unacceptable. On the other hand, folks have repeatedly indicated that the full sent of YANG integrity checks are a significant source of the time it takes to do NetConf / YANG. To a significant degree, I would think that be careful to NOT specify MUST clauses we don't want checked in ephemeral models would seem to help. > > [any form data and transport] > > DF-REQ-02: The support of large data transfers in a data format agnostic > format. This the I2RS protocol should > > support transport of data in any format including: XML, JSON, MTL > (ALias/Waveformat, .mtl), protobufs, and ascii text. > > DF-REQ-03: Support of any transport [any data form], > > [/any form data and transport] I understand that these two requirements come from the old large data set document. However, I do not believe that they are appropraite or necessary. Whatever protocol we adopt will have format or formats. Those will be the ones used. The solution will not be agnostic. There is no requirement to ship ascii, except as side-effect of shipping XML in RestConf or NetConf. We should not elevate an effect into a requirement. Also, being format agnostic means that there is no way to drive the existence of a common format between a range of clients and a range of agens. A multiplicity of optional formats is a recipe for failures of interoperability. > > [IPFIX] > > DF-REQ-04: Support for the ability to send traffic monitoring > information using IPFIX protocol and IPFIX templates, > > DF-REQ-05: Support of transmitting traffic statistics for filter-based > policies (BGP-FS, I2RS FB-RIB, policy routing), IPPM, SFLOW, and others > in yang data model format or IPFIX templates formats over XML or JSON. > > [/IPFIX] There is clearly information that is well suited to transfer using IPFIX. And an operating solution using I2RS is likely to use IPFIX as well. I do not see any reason why the I2RS component should include, mandate, or reference IPFIX. I am trying to imagine an I2RS subscribe request trying to set up an IPFIX reporting flow without having it go through the proper IPFIX setup stages. So, this looks like a description of a good idea that is not a requirement on I2RS. > > [ large data flows outside pub/sub] > > DF-REQ-06: I2RS should be able to support an action which allocates > internal resources for the I2RS agent > > (memory, processing time, interrupts) and outbound data flow bandwidth. > It is expected that an action would be > > included in a data model in an "rpc"-like format in yang. > > [/data flows outside of pub-sub - pub-sub already has this restriction] I can not parse what this requirement is outside of pub-sub. While some actions may be large, I do not know what the protocol expectation, or system expectation, is that would meet this requirement. > > [OAM and outage flows] > > DF-REQ-07: The I2RS should be able to support an action that interacts > with routing OAM functions. > > DF-REQ-08: The I2RS Agent must be able signals that it will be using > different protocol with different constraints (security, priority of > data, or transport) or different constraints on the existing protocol > (smaller message sizes, different priorities on data carried, or > different security levels). (UDP + security vs. TCP + security) > > [/OAM and outage flows] This seems to mix several different things. Support for interacting with routing OAM is a models issue. As far as I can tell, it has nothing to do with the data exchange being discussed here. Then there is a discussion of signaling what protocol is being used. The description is confusing. with some of the protocol models we are proposing, there is a capability negotiation phase, which I am happy to utilize. But I would hate to rule out using RestConf because it does not alow us to negotiate the use of something else. We are supposed to pick the protocol. > > [yang] > > DF-REQ-09: Yang MUST have a way to indicate in a data model has actions > which allow: > > different transports, different resource constraints, or different > security. > > DF-REQ-10: Yang MUST have a way to indicate a data model has different > levels of checking where: > > lowest level is message form only, medium level checks message format > plus data syntax, and highest level uses the > > message format, data syntax and referential check netconf configuration > does. The default level for I2RS is message format plus data syntax. > > [/yang] The first of these two I flat disagree with. Trying to define, on a per-model basis, the transport or security requirements of the model simply does not work. The model describes something to be manipulates. The transport and security requriements derive from the environment and operational practices of the operator in question. This came up earlier in the context of conflict handling. The model is simply the wrong place to define this. The second requirement is about what level of checking the I2RS agent will perform. It is not clear to me how much range of choices we will really have. Assuming there are choices, for the same reasons as above, it is not at all obvious to me that the decision resides at a per-model level. ... From nobody Tue Mar 15 12:50: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 A850712DD58; Tue, 15 Mar 2016 12:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.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 PtHXMIqoiYkI; Tue, 15 Mar 2016 12:50:32 -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 BCBA312DD45; Tue, 15 Mar 2016 12:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6849; q=dns/txt; s=iport; t=1458071431; x=1459281031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LkD4VpfHxFO/Siv5jul7ZgEG7i/FnC3B04I33PRXarA=; b=m2+fwX9jFi9HeI+011klQi/+F3QBrenk6ZNKQrYToi0m5sInyCW31Jzt CkpeXP6vfLsNWVGhlIV10fMBsjUTD54hnvY8sshQ8F7uMELeH6lS3Tvvi VMkF820WEEubY/ZGZI4yJ5l6AMeFijL70ASbOnXOOF3TQubGkiujELn6P Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQACZ+hW/4YNJK1VCYNGVG4GuDqCD?= =?us-ascii?q?wENgW4jhWoCgTw4FAEBAQEBAQFkJ4RCAQEDAXkFCwIBCA4EEyEyFw4CBAENBRu?= =?us-ascii?q?IBAgOvlgBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYahEKEEoRjBZMEhEsBhW6IE?= =?us-ascii?q?o8Fjn4BHgEBQoIwgTVqAQGJY34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,340,1454976000"; d="scan'208";a="83143772" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2016 19:50:30 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u2FJoUej015443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 19:50:30 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 14:50:29 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 14:50:29 -0500 From: "Alvaro Retana (aretana)" To: Susan Hares , "'The IESG'" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Thread-Index: AQHRfrrLtH9blNM/u0+GTmgMa99U6p9bJsyA///UV4A= Date: Tue, 15 Mar 2016 19:50:29 +0000 Message-ID: References: <20160315130123.29388.33945.idtracker@ietfa.amsl.com> <001b01d17ee8$3a10ff80$ae32fe80$@ndzh.com> In-Reply-To: <001b01d17ee8$3a10ff80$ae32fe80$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "mach.chen@huawei.com" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-architecture@ietf.org" Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (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: Tue, 15 Mar 2016 19:50:33 -0000 On 3/15/16, 2:26 PM, "iesg on behalf of Susan Hares" wrote: Sue: Hi! ... >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>A. There are a couple of places where operations are characterized as >>"safe" (1.1 and 6.4.1 =8B see below), but no >explanation as to what >>"safe" means. It seems to me that these mentions of "safe" go beyond >>authentication and even >authorization to perform a specific operation, >>to the content of the operation itself. I would like to see some >>>discussion about how to achieve it, and/or (at least) what the impact >>>may be. > >The definition of "safe" from a security viewpoint was a sufficient >enough discussion that two I2RS requirements documents were created: >1) defining "safe" protocol - >https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-require >ments/ >2) defining "safe" environment - >https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs >/ > >The definition of "safe" specifically also depends on the protocol(s) >selected to be combined for the I2RS higher level protocol and the "safe" >environment. Do you want these two documents back-fitted to the >architecture or are you looking for something different? The point I was trying to make is that the use of "safe" in the text I quoted (1.1 and 6.4.1) seems to not be the "safe" used in security: authentication, authorization, encryption, etc. For example, the text in 1.1 says that "I2RS will only permit modification of state that would be safe" -- note that the *modification* is what is characterized as safe, the action itself! The text above made me think about the result of that modification and whether that was considered "safe" in the network -- and what would that be, which is why I asked. As an simple example, consider a modification that would result in the connection to the Client to be lost (adding a route for that destination with an action to drop) -- while the identity, authentication, integrity, authorization, etc. may all check out correctly (I.e. The interaction is secure!), it is obviously not what I would characterize as a "safe" modification. Maybe I'm reading too much into it... ??? >=20 >B. Section 3. (Key Architectural Properties) says that "some architecture >properties such as performance and scaling are not described below >because they are discussed in [I-D.ietf-i2rs-problem-statement]". >However, as I mentioned in my review of I-D.ietf-i2rs-problem-statement >[1], that document has a very, very sparse treatment of performance and >scalability to even attempt to call it a "Key Architectural Property". > >Response: I sent you a question about what you wanted for the problem >statement. I am holding the problem statement because you have not >responded to the scaling. My preferred solution, given that I-D.ietf-i2rs-problem-statement doesn't really say anything about performance and scaling anyway, is to add the discussion in Section 3 of this document. > We have the following things you can see in other documents: > >- The I2RS pub-sub requirements documents look toward the scaling of >large data via the publication and subscription mechanisms. >draft-ietf-i2rs-pub-sub-requirements > >- Potential ability to allow minimal checking on the upload of the local >RIB (in discussion) > draft-ietf-i2rs-usecase-reqs-summary > draft-hares-i2rs-dataflow-req > >These are scaling efforts for the inbound/outbound data flows. Other >reviewers had considered these specifics were not valid in the problem >statement, but perhaps we can work through a compromise where we discuss >the problem of large data inputs/outputs in a constructive manner. Can >you suggest any text? Note that my comment was around the fact that the text mentions performance and scaling as key architectural properties (of the architecture) and there is no discussion related to them. What you point to above are requirements/scaling efforts for specific operations/mechanisms -- which clearly don't represent the architectural view that the other items in Section 3 do. Again, my preference is to see Key Architectural Properties discussed where they belong: in the architecture document. >=20 >=20 >L. Many protocols (routing-related and otherwise) are mentioned without >references. > >Sue: Do you really want all the protocols lists in the diagrams to be >reference? >If so, I am glad to do it. This question is also included in the top. It is common practice to do so. I think that many are well-known and may not need a reference, but not all are included in the RFC Editor Abbreviation List. I'll let you make the call. https://www.rfc-editor.org/materials/abbrev.expansion.txt ... >H. 3.2. (Extensibility) talks about the initial scope of I2RS (without >references). To extend the usability of this document, I would suggest >that the statements of this section be made independent of the fact that >the initial scope may be narrow. IOW, I think you may want the >protocol/data model to be extensible regardless of the size of the >initial scope (even if boiling the ocean to start with, there will always >be opportunities for extensions later). > >Sue: I agree. =20 > >How about this change: > >Old / The scope of the I2RS work is being restricted in the interests >of > achieving a deliverable and deployable result. The I2RS Working > Group is modeling only a subset of the data of interest. It is > clearly desirable for the data models defined in the I2RS to be > useful in more general settings. It should be easy to integrate data > models from the I2RS with other data. Other work should be able to > easily extend it to represent additional aspects of the network > elements or network systems. This reinforces the criticality of > designing the data models to be highly extensible, preferably in a > regular and simple fashion./ > >New / The scope of I2RS work is being designed in phases to provide > deliverable and deployable results at every phase. Each > phase will have a specific set of requirements, and > the I2RS protocol and data models will progress toward these >requirements. > Therefore, it is clearly desirable for the I2RS data models > to be easily and highly extensible to represent additional >aspects of the network elements > or network systems. It should be easy to integrate data > models from the I2RS with other data. This reinforces the >criticality of > designing the data models to be highly extensible, preferably in a > regular and simple fashion/ That works for me. Thanks! Alvaro. From nobody Tue Mar 15 13:20: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 2770812D64C; Tue, 15 Mar 2016 13:20:03 -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 2MVkVNltz4kH; Tue, 15 Mar 2016 13:20:01 -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 EEB4C12D564; Tue, 15 Mar 2016 13:20:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Alvaro Retana \(aretana\)'" , "'The IESG'" References: <20160315130123.29388.33945.idtracker@ietfa.amsl.com> <001b01d17ee8$3a10ff80$ae32fe80$@ndzh.com> In-Reply-To: Date: Tue, 15 Mar 2016 16:19:19 -0400 Message-ID: <009e01d17ef7$f5335920$df9a0b60$@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: AQKvbXVR5HZhLz3siBCyA1d3hNKPywHwZzl2AT4oF6udhZyJoA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (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: Tue, 15 Mar 2016 20:20:03 -0000 Alvaro: On "A" - and the sections in 1.1 and 6.4.1 you quoted - it is either I2RS data model safe, I2RS protocol safe, I2RS environment safe, or safe for the routing system. The text implies the last one safe for the routing system protocols and RIBs. That's an architecture big-picture comment. If you read more beyond that .. you are reading out of context (IMHO). On B - you would like to place architecture qualities of the large data flows outbound (e.g. pub-sub), and large data flows inbound (e.g. large updates) in the architecture document. I'm fine with this approach since I2RS is actively working on these features. On this topic, I want to validate the approach and my text with my co-authors (give me a few hours). On L:, I'll add all the RFCs in -14 that are not abbreviation and work with the RFC editor to make sure we are aligned with her policy. On H:, I'll use that text. What I owe you is the joint resolution for "B" in the problem and architecture statement. Let me know if "A" answers works for you. Sue -----Original Message----- From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Tuesday, March 15, 2016 3:50 PM To: Susan Hares; 'The IESG' Cc: i2rs@ietf.org; mach.chen@huawei.com; i2rs-chairs@ietf.org; draft-ietf-i2rs-architecture@ietf.org Subject: Re: Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) On 3/15/16, 2:26 PM, "iesg on behalf of Susan Hares" wrote: Sue: Hi! ... >=========== >>A. There are a couple of places where operations are characterized as >>"safe" (1.1 and 6.4.1 < see below), but no >explanation as to what >>"safe" means. It seems to me that these mentions of "safe" go beyond >>authentication and even >authorization to perform a specific >>operation, to the content of the operation itself. I would like to >>see some >>>discussion about how to achieve it, and/or (at least) what the impact >>>may be. > >The definition of "safe" from a security viewpoint was a sufficient >enough discussion that two I2RS requirements documents were created: >1) defining "safe" protocol - >https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requ >ire >ments/ >2) defining "safe" environment - >https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-r >eqs >/ > >The definition of "safe" specifically also depends on the protocol(s) >selected to be combined for the I2RS higher level protocol and the "safe" >environment. Do you want these two documents back-fitted to the >architecture or are you looking for something different? The point I was trying to make is that the use of "safe" in the text I quoted (1.1 and 6.4.1) seems to not be the "safe" used in security: authentication, authorization, encryption, etc. For example, the text in 1.1 says that "I2RS will only permit modification of state that would be safe" -- note that the *modification* is what is characterized as safe, the action itself! The text above made me think about the result of that modification and whether that was considered "safe" in the network -- and what would that be, which is why I asked. As an simple example, consider a modification that would result in the connection to the Client to be lost (adding a route for that destination with an action to drop) -- while the identity, authentication, integrity, authorization, etc. may all check out correctly (I.e. The interaction is secure!), it is obviously not what I would characterize as a "safe" modification. Maybe I'm reading too much into it... ??? > >B. Section 3. (Key Architectural Properties) says that "some >architecture properties such as performance and scaling are not >described below because they are discussed in [I-D.ietf-i2rs-problem-statement]". >However, as I mentioned in my review of I-D.ietf-i2rs-problem-statement >[1], that document has a very, very sparse treatment of performance and >scalability to even attempt to call it a "Key Architectural Property". > >Response: I sent you a question about what you wanted for the problem >statement. I am holding the problem statement because you have not >responded to the scaling. My preferred solution, given that I-D.ietf-i2rs-problem-statement doesn't really say anything about performance and scaling anyway, is to add the discussion in Section 3 of this document. > We have the following things you can see in other documents: > >- The I2RS pub-sub requirements documents look toward the scaling of >large data via the publication and subscription mechanisms. >draft-ietf-i2rs-pub-sub-requirements > >- Potential ability to allow minimal checking on the upload of the >local RIB (in discussion) > draft-ietf-i2rs-usecase-reqs-summary > draft-hares-i2rs-dataflow-req > >These are scaling efforts for the inbound/outbound data flows. Other >reviewers had considered these specifics were not valid in the problem >statement, but perhaps we can work through a compromise where we >discuss the problem of large data inputs/outputs in a constructive >manner. Can you suggest any text? Note that my comment was around the fact that the text mentions performance and scaling as key architectural properties (of the architecture) and there is no discussion related to them. What you point to above are requirements/scaling efforts for specific operations/mechanisms -- which clearly don't represent the architectural view that the other items in Section 3 do. Again, my preference is to see Key Architectural Properties discussed where they belong: in the architecture document. > > >L. Many protocols (routing-related and otherwise) are mentioned without >references. > >Sue: Do you really want all the protocols lists in the diagrams to be >reference? >If so, I am glad to do it. This question is also included in the top. It is common practice to do so. I think that many are well-known and may not need a reference, but not all are included in the RFC Editor Abbreviation List. I'll let you make the call. https://www.rfc-editor.org/materials/abbrev.expansion.txt ... >H. 3.2. (Extensibility) talks about the initial scope of I2RS (without >references). To extend the usability of this document, I would suggest >that the statements of this section be made independent of the fact >that the initial scope may be narrow. IOW, I think you may want the >protocol/data model to be extensible regardless of the size of the >initial scope (even if boiling the ocean to start with, there will >always be opportunities for extensions later). > >Sue: I agree. > >How about this change: > >Old / The scope of the I2RS work is being restricted in the interests >of > achieving a deliverable and deployable result. The I2RS Working > Group is modeling only a subset of the data of interest. It is > clearly desirable for the data models defined in the I2RS to be > useful in more general settings. It should be easy to integrate data > models from the I2RS with other data. Other work should be able to > easily extend it to represent additional aspects of the network > elements or network systems. This reinforces the criticality of > designing the data models to be highly extensible, preferably in a > regular and simple fashion./ > >New / The scope of I2RS work is being designed in phases to provide > deliverable and deployable results at every phase. Each > phase will have a specific set of requirements, and > the I2RS protocol and data models will progress toward these >requirements. > Therefore, it is clearly desirable for the I2RS data models > to be easily and highly extensible to represent additional >aspects of the network elements > or network systems. It should be easy to integrate data > models from the I2RS with other data. This reinforces the >criticality of > designing the data models to be highly extensible, preferably in a > regular and simple fashion/ That works for me. Thanks! Alvaro. From nobody Tue Mar 15 14:11: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 40ECF12DA8D; Tue, 15 Mar 2016 14:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.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 JgpPq3sgEcmk; Tue, 15 Mar 2016 14:11:14 -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 67E4212DAFD; Tue, 15 Mar 2016 14:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1818; q=dns/txt; s=iport; t=1458076274; x=1459285874; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oPFN2m/OcwdzZsk5VXqxns6m1GXajxmVUSCcGoCL8sw=; b=I+q83/xPfH9CBOGGd0yZk+SjcVzncKxcY+8pUOmDhMAPjXlGEJuynaXG xDFk9DFcj/I2iR137bkP/D2W9hoANAhre7UZJVhtc0tERgsrD1SeiTSzT cEPmiw9+4emnG652Siz4BNhNZd1/XptnJdaZMFRQqvPTl857l2klwBgH0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgCGeehW/4MNJK1eg0aBQga4OoIPA?= =?us-ascii?q?Q2BboYNAoE/OBQBAQEBAQEBZCeEQgEBBDo/EAIBCA4EJBAyFw4CBAENBYgnvng?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBF4YahEKIdQEEkwSESwGOAIFlhEmIV45+AR4BA?= =?us-ascii?q?UKCAxkUgTVqiSolFn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,341,1454976000"; d="scan'208";a="249873205" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2016 21:11:13 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2FLBDls027540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 21:11:13 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 16:11:12 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 16:11:12 -0500 From: "Alvaro Retana (aretana)" To: Susan Hares , "'The IESG'" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Thread-Index: AQHRfrrLtH9blNM/u0+GTmgMa99U6p9bJsyA///UV4CAAEshgP//y2wA Date: Tue, 15 Mar 2016 21:11:12 +0000 Message-ID: References: <20160315130123.29388.33945.idtracker@ietfa.amsl.com> <001b01d17ee8$3a10ff80$ae32fe80$@ndzh.com> <009e01d17ef7$f5335920$df9a0b60$@ndzh.com> In-Reply-To: <009e01d17ef7$f5335920$df9a0b60$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "mach.chen@huawei.com" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-architecture@ietf.org" Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (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: Tue, 15 Mar 2016 21:11:16 -0000 On 3/15/16, 4:19 PM, "iesg on behalf of Susan Hares" wrote: Sue: =20 >=20 >On B - you would like to place architecture qualities of the large data >flows outbound (e.g. pub-sub), and large data flows inbound (e.g. large >updates) in the architecture document. I'm fine with this approach since >I2RS is actively working on these features. On this topic, I want to >validate the approach and my text with my co-authors (give me a few >hours). No, I don't *want* to put anything in the document. Let's start form the beginning... The text in Section 3. (Key Architectural Properties) says that "some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement]". >From this text I assume that performance and scaling are important -- which is why they're called out in this section. I don't think that I-D.ietf-i2rs-problem-statement says anything, that can be called a "Key Architectural Property", about performance and scaling. =20 If the description of performance and scaling as "key architectural properties" is not in I-D.ietf-i2rs-problem-statement, then it should be somewhere, right? I said my preference is to describe them in the architecture document, but the decision of where to put it is yours. I don't want to add anything to the document that you didn't already mention should be considered as a "key architectural property". The details of what this description looks like are up to you. ... >=20 >Let me know if "A" answers works for you. It honestly didn't give me a warm, fuzzy feeling, but I'm ok with that. Please keep in mind that none of my comments are blocking this document. Thanks! Alvaro. From nobody Tue Mar 15 14:25: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 7E2A012D69D; Tue, 15 Mar 2016 14:25: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 3P4ABU5I1teB; Tue, 15 Mar 2016 14:25: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 CD5EA12D58C; Tue, 15 Mar 2016 14:25:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Alvaro Retana \(aretana\)'" , "'The IESG'" References: <20160315130123.29388.33945.idtracker@ietfa.amsl.com> <001b01d17ee8$3a10ff80$ae32fe80$@ndzh.com> <009e01d17ef7$f5335920$df9a0b60$@ndzh.com> In-Reply-To: Date: Tue, 15 Mar 2016 17:24:57 -0400 Message-ID: <00b101d17f01$202d0050$608700f0$@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: AQKvbXVR5HZhLz3siBCyA1d3hNKPywHwZzl2AT4oF6sB3hMCSwJNfFEgnWRU7QA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (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: Tue, 15 Mar 2016 21:25:38 -0000 Alvaro: Your comments always matter to me whether the comments are blocking or not. (smile). On you not getting "warm fuzzies" on these two documents - my real concern is that we are doing the right thing in the work. I think I know what you want in the document. Let me talk this over with my other co-authors. We are really trying to address the scaling and performance on the outbound/inbound side in data flow, and within the process in the amount of resources spent on the router. This impacts the data models and the protocol. I'll catch up with you via phone or at IETF to talk more about this. Sue -----Original Message----- From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Tuesday, March 15, 2016 5:11 PM To: Susan Hares; 'The IESG' Cc: i2rs@ietf.org; mach.chen@huawei.com; i2rs-chairs@ietf.org; draft-ietf-i2rs-architecture@ietf.org Subject: Re: Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) On 3/15/16, 4:19 PM, "iesg on behalf of Susan Hares" wrote: Sue: > >On B - you would like to place architecture qualities of the large data >flows outbound (e.g. pub-sub), and large data flows inbound (e.g. large >updates) in the architecture document. I'm fine with this approach >since I2RS is actively working on these features. On this topic, I >want to validate the approach and my text with my co-authors (give me a >few hours). No, I don't *want* to put anything in the document. Let's start form the beginning... The text in Section 3. (Key Architectural Properties) says that "some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement]". >From this text I assume that performance and scaling are important -- which is why they're called out in this section. I don't think that I-D.ietf-i2rs-problem-statement says anything, that can be called a "Key Architectural Property", about performance and scaling. If the description of performance and scaling as "key architectural properties" is not in I-D.ietf-i2rs-problem-statement, then it should be somewhere, right? I said my preference is to describe them in the architecture document, but the decision of where to put it is yours. I don't want to add anything to the document that you didn't already mention should be considered as a "key architectural property". The details of what this description looks like are up to you. ... > >Let me know if "A" answers works for you. It honestly didn't give me a warm, fuzzy feeling, but I'm ok with that. Please keep in mind that none of my comments are blocking this document. Thanks! Alvaro. From nobody Tue Mar 15 19:59: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 2588012D827 for ; Tue, 15 Mar 2016 19:59: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 r2TpLHC-lD6g for ; Tue, 15 Mar 2016 19:59:53 -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 5583712D501 for ; Tue, 15 Mar 2016 19:59:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: References: <20160316025831.18240.68022.idtracker@ietfa.amsl.com> In-Reply-To: <20160316025831.18240.68022.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 22:59:18 -0400 Message-ID: <019a01d17f2f$d56b6230$80422690$@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: AQIcH9Xv6u0Ps+ZWOZvlrvARATGm5Z7GH6gA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , kwatsen@juniper.net, 'Andy Bierman' , "'BRUNGARD, DEBORAH A'" , 'Alia Atlas' Subject: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-00.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, 16 Mar 2016 02:59:55 -0000 HI all:=20 This is a I2RS protocol strawman for discussion on Wednesday's interim = (10:00am - 11:30am ET on March 16, 2016) along with the data flow = requirements document and email sent out earlier today.=20 This personal draft comes out of what I learned from Andy Bierman, Kent = Watsen, Dean Bogdanovic, Russ White, Alia Atlas, Amit Dass, Ignas = Bagdonas, Alex Clemm, Keyur Patel, Hariharan Ananthakrishnan, Anu Nair, = Juergen Schoenwaelder, Joel Halpern, Mach Chen, Qin Wu, and Jan Medved.=20 The errors are mine - the good ideas come from wonderful group of people = over the last 9 months. It is a strawman. It is limited to just = netconf/restconf with all functions. The discussion regarding adding = IPFIX or Protobufs to this first version of I2RS higher-level protocol - = is a discussion for interim and IETF. Sue =20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Tuesday, March 15, 2016 10:59 PM To: Susan Hares Subject: New Version Notification for = draft-hares-i2rs-protocol-strawman-00.txt A new version of I-D, draft-hares-i2rs-protocol-strawman-00.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-hares-i2rs-protocol-strawman Revision: 00 Title: I2RS protocol strawman Document date: 2016-03-15 Group: Individual Submission Pages: 29 URL: = https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-0= 0.txt Status: = https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/ Htmlized: = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-00 Abstract: This document provides a strawman proposal for the I2RS protocol covering the ephemeral data store and data flow requirements not covered by i2rs publication/subscription service or traceability. It also proposes additions to YANG for the ephemeral data store and for additional data flow requirements. It proposes additions to the NETCONF and RESTCONF for these additions. Future versions of this document will propose changes to support the I2RS protocol security 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 Wed Mar 16 04:38: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 0691212D900 for ; Wed, 16 Mar 2016 04:37:59 -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 5K1z6YZW9uOK for ; Wed, 16 Mar 2016 04:37: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 2078612D54C for ; Wed, 16 Mar 2016 04:37:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Wed, 16 Mar 2016 07:37:21 -0400 Message-ID: <023f01d17f78$34ab2710$9e017530$@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: AdF/LtXMPgDM9+ANTleOoLPC2CGxlw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , kwatsen@juniper.net, 'Andy Bierman' , "'BRUNGARD, DEBORAH A'" , 'Alia Atlas' Subject: [i2rs] FW: New Version Notification for draft-hares-dt-i2rs-protocol-strawman-00.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, 16 Mar 2016 11:37:59 -0000 HI all:=20 This is a I2RS protocol strawman for discussion on Wednesday's interim = (10:00am - 11:30am ET on March 16, 2016) along with the data flow = requirements document and email sent out earlier today.=20 This personal draft comes out of what I learned from Andy Bierman, Kent = Watsen, Dean Bogdanovic, Russ White, Alia Atlas, Amit Dass, Ignas = Bagdonas, Alex Clemm, Keyur Patel, Hariharan Ananthakrishnan, Anu Nair, = Juergen Schoenwaelder, Joel Halpern, Mach Chen, Qin Wu, and Jan Medved.=20 The errors are mine - the good ideas come from wonderful group of people = over the last 9 months. It is a strawman. It is limited to just = netconf/restconf with all functions. The discussion regarding adding = IPFIX or Protobufs to this first version of I2RS higher-level protocol - = is a discussion for interim and IETF=20 Sue=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Tuesday, March 15, 2016 10:44 PM To: Susan Hares Subject: New Version Notification for = draft-hares-dt-i2rs-protocol-strawman-00.txt A new version of I-D, draft-hares-dt-i2rs-protocol-strawman-00.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-hares-dt-i2rs-protocol-strawman Revision: 00 Title: I2RS protocol strawman Document date: 2016-03-15 Group: Individual Submission Pages: 29 URL: = https://www.ietf.org/internet-drafts/draft-hares-dt-i2rs-protocol-strawma= n-00.txt Status: = https://datatracker.ietf.org/doc/draft-hares-dt-i2rs-protocol-strawman/ Htmlized: = https://tools.ietf.org/html/draft-hares-dt-i2rs-protocol-strawman-00 Abstract: This document provides a strawman proposal for the I2RS protocol covering the ephemeral data store and data flow requirements not covered by i2rs publication/subscription service or traceability. It also proposes additions to YANG for the ephemeral data store and for additional data flow requirements. It proposes additions to the NETCONF and RESTCONF for these additions. Future versions of this document will propose changes to support the I2RS protocol security 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 Wed Mar 16 04:55: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 1E9AF12D557 for ; Wed, 16 Mar 2016 04:55:21 -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 5l9l6GeEz_GE for ; Wed, 16 Mar 2016 04:55:19 -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 D8E2D12D54A for ; Wed, 16 Mar 2016 04:55:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Wed, 16 Mar 2016 07:54:42 -0400 Message-ID: <025401d17f7a$a0c381c0$e24a8540$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0255_01D17F59.19B1E1C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF/eqAQSAyfSw1rSvC1+bwxK5NnTQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Kent Watsen' , "'BRUNGARD, DEBORAH A'" , 'Andy Bierman' , 'Alia Atlas' , 'Jeffrey Haas' , "'Alvaro Retana \(aretana\)'" Subject: [i2rs] I2RS Interim today at 10:00am - 11:30am - Agenda and web-ex information 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, 16 Mar 2016 11:55:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0255_01D17F59.19B1E1C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS interim March 16: I2 RS Protocol Wednesday, March 16, 2016 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr 30 mins Agenda: 10:00 - 10:05 Bash Agenda 10:05 - 10:15 Data Flow additions 10:15 - 10:35 Discussion on Data Flow additions draft-hares-i2rs-dataflow-req-02 10:35 - 11:00 Protocol strawman 11:00 - 11:30 Discussion of Protocol Strawman draft-hares-i2rs-protocol-strawman Join WebEx meeting https://ietf.webex.com/ietf/j.php?MTID=m78d53cf15e9abe333c07f83b12f8dddb Meeting number: 646 925 475 Meeting password: byte.by.byte Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 925 475 Toll-free calling restrictions ============== ------=_NextPart_000_0255_01D17F59.19B1E1C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I2RS interim = March 16: I2 RS Protocol

Wednesday, = March 16, 2016

10:00 am  = |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr = 30 mins

 

Agenda:

10:00 - = 10:05  Bash Agenda

10:05 - = 10:15  Data Flow additions

10:15 - 10:35  Discussion on Data Flow = additions   

 draft-hares-i2rs-dataflow-req-02 =

 

10:35 - 11:00  Protocol strawman =

11:00 - 11:30  Discussion of = Protocol Strawman

 draft-hares-i2rs-protocol-strawman

=

 

Join = WebEx meeting

https://ietf.webex.com/ietf/j.php?MTID=3Dm78d53cf15e9ab= e333c07f83b12f8dddb

 

Meeting = number:            646 = 925 475

Meeting = password:         = byte.by.byte

 

Join by phone

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

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

Access code: = 646 925 475

Toll-free calling = restrictions

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

 

------=_NextPart_000_0255_01D17F59.19B1E1C0-- From nobody Wed Mar 16 08:07: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 81AE912D5B9 for ; Wed, 16 Mar 2016 08:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.638 X-Spam-Level: *** X-Spam-Status: No, score=3.638 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 t7UCIrbsZpKC for ; Wed, 16 Mar 2016 08:07: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 92B7812D532 for ; Wed, 16 Mar 2016 08:06:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Wed, 16 Mar 2016 11:06:06 -0400 Message-ID: <02d701d17f95$5e0e5fb0$1a2b1f10$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D8_01D17F73.D6FD5BF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF/lCMeJ83GPEVJTFKaN8sIAsZh6Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Joel Halpern Direct' , 'Amit Dass' , 'Alia Atlas' Subject: [i2rs] interim on March 16, 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: Wed, 16 Mar 2016 15:07:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D8_01D17F73.D6FD5BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: The interim meeting did not have enough people (4 people) to call it an interim. We'll discuss these topics at IETF 95 in Buenos Aires, and on the list. The slides which may help you understand the discussion are at: https://www.ietf.org/proceedings/interim/2016/03/16/i2rs/proceedings.html Sue Hares ------=_NextPart_000_02D8_01D17F73.D6FD5BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all: =

 

The interim meeting did not have enough people (4 = people) to call it an interim.  We’ll discuss these topics at = IETF 95 in Buenos Aires, and on the list.

 

The slides = which may help you understand the discussion are at:

https://www.ietf.org/proceedings/interim/2016/03/16/i2rs/procee= dings.html

 

Sue = Hares

------=_NextPart_000_02D8_01D17F73.D6FD5BF0-- From nobody Wed Mar 16 18:36: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 D700412D81E; Wed, 16 Mar 2016 18:36:24 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317013624.18209.45055.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 18:36:24 -0700 Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org, Fred@cisco.com Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 01:36:25 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of points, not all of them are minor (I've been wondering: COMMENT or DISCUSS. Let's go for a COMMENT) - "Second is the access to structured information and state that is frequently not directly configurable". I have a hard time reconciling the NETMOD state definition, for example from https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04 It would be good if the terminology were aligned. - This I2RS architecture assumes a data-model driven protocol where the data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1 ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). " RFC 6020 is YANG 1.0, not YANG 1.1 I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1 btw, this "YANG" not "Yang" - Are the two sentences redundant? As can be seen in Figure 1, an I2RS client can communicate with multiple I2RS agents. An I2RS client may connect to one or more I2RS agents based upon its needs. - There are several key benefits for I2RS in using model-driven architecture and protocol(s). First, it allows for transferring data-models whose content is not explicitly implemented or understood. Reading that second sentence multiple times, I still fail to understand. Model-driven on one side, but you want data-models whose content is not explicitly implemented or understood. Really confused. - Two of the existing protocols which the which may be re-used are NETCONF [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf]. "may be reused". What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used. On my side this architecture is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or YANG1.1), and in some cases, a complete specification (for example the notification) To handle I2RS Agent failure, the I2RS Agent must use two different notifications. NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the I2RS Client(s) that the associated I2RS Agent has started. It includes an agent-boot-count that indicates how many times the I2RS Agent has restarted since the associated routing element restarted. The agent-boot-count allows an I2RS Client to determine if the I2RS Agent has restarted. (Note: This notification will be only transmitted to I2RS clients which are know in some way after a reboot.) - editorial: Optionally, a routing element may permit a priority to be to be - For the case when the I2RS ephemeral state always wins for a data model, if there is an I2RS ephemeral state value it is installed instead of the local configuration state. Again, I read that sentence multiple times, and could not understand it - figure 2. "The initial services included in the I2RS architecture are as follows." Are these really the initial services for I2RS. I2RS is really dealing with all these: interfaces, policy, QoS, ... Maybe I should review the I2RS charter? - The I2RS protocol may need to use several underlying transports (TCP, SCTP (stream control transport protocol), DCCP (Datagram Congestion Control Protocol)), with suitable authentication and integrity protection mechanisms Do you really want to have define transports? And below is Fred Baker's OPS DIR review: The first nit is a statement in section 1.1: Such an interface also facilitates the injection of ephemeral state into the routing system. Ephemeral state on a router is the state which does not survive a the reboot of a routing device or the reboot of the software handling the I2RS software on a routing device. Ephemeral state is state that is "ephemeral", which my dictionary tells me means that it is "short-lived, transitory, lasting a short time". This comes to mind because of a paper I discovered I was a co-author on (story in the presence of adult beverages) last year, which suggested that congested links in a network could be offloaded by directing a subset of the routes, or a subset of the traffic using those routes, using them to other links that a routing protocol might contend were below par but which provided a non-looping path and had available capacity. The issue was that when routing changed for any reason, these SDN changes had to be undone and redone, a process that could take (in the network of interest) on the order of 40 minutes. My suggestion to my "co-authors" was that they simply change the FIB (which is by definition ephemeral), so that should routing change the FIB would became predictably correct (e.g., with no such optimizations added to it) after having re-converged, and they could now re-optimize the FIB as they saw fit without incurring a potential outage. I would suggest that the above reference to a reboot be changed to "Ephemeral state on a router is state that changes from time to time". A reboot is only one of those times. At the top of page 6, the first paragraph reads: The I2RS agent provides read and write access to selected data on the routing element that are organized into I2RS Services. Section 4 describes how access is mediated by authentication and access control mechanisms. Figure 1 shows I2RS agents being able to write ephemeral static state (e.g. RIB entries), and to read from dynamic static (e.g. MPLS LSP-ID or number of active BGP peers). In addition, the I have a hunch the authors intended to complete the final sentence. In section 3.1, which comments on "simplicity", I am very much in favor of simplicity in the sense described by RFC 3439. That said, I think the paper misses the mark by a few millimeters. It says Thus, one of the key aims for I2RS is the keep the protocol and modeling architecture simple. So for each architectural component or aspect, we ask ourselves "do we need this complexity, or is the behavior merely nice to have?" Often, simplicity is not about whether a feature is itself complex, but about whether what is externalized is complex. Theorists dealing with complexity use a swimming duck as an example: viewed from above the water line, the duck is a picture of placidity in motion, while when viewed from below its paddle feet are madly beating the water. A communication example is in TCP; heaven only knows what is really happening in the network, but TCP narrows the entire discussion into two signal classes - in this RTT, it has received a congestion signal, or it has not, and it has either received acknowledgements indicating forward progress in the session, or it has not. From the application's perspective, there is sufficient forward progress to merit continuing the session at whatever rate it is able to proceed, or progress is inadequate. Within TCP, there is actually a fair bit of complexity. However, what it externalizes to a client application is dead simple. So I would go beyond "do I need this complexity" to "do I need for this complexity to be externalized, do I need it at all, and if I need it, is there a way to meet the need with a simpler external API?" In section 4 and 4.2, I'm concerned about the issues of authorization "for classes of statements", which are mentioned obliquely but not really gone into. My personal bugaboo in this context is the router I use at my home, which is functionally equivalent to two separate routers coexisting in a single chassis. One router connects my home office to my employer using a VPN, and the other is a very typical residential CPE. We have similar issues whenever a router has multiple routing tables or contains multiple virtual routers. When I read An I2RS Client is not automatically trustworthy. Each I2RS Client is associated with identity with a set of scope limitations. I read "scope limitations" as a reference to "authorization", but I think this concept needs to be fleshed out more. An I2RS client (or the server it serves), perhaps on an interface, has a set of information, which may be complete, null, or anywhere in between, for which it is trustworthy, and it is not trustworthy for anything else. In a network like my home, I could imagine a route controller operated by my employer's IT organization and another operated by me or by my ISP on my behalf. If a single system contains multiple clients or serves multiple servers, that difference of authorization can be important. We understand that in some detail in BGP; it needs to be handled in I2RS as well. From nobody Wed Mar 16 19:35: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 D612312D962; Wed, 16 Mar 2016 19:35: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 wb2TlXTWly_R; Wed, 16 Mar 2016 19:35: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 2D86912D832; Wed, 16 Mar 2016 19:34:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Benoit Claise'" , "'The IESG'" References: <20160317013624.18209.45055.idtracker@ietfa.amsl.com> In-Reply-To: <20160317013624.18209.45055.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 22:33:48 -0400 Message-ID: <046601d17ff5$70c29350$5247b9f0$@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: AQJuHcYb7/SZZUWU/t5YvEsTyir/a54jpRYA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org, Fred@cisco.com Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 02:35:08 -0000 Benoit: Great comments - see below. Thanks for finding additional typos/unclear text. You some good questions - I hope my answers were as good. Cheerily, Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Wednesday, March 16, 2016 9:36 PM To: The IESG Cc: i2rs@ietf.org; mach.chen@huawei.com; i2rs-chairs@ietf.org; draft-ietf-i2rs-architecture@ietf.org; Fred@cisco.com Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >A couple of points, not all of them are minor (I've been wondering: >COMMENT or DISCUSS. Let's go for a COMMENT) > >- "Second is the access to structured information and state that is frequently not directly configurable". >I have a hard time reconciling the NETMOD state definition, for example from https://tools.ietf.org/html/draft->ietf-netmod-opstate-reqs-04 It would be good if the terminology were aligned. Sue: You are so right. The ietf-netmod-opstate-reqs-04 was not approved when I started the process - but I will do this in -14.txt > This I2RS architecture assumes a data-model driven protocol where the > data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1 > ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model > drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). " >RFC 6020 is YANG 1.0, not YANG 1.1 >I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1 btw, this "YANG" not "Yang" Sue: On Yang --> YANG (Ack - will fix in -14.txt). Will change error on RFC6020 to 1.0. Due to all the features we need for pub/sub - I2RS will be Yang 1.1. > Are the two sentences redundant? > As can be seen in Figure 1, an I2RS client can communicate with > multiple I2RS agents. An I2RS client may connect to one or more I2RS > agents based upon its needs. Sue: Sigh. Other reviewers felt that we needed the second sentence to Indicate that is was 1-n I2RS Agents. > There are several key benefits for I2RS in using model-driven > architecture and protocol(s). First, it allows for transferring > data-models whose content is not explicitly implemented or understood. > Reading that second sentence multiple times, I still fail to understand. > Model-driven on one side, but you want data-models whose content is not explicitly implemented or understood. > Really confused. Sue: I see your point on the editorial issue, and I will try to fix it. (see -14.txt) >Two of the existing protocols which the > which may be re-used are NETCONF [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]. >editorial "may be reused". / I will check with RFC editor (some people say reused /re-used). >What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used. > On my side this architecture is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or > YANG1.1), and in some cases, a complete specification (for example the notification) Sue: NETCONF and RESTCONF will be supported as part of the I2RS protocols. The architecture does out rule out other data transfer protocols, but says the WG will design I2RS as a higher level protocol that combines other protocols (NETCONF/RESTCONF + x). The I2RS requirements documents and protocol strawman will state is if any other protocols will be used for a particular version of I2RS with a particular scope for data modules. I am sorry if this is not what you excepted, but it was my direction from my AD on how to approach this work. At this time, we are closing in on the last of the requirements documents - the requirements for other data flows. draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data flows, but IMO the first version of the I2RS is likely to stay with just NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog module library, and some yang changes. > To handle I2RS Agent failure, the I2RS Agent must use two different notifications. > NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the > I2RS Client(s) that the associated I2RS Agent has started. It > includes an agent-boot-count that indicates how many times the > I2RS Agent has restarted since the associated routing element > restarted. The agent-boot-count allows an I2RS Client to > determine if the I2RS Agent has restarted. (Note: This > notification will be only transmitted to I2RS clients which are > know in some way after a reboot.) >- editorial: > Optionally, a routing element may permit a priority to be to be.... > For the case when the I2RS ephemeral state always wins for a data > model, if there is an I2RS ephemeral state value it is installed > instead of the local configuration state. > Again, I read that sentence multiple times, and could not understand it Sue: Reasonable editorial comment. This was added to address another comment, But it looks like we broken something. Text change below. Old/ Optionally, a routing element may permit a priority to be to be configured on the device for the Local Configuration mechanism interaction with the I2RS model. The policy mechanism would compare the I2RS client's priority with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS wins. For the case when the I2RS ephemeral state always wins for a data model, if there is an I2RS ephemeral state value it is installed instead of the local configuration state. The local configuration information is stored so that if/when I2RS client removes I2RS ephemeral state the local configuration state can be restored. / New: Optionally, a routing element may permit a priority to be to be configured on the device for the Local Configuration mechanism interaction with the I2RS model. The policy mechanism would compare the I2RS client's priority with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS wins. For the case when the configured priority of the I2RS ephemeral Is higher than the Local Configuration's policy, the The I2RS ephemeral state value it is installed instead of the local configuration state. The local configuration information is stored so that if/when I2RS client removes I2RS ephemeral state the local configuration state can be restored. / > figure 2. "The initial services included in the I2RS architecture are as follows." > Are these really the initial services for I2RS. I2RS is really dealing with all these: interfaces, policy, QoS, ... > Maybe I should review the I2RS charter? Sue: Our charter is wide, but only ephemeral layer deep. Due to the excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS - we are focusing on allowing ephemeral to be added to any data model. I2RS WG is focused first on the I2RS protocol and protocol independent modules. After this, I2RS purpose is to simply support other WGs in creating data modules with ephemeral state. > The I2RS protocol may need to use several underlying transports (TCP, SCTP > (stream control transport protocol), DCCP (Datagram Congestion > Control Protocol)), with suitable authentication and integrity > protection mechanisms > Do you really want to have define transports? Sue: We indicate that I2RS will use these protocols. Each protocol we mention has to be then validated with requirements (see protocol security requirement and security environment requirements). >And below is Fred Baker's OPS DIR review: Sue: Responded to Fred on another channel - before I got your message. I will not repeat it here. ========================== The first nit is a statement in section 1.1: Such an interface also facilitates the injection of ephemeral state into the routing system. Ephemeral state on a router is the state which does not survive a the reboot of a routing device or the reboot of the software handling the I2RS software on a routing device. Ephemeral state is state that is "ephemeral", which my dictionary tells me means that it is "short-lived, transitory, lasting a short time". This comes to mind because of a paper I discovered I was a co-author on (story in the presence of adult beverages) last year, which suggested that congested links in a network could be offloaded by directing a subset of the routes, or a subset of the traffic using those routes, using them to other links that a routing protocol might contend were below par but which provided a non-looping path and had available capacity. The issue was that when routing changed for any reason, these SDN changes had to be undone and redone, a process that could take (in the network of interest) on the order of 40 minutes. My suggestion to my "co-authors" was that they simply change the FIB (which is by definition ephemeral), so that should routing change the FIB would became predictably correct (e.g., with no such optimizations added to it) after having re-converged, and they could now re-optimize the FIB as they saw fit without incurring a potential outage. I would suggest that the above reference to a reboot be changed to "Ephemeral state on a router is state that changes from time to time". A reboot is only one of those times. At the top of page 6, the first paragraph reads: The I2RS agent provides read and write access to selected data on the routing element that are organized into I2RS Services. Section 4 describes how access is mediated by authentication and access control mechanisms. Figure 1 shows I2RS agents being able to write ephemeral static state (e.g. RIB entries), and to read from dynamic static (e.g. MPLS LSP-ID or number of active BGP peers). In addition, the I have a hunch the authors intended to complete the final sentence. In section 3.1, which comments on "simplicity", I am very much in favor of simplicity in the sense described by RFC 3439. That said, I think the paper misses the mark by a few millimeters. It says Thus, one of the key aims for I2RS is the keep the protocol and modeling architecture simple. So for each architectural component or aspect, we ask ourselves "do we need this complexity, or is the behavior merely nice to have?" Often, simplicity is not about whether a feature is itself complex, but about whether what is externalized is complex. Theorists dealing with complexity use a swimming duck as an example: viewed from above the water line, the duck is a picture of placidity in motion, while when viewed from below its paddle feet are madly beating the water. A communication example is in TCP; heaven only knows what is really happening in the network, but TCP narrows the entire discussion into two signal classes - in this RTT, it has received a congestion signal, or it has not, and it has either received acknowledgements indicating forward progress in the session, or it has not. >From the application's perspective, there is sufficient forward progress to merit continuing the session at whatever rate it is able to proceed, or progress is inadequate. Within TCP, there is actually a fair bit of complexity. However, what it externalizes to a client application is dead simple. So I would go beyond "do I need this complexity" to "do I need for this complexity to be externalized, do I need it at all, and if I need it, is there a way to meet the need with a simpler external API?" In section 4 and 4.2, I'm concerned about the issues of authorization "for classes of statements", which are mentioned obliquely but not really gone into. My personal bugaboo in this context is the router I use at my home, which is functionally equivalent to two separate routers coexisting in a single chassis. One router connects my home office to my employer using a VPN, and the other is a very typical residential CPE. We have similar issues whenever a router has multiple routing tables or contains multiple virtual routers. When I read An I2RS Client is not automatically trustworthy. Each I2RS Client is associated with identity with a set of scope limitations. I read "scope limitations" as a reference to "authorization", but I think this concept needs to be fleshed out more. An I2RS client (or the server it serves), perhaps on an interface, has a set of information, which may be complete, null, or anywhere in between, for which it is trustworthy, and it is not trustworthy for anything else. In a network like my home, I could imagine a route controller operated by my employer's IT organization and another operated by me or by my ISP on my behalf. If a single system contains multiple clients or serves multiple servers, that difference of authorization can be important. We understand that in some detail in BGP; it needs to be handled in I2RS as well. _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Mar 16 19:38: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 CA15412DADE; Wed, 16 Mar 2016 19:38:50 -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 xMMYxi3iLW_J; Wed, 16 Mar 2016 19:38:49 -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 2FA3812D962; Wed, 16 Mar 2016 19:38:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Terry Manderson'" , "'The IESG'" References: <20160316052623.21136.77818.idtracker@ietfa.amsl.com> In-Reply-To: <20160316052623.21136.77818.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 22:36:06 -0400 Message-ID: <046801d17ff5$c27704b0$47650e10$@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: AQFYM4BQjUP+Xo1/OYzh5z8ukgwjY6BOjoTQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Terry Manderson's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 02:38:51 -0000 Terry:=20 Before I respond in depth, did you read my responses to Alvaro? If so, = please let me know specific issue that was not addressed. If something = makes you "uneasy", please let me know - it may help us now and in = future work.=20 The intent is to consider the whole routing system (loads, stress, and = others) as we design in data models and protocols--- Thus our intent is = to make addition "safe" to add by careful engineering toward protocol = performance (E.g. publication/subscription mechanisms handling of large = data and events) and data model design (for actions, updates and down = load). 5 requirement drafts for the protocol (ephemeral state, = publication/subscription, protocol security, traceability, data flow = requirements) and 1 for the system (security environment).=20 =20 Sue=20 -----Original Message----- From: Terry Manderson [mailto:terry.manderson@icann.org]=20 Sent: Wednesday, March 16, 2016 1:26 AM To: The IESG Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org; = mach.chen@huawei.com; i2rs@ietf.org Subject: Terry Manderson's No Objection on = draft-ietf-i2rs-architecture-13: (with COMMENT) Terry Manderson has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi there, Firstly, I support Alvaro's two significant comments, especially with = regards to the outcomes of the I2RS initiated change. My reading of the = draft is that the resulting architecture espouses to judge intent, or = the very least the outcome of the intent, as safe. How? Apologies if I = read more into this than intended, please help clarify. I only saw one nit that hadn't been noticed in other comments. Section 3: para, last sentence. "may may" Thanks From nobody Wed Mar 16 22:07:35 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 5610512D890; Wed, 16 Mar 2016 22:07:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317050731.28048.13647.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 22:07:31 -0700 Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: [i2rs] Spencer Dawkins' No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 05:07:31 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text: 7.1. One Control and Data Exchange Protocol The I2RS protocol may need to use several underlying transports (TCP, SCTP (stream control transport protocol), DCCP (Datagram Congestion Control Protocol)), with suitable authentication and integrity protection mechanisms. These different transports can support different types of communication (e.g. control, reading, notifications, and information collection) and different sets of data. Whatever transport is used for the data exchange, it must also support suitable congestion control mechanisms. The transports chosen should be operator and implementor friendly to ease adoption. I echo Benoit's question about defining multiple underlying transports. I suspect you'll need to pick one mandatory-to-implement transport protocol, and when everyone has to support that one, I'd be surprised to see implementations that support more than one transport protocol unless the mandatory-to-implement transport protocol is seriously broken in some scenarios. From nobody Thu Mar 17 00:36: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 2D76312D86B; Thu, 17 Mar 2016 00:36:17 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317073617.24279.49371.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 00:36:17 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-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: Thu, 17 Mar 2016 07:36: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 : A YANG Data Model for Routing Information Base (RIB) Authors : Lixing Wang Hariharan Ananthakrishnan Mach(Guoyi) Chen Amit Dass Sriganesh Kini Nitin Bahadur Filename : draft-ietf-i2rs-rib-data-model-05.txt Pages : 66 Date : 2016-03-17 Abstract: This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-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 Thu Mar 17 02:01:23 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 18CB912D691; Thu, 17 Mar 2016 02:01:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317090122.19193.44222.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 02:01:22 -0700 Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, housley@vigilsec.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: [i2rs] Jari Arkko's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 09:01:22 -0000 Jari Arkko has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Russ Housley's Gen-ART review raised the following question and editorial comments. I believe it would be useful for the authors to think about the question at least, but I have not seen a response yet: --- Minor Concerns: Section 4.2 talks about authorization. I would expect policy to dictate that some writes come from a specific source, but it is unclear to me whether I2RS can require that a particular write request arrive on a particular channel. Is this desirable? If so, please expand the discussion of authorization to cover this point. Nits: Sometimes you say "i2rs architecture", but it should say "I2RS architecture" to be consistent throughout the document. Sometimes you say "I2RS Agent" and other times you say "I2RS agent". Please pick one and use it consistently. Sometimes you say "I2RS Client" and other times you say "I2RS client". Please pick one and use it consistently. Section 3: s/ may may vary based / may vary based / Section 6.3: s/ the yang data model / the YANG data model / Section 6.4.2: some bullets have periods, but others do not. Section 7.1: s/ Yang / YANG / (more than one place) From nobody Thu Mar 17 05:15: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 80DC812D535; Thu, 17 Mar 2016 05:15:23 -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 hkFegd2ph_pD; Thu, 17 Mar 2016 05:15:22 -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 9455B12D92C; Thu, 17 Mar 2016 05:15:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Spencer Dawkins'" , "'The IESG'" References: <20160317050731.28048.13647.idtracker@ietfa.amsl.com> In-Reply-To: <20160317050731.28048.13647.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 08:14:41 -0400 Message-ID: <007c01d18046$96372f00$c2a58d00$@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: AQI0N1ZyZGmcrH7Dj1x+u5eZhX/Zpp6YFrLQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Spencer Dawkins' No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 12:15:23 -0000 Spencer:=20 Thank you for your comments. Perhaps a bit of context will help ---=20 I2RS WG goal is not to create new protocols, but to re-use and extend = existing protocols. This creates a bit if a different flow in the = document path. The architecture design allows for multiple protocols = (NETCONF, RESTCONF, and others) with multiple encodings (XML, JSON) so = that the WG could work through these protocols. However, in any = particular version of the protocol will have: a) a set of requirements for features,=20 b) set of valid application protocols (e.g. NETCONF, RESTCONF) with = specific features (E.g. ephemeral state, publication/subscription = service, traceability, insecure data) c) a set of valid transport protocols (TLS, SSH, HTTP) that transport = the application, d) a set of valid protocol security mechanisms,=20 e) recommendations for security environment, and=20 f) data models supported by the protocol.=20 We are currently finalizing the requirements for version 1 with the = protocol strawman released this week for extensions to NETCONF/RESTCONF. = =20 Sue=20 -----Original Message----- From: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com]=20 Sent: Thursday, March 17, 2016 1:08 AM To: The IESG Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org; = mach.chen@huawei.com; i2rs@ietf.org Subject: Spencer Dawkins' No Objection on = draft-ietf-i2rs-architecture-13: (with COMMENT) Spencer Dawkins has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text: 7.1. One Control and Data Exchange Protocol The I2RS protocol may need to use several underlying transports (TCP, SCTP (stream control transport protocol), DCCP (Datagram Congestion Control Protocol)), with suitable authentication and integrity protection mechanisms. These different transports can support different types of communication (e.g. control, reading, notifications, and information collection) and different sets of data. Whatever transport is used for the data exchange, it must also support suitable congestion control mechanisms. The transports chosen should be operator and implementor friendly to ease adoption. =20 I echo Benoit's question about defining multiple underlying transports. = I suspect you'll need to pick one mandatory-to-implement transport = protocol, and when everyone has to support that one, I'd be surprised to = see implementations that support more than one transport protocol unless = the mandatory-to-implement transport protocol is seriously broken in = some scenarios. From nobody Thu Mar 17 05:21: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 8BB0112D540; Thu, 17 Mar 2016 05:21:35 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 05:21:35 -0700 Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 12:21:35 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - If i2rs were used to control home networks, then that would raise more privacy issues, e.g. the agent's IP address can be privacy sensitive. Would it be useful to rule that out of scope? E.g. to say that i2rs SHOULD NOT be used where the agent/router in question is specific to one person or home? - section 2: security role, hmm..... Do netconf/restconf have the concept of mapping identifiers to roles? If not, that might be tricky to graft on. Not sure. - section 4: "Mutual authentication between the I2RS Client and I2RS Agent is required. " yay! thanks:-) Even better if you did s/Mutual/Strong mutual/ to prevent someone saying that TCP-MD5 is good enough. - section 4: "The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, confidentiality and replay protection." yay! again! :-) - section 4: "Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS Client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection." sorry, boo! :-) It's often unsafe to mix and match differently protected sets of data between the same sets of entities. I think you'd be better off there saying that the requirements may *exceptionnally* differ but usually only because of e.g. some level of broadcast or multicast being part of the story, where we don't have good usable security solutions today. (This is not a DISCUSS because I think the protocol work will end up saying "just use TLS always" as that'll be simpler and better, so I hope this'll be a non-issue. If you know already that there's some other plan in place, then please say so we can chat now and avoid a trickier discussion later.) - section 4: I think you're heading here towards use of TLS and not object level security. Is that right? If so, would it be useful to say so? (Just so as to correctly set expectations for later.) - 7.7: Would it be useful to say that the relevant information here is only about network state and stastics and not about connections (e.g. who spoke to whom) or payloads? That might save some discussions about RFC2804 later on. From nobody Thu Mar 17 05:23: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 2FEF812D9FE for ; Thu, 17 Mar 2016 05:23: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 NHgiRKgGHfER for ; Thu, 17 Mar 2016 05:23: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 4DF8012DA4C for ; Thu, 17 Mar 2016 05:16:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: References: <006001d18042$a0b35840$e21a08c0$@ndzh.com> In-Reply-To: <006001d18042$a0b35840$e21a08c0$@ndzh.com> Date: Thu, 17 Mar 2016 08:16:26 -0400 Message-ID: <007e01d18046$d44a24f0$7cde6ed0$@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: AQEZ/AVgQVWgnzMQU2OaJu0vFwtWVQE/NTh0oMKb0wA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' Subject: [i2rs] FW: Gen-ART review of draft-ietf-i2rs-architecture-13 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, 17 Mar 2016 12:23:46 -0000 Fyi - response to Russ Housley. Sue -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, March 17, 2016 7:46 AM To: 'Russ Housley'; draft-ietf-i2rs-architecture.all@ietf.org Cc: 'IETF Gen-ART'; 'Jari Arkko' Subject: RE: Gen-ART review of draft-ietf-i2rs-architecture-13 Russ: I apologize for the delayed response. I thought I had responded earlier. I appreciate Jari's email that reminded me I had not sent this email. The policy dictates that writes can come from a particular specific source, but we are not requiring things to come on a particular channel. This is not desirable because we are allowing writes to come on multiple channels (RESTCONF/NETCONF - at least). Is the authorization section 4.2 - sufficient if this is the case? Sue -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Sunday, March 06, 2016 6:54 PM To: draft-ietf-i2rs-architecture.all@ietf.org Cc: IETF Gen-ART Subject: Gen-ART review of draft-ietf-i2rs-architecture-13 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-i2rs-architecture-13 Reviewer: Russ Housley Review Date: 2016-03-06 IETF LC End Date: 2016-03-14 IESG Telechat date: unknown Summary: Ready. Major Concerns: None Minor Concerns: Section 4.2 talks about authorization. I would expect policy to dictate that some writes come from a specific source, but it is unclear to me whether I2RS can require that a particular write request arrive on a particular channel. Is this desirable? If so, please expand the discussion of authorization to cover this point. Nits: Sometimes you say "i2rs architecture", but it should say "I2RS architecture" to be consistent throughout the document. Sometimes you say "I2RS Agent" and other times you say "I2RS agent". Please pick one and use it consistently. Sometimes you say "I2RS Client" and other times you say "I2RS client". Please pick one and use it consistently. Section 3: s/ may may vary based / may vary based / Section 6.3: s/ the yang data model / the YANG data model / Section 6.4.2: some bullets have periods, but others do not. Section 7.1: s/ Yang / YANG / (more than one place) From nobody Thu Mar 17 06:02: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 BE44012D6F4; Thu, 17 Mar 2016 06:01:57 -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 hBrL30flpusw; Thu, 17 Mar 2016 06:01:55 -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 87A0D12D89E; Thu, 17 Mar 2016 06:01:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Stephen Farrell'" , "'The IESG'" References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> In-Reply-To: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 09:00:48 -0400 Message-ID: <009501d1804d$070091d0$1501b570$@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: AQHacCPIaSnTqpnEd1O1DdaUpagcZZ9LsWaw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 13:01:58 -0000 Stephen:=20 Thank you for your comments. See answers below. I hope you will stay = involved in reviews. It is critical we consider privacy and security = for this new interface. Sue=20 -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Thursday, March 17, 2016 8:22 AM To: The IESG Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org; = mach.chen@huawei.com; i2rs@ietf.org Subject: Stephen Farrell's No Objection on = draft-ietf-i2rs-architecture-13: (with COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >- If i2rs were used to control home networks, then that would raise = more privacy issues,=20 >e.g. the agent's IP address can be privacy sensitive. Would it be = useful to rule that out of > scope? E.g. to say that i2rs SHOULD NOT be used where the = agent/router in question=20 > is specific to one person or home? Sue: I'm really not sure what you are getting at. Data in routers is = privacy sensitive. =20 Data between I2RS Agent and I2RS client will be encrypted except in = very, very rare circumstances where is defined to be public data in the = data model. SECDIR, OPSDIR, RTGWG, Transport-directorate will be asked = to review any IETF data model that claims this is the case to validate = it is appropriate. So... I think we are going beyond what people use = for home networks. =20 > section 2: security role, hmm..... Do netconf/restconf have the = concept of mapping >identifiers to roles? If not, that might be tricky = to graft on. Not sure. Sue:=20 - section 4: "Mutual authentication between the I2RS Client and I2RS = Agent is required. " yay! thanks:-) Even better if you did = s/Mutual/Strong mutual/ to prevent someone saying that TCP-MD5 is good = enough. Sue: At least 15 years with BGP has taught about some mistakes.=20 - section 4: "The primary communication channel that is used for client = authentication and then used by the client to write data requires = integrity, confidentiality and replay protection." yay! again! :-) Sue: This is why I do not understand the first question.=20 - section 4: "Other communications via I2RS may not require integrity, = confidentiality, and replay protection. For instance, if an I2RS Client = subscribes to an information stream of prefix announcements from OSPF, = those may require integrity but probably not confidentiality or replay = protection." sorry, boo! :-)=20 Sue: I agree the bar should be high on all of our streams. I hope you = will review (as AD or sec-dir) our proposed streams for replay. The WG = indicated that if OSPF is good enough to run the network, it is secure = enough to listen to. Perhaps OSPF needs to change (smile). =20 It's often unsafe to mix and match differently protected sets of data = between the same sets of entities. I think you'd be better off there = saying that the requirements may *exceptionnally* differ but usually only because of e.g. some level of = broadcast or multicast being part of the story, where we don't have good = usable security solutions today. (This is not a DISCUSS because I think = the protocol work will end up saying "just use TLS always" as that'll be = simpler and better, so I hope this'll be a non-issue. If you know = already that there's some other plan in place, then please say so we can = chat now and avoid a trickier discussion later.)=20 Sue: 90% answer is "just use TLS as always. For the first version of = I2RS protocol we will use NETCONF/RESTCONF as the base for = configuration, publication/subscription of large data, and action = commands. NETCONF has definitions over TLS and over SSH. RESTCONF runs = of HTTP and requires TLS. We are finalizing requirements for insecure = stream and multicast - so I would really like to hear your concerns in = person. =20 - section 4: I think you're heading here towards use of TLS and not = object level security. Is that right? If so, would it be useful to say = so? (Just so as to correctly set expectations for later.) Sue: We are using TLS, but we are indicating that certain data models = are only allowed to be accessed (read, write, or both) by certain users. = This fits within the NETCONF/RESTCONF concepts. =20 - 7.7: Would it be useful to say that the relevant information here is = only about network state and stastics and not about connections (e.g. = who spoke to whom) or payloads? That might save some discussions about = RFC2804 later on. Sue: Yes, sections about network state. It is about network = connections and topologies - but not about "who spoke to whom" or = payloads. =20 From nobody Thu Mar 17 06:11: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 4CAB112D913; Thu, 17 Mar 2016 06:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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.001, 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 6Y1h9JyiEVwz; Thu, 17 Mar 2016 06:11:26 -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 6156412D8E2; Thu, 17 Mar 2016 06:10:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8AB84BE57; Thu, 17 Mar 2016 13:10:57 +0000 (GMT) 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 3t_dAfutOWox; Thu, 17 Mar 2016 13:10:56 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.42.16.188]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5B294BE59; Thu, 17 Mar 2016 13:10:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458220256; bh=NJMIW95Vy4KP1GoIalBf/SHyy5w528LiT0FzZIplpuY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=yw22mfsofY5KFKpV9f+UmC2XZunZkelvjdTw8wYlKTWV2SQRGSCCYL2eWLs+kVhaI PvLIdtTQJUD0d4G5YQXLKVkjqO9/tEywJot1+4FIY0clx4YiCBfPr/PJuSy15gQU8I fW2S1Fdr3OUIq5pyAn8YAaSimxABSklB6RkBEjQ8= To: Susan Hares , 'The IESG' References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> <009501d1804d$070091d0$1501b570$@ndzh.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56EAACDF.8030009@cs.tcd.ie> Date: Thu, 17 Mar 2016 13:10:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <009501d1804d$070091d0$1501b570$@ndzh.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020901060401090801040001" Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 13:11:34 -0000 This is a cryptographically signed message in MIME format. --------------ms020901060401090801040001 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Just on that one point (the rest seems fine): On 17/03/16 13:00, Susan Hares wrote: >>> - If i2rs were used to control home networks, then that would >>> raise more privacy issues, e.g. the agent's IP address can be >>> privacy sensitive. Would it be useful to rule that out of >> scope? E.g. to say that i2rs SHOULD NOT be used where the >> agent/router in question >>> is specific to one person or home? > Sue: I'm really not sure what you are getting at. Data in routers > is privacy sensitive. Data between I2RS Agent and I2RS client will be > encrypted except in very, very rare circumstances where is defined to > be public data in the data model. SECDIR, OPSDIR, RTGWG, > Transport-directorate will be asked to review any IETF data model > that claims this is the case to validate it is appropriate. So... I > think we are going beyond what people use for home networks. Let's assume all client/agent stuff is wonderfully protected e.g. via TLS. Normally, the fact that a client at IP1 is managing an agent at IP2, which is still visible despite the TLS, is not much of a deal. Nor is it a deal when that happens, e.g. in reaction to some other event, perhaps even one triggered by an attacker. But if the agent is my home g/w, then the sensitivity level goes up I think, or at least it can. The reason is that the agent's address (IP2) is tied to me. If the agent was on my phone (e.g. for tethering) then it'd be even more of a deal perhaps, as I carry it with me. If i2rs just isn't intended for such use-cases, it may be worth saying that was all I meant. Cheers, S. >=20 --------------ms020901060401090801040001 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTcx MzEwNTVaMC8GCSqGSIb3DQEJBDEiBCA/iOrUSq+iKbK2sFuAq25QGy2AjSSXe7itDvHvgVdP WDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA7clwQwJR6sNtKwvKRx+wtZntgQnmolzeG3ggARYndzxf/ZJLqOPqd L+8lJL/aGHtlmkAtY4z2yi2dHnfmJrrWkYEZ/RmCit3SCh9mw9i3zH1TwMIFTz/Mkj3sn7h8 vcFQA2NuIFEdRyQgKCT96nX8oi3CmxZwO9e9lARBv3YuO3l7v9KlxxqLUsx7SDO+MGW6CyhF arpz19Kto6ylMP+ck7sMa8YejWHIORkuqIXo4zT3djTCMe0VtAu07J82oy13kXYaWhZjIbXz J6sXkYBEJ/oBomKgySPGSvk486v+A7p2H03yt6GuVFKk8RPgaSY9NWeCvv9Pq9O3M834LviI AAAAAAAA --------------ms020901060401090801040001-- From nobody Thu Mar 17 06:16:03 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 532FB12D577; Thu, 17 Mar 2016 06:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, 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 uLJUaXfycn4h; Thu, 17 Mar 2016 06:15:54 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1C612D519; Thu, 17 Mar 2016 06:15:53 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-ea-56eaa8cc91dc Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 40.D4.30335.CC8AAE65; Thu, 17 Mar 2016 13:53:32 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Thu, 17 Mar 2016 09:15:51 -0400 From: Joel Halpern To: Stephen Farrell , Susan Hares , 'The IESG' Thread-Topic: Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Thread-Index: AQHRgEeUMrxXk2ChxkSiFfv0Q6K7Kp9d3IsAgAAC1ID//719YA== Date: Thu, 17 Mar 2016 13:15:50 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB076150FB2ED@eusaamb101.ericsson.se> References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> <009501d1804d$070091d0$1501b570$@ndzh.com> <56EAACDF.8030009@cs.tcd.ie> In-Reply-To: <56EAACDF.8030009@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0011_01D18057.812E2490" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUyuXSPn+6ZFa/CDA4vMbbonfef0eLDsWY2 i3UzPrBYzPgzkdniwlphiz9vXrFYTN97jd2B3WNt91U2j5Yjb1k9liz5yeQx+/V11gCWKC6b lNSczLLUIn27BK6M38s3MBV0RFZ8vvyNtYGxJ7iLkZNDQsBE4vy9DiYIW0ziwr31bF2MXBxC AkcYJSY2LYVyljNKLJv8nhWkik1AT2Lt+8dgHSICORIbz78Fs5kFbjBK9C2N6WLk4BAWSJBo 3BsKUZIocflVB1S5k8T3tw9YQGwWAVWJ5fcfMoKU8wr4SmxZ4AwSFhLoZpT4fTgIxOYU0JRY 9WkiO4jNCHTb91NroDaJS9x6Mh/qZhGJhxdPs0HYohIvH/9jhbAVJfb1T2cHOZ9ZoJdR4t36 T2AJXgFBiZMzn7BMYBSdhWTWLGR1s5DUQRRpSzy9+RTKlpfY/nYOM4RtLTHj10E2CFtRYkr3 Q3YI21Ti9dGPjAsYOVYxcpQWF+TkphsZbGIExuwxCTbdHYz3p3seYhTgYFTi4S14+jJMiDWx rLgy9xCjClDrow2rLzBKseTl56UqifCeW/0qTIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv+reX w4QE0hNLUrNTUwtSi2CyTBycUg2M2bs7r8x7Kb1IP22v2XNBuzX9k/kCOxwex/wNjhfYfErW fUtoVkb5enP3bueVGxY+C5BjClxYZaDHJf309p7szrk9Bh3ve0K21CuUSwvO8xatnJRpNaF2 cdvW47tuuk6YerPW/GDkj+lTjczOp9yvDC5w++DyedK5rN99C+9lXU5d5HVB96ybEktxRqKh FnNRcSIA/4pmVOECAAA= Archived-At: Cc: "i2rs@ietf.org" , "mach.chen@huawei.com" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-architecture@ietf.org" Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 13:15:56 -0000 ------=_NextPart_000_0011_01D18057.812E2490 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I would hope that I2RS could be used for that (applying policy to home devices) use case. But I am not at all clear how I2RS could protect the IP address of the router containing the communicating I2RS agent. We have to have an available IP address for IP Routing. I am also not clear why this IP address is particularly more sensitive than an enterprise device IP address, or a router inside an ISP. Yours, Joel -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, March 17, 2016 2:11 PM To: Susan Hares; 'The IESG' Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org; mach.chen@huawei.com; i2rs@ietf.org Subject: Re: Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Hiya, Just on that one point (the rest seems fine): On 17/03/16 13:00, Susan Hares wrote: >>> - If i2rs were used to control home networks, then that would >>> raise more privacy issues, e.g. the agent's IP address can be >>> privacy sensitive. Would it be useful to rule that out of >> scope? E.g. to say that i2rs SHOULD NOT be used where the >> agent/router in question >>> is specific to one person or home? > Sue: I'm really not sure what you are getting at. Data in routers > is privacy sensitive. Data between I2RS Agent and I2RS client will be > encrypted except in very, very rare circumstances where is defined to > be public data in the data model. SECDIR, OPSDIR, RTGWG, > Transport-directorate will be asked to review any IETF data model > that claims this is the case to validate it is appropriate. So... I > think we are going beyond what people use for home networks. Let's assume all client/agent stuff is wonderfully protected e.g. via TLS. Normally, the fact that a client at IP1 is managing an agent at IP2, which is still visible despite the TLS, is not much of a deal. Nor is it a deal when that happens, e.g. in reaction to some other event, perhaps even one triggered by an attacker. But if the agent is my home g/w, then the sensitivity level goes up I think, or at least it can. The reason is that the agent's address (IP2) is tied to me. If the agent was on my phone (e.g. for tethering) then it'd be even more of a deal perhaps, as I carry it with me. If i2rs just isn't intended for such use-cases, it may be worth saying that was all I meant. Cheers, S. > ------=_NextPart_000_0011_01D18057.812E2490 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVTjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQDR4D5bSO3Hngk/QN7hYcOLMA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMDcx MDE4MTI1MjAxWhcNMTkxMDE3MDUwNDExWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBBQUAA4IBAQB7L2bVGhb4q6FZUtsGVNbneHh+Q5OmrXeyTfAHxWAg90PVlDgAY0+cBk4o PxOL9ZVGnhec070CdiGWHwrqqKER1uDC2H97BTr3jBzGl9mf/43MxbY7NJB9LHMONfDeF+V+8bMK ziBdedr0HocKuKtBbzbvChOkDOaAKZkqCVXEC4+x1AUwqx4++t6D3aSnC3+1CWt2+AXfXrIzjE6p AKqZcnJfrI2mqIatmAtaXvW12I8TyZR+ERIMcOVGIa4MYfxxSpz0TSSz94DWfLK3DlKiXaxT+Tqo k3yH1wZhC+6q/11vPLL52cPWk2HciFDaylK2u3watcxmk8kaxNEt6K5zMIIF6zCCA9OgAwIBAgIQ H61mfBUGJHN6xUg2XJPkxDANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNTAxMjcyMjMwMzhaFw0xODAx MjcyMjMwMzdaMGYxETAPBgNVBAoMCEVyaWNzc29uMRUwEwYDVQQDDAxKb2VsIEhhbHBlcm4xKDAm BgkqhkiG9w0BCQEWGWpvZWwuaGFscGVybkBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VoYXJqb2Uw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMJLV/6wizH1Z8P183Bl6GeEFV32D1u4A0 7zLUz4BlvZSUTASrc8KsnWf+GCUjyAWwByn5I7aBQiCBlFpH4crvlgaR5K4wvdx0irGRvz9R1omZ A0VpDswghhqRddBI2Z5JmGknGauqNG14f53xQWlcsiDQORxJMHk737J4ScHqGjnv+NeDuon8TZup EofKvh8XnthAunt5aBxCKrt71SiCwnXkBPjJ7W2nFWC+zREZeSHaRKfY+jy7oCq+bu9hC2mblcgz cethLGNxbz3e2B6q+feAPi6Z0b4UXTnGNsUgDlLShiua2fDH1scarK2oYtCuf7srbllJwhlI8AG9 fHiBAgMBAAGjggG/MIIBuzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlh LmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYB BQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9j YS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjAkBgNV HREEHTAbgRlqb2VsLmhhbHBlcm5AZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwID AQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUPeVANW4YebSX VodfJPwfvq/KeaowHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQD AgWgMA0GCSqGSIb3DQEBBQUAA4ICAQAtgUAxuGn6tRq7gquaJPUJwJ/PY92/DPTNuf7iH+idw0ms XFs2iPd/qHBnuJRsxjuhodnnxCCeHKySmeHuEfoeHEc1B6kSoKflzyLKxfUj2ZFj6DXbR84MQNgY jjSuYK+FjuVSSUlbIYwJ6jfgJZYrOdjYU8Z3zQpknk+q93XErTBDE93B2EM6WJTbI0PX0tgNM195 b6H6O6Jqo6EHFR16M7T0VnKldVBqRYoYHPcybWI6zD2gRiILGidIrIE9PkIpKXRlS8oi6Afvgar7 B1fGgI9/zjY4OrRnGJSuESYekSTYBtELPeVtuapJbhixJKfG+tO4CvSre7iXsE3Z1/CQ6Bs5XXAb 3cGYardY2A3iCGyfxcuOESMgZj+lXGM03M2pWYcbP8RYzGjkskw2w2ix3l6ORzp5R2sOC2XRG9/H 7FiVzjyhZDDRS9pGtFRSiDkmSB6FtKHdQAzTCv84Hw+p9fCqfMszQCEz4pd5a9/aMIUaz0oFL7MW XmSUgPweMFU6LSRiGMcBMdSZ5GybvQ5MLZkdpuQGNAVxlBlPtOO71+HLPKvox7JRulwVaGzEHxw9 rDx60IoM0/ct3fGApOrApYJX+857jrKWGRkKAZjourVcO2Hbc2rrfHFei0SrLqSUY10rKZ5aoFPH u93QXj471FtcWII80wJGq5qV9I4njjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8wcBZMA0G CSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVy YSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVowOjERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4Gnl17DJhklkoXOgOSBMhW6Fz GVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWXhPTdNzrB3zs5cJO7sKIyd+LRy4l/ 8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZabrGh9OxQHC4iBHkzD0YF3J/vBqB Tr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ 6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwr DgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8w STDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMX zgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0 LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1 s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggr BgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9o dHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2 MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBL BgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1UdIwQYMBaAFPCPWTgA s/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3PZBCsmGbcSZ/XL+0tnVM blInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n65c5oN+l2JDUuzrdANVKnYxh a7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+xhsfysYiIl4ORzE3TpeppQ2yWkyBB moHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy04/RnoylxSenxADi1tY9iIydHMgyO u3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER 2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+B VwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZp udnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJd INPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84Km JjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGCAvMwggLvAgEBME4wOjERMA8GA1UE CgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEB+tZnwV BiRzesVINlyT5MQwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTYwMzE3MTMxNTQ4WjAjBgkqhkiG9w0BCQQxFgQUH64/fafV2QgIUZhKqIAB nLtiJJ4wWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowXQYJKwYBBAGCNxAEMVAw TjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MgIQH61mfBUGJHN6xUg2XJPkxDBfBgsqhkiG9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEB+tZnwVBiRzesVI NlyT5MQwDQYJKoZIhvcNAQEBBQAEggEAXLYsi7dTo1sL2xgxfV72LyOEOuy3+J7NmoUUgXJ4QtTG 7ViZ2OQC08OB5VxC/YDZpKQAevjX8JGPPJub0kJkyuKm35YhVKpwol+DOmxm1MoiP0lJs0qg7XVn 7MPhxuIfeO7lo0nfsrUGCKxmPOuv60XLcKBzXUYO9FyDyzLPVil+I9GtaPD3lnVSw8jUmORgl3i3 wBpm+vV0P2r4ch1IPeJxv8sCgABRnjljGXIzmx9azewOIT9/es8T8ZrYGXIBfp019DJM1NQqEVPx 8e7b7v38GtD363g6RVp/mBN8Y4MT+6OBz+M4jZWzmHg588K8rnQksTCzNuTaf/R0Zs56zQAAAAAA AA== ------=_NextPart_000_0011_01D18057.812E2490-- From nobody Thu Mar 17 06:23: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 935CF12D8E2; Thu, 17 Mar 2016 06:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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.001, 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 oCWuCY0W02O3; Thu, 17 Mar 2016 06:23:17 -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 3BADD12D947; Thu, 17 Mar 2016 06:23:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E232DBE4C; Thu, 17 Mar 2016 13:23:10 +0000 (GMT) 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 E6pP-kB5ApK3; Thu, 17 Mar 2016 13:23:05 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.42.16.188]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C01BCBE64; Thu, 17 Mar 2016 13:23:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458220985; bh=AuSBVOJk/PIwLfFAmvYCza5bJxv6rozmvGE/bAqm6Cw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=N0u9klAeJ0MSZdekhKb7QLG6ugbPdWTTkPFlpxak5gZCwNGDikM5s8FshTFu7JbCI 4WhL2j1xIBNx6QmdVGpizeQArTRjRYGmhCN9m6qznrTJkD8IQOTWxqBUvz7LL+en/D JlbESJAgR5fZ6OqbtdX11kPisX1JTo/tAkkot/YY= To: Joel Halpern , Susan Hares , 'The IESG' References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> <009501d1804d$070091d0$1501b570$@ndzh.com> <56EAACDF.8030009@cs.tcd.ie> <6BCE198E4EAEFC4CAB45D75826EFB076150FB2ED@eusaamb101.ericsson.se> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56EAAFB8.5040207@cs.tcd.ie> Date: Thu, 17 Mar 2016 13:23:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB076150FB2ED@eusaamb101.ericsson.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070702020300060609060100" Archived-At: Cc: "i2rs@ietf.org" , "mach.chen@huawei.com" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-architecture@ietf.org" Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 13:23:18 -0000 This is a cryptographically signed message in MIME format. --------------ms070702020300060609060100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/03/16 13:15, Joel Halpern wrote: > I would hope that I2RS could be used for that (applying policy to home = > devices) use case. Ah. Good to know. >=20 > But I am not at all clear how I2RS could protect the IP address of the = router=20 > containing the communicating I2RS agent. We have to have an available = IP=20 > address for IP Routing. I didn't say it needed protecting (as in encrypting) necessarily, but that it could be more sensitive. >=20 > I am also not clear why this IP address is particularly more sensitive = than an=20 > enterprise device IP address, or a router inside an ISP. In general, if an identifier is also something one can correlate with a person, or with a person's movements or presence, then it is more privacy sensitive. If you can tell I'm at home because of an i2rs event say. For a router on the 4th floor of an office building, those are less likely interesting issues. In the home case, one needs to think more about such stuff than in the office case basically. Whether/how that impacts on protocol design is hard to say. But it's good to know that it's something that i2rs needs to consider. Cheers, S. >=20 > Yours, > Joel >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, March 17, 2016 2:11 PM > To: Susan Hares; 'The IESG' > Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org;=20 > mach.chen@huawei.com; i2rs@ietf.org > Subject: Re: Stephen Farrell's No Objection on=20 > draft-ietf-i2rs-architecture-13: (with COMMENT) >=20 >=20 > Hiya, >=20 > Just on that one point (the rest seems fine): >=20 > On 17/03/16 13:00, Susan Hares wrote: >>>> - If i2rs were used to control home networks, then that would >>>> raise more privacy issues, e.g. the agent's IP address can be >>>> privacy sensitive. Would it be useful to rule that out of >>> scope? E.g. to say that i2rs SHOULD NOT be used where the >>> agent/router in question >>>> is specific to one person or home? >=20 >> Sue: I'm really not sure what you are getting at. Data in routers >> is privacy sensitive. Data between I2RS Agent and I2RS client will be >> encrypted except in very, very rare circumstances where is defined to >> be public data in the data model. SECDIR, OPSDIR, RTGWG, >> Transport-directorate will be asked to review any IETF data model >> that claims this is the case to validate it is appropriate. So... I >> think we are going beyond what people use for home networks. >=20 > Let's assume all client/agent stuff is wonderfully protected > e.g. via TLS. >=20 > Normally, the fact that a client at IP1 is managing an agent at > IP2, which is still visible despite the TLS, is not much of a > deal. Nor is it a deal when that happens, e.g. in reaction to > some other event, perhaps even one triggered by an attacker. >=20 > But if the agent is my home g/w, then the sensitivity level goes > up I think, or at least it can. The reason is that the agent's > address (IP2) is tied to me. If the agent was on my phone (e.g. > for tethering) then it'd be even more of a deal perhaps, as I > carry it with me. >=20 > If i2rs just isn't intended for such use-cases, it may be worth > saying that was all I meant. >=20 > Cheers, > S. >=20 >=20 >> >=20 --------------ms070702020300060609060100 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTcx MzIzMDRaMC8GCSqGSIb3DQEJBDEiBCDX7lJUp0MD1zqzVm20j4tGNiN4QIUPF2PZvti+/i/L WTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBX6eibFFBePbzptBthPJJlwxYB2ZuYBin9JknlttdjDK4FrhuXHjxL iaCy74ve+prlYPW0E/YQsvtlUZC1b2JBnbGnJyZSlg9hYVZDMomfjEaXdD/VjeXAMW0TDCSa aZNWwPGFcHtAxlh4ICsjUFo+yAFUJhDgnilXmC/p/k9tXYBQSfALuSIGQqdexUu3uW/9LeSw p6NvVLwXwEyXB+m2HGVGrnHm/TPuC18UEeM2qXacPdCvWNE68Kx7/MZKEm2354nTv/VFnjgb 07zCUEy/Y1IhB13yBl2BHwXRRBwOk6s+Bfn0D0As19uYYEFfEjJYlZs//W6rkUVP7Y/O32ff AAAAAAAA --------------ms070702020300060609060100-- From nobody Thu Mar 17 06:25: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 73E2512D918; Thu, 17 Mar 2016 06:25:00 -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 97rK5oLVYWdv; Thu, 17 Mar 2016 06:24:59 -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 ABFA312D57B; Thu, 17 Mar 2016 06:24:41 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Joel Halpern'" , "'Stephen Farrell'" , "'The IESG'" References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> <009501d1804d$070091d0$1501b570$@ndzh.com> <56EAACDF.8030009@cs.tcd.ie> <6BCE198E4EAEFC4CAB45D75826EFB076150FB2ED@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB076150FB2ED@eusaamb101.ericsson.se> Date: Thu, 17 Mar 2016 09:23:54 -0400 Message-ID: <00f601d18050$415bf6a0$c413e3e0$@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: AQHacCPIaSnTqpnEd1O1DdaUpagcZQGkUVW1AfaMcYsCGO1ABZ8eINow Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 13:25:00 -0000 Stephen:=20 +1 to Joel's comment. =20 Home IP for your phone =3D=3D enterprise CEO's IP phone.=20 Both need to be secure. Access to some information is limited to = administrator.=20 I must be missing something.=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Thursday, March 17, 2016 9:16 AM To: Stephen Farrell; Susan Hares; 'The IESG' Cc: i2rs@ietf.org; mach.chen@huawei.com; i2rs-chairs@ietf.org; = draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on = draft-ietf-i2rs-architecture-13: (with COMMENT) I would hope that I2RS could be used for that (applying policy to home devices) use case. But I am not at all clear how I2RS could protect the IP address of the = router containing the communicating I2RS agent. We have to have an = available IP address for IP Routing. I am also not clear why this IP address is particularly more sensitive = than an enterprise device IP address, or a router inside an ISP. Yours, Joel -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, March 17, 2016 2:11 PM To: Susan Hares; 'The IESG' Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org; = mach.chen@huawei.com; i2rs@ietf.org Subject: Re: Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Hiya, Just on that one point (the rest seems fine): On 17/03/16 13:00, Susan Hares wrote: >>> - If i2rs were used to control home networks, then that would raise=20 >>> more privacy issues, e.g. the agent's IP address can be privacy=20 >>> sensitive. Would it be useful to rule that out of >> scope? E.g. to say that i2rs SHOULD NOT be used where the=20 >> agent/router in question >>> is specific to one person or home? > Sue: I'm really not sure what you are getting at. Data in routers is = > privacy sensitive. Data between I2RS Agent and I2RS client will be=20 > encrypted except in very, very rare circumstances where is defined to=20 > be public data in the data model. SECDIR, OPSDIR, RTGWG,=20 > Transport-directorate will be asked to review any IETF data model > that claims this is the case to validate it is appropriate. So... I > think we are going beyond what people use for home networks. Let's assume all client/agent stuff is wonderfully protected e.g. via = TLS. Normally, the fact that a client at IP1 is managing an agent at IP2, = which is still visible despite the TLS, is not much of a deal. Nor is it = a deal when that happens, e.g. in reaction to some other event, perhaps = even one triggered by an attacker. But if the agent is my home g/w, then the sensitivity level goes up I = think, or at least it can. The reason is that the agent's address (IP2) = is tied to me. If the agent was on my phone (e.g. for tethering) then it'd be even more of a deal perhaps, as I carry it = with me. If i2rs just isn't intended for such use-cases, it may be worth saying = that was all I meant. Cheers, S. > From nobody Thu Mar 17 06:25: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 B3DDD12D936; Thu, 17 Mar 2016 06:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, 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 SlJtk6xjWEqR; Thu, 17 Mar 2016 06:25:18 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E02512D91B; Thu, 17 Mar 2016 06:25:14 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-07-56eaaafdeff5 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 4B.45.30335.DFAAAE65; Thu, 17 Mar 2016 14:02:53 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Thu, 17 Mar 2016 09:25:12 -0400 From: Joel Halpern To: Stephen Farrell , Susan Hares , 'The IESG' Thread-Topic: Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Thread-Index: AQHRgEeUMrxXk2ChxkSiFfv0Q6K7Kp9d3IsAgAAC1ID//719YIAARegA//+9VYA= Date: Thu, 17 Mar 2016 13:25:12 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB076150FB368@eusaamb101.ericsson.se> References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> <009501d1804d$070091d0$1501b570$@ndzh.com> <56EAACDF.8030009@cs.tcd.ie> <6BCE198E4EAEFC4CAB45D75826EFB076150FB2ED@eusaamb101.ericsson.se> <56EAAFB8.5040207@cs.tcd.ie> In-Reply-To: <56EAAFB8.5040207@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0022_01D18058.D00DFCB0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUyuXRPrO7fVa/CDOa1mlj0zvvPaPHhWDOb xboZH1gsZvyZyGxxYa2wxZ83r1gspu+9xu7A7rG2+yqbR8uRt6weS5b8ZPKY/fo6awBLFJdN SmpOZllqkb5dAlfGpDtT2AsOJVe8frqHrYFxQ3QXIyeHhICJxMNHb9khbDGJC/fWs4HYQgJH GCWOHDHuYuQCspczSlzua2EFSbAJ6Emsff+YCcQWEciR2Hj+LRNIEbPADUaJa586gYo4OIQF EiQa94ZC1CRKXH7VAVXvJ7Ft9hGwZSwCqhIT1/0Gs3kFfCU2HTzLDLH4HaNE7xp5EJtTQFNi zdnHjCA2I9Bx30+tAZvDLCAucevJfCaIo0UkHl48zQZhi0q8fPyPFcJWlNjXP50d4rZeRond L29ALROUODnzCcsERtFZSGbNQlY3C0kdRJG2xNObT6FseYntb+cwQ9jWEjN+HWSDsBUlpnQ/ ZIewTSVeH/3IuICRYxUjR2lxQU5uupHBJkZg1B6TYNPdwXh/uuchRgEORiUe3oKnL8OEWBPL iitzDzGqALU+2rD6AqMUS15+XqqSCO+51a/ChHhTEiurUovy44tKc1KLDzFKc7AoifOuf3s5 TEggPbEkNTs1tSC1CCbLxMEp1cDoGsj58V3/56nOB//tT0hZszFL6v6qhB8K8UxmR5/eX/pS /iSTjsLdORMnMW5W61gtJvqx0eZn/qo9ny8+K/i+zTAx4OvFrUWpR2Lmqe38teSX6rKsXF6d P8bC/4Qt7T3/2DO/Evqtq7fgesnWlXcLayamf9e8u5rV32K2/O3zQV9dyy4w5GbOVWIpzkg0 1GIuKk4EAG/y62fiAgAA Archived-At: Cc: "i2rs@ietf.org" , "mach.chen@huawei.com" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-architecture@ietf.org" Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 13:25:29 -0000 ------=_NextPart_000_0022_01D18058.D00DFCB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Can you suggest wording to add to the architecture document to reflect this consideration? Yours, Joel -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, March 17, 2016 2:23 PM To: Joel Halpern; Susan Hares; 'The IESG' Cc: i2rs@ietf.org; mach.chen@huawei.com; i2rs-chairs@ietf.org; draft-ietf-i2rs-architecture@ietf.org Subject: Re: Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) On 17/03/16 13:15, Joel Halpern wrote: > I would hope that I2RS could be used for that (applying policy to home > devices) use case. Ah. Good to know. > > But I am not at all clear how I2RS could protect the IP address of the > router > containing the communicating I2RS agent. We have to have an available IP > address for IP Routing. I didn't say it needed protecting (as in encrypting) necessarily, but that it could be more sensitive. > > I am also not clear why this IP address is particularly more sensitive than > an > enterprise device IP address, or a router inside an ISP. In general, if an identifier is also something one can correlate with a person, or with a person's movements or presence, then it is more privacy sensitive. If you can tell I'm at home because of an i2rs event say. For a router on the 4th floor of an office building, those are less likely interesting issues. In the home case, one needs to think more about such stuff than in the office case basically. Whether/how that impacts on protocol design is hard to say. But it's good to know that it's something that i2rs needs to consider. Cheers, S. > > Yours, > Joel > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, March 17, 2016 2:11 PM > To: Susan Hares; 'The IESG' > Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org; > mach.chen@huawei.com; i2rs@ietf.org > Subject: Re: Stephen Farrell's No Objection on > draft-ietf-i2rs-architecture-13: (with COMMENT) > > > Hiya, > > Just on that one point (the rest seems fine): > > On 17/03/16 13:00, Susan Hares wrote: >>>> - If i2rs were used to control home networks, then that would >>>> raise more privacy issues, e.g. the agent's IP address can be >>>> privacy sensitive. Would it be useful to rule that out of >>> scope? E.g. to say that i2rs SHOULD NOT be used where the >>> agent/router in question >>>> is specific to one person or home? > >> Sue: I'm really not sure what you are getting at. Data in routers >> is privacy sensitive. Data between I2RS Agent and I2RS client will be >> encrypted except in very, very rare circumstances where is defined to >> be public data in the data model. SECDIR, OPSDIR, RTGWG, >> Transport-directorate will be asked to review any IETF data model >> that claims this is the case to validate it is appropriate. So... I >> think we are going beyond what people use for home networks. > > Let's assume all client/agent stuff is wonderfully protected > e.g. via TLS. > > Normally, the fact that a client at IP1 is managing an agent at > IP2, which is still visible despite the TLS, is not much of a > deal. Nor is it a deal when that happens, e.g. in reaction to > some other event, perhaps even one triggered by an attacker. > > But if the agent is my home g/w, then the sensitivity level goes > up I think, or at least it can. The reason is that the agent's > address (IP2) is tied to me. If the agent was on my phone (e.g. > for tethering) then it'd be even more of a deal perhaps, as I > carry it with me. > > If i2rs just isn't intended for such use-cases, it may be worth > saying that was all I meant. > > Cheers, > S. > > >> > ------=_NextPart_000_0022_01D18058.D00DFCB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVTjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQDR4D5bSO3Hngk/QN7hYcOLMA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMDcx MDE4MTI1MjAxWhcNMTkxMDE3MDUwNDExWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBBQUAA4IBAQB7L2bVGhb4q6FZUtsGVNbneHh+Q5OmrXeyTfAHxWAg90PVlDgAY0+cBk4o PxOL9ZVGnhec070CdiGWHwrqqKER1uDC2H97BTr3jBzGl9mf/43MxbY7NJB9LHMONfDeF+V+8bMK ziBdedr0HocKuKtBbzbvChOkDOaAKZkqCVXEC4+x1AUwqx4++t6D3aSnC3+1CWt2+AXfXrIzjE6p AKqZcnJfrI2mqIatmAtaXvW12I8TyZR+ERIMcOVGIa4MYfxxSpz0TSSz94DWfLK3DlKiXaxT+Tqo k3yH1wZhC+6q/11vPLL52cPWk2HciFDaylK2u3watcxmk8kaxNEt6K5zMIIF6zCCA9OgAwIBAgIQ H61mfBUGJHN6xUg2XJPkxDANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNTAxMjcyMjMwMzhaFw0xODAx MjcyMjMwMzdaMGYxETAPBgNVBAoMCEVyaWNzc29uMRUwEwYDVQQDDAxKb2VsIEhhbHBlcm4xKDAm BgkqhkiG9w0BCQEWGWpvZWwuaGFscGVybkBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VoYXJqb2Uw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMJLV/6wizH1Z8P183Bl6GeEFV32D1u4A0 7zLUz4BlvZSUTASrc8KsnWf+GCUjyAWwByn5I7aBQiCBlFpH4crvlgaR5K4wvdx0irGRvz9R1omZ A0VpDswghhqRddBI2Z5JmGknGauqNG14f53xQWlcsiDQORxJMHk737J4ScHqGjnv+NeDuon8TZup EofKvh8XnthAunt5aBxCKrt71SiCwnXkBPjJ7W2nFWC+zREZeSHaRKfY+jy7oCq+bu9hC2mblcgz cethLGNxbz3e2B6q+feAPi6Z0b4UXTnGNsUgDlLShiua2fDH1scarK2oYtCuf7srbllJwhlI8AG9 fHiBAgMBAAGjggG/MIIBuzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlh LmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYB BQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9j YS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjAkBgNV HREEHTAbgRlqb2VsLmhhbHBlcm5AZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwID AQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUPeVANW4YebSX VodfJPwfvq/KeaowHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQD AgWgMA0GCSqGSIb3DQEBBQUAA4ICAQAtgUAxuGn6tRq7gquaJPUJwJ/PY92/DPTNuf7iH+idw0ms XFs2iPd/qHBnuJRsxjuhodnnxCCeHKySmeHuEfoeHEc1B6kSoKflzyLKxfUj2ZFj6DXbR84MQNgY jjSuYK+FjuVSSUlbIYwJ6jfgJZYrOdjYU8Z3zQpknk+q93XErTBDE93B2EM6WJTbI0PX0tgNM195 b6H6O6Jqo6EHFR16M7T0VnKldVBqRYoYHPcybWI6zD2gRiILGidIrIE9PkIpKXRlS8oi6Afvgar7 B1fGgI9/zjY4OrRnGJSuESYekSTYBtELPeVtuapJbhixJKfG+tO4CvSre7iXsE3Z1/CQ6Bs5XXAb 3cGYardY2A3iCGyfxcuOESMgZj+lXGM03M2pWYcbP8RYzGjkskw2w2ix3l6ORzp5R2sOC2XRG9/H 7FiVzjyhZDDRS9pGtFRSiDkmSB6FtKHdQAzTCv84Hw+p9fCqfMszQCEz4pd5a9/aMIUaz0oFL7MW XmSUgPweMFU6LSRiGMcBMdSZ5GybvQ5MLZkdpuQGNAVxlBlPtOO71+HLPKvox7JRulwVaGzEHxw9 rDx60IoM0/ct3fGApOrApYJX+857jrKWGRkKAZjourVcO2Hbc2rrfHFei0SrLqSUY10rKZ5aoFPH u93QXj471FtcWII80wJGq5qV9I4njjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8wcBZMA0G CSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVy YSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVowOjERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4Gnl17DJhklkoXOgOSBMhW6Fz GVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWXhPTdNzrB3zs5cJO7sKIyd+LRy4l/ 8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZabrGh9OxQHC4iBHkzD0YF3J/vBqB Tr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ 6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwr DgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8w STDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMX zgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0 LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1 s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggr BgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9o dHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2 MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBL BgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1UdIwQYMBaAFPCPWTgA s/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3PZBCsmGbcSZ/XL+0tnVM blInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n65c5oN+l2JDUuzrdANVKnYxh a7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+xhsfysYiIl4ORzE3TpeppQ2yWkyBB moHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy04/RnoylxSenxADi1tY9iIydHMgyO u3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER 2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+B VwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZp udnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJd INPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84Km JjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGCAvMwggLvAgEBME4wOjERMA8GA1UE CgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEB+tZnwV BiRzesVINlyT5MQwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTYwMzE3MTMyNTEwWjAjBgkqhkiG9w0BCQQxFgQUdA7pfnH2VvE57URSgzJe rx0xP2owWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowXQYJKwYBBAGCNxAEMVAw TjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MgIQH61mfBUGJHN6xUg2XJPkxDBfBgsqhkiG9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEB+tZnwVBiRzesVI NlyT5MQwDQYJKoZIhvcNAQEBBQAEggEAenGJgjvgiw4WHFqCkuvu60lTnXJg/v00zHtUiofZuT5H hVDQRm413FyH5wij8EjItPBHVyeXILR9GSMjjGj6wB7Atondx64H0Jn7s6Ae+JcZYbJvFsW3i/K2 dc3Hl2rfwv64tDXS4nKDk5X3tUkaSaZ7GsH/aSYaaEWn4hCB2+TTKnVhFlzYtn+K142fmMGdwS1N TKjf/j59Zu3xNHcxh6D3iFhHwTbLWUh9sdBELl0TRcWV45FCbQQpTjN3YxTf0WQ1U5DpVK51r3ix bKXxBb28d0g7ewhACEfSuM1++gCFAfUgYBdqWJ9dscklrI7+TC/muWneqLOf3sevLiijYwAAAAAA AA== ------=_NextPart_000_0022_01D18058.D00DFCB0-- From nobody Thu Mar 17 06:27: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 747DF12D912; Thu, 17 Mar 2016 06:27:40 -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 D7bv-8eRJkO4; Thu, 17 Mar 2016 06:27: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 343DE12D57B; Thu, 17 Mar 2016 06:27:34 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Stephen Farrell'" , "'Joel Halpern'" , "'The IESG'" References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> <009501d1804d$070091d0$1501b570$@ndzh.com> <56EAACDF.8030009@cs.tcd.ie> <6BCE198E4EAEFC4CAB45D75826EFB076150FB2ED@eusaamb101.ericsson.se> <56EAAFB8.5040207@cs.tcd.ie> In-Reply-To: <56EAAFB8.5040207@cs.tcd.ie> Date: Thu, 17 Mar 2016 09:26:51 -0400 Message-ID: <010801d18050$ab3f81e0$01be85a0$@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: AQHacCPIaSnTqpnEd1O1DdaUpagcZQGkUVW1AfaMcYsCGO1ABQGWhpvvnxFt0YA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 13:27:40 -0000 Stephen:=20 I think my last email covered it. Most operators tree Routing = information as sensitive info.=20 Sue=20 -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Thursday, March 17, 2016 9:23 AM To: Joel Halpern; Susan Hares; 'The IESG' Cc: i2rs@ietf.org; mach.chen@huawei.com; i2rs-chairs@ietf.org; = draft-ietf-i2rs-architecture@ietf.org Subject: Re: Stephen Farrell's No Objection on = draft-ietf-i2rs-architecture-13: (with COMMENT) On 17/03/16 13:15, Joel Halpern wrote: > I would hope that I2RS could be used for that (applying policy to home = > devices) use case. Ah. Good to know. >=20 > But I am not at all clear how I2RS could protect the IP address of the = router=20 > containing the communicating I2RS agent. We have to have an available = IP=20 > address for IP Routing. I didn't say it needed protecting (as in encrypting) necessarily, but that it could be more sensitive. >=20 > I am also not clear why this IP address is particularly more sensitive = than an=20 > enterprise device IP address, or a router inside an ISP. In general, if an identifier is also something one can correlate with a person, or with a person's movements or presence, then it is more privacy sensitive. If you can tell I'm at home because of an i2rs event say. For a router on the 4th floor of an office building, those are less likely interesting issues. In the home case, one needs to think more about such stuff than in the office case basically. Whether/how that impacts on protocol design is hard to say. But it's good to know that it's something that i2rs needs to consider. Cheers, S. >=20 > Yours, > Joel >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, March 17, 2016 2:11 PM > To: Susan Hares; 'The IESG' > Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org;=20 > mach.chen@huawei.com; i2rs@ietf.org > Subject: Re: Stephen Farrell's No Objection on=20 > draft-ietf-i2rs-architecture-13: (with COMMENT) >=20 >=20 > Hiya, >=20 > Just on that one point (the rest seems fine): >=20 > On 17/03/16 13:00, Susan Hares wrote: >>>> - If i2rs were used to control home networks, then that would >>>> raise more privacy issues, e.g. the agent's IP address can be >>>> privacy sensitive. Would it be useful to rule that out of >>> scope? E.g. to say that i2rs SHOULD NOT be used where the >>> agent/router in question >>>> is specific to one person or home? >=20 >> Sue: I'm really not sure what you are getting at. Data in routers >> is privacy sensitive. Data between I2RS Agent and I2RS client will be >> encrypted except in very, very rare circumstances where is defined to >> be public data in the data model. SECDIR, OPSDIR, RTGWG, >> Transport-directorate will be asked to review any IETF data model >> that claims this is the case to validate it is appropriate. So... I >> think we are going beyond what people use for home networks. >=20 > Let's assume all client/agent stuff is wonderfully protected > e.g. via TLS. >=20 > Normally, the fact that a client at IP1 is managing an agent at > IP2, which is still visible despite the TLS, is not much of a > deal. Nor is it a deal when that happens, e.g. in reaction to > some other event, perhaps even one triggered by an attacker. >=20 > But if the agent is my home g/w, then the sensitivity level goes > up I think, or at least it can. The reason is that the agent's > address (IP2) is tied to me. If the agent was on my phone (e.g. > for tethering) then it'd be even more of a deal perhaps, as I > carry it with me. >=20 > If i2rs just isn't intended for such use-cases, it may be worth > saying that was all I meant. >=20 > Cheers, > S. >=20 >=20 >> >=20 From nobody Thu Mar 17 06:28:26 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 E726E12D918; Thu, 17 Mar 2016 06:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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.001, 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 ilwshi4G64W0; Thu, 17 Mar 2016 06:28:23 -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 E048812D51F; Thu, 17 Mar 2016 06:28:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94064BE75; Thu, 17 Mar 2016 13:28:21 +0000 (GMT) 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 7hKRIHi4Bws4; Thu, 17 Mar 2016 13:28:19 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.42.16.188]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BAB3CBE64; Thu, 17 Mar 2016 13:28:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458221299; bh=W1fC48m/3rRiSlotpOg4rOVbSL2ilrHMjFvN5rGK7Ug=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=PA+pHL3IkSkzJP+mtmPvGrVGaqp64xNb6WMPPOqiX8L4jnMqSzs+NdvA309Y5OM9m VC7urlKTJAjXPil7OjT+CpI/HpGP8S7SQeaWd5zeC7/tjRQl2btp9YoEL5ylU4RdsI phAYKJAJpV1QyKSX5nmfv94ebpIcqsb8wJq/gY+M= To: Joel Halpern , Susan Hares , 'The IESG' References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> <009501d1804d$070091d0$1501b570$@ndzh.com> <56EAACDF.8030009@cs.tcd.ie> <6BCE198E4EAEFC4CAB45D75826EFB076150FB2ED@eusaamb101.ericsson.se> <56EAAFB8.5040207@cs.tcd.ie> <6BCE198E4EAEFC4CAB45D75826EFB076150FB368@eusaamb101.ericsson.se> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56EAB0ED.9030603@cs.tcd.ie> Date: Thu, 17 Mar 2016 13:28:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB076150FB368@eusaamb101.ericsson.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060802090509060804090303" Archived-At: Cc: "i2rs@ietf.org" , "mach.chen@huawei.com" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-architecture@ietf.org" Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 13:28:25 -0000 This is a cryptographically signed message in MIME format. --------------ms060802090509060804090303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/03/16 13:25, Joel Halpern wrote: > Can you suggest wording to add to the architecture document to reflect = this=20 > consideration? Maybe something along the lines of: "If an i2rs agent or client is such that it is likely tightly correlated with a person (say if an agent is running on someone's phone to control tethering) then that can raise privacy issues, over and above.the security and privacy issues that normally need to be handled in i2rs. For example, if an i2rs interaction enabled easier location tracking in the above example. i2rs protocols should consider if such privacy issues can arise when clients or agents are used for such use-cases." Cheers S. >=20 > Yours, > Joel >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, March 17, 2016 2:23 PM > To: Joel Halpern; Susan Hares; 'The IESG' > Cc: i2rs@ietf.org; mach.chen@huawei.com; i2rs-chairs@ietf.org;=20 > draft-ietf-i2rs-architecture@ietf.org > Subject: Re: Stephen Farrell's No Objection on=20 > draft-ietf-i2rs-architecture-13: (with COMMENT) >=20 >=20 >=20 > On 17/03/16 13:15, Joel Halpern wrote: >> I would hope that I2RS could be used for that (applying policy to home= >> devices) use case. >=20 > Ah. Good to know. >=20 >> >> But I am not at all clear how I2RS could protect the IP address of the= =20 >> router >> containing the communicating I2RS agent. We have to have an available= IP >> address for IP Routing. >=20 > I didn't say it needed protecting (as in encrypting) necessarily, > but that it could be more sensitive. >=20 >> >> I am also not clear why this IP address is particularly more sensitive= than=20 >> an >> enterprise device IP address, or a router inside an ISP. >=20 > In general, if an identifier is also something one can correlate > with a person, or with a person's movements or presence, then it > is more privacy sensitive. If you can tell I'm at home because of > an i2rs event say. >=20 > For a router on the 4th floor of an office building, those are > less likely interesting issues. >=20 > In the home case, one needs to think more about such stuff than > in the office case basically. >=20 > Whether/how that impacts on protocol design is hard to say. But > it's good to know that it's something that i2rs needs to consider. >=20 > Cheers, > S. >=20 >=20 >> >> Yours, >> Joel >> >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Thursday, March 17, 2016 2:11 PM >> To: Susan Hares; 'The IESG' >> Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org; >> mach.chen@huawei.com; i2rs@ietf.org >> Subject: Re: Stephen Farrell's No Objection on >> draft-ietf-i2rs-architecture-13: (with COMMENT) >> >> >> Hiya, >> >> Just on that one point (the rest seems fine): >> >> On 17/03/16 13:00, Susan Hares wrote: >>>>> - If i2rs were used to control home networks, then that would >>>>> raise more privacy issues, e.g. the agent's IP address can be >>>>> privacy sensitive. Would it be useful to rule that out of >>>> scope? E.g. to say that i2rs SHOULD NOT be used where the >>>> agent/router in question >>>>> is specific to one person or home? >> >>> Sue: I'm really not sure what you are getting at. Data in routers >>> is privacy sensitive. Data between I2RS Agent and I2RS client will be= >>> encrypted except in very, very rare circumstances where is defined to= >>> be public data in the data model. SECDIR, OPSDIR, RTGWG, >>> Transport-directorate will be asked to review any IETF data model >>> that claims this is the case to validate it is appropriate. So... I= >>> think we are going beyond what people use for home networks. >> >> Let's assume all client/agent stuff is wonderfully protected >> e.g. via TLS. >> >> Normally, the fact that a client at IP1 is managing an agent at >> IP2, which is still visible despite the TLS, is not much of a >> deal. Nor is it a deal when that happens, e.g. in reaction to >> some other event, perhaps even one triggered by an attacker. >> >> But if the agent is my home g/w, then the sensitivity level goes >> up I think, or at least it can. The reason is that the agent's >> address (IP2) is tied to me. If the agent was on my phone (e.g. >> for tethering) then it'd be even more of a deal perhaps, as I >> carry it with me. >> >> If i2rs just isn't intended for such use-cases, it may be worth >> saying that was all I meant. >> >> Cheers, >> S. >> >> >>> >> >=20 --------------ms060802090509060804090303 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTcx MzI4MTNaMC8GCSqGSIb3DQEJBDEiBCDUD9ZmDjV/sT3LL50ZGA9h+cplGP4+VvTtQdS7VVIz IDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQChpZtgo+Z8EQNnifZ2uE7vru99knTrwnL5frS27ortfySAWBnlk121 k+hatX8qJyX3/OL4NVUwcGHgKiWlrP5hhBLByDQ4oOy2RGuVZqpaqjw+mXwiYenwDbhx1Ppy YQRPVnH6eOjtqD0ZG7z43WTmCOakrOSANZ/jNmHiQLKTcWgnAAC8yIy0AYOxF9XPkUWVz7qv UCgI0q1/zkx2AjDtTckXzrEC/qcsqa8JgBKaUMNlSyEYOTIsyAP3qk3K2miF4eb8VjWARnNP MA+NbT8VMx20kB0yWROMnHjqSnLkczUOS1Bf7efN9/GcT0ohVQuBwQrGBScXsrmeoQpnO+O1 AAAAAAAA --------------ms060802090509060804090303-- From nobody Thu Mar 17 06:29: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 42E9912D55F; Thu, 17 Mar 2016 06:29:16 -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 m4Rg5UwhHgPS; Thu, 17 Mar 2016 06:29:14 -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 6555112D511; Thu, 17 Mar 2016 06:29:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'Stephen Farrell'" , "'Joel Halpern'" , "'The IESG'" References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> <009501d1804d$070091d0$1501b570$@ndzh.com> <56EAACDF.8030009@cs.tcd.ie> <6BCE198E4EAEFC4CAB45D75826EFB076150FB2ED@eusaamb101.ericsson.se> <56EAAFB8.5040207@cs.tcd.ie> <6BCE198E4EAEFC4CAB45D75826EFB076150FB368@eusaamb101.ericsson.se> <56EAB0ED.9030603@cs.tcd.ie> In-Reply-To: <56EAB0ED.9030603@cs.tcd.ie> Date: Thu, 17 Mar 2016 09:28:29 -0400 Message-ID: <016e01d18050$e5357580$afa06080$@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: AQHacCPIaSnTqpnEd1O1DdaUpagcZQGkUVW1AfaMcYsCGO1ABQGWhpvvAefF46sCrm4Mop7svUYQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 17 Mar 2016 13:29:16 -0000 Stephen:=20 Thank you for the suggestion.=20 Sue=20 -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Thursday, March 17, 2016 9:28 AM To: Joel Halpern; Susan Hares; 'The IESG' Cc: i2rs@ietf.org; mach.chen@huawei.com; i2rs-chairs@ietf.org; = draft-ietf-i2rs-architecture@ietf.org Subject: Re: Stephen Farrell's No Objection on = draft-ietf-i2rs-architecture-13: (with COMMENT) On 17/03/16 13:25, Joel Halpern wrote: > Can you suggest wording to add to the architecture document to reflect = this=20 > consideration? Maybe something along the lines of: "If an i2rs agent or client is such that it is likely tightly correlated with a person (say if an agent is running on someone's phone to control tethering) then that can raise privacy issues, over and above.the security and privacy issues that normally need to be handled in i2rs. For example, if an i2rs interaction enabled easier location tracking in the above example. i2rs protocols should consider if such privacy issues can arise when clients or agents are used for such use-cases." Cheers S. >=20 > Yours, > Joel >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, March 17, 2016 2:23 PM > To: Joel Halpern; Susan Hares; 'The IESG' > Cc: i2rs@ietf.org; mach.chen@huawei.com; i2rs-chairs@ietf.org;=20 > draft-ietf-i2rs-architecture@ietf.org > Subject: Re: Stephen Farrell's No Objection on=20 > draft-ietf-i2rs-architecture-13: (with COMMENT) >=20 >=20 >=20 > On 17/03/16 13:15, Joel Halpern wrote: >> I would hope that I2RS could be used for that (applying policy to = home >> devices) use case. >=20 > Ah. Good to know. >=20 >> >> But I am not at all clear how I2RS could protect the IP address of = the=20 >> router >> containing the communicating I2RS agent. We have to have an = available IP >> address for IP Routing. >=20 > I didn't say it needed protecting (as in encrypting) necessarily, > but that it could be more sensitive. >=20 >> >> I am also not clear why this IP address is particularly more = sensitive than=20 >> an >> enterprise device IP address, or a router inside an ISP. >=20 > In general, if an identifier is also something one can correlate > with a person, or with a person's movements or presence, then it > is more privacy sensitive. If you can tell I'm at home because of > an i2rs event say. >=20 > For a router on the 4th floor of an office building, those are > less likely interesting issues. >=20 > In the home case, one needs to think more about such stuff than > in the office case basically. >=20 > Whether/how that impacts on protocol design is hard to say. But > it's good to know that it's something that i2rs needs to consider. >=20 > Cheers, > S. >=20 >=20 >> >> Yours, >> Joel >> >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Thursday, March 17, 2016 2:11 PM >> To: Susan Hares; 'The IESG' >> Cc: draft-ietf-i2rs-architecture@ietf.org; i2rs-chairs@ietf.org; >> mach.chen@huawei.com; i2rs@ietf.org >> Subject: Re: Stephen Farrell's No Objection on >> draft-ietf-i2rs-architecture-13: (with COMMENT) >> >> >> Hiya, >> >> Just on that one point (the rest seems fine): >> >> On 17/03/16 13:00, Susan Hares wrote: >>>>> - If i2rs were used to control home networks, then that would >>>>> raise more privacy issues, e.g. the agent's IP address can be >>>>> privacy sensitive. Would it be useful to rule that out of >>>> scope? E.g. to say that i2rs SHOULD NOT be used where the >>>> agent/router in question >>>>> is specific to one person or home? >> >>> Sue: I'm really not sure what you are getting at. Data in routers >>> is privacy sensitive. Data between I2RS Agent and I2RS client will = be >>> encrypted except in very, very rare circumstances where is defined = to >>> be public data in the data model. SECDIR, OPSDIR, RTGWG, >>> Transport-directorate will be asked to review any IETF data model >>> that claims this is the case to validate it is appropriate. So... = I >>> think we are going beyond what people use for home networks. >> >> Let's assume all client/agent stuff is wonderfully protected >> e.g. via TLS. >> >> Normally, the fact that a client at IP1 is managing an agent at >> IP2, which is still visible despite the TLS, is not much of a >> deal. Nor is it a deal when that happens, e.g. in reaction to >> some other event, perhaps even one triggered by an attacker. >> >> But if the agent is my home g/w, then the sensitivity level goes >> up I think, or at least it can. The reason is that the agent's >> address (IP2) is tied to me. If the agent was on my phone (e.g. >> for tethering) then it'd be even more of a deal perhaps, as I >> carry it with me. >> >> If i2rs just isn't intended for such use-cases, it may be worth >> saying that was all I meant. >> >> Cheers, >> S. >> >> >>> >> >=20 From nobody Thu Mar 17 06: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 B27B912D947 for ; Thu, 17 Mar 2016 06:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.439 X-Spam-Level: **** X-Spam-Status: No, score=4.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 08dWmR857W7L for ; Thu, 17 Mar 2016 06:37: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 008EC12DBE4 for ; Thu, 17 Mar 2016 06:37:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Thu, 17 Mar 2016 09:36:46 -0400 Message-ID: <018b01d18052$0efd2600$2cf77200$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018C_01D18030.87ED0CA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGAUXb4Td8YcYZ2RgWX+pLyR+qbpA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' Subject: [i2rs] Call for presentations 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, 17 Mar 2016 13:37:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018C_01D18030.87ED0CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS WG: I2RS will meet at IETF on Tuesday 4/5 at 14:00-16:00 and Thursday 4/7 at 16:20-17:20. Please send in your requests for presentations. We plan to discuss the Data Flow Requirements and Protocol Strawman on Tuesday. Sue Hares ------=_NextPart_000_018C_01D18030.87ED0CA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS WG: =

 

I2RS will meet at IETF on Tuesday 4/5 at 14:00-16:00 = and Thursday  4/7 at 16:20-17:20.

 

Please send = in your requests for presentations.  We plan to discuss the Data = Flow Requirements and Protocol Strawman on Tuesday.  =  

 

Sue Hares

------=_NextPart_000_018C_01D18030.87ED0CA0-- From nobody Thu Mar 17 06:40: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 42AC612D950 for ; Thu, 17 Mar 2016 06:40:23 -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 D5gbeLtyOnlh for ; Thu, 17 Mar 2016 06:40:21 -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 E9BB312D90D for ; Thu, 17 Mar 2016 06:40:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Thu, 17 Mar 2016 09:39:45 -0400 Message-ID: <01aa01d18052$788dd650$69a982f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AB_01D18030.F17C3650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGAUiI8Nz/ZjO2mQJiYaNguV2chEg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Daniel Migault' , "'Joel M. Halpern'" , 'Alia Atlas' Subject: Re: [i2rs] 2 week WG last call on draft-ietf-i2rs-security-environment-reqs - WG LC 3/17 to 4/7 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, 17 Mar 2016 13:40:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AB_01D18030.F17C3650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit HI all: We have not received any input on the draft-ietf-i2rs-security-environment-reqs document. The security environments is part of the package of requirements, the WG chairs wish to send to the IESG. Please take time to review this document prior to IETF, and send comments to the list including whether it is ready for publication. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, December 31, 2015 9:50 PM To: i2rs@ietf.org Cc: 'Jeffrey Haas'; 'Daniel Migault'; 'Joel M. Halpern'; 'Alia Atlas' Subject: Re: [i2rs] 2 week WG last call on draft-ietf-i2rs-security-environment-reqs (12/14 to 12/28) - extended to 1/11/2016 Due to the holiday season we will extend the WG LC for draft-ietf-i2rs-security-environment-reqs until 1/11/2016. Please comment on the list if you feel this document is ready/not ready for publication. Sue Hares ------=_NextPart_000_01AB_01D18030.F17C3650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI all:

 

We have not received any = input on the draft-ietf-i2rs-security-environment-reqs document.  = The security environments is part of the package of requirements, the WG = chairs wish to send to the IESG. 

 

Please take time to = review  this document prior to IETF, and send comments to the list = including whether it is ready for publication.

 

Sue =

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Thursday, December 31, 2015 9:50 PM
To: = i2rs@ietf.org
Cc: 'Jeffrey Haas'; 'Daniel Migault'; 'Joel M. = Halpern'; 'Alia Atlas'
Subject: Re: [i2rs] 2 week WG last call = on draft-ietf-i2rs-security-environment-reqs (12/14 to 12/28) - extended = to 1/11/2016

 

Due to the = holiday season we will extend the WG LC for = draft-ietf-i2rs-security-environment-reqs until 1/11/2016. =

 

Please comment on the list if you feel this document = is ready/not ready for publication.

 

Sue Hares =

------=_NextPart_000_01AB_01D18030.F17C3650-- From nobody Sat Mar 19 08:01: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 802AC12DE04; Fri, 11 Mar 2016 15:05:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230533.15028.85632.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:33 -0800 Archived-At: X-Mailman-Approved-At: Sat, 19 Mar 2016 08:01:03 -0700 Cc: i2rs@ietf.org, akatlas@gmail.com Subject: [i2rs] i2rs - Requested sessions have been scheduled for IETF 95 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, 11 Mar 2016 23:05:34 -0000 Dear Susan Hares, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. i2rs Session 1 (1:30:00) Tuesday, Afternoon Session I 1400-1600 Room Name: Quebracho A size: 75 --------------------------------------------- i2rs Session 2 (1:30:00) Thursday, Afternoon Session II 1620-1720 Room Name: Atlantico B size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Interface to the Routing System Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: i2nsf idr trill netmod netconf rtgwg bfd Second Priority: bess ospf rtgarea sidr nvo3 teas isis l3sm Third Priority: nfvrg nmlrg nmrg Special Requests: --------------------------------------------------------- From nobody Sat Mar 19 08:01:07 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 164B512D8BB; Tue, 15 Mar 2016 22:26:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316052623.21136.77818.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 22:26:23 -0700 Archived-At: X-Mailman-Approved-At: Sat, 19 Mar 2016 08:01:03 -0700 Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org Subject: [i2rs] Terry Manderson's No Objection on draft-ietf-i2rs-architecture-13: (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, 16 Mar 2016 05:26:23 -0000 Terry Manderson has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi there, Firstly, I support Alvaro's two significant comments, especially with regards to the outcomes of the I2RS initiated change. My reading of the draft is that the resulting architecture espouses to judge intent, or the very least the outcome of the intent, as safe. How? Apologies if I read more into this than intended, please help clarify. I only saw one nit that hadn't been noticed in other comments. Section 3: para, last sentence. "may may" Thanks From nobody Mon Mar 21 12:23: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 AB7E512DA9C for ; Mon, 21 Mar 2016 12:23:17 -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 7oVvVLH5h98U for ; Mon, 21 Mar 2016 12:23:15 -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 A3A9412DAA1 for ; Mon, 21 Mar 2016 12:23:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: References: <20160321192153.12235.45692.idtracker@ietfa.amsl.com> In-Reply-To: <20160321192153.12235.45692.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 15:22:23 -0400 Message-ID: <031401d183a6$ff0d0c30$fd272490$@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: AQIW2aOU5qFBK4yJQFxKasMLlmsY5J7ZmnuQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-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: Mon, 21 Mar 2016 19:23:17 -0000 Fyi - protocol strawman for discussion on mail list and at IETF-95. = Ephemeral state document is updated to match this protocol strawman.=20 Sue=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, March 21, 2016 3:22 PM To: Amit Daas; amit.dass@ericsson.com; Andy Bierman; Susan Hares Subject: New Version Notification for = draft-hares-i2rs-protocol-strawman-01.txt A new version of I-D, draft-hares-i2rs-protocol-strawman-01.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-hares-i2rs-protocol-strawman Revision: 01 Title: I2RS protocol strawman Document date: 2016-03-21 Group: Individual Submission Pages: 34 URL: = https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-0= 1.txt Status: = https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/ Htmlized: = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-01 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-protocol-strawman-01= Abstract: This document provides a strawman proposal for the I2RS protocol covering the ephemeral data store and data flow requirements not covered by I2RS publication/subscription service or traceability. It also proposes additions to YANG for the ephemeral data store and for additional data flow requirements. It proposes additions to the NETCONF and RESTCONF for these additions. Future versions of this document will propose changes to support the I2RS protocol security 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 Mon Mar 21 12:49: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 D368B12DA7A; Mon, 21 Mar 2016 12:49:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321194902.12227.36570.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 12:49:02 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-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: Mon, 21 Mar 2016 19:49: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 : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-05.txt Pages : 15 Date : 2016-03-21 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-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 Tue Mar 22 19:43: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 AC3F912DB0F; Tue, 22 Mar 2016 19:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 7GHcji2E-X4g; Tue, 22 Mar 2016 19:43:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE8812DB13; Tue, 22 Mar 2016 19:43:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 886F11E837; Tue, 22 Mar 2016 22:46:58 -0400 (EDT) Date: Tue, 22 Mar 2016 22:46:58 -0400 From: Jeffrey Haas To: Stephen Farrell Message-ID: <20160323024658.GB5850@pfrc.org> References: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160317122135.18578.48113.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, The IESG , draft-ietf-i2rs-architecture@ietf.org, i2rs-chairs@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (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: Wed, 23 Mar 2016 02:43:12 -0000 On Thu, Mar 17, 2016 at 05:21:35AM -0700, Stephen Farrell wrote: > - section 2: security role, hmm..... Do netconf/restconf have > the concept of mapping identifiers to roles? If not, that > might be tricky to graft on. Not sure. There may be room in the future protocol specific work for I2RS across a transport such as netconf/restconf to further refine this. However, as one example of role-binding, a given user (identity) may have access to specific resources such as portions of the configuration tree. Basically, typical user to configuration privileges. An example of this is user jeff is allowed to configure bgp, but should enver be allowed to interact with the device's security settings. NACM already provides something rather similar to this behavior in netconf, but discussion with the netconf working group is ongoing in terms of further bindings that are i2rs specific, such as priority. -- Jeff From nobody Tue Mar 22 19:46: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 BB6B112D10A; Tue, 22 Mar 2016 19:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 2GL5mN0VvX-e; Tue, 22 Mar 2016 19:46:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CA35D12D104; Tue, 22 Mar 2016 19:46:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 36A281E839; Tue, 22 Mar 2016 22:50:23 -0400 (EDT) Date: Tue, 22 Mar 2016 22:50:23 -0400 From: Jeffrey Haas To: Jari Arkko Message-ID: <20160323025023.GC5850@pfrc.org> References: <20160317090122.19193.44222.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160317090122.19193.44222.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, draft-ietf-i2rs-architecture@ietf.org, housley@vigilsec.com, i2rs-chairs@ietf.org, The IESG Subject: Re: [i2rs] Jari Arkko's No Objection on draft-ietf-i2rs-architecture-13: (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: Wed, 23 Mar 2016 02:46:37 -0000 Jari, On Thu, Mar 17, 2016 at 02:01:22AM -0700, Jari Arkko wrote: > Section 4.2 talks about authorization. I would expect policy to > dictate that some writes come from a specific source, but it is > unclear to me whether I2RS can require that a particular write > request arrive on a particular channel. Is this desirable? If so, > please expand the discussion of authorization to cover this point. This may be beneficial. However, since a goal of i2rs is to utilize as much as possible in existing transports such as netconf/restconf, a better question should be whether the mechanism should be introduced there? In my opinion, this may be a useful feature but is not a blocking item. As noted in my response to Stephen's COMMENT, binding to role already exists in a form courtesy of mechanisms such as NACM or similar local privilege configuration. -- Jeff From nobody Thu Mar 24 03:53: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 4E5EB12D7F9; Thu, 24 Mar 2016 03:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ydobTKzjUELi; Thu, 24 Mar 2016 03:53:52 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8E312D7E1; Thu, 24 Mar 2016 03:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14995; q=dns/txt; s=iport; t=1458816830; x=1460026430; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Js99tk2tmsABJ7Jy/FZ/ZCAOB5acb7Fjixdwz/mdApc=; b=MWaX8q43P9bwG5nOLSEcUC6lfz68+2XW+qQgMzIrzu/bOY0adyUvuM6F vdJi5VNTfvAFO5nDsvgdsM8N50wB6IYPDBs1QfQjUIHa/iqBxSrAUPZKX PjInTrrALT/mDuTzj4uTWr2bxJ9TYLo/0fEMz7gxplPNhK9vWq3N9prGc k=; X-IronPort-AV: E=Sophos;i="5.24,385,1454976000"; d="scan'208,217";a="636504864" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2016 10:53:47 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2OArlgF025454; Thu, 24 Mar 2016 10:53:47 GMT To: Susan Hares , "'The IESG'" References: <20160317013624.18209.45055.idtracker@ietfa.amsl.com> <046601d17ff5$70c29350$5247b9f0$@ndzh.com> From: Benoit Claise Message-ID: <56F3C73A.9090500@cisco.com> Date: Thu, 24 Mar 2016 07:53:46 -0300 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: <046601d17ff5$70c29350$5247b9f0$@ndzh.com> Content-Type: multipart/alternative; boundary="------------070902000409020900080306" Archived-At: Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org, Fred@cisco.com Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 24 Mar 2016 10:53:54 -0000 This is a multi-part message in MIME format. --------------070902000409020900080306 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sue, > >Two of the existing protocols which the > > which may be re-used are NETCONF [RFC6241] and RESTCONF > > [I-D.ietf-netconf-restconf]. > >> editorial "may be reused". / I will check with RFC editor (some people say > reused /re-used). > >> What does it mean? I was hoping that an architecture documents would at > least tell me which protocols are used. >> On my side this architecture is flexible (NETCONF or RESTCONF), on the > other side unclear (YANG 1.0 or >> YANG1.1), and in some cases, a complete specification (for example the > notification) > > Sue: NETCONF and RESTCONF will be supported as part of the I2RS protocols. > The architecture does out rule out other data transfer protocols, but says > the WG will design I2RS as a higher level protocol that combines other > protocols (NETCONF/RESTCONF + x). This is what I could not understand with the draft sentence: "Two of the existing protocols which the which may _be re-used_ are NETCONF [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]." Sure many things could be reused. I'm expecting from an architecture document to explain which pieces are used and how they are used. > The I2RS requirements documents and > protocol strawman will state is if any other protocols will be used for a > particular version of I2RS with a particular scope for data modules. Probably, my issue stems from the fact that I2RS produces an architecture before fixing requirements. > > I am sorry if this is not what you excepted, but it was my direction from my > AD on how to approach this work. > > At this time, we are closing in on the last of the requirements documents - > the requirements for other data flows. > draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data > flows, but IMO the first version of the I2RS is likely to stay with just > NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog module > library, and some yang changes. > > >> To handle I2RS Agent failure, the I2RS Agent must use two different > notifications. >> NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the >> I2RS Client(s) that the associated I2RS Agent has started. It >> includes an agent-boot-count that indicates how many times the >> I2RS Agent has restarted since the associated routing element >> restarted. The agent-boot-count allows an I2RS Client to >> determine if the I2RS Agent has restarted. (Note: This >> notification will be only transmitted to I2RS clients which are >> know in some way after a reboot.) No comment on "the I2RS Agent _must _use two different notifications"? This one is clear spec. >> - editorial: >> Optionally, a routing element may permit a priority to be to be.... >> For the case when the I2RS ephemeral state always wins for a data >> model, if there is an I2RS ephemeral state value it is installed >> instead of the local configuration state. >> Again, I read that sentence multiple times, and could not understand it > Sue: Reasonable editorial comment. This was added to address another > comment, > But it looks like we broken something. Text change below. > > Old/ Optionally, a routing element may permit a priority to be to be > configured on the device for the Local Configuration mechanism > interaction with the I2RS model. The policy mechanism would compare > the I2RS client's priority with that priority assigned to the Local > Configuration in order to determine whether Local Configuration or > I2RS wins. > > For the case when the I2RS ephemeral state always wins for a data > model, if there is an I2RS ephemeral state value it is installed > instead of the local configuration state. The local configuration > information is stored so that if/when I2RS client removes I2RS > ephemeral state the local configuration state can be restored. > / > New: > Optionally, a routing element may permit a priority to be to be to be to be > configured on the device for the Local Configuration mechanism > interaction with the I2RS model. The policy mechanism would compare > the I2RS client's priority with that priority assigned to the Local > Configuration in order to determine whether Local Configuration or > I2RS wins. > > For the case when the configured priority of the I2RS ephemeral > Is higher than the Local Configuration's policy, the > The I2RS ephemeral state value it is installed remove "it" > instead of the local configuration state. The local configuration > information is stored so that if/when I2RS client removes I2RS > ephemeral state the local configuration state can be restored. > / > >> figure 2. "The initial services included in the I2RS architecture are as > follows." >> Are these really the initial services for I2RS. I2RS is really dealing > with all these: interfaces, policy, QoS, ... >> Maybe I should review the I2RS charter? > Sue: Our charter is wide, but only ephemeral layer deep. Due to the > excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS - we > are focusing on allowing ephemeral to be added to any data model. I2RS WG > is focused first on the I2RS protocol and protocol independent modules. > After this, I2RS purpose is to simply support other WGs in creating data > modules with ephemeral state. > >> The I2RS protocol may need to use several underlying transports (TCP, > SCTP >> (stream control transport protocol), DCCP (Datagram Congestion >> Control Protocol)), with suitable authentication and integrity >> protection mechanisms >> Do you really want to have define transports? > Sue: We indicate that I2RS will use these protocols. Each protocol we > mention has to be then validated with requirements (see protocol security > requirement and security environment requirements). > So I2RS will publish a second architecture doc when the requirements are validated and the protocols (transport, config, notifications) are finally selected? Regards, Benoit --------------070902000409020900080306 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Sue, 

    

      
 >Two of the existing protocols which the
 > which may be re-used are NETCONF [RFC6241] and RESTCONF
 > [I-D.ietf-netconf-restconf].



      

        
editorial "may be reused".  / I will check with RFC editor (some people say


      

      
reused /re-used). 



      

        
What does it mean? I was hoping that an architecture documents would at


      

      
least tell me which protocols are used. 


      

        
 On my side this architecture is flexible (NETCONF or RESTCONF), on the


      

      
other side unclear (YANG 1.0 or 


      

        
YANG1.1), and in some cases, a complete specification (for example the


      

      
notification)

Sue: NETCONF and RESTCONF will be supported as part of the I2RS protocols.
The architecture does out rule out other data transfer protocols, but says
the WG will design I2RS as a higher level protocol that combines other
protocols (NETCONF/RESTCONF + x).  

    

    This is what I could not understand with the draft sentence: "Two of
    the existing protocols which the which may be re-used are
    NETCONF [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]."

    Sure many things could be reused. I'm expecting from an architecture
    document to explain which pieces are used and how they are used.

    

      
The I2RS requirements documents and
protocol strawman will state is if any other protocols will be used for a
particular version of I2RS with a particular scope for data modules. 

    

    Probably, my issue stems from the fact that I2RS produces an
    architecture before fixing requirements.

    

      

I am sorry if this is not what you excepted, but it was my direction from my
AD on how to approach this work. 

At this time, we are closing in on the last of the requirements documents -
the requirements for other data flows. 
draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data
flows, but IMO the first version of the I2RS is likely to stay with just
NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog module
library, and some yang changes. 




      

        
   To handle I2RS Agent failure, the I2RS Agent must  use two different


      

      
notifications.


      

        
     NOTIFICATION_I2RS_AGENT_STARTING:   This notification signals to the
        I2RS Client(s) that the associated I2RS Agent has started.  It
         includes an agent-boot-count that indicates how many times the
         I2RS Agent has restarted since the associated routing element
         restarted.  The agent-boot-count allows an I2RS Client to
         determine if the I2RS Agent has restarted.  (Note: This
         notification will be only transmitted to I2RS clients which are
         know in some way after a reboot.)


      

    

    No comment on "the I2RS Agent must use two different
    notifications"?

    This one is clear spec.

    

      

      

        
- editorial:
  Optionally, a routing element may permit a priority to be to be.... 
  For the case when the I2RS ephemeral state always wins for a data
 model, if there is an I2RS ephemeral state value it is installed
  instead of the local configuration state. 
Again, I read that sentence multiple times, and could not understand it


      

      
Sue: Reasonable editorial comment.  This was added to address another
comment, 
But it looks like we broken something.  Text change below. 
 
 Old/  Optionally, a routing element may permit a priority to be to be
   configured on the device for the Local Configuration mechanism
   interaction with the I2RS model.  The policy mechanism would compare
   the I2RS client's priority with that priority assigned to the Local
   Configuration in order to determine whether Local Configuration or
   I2RS wins.

   For the case when the I2RS ephemeral state always wins for a data
   model, if there is an I2RS ephemeral state value it is installed
   instead of the local configuration state.  The local configuration
   information is stored so that if/when I2RS client removes I2RS
   ephemeral state the local configuration state can be restored.
/ 
New: 
Optionally, a routing element may permit a priority to be to be

    

    to be to be

    

      
   configured on the device for the Local Configuration mechanism
   interaction with the I2RS model.  The policy mechanism would compare
   the I2RS client's priority with that priority assigned to the Local
   Configuration in order to determine whether Local Configuration or
   I2RS wins.

   For the case when the configured priority of the I2RS ephemeral
   Is higher than the Local Configuration's policy, the  
   The I2RS ephemeral state value it is installed

    

    remove "it"

    

      
   instead of the local configuration state.  The local configuration
   information is stored so that if/when I2RS client removes I2RS
   ephemeral state the local configuration state can be restored.
/ 



      

        
figure 2. "The initial services included in the I2RS architecture are as


      

      
follows."


      

        
Are these really the initial services for I2RS. I2RS is really dealing


      

      
with all these: interfaces, policy, QoS, ...


      

        
Maybe I should review the I2RS charter? 


      

      
Sue:  Our charter is wide, but only ephemeral layer deep.  Due to the
excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS - we
are focusing on allowing ephemeral to be added to any data model.  I2RS WG
is focused first on the I2RS protocol and protocol independent modules.
After this, I2RS purpose is to simply support other WGs in creating data
modules with ephemeral state. 
    


      

        
  The I2RS  protocol may need to use several underlying transports (TCP,


      

      
SCTP


      

        
  (stream control transport protocol), DCCP (Datagram Congestion
Control Protocol)), with suitable authentication and integrity
 protection mechanisms
 Do you really want to have define transports?


      

      
Sue: We indicate that I2RS will use these protocols.  Each protocol we
mention has to be then validated with requirements (see protocol security
requirement and security environment requirements). 



    

    So I2RS will publish a second architecture doc when the requirements
    are validated and the protocols (transport, config, notifications)
    are finally selected?

    

    Regards, Benoit

  


--------------070902000409020900080306--


From nobody Thu Mar 24 05:17: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 4E10912DB07; Thu, 24 Mar 2016 05:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Level: 
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_SORBS_WEB=0.77, 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 SO9JyGMcwRVH; Thu, 24 Mar 2016 05:17:10 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5115312DB01; Thu, 24 Mar 2016 05:16:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 234DB1C00FB; Thu, 24 Mar 2016 05:16:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1458821816; bh=fP2kUUkEkZk03+J4FTOU37OeXWVK6f3HhDvgMqU3guc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=NGyUcPD0kVpuauvpeM0RN8SVFN5s6JzfMGIDOOkm3vsznmk1djUOaAtKPlYOWzaW5 lKVgqgUoE/cQlwjwZIPUmpvIEdpwNNz9YoWlThalCAMdLWQOKuoeTqv4HYTxaluzKa myf4DXnUx3wTof3sdiFyNj8ikEvvj0Qbsimv69GQ=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [192.165.126.74]) (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 079DF1C0264; Thu, 24 Mar 2016 05:16:53 -0700 (PDT)
To: Benoit Claise , Susan Hares , 'The IESG' 
References: <20160317013624.18209.45055.idtracker@ietfa.amsl.com> <046601d17ff5$70c29350$5247b9f0$@ndzh.com> <56F3C73A.9090500@cisco.com>
From: "Joel M. Halpern" 
Message-ID: <56F3DAB3.5040607@joelhalpern.com>
Date: Thu, 24 Mar 2016 08:16:51 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <56F3C73A.9090500@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org, Fred@cisco.com
Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 24 Mar 2016 12:17:13 -0000

Benoit, you seem to be looking for a level of specificity in the 
architecture that the working group never intended.  The charter calls 
for a high level architecture.

I believe your comment calls out an interesting gap in the charter, as 
there is no document called out which actually says "we are using pieces 
X, Y, and Z, in ways A, B, and C, to solve the I2RS problem."

We could have tried to use the architecture document for that, but the 
intention was to use the architecture document to guide the selection of 
protocol and mechanisms.

Yours,
Joel

On 3/24/16 6:53 AM, Benoit Claise wrote:
> Sue,
>
>>   >Two of the existing protocols which the
>>   > which may be re-used are NETCONF [RFC6241] and RESTCONF
>>   > [I-D.ietf-netconf-restconf].
>>
>>> editorial "may be reused".  / I will check with RFC editor (some people say
>> reused /re-used).
>>
>>> What does it mean? I was hoping that an architecture documents would at
>> least tell me which protocols are used.
>>>   On my side this architecture is flexible (NETCONF or RESTCONF), on the
>> other side unclear (YANG 1.0 or
>>> YANG1.1), and in some cases, a complete specification (for example the
>> notification)
>>
>> Sue: NETCONF and RESTCONF will be supported as part of the I2RS protocols.
>> The architecture does out rule out other data transfer protocols, but says
>> the WG will design I2RS as a higher level protocol that combines other
>> protocols (NETCONF/RESTCONF + x).
> This is what I could not understand with the draft sentence: "Two of the
> existing protocols which the which may _be re-used_ are NETCONF
> [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]."
> Sure many things could be reused. I'm expecting from an architecture
> document to explain which pieces are used and how they are used.
>> The I2RS requirements documents and
>> protocol strawman will state is if any other protocols will be used for a
>> particular version of I2RS with a particular scope for data modules.
> Probably, my issue stems from the fact that I2RS produces an
> architecture before fixing requirements.
>>
>> I am sorry if this is not what you excepted, but it was my direction from my
>> AD on how to approach this work.
>>
>> At this time, we are closing in on the last of the requirements documents -
>> the requirements for other data flows.
>> draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data
>> flows, but IMO the first version of the I2RS is likely to stay with just
>> NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog module
>> library, and some yang changes.
>>
>>
>>>     To handle I2RS Agent failure, the I2RS Agent must  use two different
>> notifications.
>>>       NOTIFICATION_I2RS_AGENT_STARTING:   This notification signals to the
>>>          I2RS Client(s) that the associated I2RS Agent has started.  It
>>>           includes an agent-boot-count that indicates how many times the
>>>           I2RS Agent has restarted since the associated routing element
>>>           restarted.  The agent-boot-count allows an I2RS Client to
>>>           determine if the I2RS Agent has restarted.  (Note: This
>>>           notification will be only transmitted to I2RS clients which are
>>>           know in some way after a reboot.)
> No comment on "the I2RS Agent _must _use two different notifications"?
> This one is clear spec.
>>> - editorial:
>>>    Optionally, a routing element may permit a priority to be to be....
>>>    For the case when the I2RS ephemeral state always wins for a data
>>>   model, if there is an I2RS ephemeral state value it is installed
>>>    instead of the local configuration state.
>>> Again, I read that sentence multiple times, and could not understand it
>> Sue: Reasonable editorial comment.  This was added to address another
>> comment,
>> But it looks like we broken something.  Text change below.
>>
>>   Old/  Optionally, a routing element may permit a priority to be to be
>>     configured on the device for the Local Configuration mechanism
>>     interaction with the I2RS model.  The policy mechanism would compare
>>     the I2RS client's priority with that priority assigned to the Local
>>     Configuration in order to determine whether Local Configuration or
>>     I2RS wins.
>>
>>     For the case when the I2RS ephemeral state always wins for a data
>>     model, if there is an I2RS ephemeral state value it is installed
>>     instead of the local configuration state.  The local configuration
>>     information is stored so that if/when I2RS client removes I2RS
>>     ephemeral state the local configuration state can be restored.
>> /
>> New:
>> Optionally, a routing element may permit a priority to be to be
> to be to be
>>     configured on the device for the Local Configuration mechanism
>>     interaction with the I2RS model.  The policy mechanism would compare
>>     the I2RS client's priority with that priority assigned to the Local
>>     Configuration in order to determine whether Local Configuration or
>>     I2RS wins.
>>
>>     For the case when the configured priority of the I2RS ephemeral
>>     Is higher than the Local Configuration's policy, the
>>     The I2RS ephemeral state value it is installed
> remove "it"
>>     instead of the local configuration state.  The local configuration
>>     information is stored so that if/when I2RS client removes I2RS
>>     ephemeral state the local configuration state can be restored.
>> /
>>
>>> figure 2. "The initial services included in the I2RS architecture are as
>> follows."
>>> Are these really the initial services for I2RS. I2RS is really dealing
>> with all these: interfaces, policy, QoS, ...
>>> Maybe I should review the I2RS charter?
>> Sue:  Our charter is wide, but only ephemeral layer deep.  Due to the
>> excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS - we
>> are focusing on allowing ephemeral to be added to any data model.  I2RS WG
>> is focused first on the I2RS protocol and protocol independent modules.
>> After this, I2RS purpose is to simply support other WGs in creating data
>> modules with ephemeral state.
>>
>>>    The I2RS  protocol may need to use several underlying transports (TCP,
>> SCTP
>>>    (stream control transport protocol), DCCP (Datagram Congestion
>>> Control Protocol)), with suitable authentication and integrity
>>>   protection mechanisms
>>>   Do you really want to have define transports?
>> Sue: We indicate that I2RS will use these protocols.  Each protocol we
>> mention has to be then validated with requirements (see protocol security
>> requirement and security environment requirements).
>>
> So I2RS will publish a second architecture doc when the requirements are
> validated and the protocols (transport, config, notifications) are
> finally selected?
>
> Regards, Benoit
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>


From nobody Thu Mar 24 06:04: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 617FE12DAD0; Thu, 24 Mar 2016 06:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 POxW5457ZSYq; Thu, 24 Mar 2016 06:04:03 -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 759DE12D12D; Thu, 24 Mar 2016 06:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22593; q=dns/txt; s=iport; t=1458824604; x=1460034204; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=gjRiwGf2X5ohXEKmCEAC1085pgW5emSz/WBGf768M/E=; b=X+I7GSUzC7b4k2TAyn0962MmlxkLwdKOC+IMPCDSa93D8msljEN9c/BQ jZR4gcMnUoEFC4LkhvxdSXvneE0HdESKJFbOX2Zou4oSNeWAxjCjJFGiN +JzXvpG3zhdwhZQ/j1qVtmcgRnBP081Yz0OB9qhwRIUfNsvc51qa0e0dg M=;
X-IronPort-AV: E=Sophos;i="5.24,385,1454976000";  d="scan'208,217";a="676260307"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2016 13:03:21 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2OD3Koq004924; Thu, 24 Mar 2016 13:03:21 GMT
To: "Joel M. Halpern" , Susan Hares , "'The IESG'" 
References: <20160317013624.18209.45055.idtracker@ietfa.amsl.com> <046601d17ff5$70c29350$5247b9f0$@ndzh.com> <56F3C73A.9090500@cisco.com> <56F3DAB3.5040607@joelhalpern.com>
From: Benoit Claise 
Message-ID: <56F3E598.3030708@cisco.com>
Date: Thu, 24 Mar 2016 10:03:20 -0300
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: <56F3DAB3.5040607@joelhalpern.com>
Content-Type: multipart/alternative; boundary="------------090906060808090706000004"
Archived-At: 
Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org, Fred@cisco.com
Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 24 Mar 2016 13:04:07 -0000

This is a multi-part message in MIME format.
--------------090906060808090706000004
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Joel,

Thanks, that's helpful.

1. Let's look at the charter

    The I2RS working group works to develop a high-level architecture that
    describes the basic building-blocks necessary to enable the specific
    use
    cases, and that will lead to an understanding of the abstract
    informational models and requirements for encodings and protocols
    for the I2RS interfaces.

2. Let's review the draft abstract

        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).

Reading 1., I understand your point of view.
However, I read 2. as this draft is about "we are using pieces X, Y, and 
Z, in ways A, B, and C, to solve the I2RS problem."
I reviewed the draft content looking for 1., and could not find it.

Do you understand my confusion?

Regards, Benoit
> Benoit, you seem to be looking for a level of specificity in the 
> architecture that the working group never intended. 
> The charter calls for a high level architecture.
>
> I believe your comment calls out an interesting gap in the charter, as 
> there is no document called out which actually says "we are using 
> pieces X, Y, and Z, in ways A, B, and C, to solve the I2RS problem."
>
> We could have tried to use the architecture document for that, but the 
> intention was to use the architecture document to guide the selection 
> of protocol and mechanisms.
>
> Yours,
> Joel
>
> On 3/24/16 6:53 AM, Benoit Claise wrote:
>> Sue,
>>
>>>   >Two of the existing protocols which the
>>>   > which may be re-used are NETCONF [RFC6241] and RESTCONF
>>>   > [I-D.ietf-netconf-restconf].
>>>
>>>> editorial "may be reused".  / I will check with RFC editor (some 
>>>> people say
>>> reused /re-used).
>>>
>>>> What does it mean? I was hoping that an architecture documents 
>>>> would at
>>> least tell me which protocols are used.
>>>>   On my side this architecture is flexible (NETCONF or RESTCONF), 
>>>> on the
>>> other side unclear (YANG 1.0 or
>>>> YANG1.1), and in some cases, a complete specification (for example the
>>> notification)
>>>
>>> Sue: NETCONF and RESTCONF will be supported as part of the I2RS 
>>> protocols.
>>> The architecture does out rule out other data transfer protocols, 
>>> but says
>>> the WG will design I2RS as a higher level protocol that combines other
>>> protocols (NETCONF/RESTCONF + x).
>> This is what I could not understand with the draft sentence: "Two of the
>> existing protocols which the which may _be re-used_ are NETCONF
>> [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]."
>> Sure many things could be reused. I'm expecting from an architecture
>> document to explain which pieces are used and how they are used.
>>> The I2RS requirements documents and
>>> protocol strawman will state is if any other protocols will be used 
>>> for a
>>> particular version of I2RS with a particular scope for data modules.
>> Probably, my issue stems from the fact that I2RS produces an
>> architecture before fixing requirements.
>>>
>>> I am sorry if this is not what you excepted, but it was my direction 
>>> from my
>>> AD on how to approach this work.
>>>
>>> At this time, we are closing in on the last of the requirements 
>>> documents -
>>> the requirements for other data flows.
>>> draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data
>>> flows, but IMO the first version of the I2RS is likely to stay with 
>>> just
>>> NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog 
>>> module
>>> library, and some yang changes.
>>>
>>>
>>>>     To handle I2RS Agent failure, the I2RS Agent must  use two 
>>>> different
>>> notifications.
>>>> NOTIFICATION_I2RS_AGENT_STARTING:   This notification signals to the
>>>>          I2RS Client(s) that the associated I2RS Agent has 
>>>> started.  It
>>>>           includes an agent-boot-count that indicates how many 
>>>> times the
>>>>           I2RS Agent has restarted since the associated routing 
>>>> element
>>>>           restarted.  The agent-boot-count allows an I2RS Client to
>>>>           determine if the I2RS Agent has restarted.  (Note: This
>>>>           notification will be only transmitted to I2RS clients 
>>>> which are
>>>>           know in some way after a reboot.)
>> No comment on "the I2RS Agent _must _use two different notifications"?
>> This one is clear spec.
>>>> - editorial:
>>>>    Optionally, a routing element may permit a priority to be to be....
>>>>    For the case when the I2RS ephemeral state always wins for a data
>>>>   model, if there is an I2RS ephemeral state value it is installed
>>>>    instead of the local configuration state.
>>>> Again, I read that sentence multiple times, and could not 
>>>> understand it
>>> Sue: Reasonable editorial comment.  This was added to address another
>>> comment,
>>> But it looks like we broken something.  Text change below.
>>>
>>>   Old/  Optionally, a routing element may permit a priority to be to be
>>>     configured on the device for the Local Configuration mechanism
>>>     interaction with the I2RS model.  The policy mechanism would 
>>> compare
>>>     the I2RS client's priority with that priority assigned to the Local
>>>     Configuration in order to determine whether Local Configuration or
>>>     I2RS wins.
>>>
>>>     For the case when the I2RS ephemeral state always wins for a data
>>>     model, if there is an I2RS ephemeral state value it is installed
>>>     instead of the local configuration state.  The local configuration
>>>     information is stored so that if/when I2RS client removes I2RS
>>>     ephemeral state the local configuration state can be restored.
>>> /
>>> New:
>>> Optionally, a routing element may permit a priority to be to be
>> to be to be
>>>     configured on the device for the Local Configuration mechanism
>>>     interaction with the I2RS model.  The policy mechanism would 
>>> compare
>>>     the I2RS client's priority with that priority assigned to the Local
>>>     Configuration in order to determine whether Local Configuration or
>>>     I2RS wins.
>>>
>>>     For the case when the configured priority of the I2RS ephemeral
>>>     Is higher than the Local Configuration's policy, the
>>>     The I2RS ephemeral state value it is installed
>> remove "it"
>>>     instead of the local configuration state.  The local configuration
>>>     information is stored so that if/when I2RS client removes I2RS
>>>     ephemeral state the local configuration state can be restored.
>>> /
>>>
>>>> figure 2. "The initial services included in the I2RS architecture 
>>>> are as
>>> follows."
>>>> Are these really the initial services for I2RS. I2RS is really dealing
>>> with all these: interfaces, policy, QoS, ...
>>>> Maybe I should review the I2RS charter?
>>> Sue:  Our charter is wide, but only ephemeral layer deep.  Due to the
>>> excellent people in the NETCONF/NETMOD, routing area (rtgwg) and 
>>> TEAS - we
>>> are focusing on allowing ephemeral to be added to any data model.  
>>> I2RS WG
>>> is focused first on the I2RS protocol and protocol independent modules.
>>> After this, I2RS purpose is to simply support other WGs in creating 
>>> data
>>> modules with ephemeral state.
>>>
>>>>    The I2RS  protocol may need to use several underlying transports 
>>>> (TCP,
>>> SCTP
>>>>    (stream control transport protocol), DCCP (Datagram Congestion
>>>> Control Protocol)), with suitable authentication and integrity
>>>>   protection mechanisms
>>>>   Do you really want to have define transports?
>>> Sue: We indicate that I2RS will use these protocols.  Each protocol we
>>> mention has to be then validated with requirements (see protocol 
>>> security
>>> requirement and security environment requirements).
>>>
>> So I2RS will publish a second architecture doc when the requirements are
>> validated and the protocols (transport, config, notifications) are
>> finally selected?
>>
>> Regards, Benoit
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
> .
>


--------------090906060808090706000004
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Joel,

      

      Thanks, that's helpful.

      

      1. Let's look at the charter

      
The I2RS working group works to develop a high-level
        architecture that 

        describes the basic building-blocks necessary to enable the
        specific use 

        cases, and that will lead to an understanding of the abstract

        informational models and requirements for encodings and
        protocols for the I2RS interfaces.

      

      2. Let's review the draft abstract

      

        
   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).

      

      Reading 1., I understand your point of view.

      However, I read 2. as this draft is about "we are using pieces X,
      Y, and Z, in ways A, B, and C, to solve the I2RS problem."

      I reviewed the draft content looking for 1., and could not find
      it.

      

      Do you understand my confusion?

      

      Regards, Benoit 

    

    
Benoit,
      you seem to be looking for a level of specificity in the
      architecture that the working group never intended.  

    
The
      charter calls for a high level architecture.
      

      

      I believe your comment calls out an interesting gap in the
      charter, as there is no document called out which actually says
      "we are using pieces X, Y, and Z, in ways A, B, and C, to solve
      the I2RS problem."
      

      

      We could have tried to use the architecture document for that, but
      the intention was to use the architecture document to guide the
      selection of protocol and mechanisms.
      

      

      Yours,
      

      Joel
      

      

      On 3/24/16 6:53 AM, Benoit Claise wrote:
      

      
Sue,
        

        

        
  >Two of the existing protocols
          which the
          

            > which may be re-used are NETCONF [RFC6241] and RESTCONF
          

            > [I-D.ietf-netconf-restconf].
          

          

          
editorial "may be reused".  / I will
            check with RFC editor (some people say
            

          

          reused /re-used).
          

          

          
What does it mean? I was hoping that
            an architecture documents would at
            

          

          least tell me which protocols are used.
          

          
  On my side this architecture is
            flexible (NETCONF or RESTCONF), on the
            

          

          other side unclear (YANG 1.0 or
          

          
YANG1.1), and in some cases, a
            complete specification (for example the
            

          

          notification)
          

          

          Sue: NETCONF and RESTCONF will be supported as part of the
          I2RS protocols.
          

          The architecture does out rule out other data transfer
          protocols, but says
          

          the WG will design I2RS as a higher level protocol that
          combines other
          

          protocols (NETCONF/RESTCONF + x).
          

        

        This is what I could not understand with the draft sentence:
        "Two of the
        

        existing protocols which the which may _be re-used_ are NETCONF
        

        [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]."
        

        Sure many things could be reused. I'm expecting from an
        architecture
        

        document to explain which pieces are used and how they are used.
        

        
The I2RS requirements documents and
          

          protocol strawman will state is if any other protocols will be
          used for a
          

          particular version of I2RS with a particular scope for data
          modules.
          

        

        Probably, my issue stems from the fact that I2RS produces an
        

        architecture before fixing requirements.
        

        

          

          I am sorry if this is not what you excepted, but it was my
          direction from my
          

          AD on how to approach this work.
          

          

          At this time, we are closing in on the last of the
          requirements documents -
          

          the requirements for other data flows.
          

          draft-hares-i2rs-dataflow-req-02 that gives the potential
          scope of data
          

          flows, but IMO the first version of the I2RS is likely to stay
          with just
          

          NETCONF/RESTCONF with ephemeral state, push pub/sub support,
          syslog module
          

          library, and some yang changes.
          

          

          

          
    To handle I2RS Agent failure, the
            I2RS Agent must  use two different
            

          

          notifications.
          

          
     
            NOTIFICATION_I2RS_AGENT_STARTING:   This notification
            signals to the
            

                     I2RS Client(s) that the associated I2RS Agent has
            started.  It
            

                      includes an agent-boot-count that indicates how
            many times the
            

                      I2RS Agent has restarted since the associated
            routing element
            

                      restarted.  The agent-boot-count allows an I2RS
            Client to
            

                      determine if the I2RS Agent has restarted.  (Note:
            This
            

                      notification will be only transmitted to I2RS
            clients which are
            

                      know in some way after a reboot.)
            

          

        

        No comment on "the I2RS Agent _must _use two different
        notifications"?
        

        This one is clear spec.
        

        

          
- editorial:
            

               Optionally, a routing element may permit a priority to be
            to be....
            

               For the case when the I2RS ephemeral state always wins
            for a data
            

              model, if there is an I2RS ephemeral state value it is
            installed
            

               instead of the local configuration state.
            

            Again, I read that sentence multiple times, and could not
            understand it
            

          

          Sue: Reasonable editorial comment.  This was added to address
          another
          

          comment,
          

          But it looks like we broken something.  Text change below.
          

          

            Old/  Optionally, a routing element may permit a priority to
          be to be
          

              configured on the device for the Local Configuration
          mechanism
          

              interaction with the I2RS model.  The policy mechanism
          would compare
          

              the I2RS client's priority with that priority assigned to
          the Local
          

              Configuration in order to determine whether Local
          Configuration or
          

              I2RS wins.
          

          

              For the case when the I2RS ephemeral state always wins for
          a data
          

              model, if there is an I2RS ephemeral state value it is
          installed
          

              instead of the local configuration state.  The local
          configuration
          

              information is stored so that if/when I2RS client removes
          I2RS
          

              ephemeral state the local configuration state can be
          restored.
          

          /
          

          New:
          

          Optionally, a routing element may permit a priority to be to
          be
          

        

        to be to be
        

        
    configured on the device for the
          Local Configuration mechanism
          

              interaction with the I2RS model.  The policy mechanism
          would compare
          

              the I2RS client's priority with that priority assigned to
          the Local
          

              Configuration in order to determine whether Local
          Configuration or
          

              I2RS wins.
          

          

              For the case when the configured priority of the I2RS
          ephemeral
          

              Is higher than the Local Configuration's policy, the
          

              The I2RS ephemeral state value it is installed
          

        

        remove "it"
        

        
    instead of the local configuration
          state.  The local configuration
          

              information is stored so that if/when I2RS client removes
          I2RS
          

              ephemeral state the local configuration state can be
          restored.
          

          /
          

          

          
figure 2. "The initial services
            included in the I2RS architecture are as
            

          

          follows."
          

          
Are these really the initial services
            for I2RS. I2RS is really dealing
            

          

          with all these: interfaces, policy, QoS, ...
          

          
Maybe I should review the I2RS
            charter?
            

          

          Sue:  Our charter is wide, but only ephemeral layer deep.  Due
          to the
          

          excellent people in the NETCONF/NETMOD, routing area (rtgwg)
          and TEAS - we
          

          are focusing on allowing ephemeral to be added to any data
          model.  I2RS WG
          

          is focused first on the I2RS protocol and protocol independent
          modules.
          

          After this, I2RS purpose is to simply support other WGs in
          creating data
          

          modules with ephemeral state.
          

          

          
   The I2RS  protocol may need to use
            several underlying transports (TCP,
            

          

          SCTP
          

          
   (stream control transport
            protocol), DCCP (Datagram Congestion
            

            Control Protocol)), with suitable authentication and
            integrity
            

              protection mechanisms
            

              Do you really want to have define transports?
            

          

          Sue: We indicate that I2RS will use these protocols.  Each
          protocol we
          

          mention has to be then validated with requirements (see
          protocol security
          

          requirement and security environment requirements).
          

          

        

        So I2RS will publish a second architecture doc when the
        requirements are
        

        validated and the protocols (transport, config, notifications)
        are
        

        finally selected?
        

        

        Regards, Benoit
        

        

        

        _______________________________________________
        

        i2rs mailing list
        

        i2rs@ietf.org
        

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

        

      

      .
      

      

    

    

  


--------------090906060808090706000004--


From nobody Thu Mar 24 06:08: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 09C2012DB60; Thu, 24 Mar 2016 06:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Level: 
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_SORBS_WEB=0.77, 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 o0fnw1bADAkU; Thu, 24 Mar 2016 06:08:43 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5AC12DAE0; Thu, 24 Mar 2016 06:07:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 392F41C0134; Thu, 24 Mar 2016 06:07:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1458824829; bh=qe0zVqP65Gl7SxYvZuCYTzbIQiTisxxbQuzgywo617o=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=CI8Kuz/bSOWIAIym+/FkZECvJ3pNnX4f+TXIeaZEMBbn04vIwTWRelyJrwiIshcsd p73Q0Mv5fj3iSwBXpRDQ87WtvDgxizwKqWT+jhVije9Pm6q9hTwNSwrN1vv7x71Ady TWNl/loybwvPj3jZRFIkKW4+lJs2sD5mcjpT7/X0=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [192.165.126.74]) (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 F06DE1C00FB; Thu, 24 Mar 2016 06:07:06 -0700 (PDT)
To: Benoit Claise , Susan Hares , 'The IESG' 
References: <20160317013624.18209.45055.idtracker@ietfa.amsl.com> <046601d17ff5$70c29350$5247b9f0$@ndzh.com> <56F3C73A.9090500@cisco.com> <56F3DAB3.5040607@joelhalpern.com> <56F3E598.3030708@cisco.com>
From: "Joel M. Halpern" 
Message-ID: <56F3E678.4080105@joelhalpern.com>
Date: Thu, 24 Mar 2016 09:07:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <56F3E598.3030708@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: i2rs@ietf.org, mach.chen@huawei.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-architecture@ietf.org, Fred@cisco.com
Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (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: Thu, 24 Mar 2016 13:08:47 -0000

Now I understand your confusion.
Putting aside the abstract, I thought we were focused om task 1 (from 
the charter) in writing.  I think we probably crept into task 2, 
resulting in a document which is confusing about its scope.

Not sure how to resolve this.
Yours,
Joel

On 3/24/16 9:03 AM, Benoit Claise wrote:
> Joel,
>
> Thanks, that's helpful.
>
> 1. Let's look at the charter
>
>     The I2RS working group works to develop a high-level architecture that
>     describes the basic building-blocks necessary to enable the specific
>     use
>     cases, and that will lead to an understanding of the abstract
>     informational models and requirements for encodings and protocols
>     for the I2RS interfaces.
>
> 2. Let's review the draft abstract
>
>         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).
>
> Reading 1., I understand your point of view.
> However, I read 2. as this draft is about "we are using pieces X, Y, and
> Z, in ways A, B, and C, to solve the I2RS problem."
> I reviewed the draft content looking for 1., and could not find it.
>
> Do you understand my confusion?
>
> Regards, Benoit
>> Benoit, you seem to be looking for a level of specificity in the
>> architecture that the working group never intended.
>> The charter calls for a high level architecture.
>>
>> I believe your comment calls out an interesting gap in the charter, as
>> there is no document called out which actually says "we are using
>> pieces X, Y, and Z, in ways A, B, and C, to solve the I2RS problem."
>>
>> We could have tried to use the architecture document for that, but the
>> intention was to use the architecture document to guide the selection
>> of protocol and mechanisms.
>>
>> Yours,
>> Joel
>>
>> On 3/24/16 6:53 AM, Benoit Claise wrote:
>>> Sue,
>>>
>>>>   >Two of the existing protocols which the
>>>>   > which may be re-used are NETCONF [RFC6241] and RESTCONF
>>>>   > [I-D.ietf-netconf-restconf].
>>>>
>>>>> editorial "may be reused".  / I will check with RFC editor (some
>>>>> people say
>>>> reused /re-used).
>>>>
>>>>> What does it mean? I was hoping that an architecture documents
>>>>> would at
>>>> least tell me which protocols are used.
>>>>>   On my side this architecture is flexible (NETCONF or RESTCONF),
>>>>> on the
>>>> other side unclear (YANG 1.0 or
>>>>> YANG1.1), and in some cases, a complete specification (for example the
>>>> notification)
>>>>
>>>> Sue: NETCONF and RESTCONF will be supported as part of the I2RS
>>>> protocols.
>>>> The architecture does out rule out other data transfer protocols,
>>>> but says
>>>> the WG will design I2RS as a higher level protocol that combines other
>>>> protocols (NETCONF/RESTCONF + x).
>>> This is what I could not understand with the draft sentence: "Two of the
>>> existing protocols which the which may _be re-used_ are NETCONF
>>> [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]."
>>> Sure many things could be reused. I'm expecting from an architecture
>>> document to explain which pieces are used and how they are used.
>>>> The I2RS requirements documents and
>>>> protocol strawman will state is if any other protocols will be used
>>>> for a
>>>> particular version of I2RS with a particular scope for data modules.
>>> Probably, my issue stems from the fact that I2RS produces an
>>> architecture before fixing requirements.
>>>>
>>>> I am sorry if this is not what you excepted, but it was my direction
>>>> from my
>>>> AD on how to approach this work.
>>>>
>>>> At this time, we are closing in on the last of the requirements
>>>> documents -
>>>> the requirements for other data flows.
>>>> draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data
>>>> flows, but IMO the first version of the I2RS is likely to stay with
>>>> just
>>>> NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog
>>>> module
>>>> library, and some yang changes.
>>>>
>>>>
>>>>>     To handle I2RS Agent failure, the I2RS Agent must  use two
>>>>> different
>>>> notifications.
>>>>> NOTIFICATION_I2RS_AGENT_STARTING:   This notification signals to the
>>>>>          I2RS Client(s) that the associated I2RS Agent has
>>>>> started.  It
>>>>>           includes an agent-boot-count that indicates how many
>>>>> times the
>>>>>           I2RS Agent has restarted since the associated routing
>>>>> element
>>>>>           restarted.  The agent-boot-count allows an I2RS Client to
>>>>>           determine if the I2RS Agent has restarted.  (Note: This
>>>>>           notification will be only transmitted to I2RS clients
>>>>> which are
>>>>>           know in some way after a reboot.)
>>> No comment on "the I2RS Agent _must _use two different notifications"?
>>> This one is clear spec.
>>>>> - editorial:
>>>>>    Optionally, a routing element may permit a priority to be to be....
>>>>>    For the case when the I2RS ephemeral state always wins for a data
>>>>>   model, if there is an I2RS ephemeral state value it is installed
>>>>>    instead of the local configuration state.
>>>>> Again, I read that sentence multiple times, and could not
>>>>> understand it
>>>> Sue: Reasonable editorial comment.  This was added to address another
>>>> comment,
>>>> But it looks like we broken something.  Text change below.
>>>>
>>>>   Old/  Optionally, a routing element may permit a priority to be to be
>>>>     configured on the device for the Local Configuration mechanism
>>>>     interaction with the I2RS model.  The policy mechanism would
>>>> compare
>>>>     the I2RS client's priority with that priority assigned to the Local
>>>>     Configuration in order to determine whether Local Configuration or
>>>>     I2RS wins.
>>>>
>>>>     For the case when the I2RS ephemeral state always wins for a data
>>>>     model, if there is an I2RS ephemeral state value it is installed
>>>>     instead of the local configuration state.  The local configuration
>>>>     information is stored so that if/when I2RS client removes I2RS
>>>>     ephemeral state the local configuration state can be restored.
>>>> /
>>>> New:
>>>> Optionally, a routing element may permit a priority to be to be
>>> to be to be
>>>>     configured on the device for the Local Configuration mechanism
>>>>     interaction with the I2RS model.  The policy mechanism would
>>>> compare
>>>>     the I2RS client's priority with that priority assigned to the Local
>>>>     Configuration in order to determine whether Local Configuration or
>>>>     I2RS wins.
>>>>
>>>>     For the case when the configured priority of the I2RS ephemeral
>>>>     Is higher than the Local Configuration's policy, the
>>>>     The I2RS ephemeral state value it is installed
>>> remove "it"
>>>>     instead of the local configuration state.  The local configuration
>>>>     information is stored so that if/when I2RS client removes I2RS
>>>>     ephemeral state the local configuration state can be restored.
>>>> /
>>>>
>>>>> figure 2. "The initial services included in the I2RS architecture
>>>>> are as
>>>> follows."
>>>>> Are these really the initial services for I2RS. I2RS is really dealing
>>>> with all these: interfaces, policy, QoS, ...
>>>>> Maybe I should review the I2RS charter?
>>>> Sue:  Our charter is wide, but only ephemeral layer deep.  Due to the
>>>> excellent people in the NETCONF/NETMOD, routing area (rtgwg) and
>>>> TEAS - we
>>>> are focusing on allowing ephemeral to be added to any data model.
>>>> I2RS WG
>>>> is focused first on the I2RS protocol and protocol independent modules.
>>>> After this, I2RS purpose is to simply support other WGs in creating
>>>> data
>>>> modules with ephemeral state.
>>>>
>>>>>    The I2RS  protocol may need to use several underlying transports
>>>>> (TCP,
>>>> SCTP
>>>>>    (stream control transport protocol), DCCP (Datagram Congestion
>>>>> Control Protocol)), with suitable authentication and integrity
>>>>>   protection mechanisms
>>>>>   Do you really want to have define transports?
>>>> Sue: We indicate that I2RS will use these protocols.  Each protocol we
>>>> mention has to be then validated with requirements (see protocol
>>>> security
>>>> requirement and security environment requirements).
>>>>
>>> So I2RS will publish a second architecture doc when the requirements are
>>> validated and the protocols (transport, config, notifications) are
>>> finally selected?
>>>
>>> Regards, Benoit
>>>
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> i2rs@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>> .
>>
>


From nobody Thu Mar 24 10:03:03 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 DB47F12D620; Thu, 24 Mar 2016 10:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.638
X-Spam-Level: ***
X-Spam-Status: No, score=3.638 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 raqm6tEoB4j4; Thu, 24 Mar 2016 10:02:59 -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 05B9312D61A; Thu, 24 Mar 2016 10:02:58 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; 
From: "Susan Hares" 
To: 
Date: Thu, 24 Mar 2016 13:02:27 -0400
Message-ID: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D8_01D185CD.6AF13E80"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdGF7u3xjBynKRvjQdyb5YDZuMHPDw==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: 'Joel Halpern Direct' , ops-dir@ietf.org, "'Fred Baker \(fred\)'" 
Subject: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 17:03:01 -0000

This is a multipart message in MIME format.

------=_NextPart_000_01D8_01D185CD.6AF13E80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all: 

 

 

The draft-ietf-i2rs-architecture document has been approved as an RFC.  In
the review, the OPS-DIR review indicated that "ephemeral" meant more than
"does not survive a reboot". They have asked the I2RS working group if
replacing "ephemeral" with non-persistent (across power on/off or reboot
cycles) would be a better choice.  

 

What do you think - leave at it at "ephemeral" or change to "non-persistent
(across power on/off or reboot cycles) ? We will have a 1 week call on 

 

This would mean every place that "ephemeral" is listed, the authors would
replace with "non-persistent".  In the first instance, we will indicate
"non-persistent (across power on/off or reboot cycles).

 

  

 

As the author, I think we are better to define ephemeral at the beginning as
"non-persistent (across power on /off or reboot).  Changing the definition
at this point, I suspect will simply confuse people. 

 

Sue Hares

 


------=_NextPart_000_01D8_01D185CD.6AF13E80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi all: =

 
<wg chair hat on> 
The draft-ietf-i2rs-architecture document has been =
approved as an RFC.  In the review, the OPS-DIR review indicated =
that “ephemeral” meant more than “does not survive a =
reboot”. They have asked the I2RS working group if replacing =
“ephemeral” with non-persistent (across power on/off or =
reboot cycles) would be a better choice.  
 
What do you =
think – leave at it at “ephemeral” or change to =
“non-persistent (across power on/off or reboot cycles) ? We will =
have a 1 week call on 
 
This would =
mean every place that “ephemeral” is listed, the authors =
would replace with “non-persistent”.  In the first =
instance, we will indicate “non-persistent (across power on/off or =
reboot cycles).
 
<wg chair =
hat off>  
 
As the =
author, I think we are better to define ephemeral at the beginning as =
“non-persistent (across power on /off or reboot).  Changing =
the definition at this point, I suspect will simply confuse people. =

 
Sue Hares
 =
 

------=_NextPart_000_01D8_01D185CD.6AF13E80--


From nobody Thu Mar 24 10:05: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 7554112D677; Thu, 24 Mar 2016 10:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 vMR8OkDUMGJB; Thu, 24 Mar 2016 10:05:35 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC0412D675; Thu, 24 Mar 2016 10:05:34 -0700 (PDT)
Received: from muimrel001.emea.nsn-intra.net ([10.159.32.132]) by demumfd002.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id u2OH5WCA016619 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 17:05:32 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by muimrel001.emea.nsn-intra.net (8.14.3/8.14.3) with ESMTP id u2OH5WvL002703 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Mar 2016 17:05:32 GMT
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.279.2; Thu, 24 Mar 2016 18:05:31 +0100
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.154]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0279.002; Thu, 24 Mar 2016 18:05:31 +0100
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: EXT Susan Hares , "i2rs@ietf.org" 
Thread-Topic: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AdGF7u3xjBynKRvjQdyb5YDZuMHPDwAAGuRA
Date: Thu, 24 Mar 2016 17:05:30 +0000
Message-ID: 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>
In-Reply-To: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.100]
Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81CBA3BDEDEMUMBX005nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 6203
X-purgate-ID: 151667::1458839132-000079EB-ADF5B3C2/0/0
Archived-At: 
Cc: 'Joel Halpern Direct' , "ops-dir@ietf.org" 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 17:05:39 -0000

--_000_E4DE949E6CE3E34993A2FF8AE79131F81CBA3BDEDEMUMBX005nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Agree.

Cheers,
Mehmet

From: OPS-DIR [mailto:ops-dir-bounces@ietf.org] On Behalf Of EXT Susan Hare=
s
Sent: Thursday, March 24, 2016 6:02 PM
To: i2rs@ietf.org
Cc: 'Joel Halpern Direct' ; ops-dir@ietf.org
Subject: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) C=
all for opinion

Hi all:


The draft-ietf-i2rs-architecture document has been approved as an RFC.  In =
the review, the OPS-DIR review indicated that "ephemeral" meant more than "=
does not survive a reboot". They have asked the I2RS working group if repla=
cing "ephemeral" with non-persistent (across power on/off or reboot cycles)=
 would be a better choice.

What do you think - leave at it at "ephemeral" or change to "non-persistent=
 (across power on/off or reboot cycles) ? We will have a 1 week call on

This would mean every place that "ephemeral" is listed, the authors would r=
eplace with "non-persistent".  In the first instance, we will indicate "non=
-persistent (across power on/off or reboot cycles).



As the author, I think we are better to define ephemeral at the beginning a=
s "non-persistent (across power on /off or reboot).  Changing the definitio=
n at this point, I suspect will simply confuse people.

Sue Hares


--_000_E4DE949E6CE3E34993A2FF8AE79131F81CBA3BDEDEMUMBX005nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Agree.


 




Cheers, 
Mehmet 




 






From: OPS-DIR [mailto:ops-dir-bounces@ietf.or=
g] On Behalf Of
EXT Susan Hares

Sent: Thursday, March 24, 2016 6:02 PM

To: i2rs@ietf.org

Cc: 'Joel Halpern Direct' <jmh.direct@joelhalpern.com>; ops-di=
r@ietf.org

Subject: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to=
 4/3) Call for opinion






 


Hi all: 


 


<wg chair hat on> 


The draft-ietf-i2rs-architecture document has been a=
pproved as an RFC.  In the review, the OPS-DIR review indicated that &=
#8220;ephemeral” meant more than “does not survive a rebootR=
21;. They have asked the I2RS working group if replacing “ephemeral&#=
8221;
 with non-persistent (across power on/off or reboot cycles) would be a bett=
er choice. 



 


What do you think – leave at it at “ephe=
meral” or change to “non-persistent (across power on/off or reb=
oot cycles) ? We will have a 1 week call on



 


This would mean every place that “ephemeral=
221; is listed, the authors would replace with “non-persistent”=
.  In the first instance, we will indicate “non-persistent (acro=
ss power on/off or reboot cycles).


 


<wg chair hat off>  


 


As the author, I think we are better to define ephem=
eral at the beginning as “non-persistent (across power on /off or reb=
oot).  Changing the definition at this point, I suspect will simply co=
nfuse people.



 


Sue Hares


 






--_000_E4DE949E6CE3E34993A2FF8AE79131F81CBA3BDEDEMUMBX005nsnin_--


From nobody Thu Mar 24 10:30: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 504C912D6A5; Thu, 24 Mar 2016 10:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dcfh3Hoo0SOj; Thu, 24 Mar 2016 10:30:26 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF7712D1D8; Thu, 24 Mar 2016 10:30:26 -0700 (PDT)
Received: from muvmp319.nsn-intra.net ([10.159.32.166]) by demumfd002.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id u2OHUOkQ021986 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 17:30:24 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by muvmp319.nsn-intra.net (8.14.3/8.14.3) with ESMTP id u2OHUOLE009329 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Mar 2016 17:30:24 GMT
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.154]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0279.002; Thu, 24 Mar 2016 18:30:24 +0100
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: "Ersue, Mehmet (Nokia - DE/Munich)" , "EXT Susan Hares" , "i2rs@ietf.org" 
Thread-Topic: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AdGF7u3xjBynKRvjQdyb5YDZuMHPDwAAGuRAAAC2pQA=
Date: Thu, 24 Mar 2016 17:30:23 +0000
Message-ID: 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.100]
Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81CBA3D8FDEMUMBX005nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 8802
X-purgate-ID: 151667::1458840624-000079EB-EC1B134E/0/0
Archived-At: 
Cc: 'Joel Halpern Direct' , "ops-dir@ietf.org" 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 17:30:31 -0000

--_000_E4DE949E6CE3E34993A2FF8AE79131F81CBA3D8FDEMUMBX005nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Let me say it a bit more clearly.

I think Sue (the author) is right. We should define the term ephemeral at t=
he beginning of the document and keep using it throughout the document. It =
would be confusing for the people to change it to "non-persistent (across p=
ower on /off or reboot)".

Cheers,
Mehmet

From: OPS-DIR [mailto:ops-dir-bounces@ietf.org] On Behalf Of EXT Ersue, Meh=
met (Nokia - DE/Munich)
Sent: Thursday, March 24, 2016 6:06 PM
To: EXT Susan Hares ; i2rs@ietf.org
Cc: 'Joel Halpern Direct' ; ops-dir@ietf.org
Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/=
3) Call for opinion

Agree.

Cheers,
Mehmet

From: OPS-DIR [mailto:ops-dir-bounces@ietf.org] On Behalf Of EXT Susan Hare=
s
Sent: Thursday, March 24, 2016 6:02 PM
To: i2rs@ietf.org
Cc: 'Joel Halpern Direct' >; ops-dir@ietf.org
Subject: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) C=
all for opinion

Hi all:


The draft-ietf-i2rs-architecture document has been approved as an RFC.  In =
the review, the OPS-DIR review indicated that "ephemeral" meant more than "=
does not survive a reboot". They have asked the I2RS working group if repla=
cing "ephemeral" with non-persistent (across power on/off or reboot cycles)=
 would be a better choice.

What do you think - leave at it at "ephemeral" or change to "non-persistent=
 (across power on/off or reboot cycles) ? We will have a 1 week call on

This would mean every place that "ephemeral" is listed, the authors would r=
eplace with "non-persistent".  In the first instance, we will indicate "non=
-persistent (across power on/off or reboot cycles).



As the author, I think we are better to define ephemeral at the beginning a=
s "non-persistent (across power on /off or reboot).  Changing the definitio=
n at this point, I suspect will simply confuse people.

Sue Hares


--_000_E4DE949E6CE3E34993A2FF8AE79131F81CBA3D8FDEMUMBX005nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Let me say it a bit mo=
re clearly.


 


I think Sue (the autho=
r) is right. We should define the term ephemeral at the beginning of the do=
cument and keep using it throughout the document. It would be confusing for=
 the people to change it to “non-persistent
 (across power on /off or reboot)”.


 




Cheers, 

Mehmet 




 






From: OPS-DIR [mailto:ops-dir-bounces@ietf.or=
g] On Behalf Of
EXT Ersue, Mehmet (Nokia - DE/Munich)

Sent: Thursday, March 24, 2016 6:06 PM

To: EXT Susan Hares <shares@ndzh.com>; i2rs@ietf.org

Cc: 'Joel Halpern Direct' <jmh.direct@joelhalpern.com>; ops-di=
r@ietf.org

Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/2=
4 to 4/3) Call for opinion






 


Agree.


 




Cheers, 
Mehmet 




 






From: OPS-DIR [mailto:ops-dir-bounces@ietf.org]
On Behalf Of EXT Susan Hares

Sent: Thursday, March 24, 2016 6:02 PM

To: i2rs@ietf.org

Cc: 'Joel Halpern Direct' <jmh.direct@joelhalpern.com>;
ops-dir@ietf.org

Subject: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to=
 4/3) Call for opinion






 


Hi all: 


 


<wg chair hat on> 


The draft-ietf-i2rs-architecture document has been a=
pproved as an RFC.  In the review, the OPS-DIR review indicated that &=
#8220;ephemeral” meant more than “does not survive a rebootR=
21;. They have asked the I2RS working group if replacing “ephemeral&#=
8221;
 with non-persistent (across power on/off or reboot cycles) would be a bett=
er choice. 



 


What do you think – leave at it at “ephe=
meral” or change to “non-persistent (across power on/off or reb=
oot cycles) ? We will have a 1 week call on



 


This would mean every place that “ephemeral=
221; is listed, the authors would replace with “non-persistent”=
.  In the first instance, we will indicate “non-persistent (acro=
ss power on/off or reboot cycles).


 


<wg chair hat off>  


 


As the author, I think we are better to define ephem=
eral at the beginning as “non-persistent (across power on /off or reb=
oot).  Changing the definition at this point, I suspect will simply co=
nfuse people.



 


Sue Hares


 






--_000_E4DE949E6CE3E34993A2FF8AE79131F81CBA3D8FDEMUMBX005nsnin_--


From nobody Thu Mar 24 11:22: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 AA0FB12D1DC; Thu, 24 Mar 2016 11:22:14 -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 nBdvd2phgdk4; Thu, 24 Mar 2016 11:22: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 9632F12D0C1; Thu, 24 Mar 2016 11:22:12 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; 
From: "Susan Hares" 
To: "'Gunter Van De Velde'" 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com> 
In-Reply-To: 
Date: Thu, 24 Mar 2016 14:21:40 -0400
Message-ID: <028f01d185fa$037c96f0$0a75c4d0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0290_01D185D8.7C6E0430"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL1cmQL65XiP+Rc6iRVZO2xGznKbQGRYBXWnRSEG+A=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: i2rs@ietf.org, ops-dir@ietf.org, 'Joel Halpern Direct' 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 18:22:14 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0290_01D185D8.7C6E0430
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Gunter:=20

=20

The goal is to explain it in the I2RS architecture statement, and then =
refer back to it in other documents (if needed).=20

=20

Sue

=20

From: Gunter Van De Velde [mailto:guntervandeveldecc@icloud.com]=20
Sent: Thursday, March 24, 2016 2:08 PM
To: Susan Hares
Cc: i2rs@ietf.org; Joel Halpern Direct; ops-dir@ietf.org
Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to =
4/3) Call for opinion

=20

I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D, =
although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn=E2=80=99t 100% reflect the =
Webster dictionary intended meaning.

=20

It is only about a year ago i started reading up on i2rs and discovered =
this particular terminology, and at the time a google search on this =
terminology was not very conclusive and resulted to some confusion.=20

I understand very well the confusion at play here from non-native =
english speaker perspective.

=20

Adding text to explain the context in which the term Ephemeral is =
useful/advised. fwiw now that i am used to seeing =E2=80=98Ephemeral' as =
non-permanent config across reboot, i=E2=80=99m adapted its intended =
purpose=E2=80=A6=20

=20

Is the goal to explain the intended meaning in each draft/rfc mentioning =
it?

=20

Be well,

G/

=20

On 24 Mar 2016, at 18:02, Susan Hares  wrote:

=20

Hi all:=20

=20

=20

The draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =
=E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes not survive a =
reboot=E2=80=9D. They have asked the I2RS working group if replacing =
=E2=80=9Cephemeral=E2=80=9D with non-persistent (across power on/off or =
reboot cycles) would be a better choice. =20

=20

What do you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D =
or change to =E2=80=9Cnon-persistent (across power on/off or reboot =
cycles) ? We will have a 1 week call on=20

=20

This would mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, =
the authors would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the =
first instance, we will indicate =E2=80=9Cnon-persistent (across power =
on/off or reboot cycles).

=20

 =20

=20

As the author, I think we are better to define ephemeral at the =
beginning as =E2=80=9Cnon-persistent (across power on /off or reboot).  =
Changing the definition at this point, I suspect will simply confuse =
people.=20

=20

Sue Hares

=20

_______________________________________________
OPS-DIR mailing list
  OPS-DIR@ietf.org
  =
https://www.ietf.org/mailman/listinfo/ops-dir

=20


------=_NextPart_000_0290_01D185D8.7C6E0430
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Gunter: 
 
The goal is to explain it in the I2RS architecture statement, and =
then refer back to it in other documents (if needed). =

 
Sue
 
From:=
 =
Gunter Van De Velde [mailto:guntervandeveldecc@icloud.com] =

Sent: Thursday, March 24, 2016 2:08 PM
To: Susan =
Hares
Cc: i2rs@ietf.org; Joel Halpern Direct; =
ops-dir@ietf.org
Subject: Re: [OPS-DIR] Ephemeral - Should we =
use another word - (3/24 to 4/3) Call for =
opinion
 
I am ok =
nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D, =
although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn=E2=80=99t 100% reflect the =
Webster dictionary intended meaning.
 
It is only about a year ago i started reading up on =
i2rs and discovered this particular terminology, and at the time a =
google search on this terminology was not very conclusive and resulted =
to some confusion. 
I =
understand very well the confusion at play here from non-native english =
speaker perspective.
 
Adding text to explain the context in which the term =
Ephemeral is useful/advised. fwiw now that i am used to seeing =
=E2=80=98Ephemeral' as non-permanent config across reboot, i=E2=80=99m =
adapted its intended purpose=E2=80=A6 
 
Is the goal to explain the intended meaning in each =
draft/rfc mentioning it?
 
Be well,
G/
 
On 24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> =
wrote:
 
Hi =
all: 
 =

<wg =
chair hat on> 
The =
draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =
=E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes not survive a =
reboot=E2=80=9D. They have asked the I2RS working group if replacing =
=E2=80=9Cephemeral=E2=80=9D with non-persistent (across power on/off or =
reboot cycles) would be a better choice.  
 =

What do =
you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D or change =
to =E2=80=9Cnon-persistent (across power on/off or reboot cycles) ? We =
will have a 1 week call on 
 =

This would =
mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, the authors =
would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the first =
instance, we will indicate =E2=80=9Cnon-persistent (across power on/off =
or reboot cycles).
 =

<wg =
chair hat off>  
 =

As the =
author, I think we are better to define ephemeral at the beginning as =
=E2=80=9Cnon-persistent (across power on /off or reboot).  Changing =
the definition at this point, I suspect will simply confuse people. 
 =

Sue =
Hares
 =

__________=
_____________________________________
OPS-DIR mailing =
list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
 

------=_NextPart_000_0290_01D185D8.7C6E0430--


From nobody Thu Mar 24 11:33: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 98B9512D738; Thu, 24 Mar 2016 11:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 MdBezfyk613x; Thu, 24 Mar 2016 11:33:00 -0700 (PDT)
Received: from g1t5425.austin.hp.com (g1t5425.austin.hp.com [15.216.225.55]) (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 2AC3812D689; Thu, 24 Mar 2016 11:33:00 -0700 (PDT)
Received: from G1W8108.americas.hpqcorp.net (g1w8108.austin.hp.com [16.193.72.60]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by g1t5425.austin.hp.com (Postfix) with ESMTPS id 92CA061; Thu, 24 Mar 2016 18:32:58 +0000 (UTC)
Received: from G1W8108.americas.hpqcorp.net (2002:10c3:2114::10c3:2114) by G1W8108.americas.hpqcorp.net (2002:10c3:2114::10c3:2114) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 24 Mar 2016 18:32:56 +0000
Received: from G4W6303.americas.hpqcorp.net (16.210.26.228) by G1W8108.americas.hpqcorp.net (16.193.72.60) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Thu, 24 Mar 2016 18:32:56 +0000
Received: from G4W3293.americas.hpqcorp.net ([169.254.2.119]) by G4W6303.americas.hpqcorp.net ([16.210.26.228]) with mapi id 14.03.0169.001; Thu, 24 Mar 2016 18:32:56 +0000
From: "Fedyk, Don" 
To: Susan Hares , "i2rs@ietf.org" 
Thread-Topic: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AdGF7u3xjBynKRvjQdyb5YDZuMHPDwAC5tzg
Date: Thu, 24 Mar 2016 18:32:55 +0000
Message-ID: 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>
In-Reply-To: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [16.210.48.16]
Content-Type: multipart/alternative; boundary="_000_A46D9C092EA46F489F135060986AD9FF225BA155G4W3293americas_"
MIME-Version: 1.0
Archived-At: 
Cc: 'Joel Halpern Direct' , "ops-dir@ietf.org" , "'Fred Baker \(fred\)'" 
Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 18:33:04 -0000

--_000_A46D9C092EA46F489F135060986AD9FF225BA155G4W3293americas_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi

Sue I like maintaining the use of the term ephemeral and defining it as you=
 indicated.  By defining the time scope of reboot cycles etc. I think the u=
se is clear.  (I think if we used another term at this point we would have =
to similarly define that term too.)

Cheers
Don

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 24, 2016 1:02 PM
To: i2rs@ietf.org
Cc: 'Joel Halpern Direct' ; ops-dir@ietf.org; '=
Fred Baker (fred)' 
Subject: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call=
 for opinion

Hi all:


The draft-ietf-i2rs-architecture document has been approved as an RFC.  In =
the review, the OPS-DIR review indicated that "ephemeral" meant more than "=
does not survive a reboot". They have asked the I2RS working group if repla=
cing "ephemeral" with non-persistent (across power on/off or reboot cycles)=
 would be a better choice.

What do you think - leave at it at "ephemeral" or change to "non-persistent=
 (across power on/off or reboot cycles) ? We will have a 1 week call on

This would mean every place that "ephemeral" is listed, the authors would r=
eplace with "non-persistent".  In the first instance, we will indicate "non=
-persistent (across power on/off or reboot cycles).



As the author, I think we are better to define ephemeral at the beginning a=
s "non-persistent (across power on /off or reboot).  Changing the definitio=
n at this point, I suspect will simply confuse people.

Sue Hares


--_000_A46D9C092EA46F489F135060986AD9FF225BA155G4W3293americas_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi <=
/p>

 


Sue I like maintaining=
 the use of the term ephemeral and defining it as you indicated.  By d=
efining the time scope of reboot cycles etc. I think the use is clear. &nbs=
p;(I think if we used another term at this point
 we would have to similarly define that term too.) 


 


Cheers


Don =



 








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

Sent: Thursday, March 24, 2016 1:02 PM

To: i2rs@ietf.org

Cc: 'Joel Halpern Direct' <jmh.direct@joelhalpern.com>; ops-di=
r@ietf.org; 'Fred Baker (fred)' <fred@cisco.com>

Subject: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/=
3) Call for opinion






 


Hi all: 


 


<wg chair hat on> 


The draft-ietf-i2rs-architecture document has been a=
pproved as an RFC.  In the review, the OPS-DIR review indicated that &=
#8220;ephemeral” meant more than “does not survive a rebootR=
21;. They have asked the I2RS working group if replacing “ephemeral&#=
8221;
 with non-persistent (across power on/off or reboot cycles) would be a bett=
er choice. 



 


What do you think – leave at it at “ephe=
meral” or change to “non-persistent (across power on/off or reb=
oot cycles) ? We will have a 1 week call on



 


This would mean every place that “ephemeral=
221; is listed, the authors would replace with “non-persistent”=
.  In the first instance, we will indicate “non-persistent (acro=
ss power on/off or reboot cycles).


 


<wg chair hat off>  


 


As the author, I think we are better to define ephem=
eral at the beginning as “non-persistent (across power on /off or reb=
oot).  Changing the definition at this point, I suspect will simply co=
nfuse people.



 


Sue Hares


 








--_000_A46D9C092EA46F489F135060986AD9FF225BA155G4W3293americas_--


From nobody Thu Mar 24 11:41: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 1909612D7AD; Thu, 24 Mar 2016 11:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 lXlOpERr20ZL; Thu, 24 Mar 2016 11:07:45 -0700 (PDT)
Received: from st13p11im-asmtp003.me.com (st13p11im-asmtp003.me.com [17.164.40.218]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0936A12D7AB; Thu, 24 Mar 2016 11:07:45 -0700 (PDT)
Received: from [10.214.90.112] (147.168-179-91.adsl-dyn.isp.belgacom.be [91.179.168.147]) by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O4K000B42CNFS30@st13p11im-asmtp003.me.com>; Thu, 24 Mar 2016 18:07:37 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-24_08:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1603240278
Content-type: multipart/alternative; boundary="Apple-Mail=_0A92802A-D9CE-44AE-A76F-76571FDBC708"
MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Gunter Van De Velde 
In-reply-to: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>
Date: Thu, 24 Mar 2016 19:07:35 +0100
Message-id: 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>
To: Susan Hares 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
X-Mailman-Approved-At: Thu, 24 Mar 2016 11:41:47 -0700
Cc: i2rs@ietf.org, ops-dir@ietf.org, Joel Halpern Direct 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 18:07:47 -0000

--Apple-Mail=_0A92802A-D9CE-44AE-A76F-76571FDBC708
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D, =
although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn=E2=80=99t 100% reflect the =
Webster dictionary intended meaning.

It is only about a year ago i started reading up on i2rs and discovered =
this particular terminology, and at the time a google search on this =
terminology was not very conclusive and resulted to some confusion.=20
I understand very well the confusion at play here from non-native =
english speaker perspective.

Adding text to explain the context in which the term Ephemeral is =
useful/advised. fwiw now that i am used to seeing =E2=80=98Ephemeral' as =
non-permanent config across reboot, i=E2=80=99m adapted its intended =
purpose=E2=80=A6=20

Is the goal to explain the intended meaning in each draft/rfc mentioning =
it?

Be well,
G/

> On 24 Mar 2016, at 18:02, Susan Hares  wrote:
>=20
> Hi all:=20
> =20
> =20
> The draft-ietf-i2rs-architecture document has been approved as an RFC. =
 In the review, the OPS-DIR review indicated that =E2=80=9Cephemeral=E2=80=
=9D meant more than =E2=80=9Cdoes not survive a reboot=E2=80=9D. They =
have asked the I2RS working group if replacing =E2=80=9Cephemeral=E2=80=9D=
 with non-persistent (across power on/off or reboot cycles) would be a =
better choice. =20
> =20
> What do you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D =
or change to =E2=80=9Cnon-persistent (across power on/off or reboot =
cycles) ? We will have a 1 week call on=20
> =20
> This would mean every place that =E2=80=9Cephemeral=E2=80=9D is =
listed, the authors would replace with =E2=80=9Cnon-persistent=E2=80=9D. =
 In the first instance, we will indicate =E2=80=9Cnon-persistent (across =
power on/off or reboot cycles).
> =20
>  =20
> =20
> As the author, I think we are better to define ephemeral at the =
beginning as =E2=80=9Cnon-persistent (across power on /off or reboot).  =
Changing the definition at this point, I suspect will simply confuse =
people.=20
> =20
> Sue Hares
> =20
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org 
> https://www.ietf.org/mailman/listinfo/ops-dir =


--Apple-Mail=_0A92802A-D9CE-44AE-A76F-76571FDBC708
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


I am ok nowadays with using the terminology =
=E2=80=9CEphemeral=E2=80=9D, although for a non-natve speaker it is =
non-trivial exotic word, particular if the intended usage doesn=E2=80=99t =
100% reflect the Webster dictionary intended meaning.

It is only about a year =
ago i started reading up on i2rs and discovered this particular =
terminology, and at the time a google search on this terminology was not =
very conclusive and resulted to some confusion. 
I understand very well the confusion at play here from =
non-native english speaker perspective.

Adding text to explain the context in =
which the term Ephemeral is useful/advised. fwiw now that i am used to =
seeing =E2=80=98Ephemeral' as non-permanent config across reboot, i=E2=80=99=
m adapted its intended purpose=E2=80=A6 

Is the goal to explain the intended =
meaning in each draft/rfc mentioning it?

Be well,
G/
On =
24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> wrote:

Hi all: 
 
<wg =
chair hat on> 
The =
draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =E2=80=9Cephemeral=E2=80=9D=
 meant more than =E2=80=9Cdoes not survive a reboot=E2=80=9D. They have =
asked the I2RS working group if replacing =E2=80=9Cephemeral=E2=80=9D =
with non-persistent (across power on/off or reboot cycles) would be a =
better choice.  
 
What do =
you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D or change =
to =E2=80=9Cnon-persistent (across power on/off or reboot cycles) ? We =
will have a 1 week call on 
 
This =
would mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, the =
authors would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In =
the first instance, we will indicate =E2=80=9Cnon-persistent (across =
power on/off or reboot cycles).
 
<wg chair hat off>  
 
As the =
author, I think we are better to define ephemeral at the beginning as =
=E2=80=9Cnon-persistent (across power on /off or reboot).  Changing =
the definition at this point, I suspect will simply confuse people. 
 
Sue =
Hares
 
_______________________________________________
OPS-DIR mailing =
list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

=

--Apple-Mail=_0A92802A-D9CE-44AE-A76F-76571FDBC708--


From nobody Thu Mar 24 12:31: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 9335012D108; Thu, 24 Mar 2016 12:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 yn5xg_2k9gzE; Thu, 24 Mar 2016 12:31:10 -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 1C9D012D17E; Thu, 24 Mar 2016 12:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11030; q=dns/txt; s=iport; t=1458847867; x=1460057467; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XIjtUbzziEP/Jc9ayMuq06LwzrZF/Hf5AQouSRu/qag=; b=ktK8CkGau/evWF4pK4MxHaeZTZ8pe9qTCNqTOEt6QrYqqmevyIkILpiP xoPfdqIqHR14kUmdWcjTV24mjlXSzMxmTd5OZunp2Al9co/A9gYm9GD3g NkukgHg4m9wn058XdC27udOJqAwUNHpmc8vKLDoVo5mEszxEfi83KRxTd Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AgAdP/RW/5pdJa1egmdMU30GtV+Eb?= =?us-ascii?q?gENgXCCXYMwAoE2OBQBAQEBAQEBZCeEQQEBAQQMERBMEAIBCBEBAwEBKAcyFAM?= =?us-ascii?q?GCAEBBAENBQiIH8FBAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYehESEIFKFIAWIP?= =?us-ascii?q?Y8hAY18jxKPCAEeAQFCgjCBNWyIVn4BAQE?=
X-IronPort-AV: E=Sophos; i="5.24,386,1454976000"; d="scan'208,217"; a="86363418"
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; 24 Mar 2016 19:31:05 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2OJV5CS028074 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Mar 2016 19:31:05 GMT
Received: from xch-aln-012.cisco.com (173.36.7.22) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Mar 2016 14:31:05 -0500
Received: from xch-aln-012.cisco.com ([173.36.7.22]) by XCH-ALN-012.cisco.com ([173.36.7.22]) with mapi id 15.00.1104.009; Thu, 24 Mar 2016 14:31:04 -0500
From: "Steve Braaten (sbraaten)" 
To: "Fedyk, Don" , Susan Hares , "i2rs@ietf.org" 
Thread-Topic: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AdGF7u3xjBynKRvjQdyb5YDZuMHPDwAC5tzgAAH93CA=
Date: Thu, 24 Mar 2016 19:31:04 +0000
Message-ID: 
References: <01d701d185ee$f20157e0$d60407a0$@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.24.98.166]
Content-Type: multipart/alternative; boundary="_000_cd52d88072c9481cb95b4c726b912f87XCHALN012ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: 'Joel Halpern Direct' , "ops-dir@ietf.org" , "Fred Baker \(fred\)" 
Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 19:31:12 -0000

--_000_cd52d88072c9481cb95b4c726b912f87XCHALN012ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All -

While I am not actively involved in i2rs, I have been watching it from the =
beginning and will admit the group's use of the term "ephemeral" has always=
 been confusing to me.  So from an "outsider's" point of view:

While the dictionary will define "ephemeral" as "short-lived," in my 25+ ye=
ars in networking it has meant "constantly changing."  I wouldn't bother wi=
th the semantic, except there is nothing to stop an implementation from sto=
ring ephemeral state persistently, such that when a box or software module =
dies or restarts, it can return to its last known state.  And in this way, =
I feel like term is actually being used technically incorrectly by i2rs.

I am not suggesting you change your proposed course of action, just pointin=
g out what it looks like to someone who is not in the i2rs weeds.

Steve


From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Fedyk, Don
Sent: Thursday, March 24, 2016 11:33 AM
To: Susan Hares ; i2rs@ietf.org
Cc: 'Joel Halpern Direct' ; ops-dir@ietf.org; F=
red Baker (fred) 
Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) =
Call for opinion

Hi

Sue I like maintaining the use of the term ephemeral and defining it as you=
 indicated.  By defining the time scope of reboot cycles etc. I think the u=
se is clear.  (I think if we used another term at this point we would have =
to similarly define that term too.)

Cheers
Don

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 24, 2016 1:02 PM
To: i2rs@ietf.org
Cc: 'Joel Halpern Direct' >; ops-dir@ietf.org; 'Fred Baker (fre=
d)' >
Subject: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call=
 for opinion

Hi all:


The draft-ietf-i2rs-architecture document has been approved as an RFC.  In =
the review, the OPS-DIR review indicated that "ephemeral" meant more than "=
does not survive a reboot". They have asked the I2RS working group if repla=
cing "ephemeral" with non-persistent (across power on/off or reboot cycles)=
 would be a better choice.

What do you think - leave at it at "ephemeral" or change to "non-persistent=
 (across power on/off or reboot cycles) ? We will have a 1 week call on

This would mean every place that "ephemeral" is listed, the authors would r=
eplace with "non-persistent".  In the first instance, we will indicate "non=
-persistent (across power on/off or reboot cycles).



As the author, I think we are better to define ephemeral at the beginning a=
s "non-persistent (across power on /off or reboot).  Changing the definitio=
n at this point, I suspect will simply confuse people.

Sue Hares


--_000_cd52d88072c9481cb95b4c726b912f87XCHALN012ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











All –


 


While I am not actively involved in i2rs, I have bee=
n watching it from the beginning and will admit the group’s use of th=
e term “ephemeral” has always been confusing to me.  So fr=
om an “outsider’s” point of view:


 


While the dictionary will define “ephemeral=
221; as “short-lived,” in my 25+ years in networking it has=
 meant “constantly changing.”  I wouldn’t bother wit=
h the semantic, except there is nothing to stop an implementation from stor=
ing ephemeral
 state persistently, such that when a box or software module dies or restar=
ts, it can return to its last known state.  And in this way, I feel li=
ke term is actually being used technically incorrectly by i2rs.<=
/p>

 


I am not suggesting you change your proposed course =
of action, just pointing out what it looks like to someone who is not in th=
e i2rs weeds.


 


Steve


 


 





From: i2rs [mailto:i2rs-bounces@ietf.org] =
On Behalf Of
Fedyk, Don

Sent: Thursday, March 24, 2016 11:33 AM

To: Susan Hares <shares@ndzh.com>; i2rs@ietf.org

Cc: 'Joel Halpern Direct' <jmh.direct@joelhalpern.com>; ops-di=
r@ietf.org; Fred Baker (fred) <fred@cisco.com>

Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 t=
o 4/3) Call for opinion






 


Hi <=
/p>

 


Sue I like maintaining=
 the use of the term ephemeral and defining it as you indicated.  By d=
efining the time scope of reboot cycles etc. I think the use is clear. &nbs=
p;(I think if we used another term at this point
 we would have to similarly define that term too.) 


 


Cheers


Don =



 








From: i2rs [mailto:i2rs-bounces@ietf.org]
On Behalf Of Susan Hares

Sent: Thursday, March 24, 2016 1:02 PM

To: i2rs@ietf.org

Cc: 'Joel Halpern Direct' <jmh.direct@joelhalpern.com>;
ops-dir@ietf.org; 'Fred Baker (fred=
)' <fred@cisco.com>

Subject: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/=
3) Call for opinion






 


Hi all: 


 


<wg chair hat on> 


The draft-ietf-i2rs-architecture document has been a=
pproved as an RFC.  In the review, the OPS-DIR review indicated that &=
#8220;ephemeral” meant more than “does not survive a rebootR=
21;. They have asked the I2RS working group if replacing “ephemeral&#=
8221;
 with non-persistent (across power on/off or reboot cycles) would be a bett=
er choice. 



 


What do you think – leave at it at “ephe=
meral” or change to “non-persistent (across power on/off or reb=
oot cycles) ? We will have a 1 week call on



 


This would mean every place that “ephemeral=
221; is listed, the authors would replace with “non-persistent”=
.  In the first instance, we will indicate “non-persistent (acro=
ss power on/off or reboot cycles).


 


<wg chair hat off>  


 


As the author, I think we are better to define ephem=
eral at the beginning as “non-persistent (across power on /off or reb=
oot).  Changing the definition at this point, I suspect will simply co=
nfuse people.



 


Sue Hares


 








--_000_cd52d88072c9481cb95b4c726b912f87XCHALN012ciscocom_--


From nobody Thu Mar 24 17:14: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 D394F12D0B7; Thu, 24 Mar 2016 17:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level: 
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 oUoj0R7XXdgI; Thu, 24 Mar 2016 17:14:39 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 87EF112D0A2; Thu, 24 Mar 2016 17:14:39 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id DCFA41E838; Thu, 24 Mar 2016 20:18:29 -0400 (EDT)
Date: Thu, 24 Mar 2016 20:18:29 -0400
From: Jeffrey Haas 
To: "Joel M. Halpern" 
Message-ID: <20160325001829.GB2966@pfrc.org>
References: <20160317013624.18209.45055.idtracker@ietfa.amsl.com> <046601d17ff5$70c29350$5247b9f0$@ndzh.com> <56F3C73A.9090500@cisco.com> <56F3DAB3.5040607@joelhalpern.com> <56F3E598.3030708@cisco.com> <56F3E678.4080105@joelhalpern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56F3E678.4080105@joelhalpern.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: i2rs@ietf.org, mach.chen@huawei.com, draft-ietf-i2rs-architecture@ietf.org, i2rs-chairs@ietf.org, 'The IESG' , Benoit Claise , Susan Hares , Fred@cisco.com
Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (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: Fri, 25 Mar 2016 00:14:41 -0000

On Thu, Mar 24, 2016 at 09:07:04AM -0400, Joel M. Halpern wrote:
> Now I understand your confusion.
> Putting aside the abstract, I thought we were focused om task 1
> (from the charter) in writing.  I think we probably crept into task
> 2, resulting in a document which is confusing about its scope.

In general, we should avoid trying to say "we're re-using " too much in
the architecture draft.  As we've seen from the long (very long) discussions
on potential protocol tweaks to enable I2RS applications on existing IETF
protocols, we know this is tricky to bring to some sort of consensus.

Benoit, I think the other half of this challenge is in many cases we mention
other IETF technologies because they provide example components of things we
might be able to use.  By their example, we get a huge amount of semantic
help with what is covered, with the downfall of some amount of "you probably
don't want this component".  I think the advantages of drawing analogies to
existing techs outweighs the issues of saying "we *are* (re-)using this
technology".

Given the above, are there specific changes you'd recommend that allow us to
continue to get semantic leverage out of any references we have to existing
techs?

-- Jeff


From nobody Thu Mar 24 17:26: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 8069012D1DD; Thu, 24 Mar 2016 11:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.53
X-Spam-Level: 
X-Spam-Status: No, score=-114.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 aKe3K9hzf2Rg; Thu, 24 Mar 2016 11:59: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 B4F4112D19A; Thu, 24 Mar 2016 11:59:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14773; q=dns/txt; s=iport; t=1458845959; x=1460055559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SgYNRSU/RsXKEQsWWiYG69WnXcz3WpfA3LFDz20v4aA=; b=DGUT+9ogyqEb43QZkFGvDUz/v2bBi1JC4xVEcDHC9ixODanoenVkRsMv Rz4+leYHeVrXmlOgTm5G7PnnQgKAA3rFijnZQrauKUUNapThcfTDkRgCo QAZJEVrTY0s6+LWLrJfBjo0ZyNTLJd2kh2x3IC4KLsJWbqkBXMB4CV66O c=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAwCNOPRW/5JdJa1dgmdMU30GtV+Eb?= =?us-ascii?q?g6BcBcBCYVsAoE0OBQBAQEBAQEBZCeEQQEBAQMBAQEBGgZLCwULAgEIEgYnAwI?= =?us-ascii?q?CJwsUAw4CBA4FDogRCA6wRZBiAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEiBEIg?= =?us-ascii?q?kmEIEmCUyuCKwWXXgGDHYFmiQCPC48IAR4BQ4IwgTVsiFZ+AQEB?=
X-IronPort-AV: E=Sophos;i="5.24,386,1454976000";  d="asc'?scan'208,217";a="252488900"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2016 18:59:18 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u2OIxIdV006120 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Mar 2016 18:59:18 GMT
Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Mar 2016 13:59:17 -0500
Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Thu, 24 Mar 2016 13:59:17 -0500
From: "Fred Baker (fred)" 
To: Gunter Van De Velde 
Thread-Topic: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AQHRhfgWFE8b8G0o+kuMobFow5ULs59pRngA
Date: Thu, 24 Mar 2016 18:59:17 +0000
Message-ID: <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com>
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3124)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.28.158]
Content-Type: multipart/signed; boundary="Apple-Mail=_A8A17FDD-D2A3-436E-92B9-DE6C98E46590"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Thu, 24 Mar 2016 17:26:54 -0700
Cc: "i2rs@ietf.org" , "ops-dir@ietf.org" , Susan Hares , Joel Halpern Direct 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 18:59:22 -0000

--Apple-Mail=_A8A17FDD-D2A3-436E-92B9-DE6C98E46590
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F565422E-6D4F-48D5-B786-391D34716F31"


--Apple-Mail=_F565422E-6D4F-48D5-B786-391D34716F31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

My comment was a review comment, that the word was being used in a way =
that wasn't consistent with its dictionary definition (something with a =
short lifetime, quite irrespective of birth/death processes) or common =
usage (at least in my context). At this point, the draft has been sent =
to the RFC Editor, so to my mind this discussion is mostly moot. If in =
your other drafts you are pointing people to a glossary in the =
architecture document (which I imagine you already are) and the =
architecture document defines the term as you are using it, you have =
probably done enough.

> On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde =
 wrote:
>=20
> I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D,=
 although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn=E2=80=99t 100% reflect the =
Webster dictionary intended meaning.
>=20
> It is only about a year ago i started reading up on i2rs and =
discovered this particular terminology, and at the time a google search =
on this terminology was not very conclusive and resulted to some =
confusion.
> I understand very well the confusion at play here from non-native =
english speaker perspective.
>=20
> Adding text to explain the context in which the term Ephemeral is =
useful/advised. fwiw now that i am used to seeing =E2=80=98Ephemeral' as =
non-permanent config across reboot, i=E2=80=99m adapted its intended =
purpose=E2=80=A6
>=20
> Is the goal to explain the intended meaning in each draft/rfc =
mentioning it?
>=20
> Be well,
> G/
>=20
>> On 24 Mar 2016, at 18:02, Susan Hares > wrote:
>>=20
>> Hi all:
>>=20
>> 
>> The draft-ietf-i2rs-architecture document has been approved as an =
RFC.  In the review, the OPS-DIR review indicated that =E2=80=9Cephemeral=E2=
=80=9D meant more than =E2=80=9Cdoes not survive a reboot=E2=80=9D. They =
have asked the I2RS working group if replacing =E2=80=9Cephemeral=E2=80=9D=
 with non-persistent (across power on/off or reboot cycles) would be a =
better choice.
>>=20
>> What do you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D =
or change to =E2=80=9Cnon-persistent (across power on/off or reboot =
cycles) ? We will have a 1 week call on
>>=20
>> This would mean every place that =E2=80=9Cephemeral=E2=80=9D is =
listed, the authors would replace with =E2=80=9Cnon-persistent=E2=80=9D. =
 In the first instance, we will indicate =E2=80=9Cnon-persistent (across =
power on/off or reboot cycles).
>>=20
>> 
>>=20
>> As the author, I think we are better to define ephemeral at the =
beginning as =E2=80=9Cnon-persistent (across power on /off or reboot).  =
Changing the definition at this point, I suspect will simply confuse =
people.
>>=20
>> Sue Hares
>>=20
>> _______________________________________________
>> OPS-DIR mailing list
>> OPS-DIR@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ops-dir =

> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir


--Apple-Mail=_F565422E-6D4F-48D5-B786-391D34716F31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

My comment was a review comment, that the word was being used =
in a way that wasn't consistent with its dictionary definition =
(something with a short lifetime, quite irrespective of birth/death =
processes) or common usage (at least in my context). At this point, the =
draft has been sent to the RFC Editor, so to my mind this discussion is =
mostly moot. If in your other drafts you are pointing people to a =
glossary in the architecture document (which I imagine you already are) =
and the architecture document defines the term as you are using it, you =
have probably done enough.

On Mar 24, 2016, at 11:07 AM, =
Gunter Van De Velde <guntervandeveldecc@icloud.com> wrote:



I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=
=80=9D, although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn=E2=80=99t 100% reflect the =
Webster dictionary intended meaning.

It is only about a year ago i started =
reading up on i2rs and discovered this particular terminology, and at =
the time a google search on this terminology was not very conclusive and =
resulted to some confusion. 
I understand very =
well the confusion at play here from non-native english speaker =
perspective.

Adding text to explain the context in which the term =
Ephemeral is useful/advised. fwiw now that i am used to seeing =
=E2=80=98Ephemeral' as non-permanent config across reboot, i=E2=80=99m =
adapted its intended purpose=E2=80=A6 

Is the goal to explain the intended =
meaning in each draft/rfc mentioning it?

Be well,
G/
On 24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> =
wrote:

Hi all: 
 
<wg =
chair hat on> 
The =
draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =E2=80=9Cephemeral=E2=80=9D=
 meant more than =E2=80=9Cdoes not survive a reboot=E2=80=9D. They have =
asked the I2RS working group if replacing =E2=80=9Cephemeral=E2=80=9D =
with non-persistent (across power on/off or reboot cycles) would be a =
better choice.  
 
What do =
you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D or change =
to =E2=80=9Cnon-persistent (across power on/off or reboot cycles) ? We =
will have a 1 week call on 
 
This =
would mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, the =
authors would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In =
the first instance, we will indicate =E2=80=9Cnon-persistent (across =
power on/off or reboot cycles).
 
<wg chair hat off>  
 
As the =
author, I think we are better to define ephemeral at the beginning as =
=E2=80=9Cnon-persistent (across power on /off or reboot).  Changing =
the definition at this point, I suspect will simply confuse people. 
 
Sue =
Hares
 
_______________________________________________
OPS-DIR mailing =
list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

=

--Apple-Mail=_F565422E-6D4F-48D5-B786-391D34716F31--

--Apple-Mail=_A8A17FDD-D2A3-436E-92B9-DE6C98E46590
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIVAwUBVvQ5EkayAOS/EQ8MAQKaZhAAhh7IWk0hwJfPmd+3/8JCnQYTZ1p4WIOR
UWuARp5Qrf4yriMbd6VQCRbjyDbz/f21Qcpz8s315n/JsFY4zsaYQxjLOsqy8ORH
KA2E+LLs8ETSCffeQPtd/VLhIiJOmWSCMu5EjGVdejr2LOevreZId+lYlE1QIxh7
iAayEcEk4Hr5sb6aHlhRVzIl7LceIcUVGwwMbiZwZUeY5hKicWNy4GXD4X7RIhG2
OddqH0VXWr/GhyagZuMiAFCiWklLx3krx5zhBphFeRiSJGIDsQ2+lbwHi2e522ot
mTM7bmUfZrzQmPs9fkIwIJzxqBuidaUONfpugxu3UxkOJyd4E7v7UiHTlBkdstpT
z2LFAYxbfj/e3DaXueWYWqAA7IEO64PDbz0QY1GQmRNuNq4a1O+af3iFaaPzmlQm
EJV7+XwfBgk1s6/Dq/SdzqGXyhH+PXAlVqmYhOdZDD9w4wtr9QOh1iU6E5IUC5+d
Hj0DjxOEO3qK9dj0BqbGGnzDywwOyXN91GJMGUt4cFjrgf7f1tgK5eildXuNmu1r
kyVUszfau8Kw+IGDZEhlOjNIZiMgaA4+yIuy3y28pPDoFRKEzoBYDasIfcyLsS4z
JNPtc7b/XG1NPThdmI1duzbeoVP1XRAMmD2g8lX2kKTiYysmIZbDtONOeZXjK0B/
M0aYVBygSRg=
=ENYy
-----END PGP SIGNATURE-----

--Apple-Mail=_A8A17FDD-D2A3-436E-92B9-DE6C98E46590--


From nobody Thu Mar 24 17:27: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 0056912DA72; Thu, 24 Mar 2016 12:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ACGMF6bbBb2o; Thu, 24 Mar 2016 12:38:35 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 69FEB12D849; Thu, 24 Mar 2016 12:38:35 -0700 (PDT)
Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 54B32120B04; Thu, 24 Mar 2016 15:42:29 -0400 (EDT)
Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 5269C405C1F; Thu, 24 Mar 2016 15:37:15 -0400 (EDT)
Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Thu, 24 Mar 2016 15:37:15 -0400
From: "MORTON, ALFRED C (AL)" 
To: "Fred Baker (fred)" , Gunter Van De Velde 
Date: Thu, 24 Mar 2016 15:37:14 -0400
Thread-Topic: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AQHRhfgWFE8b8G0o+kuMobFow5ULs59pRngA//+xPqU=
Message-ID: <4AF73AA205019A4C8A1DDD32C034631D445ACBE717@NJFPSRVEXG0.research.att.com>
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com> , <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com>
In-Reply-To: <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D445ACBE717NJFPSRVEXG0re_"
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Thu, 24 Mar 2016 17:26:54 -0700
Cc: "i2rs@ietf.org" , "ops-dir@ietf.org" , Joel Halpern Direct 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 19:38:38 -0000

--_000_4AF73AA205019A4C8A1DDD32C034631D445ACBE717NJFPSRVEXG0re_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I agree Fred, i2rs folks seem willing to carry the baggage of explaining a =
term
that some of us first-time readers felt was inconsistent with the dictionar=
y
definition.  They can continue explaining their choice in every future talk=
, etc.

With respect to documents outside the shadow of i2rs, authors should feel
free to use terms that best match the idea or concept. Further, I think we
have indicated a preference for the term "non-persistent" to describe this
concept in future OPS-DIR reviews and memos from OPS area.

regards, and thanks for raising this issue in your review,
Al

________________________________
From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Fred Baker (fred) [fr=
ed@cisco.com]
Sent: Thursday, March 24, 2016 2:59 PM
To: Gunter Van De Velde
Cc: i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/=
3) Call for opinion

My comment was a review comment, that the word was being used in a way that=
 wasn't consistent with its dictionary definition (something with a short l=
ifetime, quite irrespective of birth/death processes) or common usage (at l=
east in my context). At this point, the draft has been sent to the RFC Edit=
or, so to my mind this discussion is mostly moot. If in your other drafts y=
ou are pointing people to a glossary in the architecture document (which I =
imagine you already are) and the architecture document defines the term as =
you are using it, you have probably done enough.

On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde > wrote:

I am ok nowadays with using the terminology =93Ephemeral=94, although for a=
 non-natve speaker it is non-trivial exotic word, particular if the intende=
d usage doesn=92t 100% reflect the Webster dictionary intended meaning.

It is only about a year ago i started reading up on i2rs and discovered thi=
s particular terminology, and at the time a google search on this terminolo=
gy was not very conclusive and resulted to some confusion.
I understand very well the confusion at play here from non-native english s=
peaker perspective.

Adding text to explain the context in which the term Ephemeral is useful/ad=
vised. fwiw now that i am used to seeing =91Ephemeral' as non-permanent con=
fig across reboot, i=92m adapted its intended purpose=85

Is the goal to explain the intended meaning in each draft/rfc mentioning it=
?

Be well,
G/

On 24 Mar 2016, at 18:02, Susan Hares > wrote:

Hi all:


The draft-ietf-i2rs-architecture document has been approved as an RFC.  In =
the review, the OPS-DIR review indicated that =93ephemeral=94 meant more th=
an =93does not survive a reboot=94. They have asked the I2RS working group =
if replacing =93ephemeral=94 with non-persistent (across power on/off or re=
boot cycles) would be a better choice.

What do you think =96 leave at it at =93ephemeral=94 or change to =93non-pe=
rsistent (across power on/off or reboot cycles) ? We will have a 1 week cal=
l on

This would mean every place that =93ephemeral=94 is listed, the authors wou=
ld replace with =93non-persistent=94.  In the first instance, we will indic=
ate =93non-persistent (across power on/off or reboot cycles).



As the author, I think we are better to define ephemeral at the beginning a=
s =93non-persistent (across power on /off or reboot).  Changing the definit=
ion at this point, I suspect will simply confuse people.

Sue Hares

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir


--_000_4AF73AA205019A4C8A1DDD32C034631D445ACBE717NJFPSRVEXG0re_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable










I agree Fred, i2rs folks seem willing to carry the baggage of explaini=
ng a term


that some of us first-time readers felt was inco=
nsistent with the dictionary


definition.  They can continue explain=
ing their choice in every future talk, etc.


 


With respect to documents outside the shadow of =
i2rs, authors should feel


free to use terms that best match the idea or co=
ncept. Further, I think we



have indicated a preference for the term &q=
uot;non-persistent" to describe this


concept in fut=
ure OPS-DIR reviews and memos from OPS area.


 


regards, and thanks for raising this issue in yo=
ur review,


Al


=
 





From: OPS-DIR [op=
s-dir-bounces@ietf.org] On Behalf Of Fred Baker (fred) [fred@cisco.com]

Sent: Thursday, March 24, 2016 2:59 PM

To: Gunter Van De Velde

Cc: i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern Direct

Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/2=
4 to 4/3) Call for opinion








My comment was a review comment, that the word was being used in a way=
 that wasn't consistent with its dictionary definition (something with a sh=
ort lifetime, quite irrespective of birth/death processes) or common usage =
(at least in my context). At this
 point, the draft has been sent to the RFC Editor, so to my mind this discu=
ssion is mostly moot. If in your other drafts you are pointing people to a =
glossary in the architecture document (which I imagine you already are) and=
 the architecture document defines
 the term as you are using it, you have probably done enough.








On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde <guntervandeveldecc@icloud.com> wrot=
e:








I am ok nowadays with using the terminology =93Ephemeral=94, although =
for a non-natve speaker it is non-trivial exotic word, particular if the in=
tended usage doesn=92t 100% reflect the Webster dictionary intended meaning=
.







It is only about a year ago i started reading up on i2rs and discovere=
d this particular terminology, and at the time a google search on this term=
inology was not very conclusive and resulted to some confusion. 


I understand very well the confusion at play here from non-native engl=
ish speaker perspective.







Adding text to explain the context in which the term Ephemeral is usef=
ul/advised. fwiw now that i am used to seeing =91Ephemeral' as non-permanen=
t config across reboot, i=92m adapted its intended purpose=85 







Is the goal to explain the intended meaning in each draft/rfc mentioni=
ng it?







Be well,


G/








On 24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> wrote:









Hi all: 



 



<wg chair hat on> <=
/div>


The draft-ietf-i2rs-architecture document has been approved as an RFC. =
; In the review, the OPS-DIR review indicated that =93ephemeral=94 meant mo=
re than =93does not survive a reboot=94. They have asked the I2RS working g=
roup if replacing =93ephemeral=94 with non-persistent
 (across power on/off or reboot cycles) would be a better choice.  



 



What do you think =96 leave at it at =93ephemeral=94 or change to =93non-pe=
rsistent (across power on/off or reboot cycles) ? We will have a 1 week cal=
l on 



 



This would mean every place that =93ephemeral=94 is listed, the authors wou=
ld replace with =93non-persistent=94.  In the first instance, we will =
indicate =93non-persistent (across power on/off or reboot cycles).



 



<wg chair hat off>  



 



As the author, I think we are better to define ephemeral at the beginning a=
s =93non-persistent (across power on /off or reboot).  Changing the de=
finition at this point, I suspect will simply confuse people. 



 



Sue Hares



 



_______________________________________________

OPS-DIR mailing list

OPS-DIR@ietf.org

https://www.ietf.org/mailman/listinfo/ops-dir









_______________________________________________

OPS-DIR mailing list

OPS-DIR@ietf.org

https://www.ietf.org/mailman/listinfo/ops-dir


















--_000_4AF73AA205019A4C8A1DDD32C034631D445ACBE717NJFPSRVEXG0re_--


From nobody Thu Mar 24 17:27: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 05C9E12D0E4; Thu, 24 Mar 2016 16:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 r1TuXo9y0VKd; Thu, 24 Mar 2016 16:04:56 -0700 (PDT)
Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368B012D0A0; Thu, 24 Mar 2016 16:04:55 -0700 (PDT)
Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id Zz4s1s00X3vXPcr01z4tHH; Fri, 25 Mar 2016 00:04:54 +0100
To: "Ersue, Mehmet (Nokia - DE/Munich)" , EXT Susan Hares , "i2rs@ietf.org" 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  
From: "Bert Wijnen (IETF)" 
Message-ID: <56F47294.8000008@bwijnen.net>
Date: Fri, 25 Mar 2016 00:04:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Thu, 24 Mar 2016 17:26:54 -0700
Cc: 'Joel Halpern Direct' , "ops-dir@ietf.org" 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 24 Mar 2016 23:04:59 -0000

that would be fine by me.

Bert

On 24/03/16 18:30, Ersue, Mehmet (Nokia - DE/Munich) wrote:
>
> Let me say it a bit more clearly.
>
> I think Sue (the author) is right. We should define the term ephemeral at the beginning of the document and keep using it 
> throughout the document. It would be confusing for the people to change it to “non-persistent (across power on /off or reboot)”.
>
> Cheers,
> Mehmet
>
> *From:* OPS-DIR [mailto:ops-dir-bounces@ietf.org] *On Behalf Of *EXT Ersue, Mehmet (Nokia - DE/Munich)
> *Sent:* Thursday, March 24, 2016 6:06 PM
> *To:* EXT Susan Hares ; i2rs@ietf.org
> *Cc:* 'Joel Halpern Direct' ; ops-dir@ietf.org
> *Subject:* Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
>
> Agree.
>
> Cheers,
> Mehmet
>
> *From:* OPS-DIR [mailto:ops-dir-bounces@ietf.org] *On Behalf Of *EXT Susan Hares
> *Sent:* Thursday, March 24, 2016 6:02 PM
> *To:* i2rs@ietf.org 
> *Cc:* 'Joel Halpern Direct' >; ops-dir@ietf.org 
> 
> *Subject:* [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
>
> Hi all:
>
> 
>
> The draft-ietf-i2rs-architecture document has been approved as an RFC.  In the review, the OPS-DIR review indicated that 
> “ephemeral” meant more than “does not survive a reboot”. They have asked the I2RS working group if replacing “ephemeral” with 
> non-persistent (across power on/off or reboot cycles) would be a better choice.
>
> What do you think – leave at it at “ephemeral” or change to “non-persistent (across power on/off or reboot cycles) ? We will have 
> a 1 week call on
>
> This would mean every place that “ephemeral” is listed, the authors would replace with “non-persistent”.  In the first instance, 
> we will indicate “non-persistent (across power on/off or reboot cycles).
>
> 
>
> As the author, I think we are better to define ephemeral at the beginning as “non-persistent (across power on /off or reboot).  
> Changing the definition at this point, I suspect will simply confuse people.
>
> Sue Hares
>
>
>
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir


From nobody Thu Mar 24 18: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 5527A12D1D4 for ; Thu, 24 Mar 2016 18:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level: 
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 szrVTsQiA60u for ; Thu, 24 Mar 2016 18:03:58 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E799412D711 for ; Thu, 24 Mar 2016 18:03:57 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 585781E838; Thu, 24 Mar 2016 21:07:48 -0400 (EDT)
Date: Thu, 24 Mar 2016 21:07:48 -0400
From: Jeffrey Haas 
To: Susan Hares 
Message-ID: <20160325010748.GA19701@pfrc.org>
References: <01aa01d18052$788dd650$69a982f0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01aa01d18052$788dd650$69a982f0$@ndzh.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: i2rs@ietf.org, 'Daniel Migault' , "'Joel M. Halpern'" , 'Alia Atlas' 
Subject: Re: [i2rs] 2 week WG last call on draft-ietf-i2rs-security-environment-reqs - WG LC 3/17 to 4/7
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, 25 Mar 2016 01:04:00 -0000

On Thu, Mar 17, 2016 at 09:39:45AM -0400, Susan Hares wrote:
> We have not received any input on the
> draft-ietf-i2rs-security-environment-reqs document.  The security
> environments is part of the package of requirements, the WG chairs wish to
> send to the IESG.  
> 
> Please take time to review  this document prior to IETF, and send comments
> to the list including whether it is ready for publication. 

I have reviewed draft-ietf-i2rs-protocol-security-requirements-03.  It
addresses the comments formerly given as part of my shepherd review.

(The shepherd report is here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/shepherdwriteup/)

I noted in my review of -03 that there are a few spelling nits that should
be addressed before a request for publication.  Russ White, however, did a
much more thorough review than I did and in two messages recently to the
list gave some suggested edits:

https://mailarchive.ietf.org/arch/msg/i2rs/4ES9UUPEUQ4kSAnL7-riShMJee8
https://mailarchive.ietf.org/arch/msg/i2rs/P6QZNAidn5Azye1dNAOTtxt_BuA

I would suggest to the authors to do a quick update and once these edits are
complete we can send the document to the IESG.

The pending edits do not impact my prior shepherd report.

-- Jeff


From nobody Thu Mar 24 18:05: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 6A7D212D096 for ; Thu, 24 Mar 2016 18:05:15 -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 pmwfb0QOpIoN for ; Thu, 24 Mar 2016 18:05:12 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D23A12D989 for ; Thu, 24 Mar 2016 18:05:12 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id o73so46632825lfe.0 for ; Thu, 24 Mar 2016 18:05:12 -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=WTTnRAwY3vkQIQHRPPHXN9Ytpd1002fyaeuCx3srt6w=; b=WazRjW6H/HQjjHuFiQfrz0mklFGQ89IE8H139Z5yERvQE+ZfBHfBTfznL7i/iFuPlr neWLG3QWl4oS0s5MsZ/WYpzsjczBQO78hYqdwYRYjhXvJeiL5Vw3i5q3ZxxukSH9wZHS m9gKQKMZz+seEZCEw4Vj1E9YL3/uNmC/Fbe0ezupZCWejdRsndM8BqKs8RQuwRKLpf8E SGClQON7wkexSDd/eXcFeAIgJrS8EJ8QVrVlNepITZgtBc1l/Rr38WYoxytWFATBB0fj yRcwb5KMUCmf/Y1h2i16AlDIPnetBE8RXhYacxKNxS8LNlYKu7195QUHvPDzj761aRuf lwqw==
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=WTTnRAwY3vkQIQHRPPHXN9Ytpd1002fyaeuCx3srt6w=; b=dbgLKAxeXA0Yjn17OkEEgzCPQ9GIbDzSszBueEPhmNPi5Ast8gsr7lsFZRKBKVatYe yXctfvcX0eKV3UwY5Wph+dKg6XTFIpQ+DMcyY9xiGueteSaL9yCVPwyeaiF2jBWCbcSM 79poc3FJ487rZNGnr3/ZKADXp4uH9BwjFebsDykyX8AxHasify1c877ahkAEmw7JU2tq VnMsBZZV5zXdeV9UQKsBMpylyy42JIYss65JAWn6tNM85R2HI0IProDcuUTN0TMHrHvp 88LuQLS+dsffmutGe26Z215tzVeqpfLFTrStEjTZBT6btn/N7DKybV/5Tnn32lERUh4y WL7A==
X-Gm-Message-State: AD7BkJL4bvjnHl/H/tlwKFb1K/zvfw9Ntm5Udkl2rDDmSRmrAwkvCTherzzcEPFnF7+UwQIyq+QGMInsbQXBvw==
MIME-Version: 1.0
X-Received: by 10.25.30.73 with SMTP id e70mr4700130lfe.13.1458867910476; Thu, 24 Mar 2016 18:05:10 -0700 (PDT)
Received: by 10.112.135.97 with HTTP; Thu, 24 Mar 2016 18:05:10 -0700 (PDT)
In-Reply-To: <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com>
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com>
Date: Thu, 24 Mar 2016 18:05:10 -0700
Message-ID: 
From: Andy Bierman 
To: "Fred Baker (fred)" 
Content-Type: multipart/alternative; boundary=001a114027589419e6052ed5276b
Archived-At: 
Cc: Joel Halpern Direct , Gunter Van De Velde , "ops-dir@ietf.org" , Susan Hares , "i2rs@ietf.org" 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 25 Mar 2016 01:05:15 -0000

--001a114027589419e6052ed5276b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 24, 2016 at 11:59 AM, Fred Baker (fred)  wrote:

> My comment was a review comment, that the word was being used in a way
> that wasn't consistent with its dictionary definition (something with a
> short lifetime, quite irrespective of birth/death processes) or common
> usage (at least in my context). At this point, the draft has been sent to
> the RFC Editor, so to my mind this discussion is mostly moot. If in your
> other drafts you are pointing people to a glossary in the architecture
> document (which I imagine you already are) and the architecture document
> defines the term as you are using it, you have probably done enough.
>
>

I never liked this term in I2RS, mostly because I keep misspelling it ;-)

The thing about the ephemeral datastore that is interesting is that it
overrides the local running datastore. But I am not suggesting a name chang=
e
at this late date.



Andy


On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde <
> guntervandeveldecc@icloud.com> wrote:
>
> I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D, =
although for a
> non-natve speaker it is non-trivial exotic word, particular if the intend=
ed
> usage doesn=E2=80=99t 100% reflect the Webster dictionary intended meanin=
g.
>
> It is only about a year ago i started reading up on i2rs and discovered
> this particular terminology, and at the time a google search on this
> terminology was not very conclusive and resulted to some confusion.
> I understand very well the confusion at play here from non-native english
> speaker perspective.
>
> Adding text to explain the context in which the term Ephemeral is
> useful/advised. fwiw now that i am used to seeing =E2=80=98Ephemeral' as
> non-permanent config across reboot, i=E2=80=99m adapted its intended purp=
ose=E2=80=A6
>
> Is the goal to explain the intended meaning in each draft/rfc mentioning
> it?
>
> Be well,
> G/
>
> On 24 Mar 2016, at 18:02, Susan Hares  wrote:
>
> Hi all:
>
> 
> The draft-ietf-i2rs-architecture document has been approved as an RFC.  I=
n
> the review, the OPS-DIR review indicated that =E2=80=9Cephemeral=E2=80=9D=
 meant more than
> =E2=80=9Cdoes not survive a reboot=E2=80=9D. They have asked the I2RS wor=
king group if
> replacing =E2=80=9Cephemeral=E2=80=9D with non-persistent (across power o=
n/off or reboot
> cycles) would be a better choice.
>
> What do you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D or=
 change to
> =E2=80=9Cnon-persistent (across power on/off or reboot cycles) ? We will =
have a 1
> week call on
>
> This would mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, t=
he authors would
> replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the first instance, we=
 will indicate
> =E2=80=9Cnon-persistent (across power on/off or reboot cycles).
>
> 
>
> As the author, I think we are better to define ephemeral at the beginning
> as =E2=80=9Cnon-persistent (across power on /off or reboot).  Changing th=
e
> definition at this point, I suspect will simply confuse people.
>
> Sue Hares
>
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
>
>
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
>
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
>

--001a114027589419e6052ed5276b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Mar 24, 2016 at 11:59 AM, Fred Baker (fred) &=
lt;fred@cisco.com&g=
t; wrote:
My comment was a review comment, that the word was being used i=
n a way that wasn't consistent with its dictionary definition (somethin=
g with a short lifetime, quite irrespective of birth/death processes) or co=
mmon usage (at least in my context). At this point, the draft has been sent=
 to the RFC Editor, so to my mind this discussion is mostly moot. If in you=
r other drafts you are pointing people to a glossary in the architecture do=
cument (which I imagine you already are) and the architecture document defi=
nes the term as you are using it, you have probably done enough.



I never liked thi=
s term in I2RS, mostly because I keep misspelling it ;-)

The thing about the ephemeral datastore that is interesting is that =
it
overrides the local running datastore. But I am not suggesting=
 a name change
at this late date.



Andy


On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde <=
;gunterv=
andeveldecc@icloud.com> wrote:



I am ok nowadays with using the te=
rminology =E2=80=9CEphemeral=E2=80=9D, although for a non-natve speaker it =
is non-trivial exotic word, particular if the intended usage doesn=E2=80=99=
t 100% reflect the Webster dictionary intended meaning.

It is only about a year ago i started reading up on i2rs and discover=
ed this particular terminology, and at the time a google search on this ter=
minology was not very conclusive and resulted to some confusion.=C2=A0
I understand very well the confusion at play here from non-native eng=
lish speaker perspective.

Adding text to explain t=
he context in which the term Ephemeral is useful/advised. fwiw now that i a=
m used to seeing =E2=80=98Ephemeral' as non-permanent config across reb=
oot, i=E2=80=99m adapted its intended purpose=E2=80=A6=C2=A0

=

Is the goal to explain the intended meaning in each draft/rfc me=
ntioning it?

Be well,
G/

<=
blockquote type=3D"cite">
On 24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> w=
rote:

Hi all:=C2=A0
=C2=A0
<wg chair hat on>=C2=
=A0
The draft-ietf-i2rs-architecture do=
cument has been approved as an RFC.=C2=A0 In the review, the OPS-DIR review=
 indicated that =E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes n=
ot survive a reboot=E2=80=9D. They have asked the I2RS working group if rep=
lacing =E2=80=9Cephemeral=E2=80=9D with non-persistent (across power on/off=
 or reboot cycles) would be a better choice.=C2=A0=C2=A0
=C2=A0
What do you thi=
nk =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D or change to =E2=80=
=9Cnon-persistent (across power on/off or reboot cycles) ? We will have a 1=
 week call on=C2=A0
=C2=A0=

This would mean every place that =E2=80=9Cephemeral=
=E2=80=9D is listed, the authors would replace with =E2=80=9Cnon-persistent=
=E2=80=9D.=C2=A0 In the first instance, we will indicate =E2=80=9Cnon-persi=
stent (across power on/off or reboot cycles).
=
=C2=A0
<wg chair hat off> =C2=A0<=
u>
=C2=A0
As the author, I =
think we are better to define ephemeral at the beginning as =E2=80=9Cnon-pe=
rsistent (across power on /off or reboot).=C2=A0 Changing the definition at=
 this point, I suspect will simply confuse people.=C2=A0
=C2=A0
Sue Hares
=C2=A0
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

_______________________________________________OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir<=
/a>


_______________________=
________________________

i2rs mailing list

i2rs@ietf.org

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





--001a114027589419e6052ed5276b--


From nobody Thu Mar 24 18:34: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 3CF6512D0FE; Thu, 24 Mar 2016 18:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level: 
X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 IKUA4o74jenf; Thu, 24 Mar 2016 18:34:05 -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 ED9EC12D13E; Thu, 24 Mar 2016 18:34:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2538; q=dns/txt; s=iport; t=1458869644; x=1460079244; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=DTw6Itd2Mz4VQF0CME+YTz6QZ4O/hjvFJYawxmTgNdQ=; b=C/pEbaR87tgHOvUVFdS8qLf+82IMZZ0Eu8qVWr+4E+kgyydoUsXETVrS 3TmqtprksZ0VET5BvXFPKehqZCkgDdXA9Sr3+dcKnuKgFNiND7Wh0cSm5 YTeOzba8qya7kKMxBC2uF5qAh0YNbpgM+agkwYHhBo+4FULpYE4aJgFRf 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQDilPRW/5JdJa1dgzRTfbpWAQ2Bc?= =?us-ascii?q?BcKhWwCgTY4FAEBAQEBAQFkJ4RBAQEBAwEBAQEaFQEFNgoBEAsRAQMBAQEJFgg?= =?us-ascii?q?HCQMCAQIBFR8DBggGAQwGAgEBiBsIDsEdAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QSGHoREhCCFcgEEl16OBIk3hVSPCh4BAUKCMIFRIDCJVAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,388,1454976000"; d="scan'208";a="253550093"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2016 01:34:03 +0000
Received: from [10.117.46.165] (rtp-jclarke-8914.cisco.com [10.117.46.165]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u2P1Y397020931; Fri, 25 Mar 2016 01:34:03 GMT
To: "Ersue, Mehmet (Nokia - DE/Munich)" , EXT Susan Hares , "i2rs@ietf.org" 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  
From: Joe Clarke 
Organization: Cisco Systems, Inc.
Message-ID: <56F4958B.4020101@cisco.com>
Date: Thu, 24 Mar 2016 21:34:03 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: 'Joel Halpern Direct' , "ops-dir@ietf.org" 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 25 Mar 2016 01:34:07 -0000

On 3/24/16 13:30, Ersue, Mehmet (Nokia - DE/Munich) wrote:
> Let me say it a bit more clearly.
>
> I think Sue (the author) is right. We should define the term ephemeral
> at the beginning of the document and keep using it throughout the
> document. It would be confusing for the people to change it to
> “non-persistent (across power on /off or reboot)”.

Agree with this.  I think this definition covers what we've meant by 
ephemeral, and explicitly stating it once is good.

Joe

>
> Cheers,
> Mehmet
>
> *From:* OPS-DIR [mailto:ops-dir-bounces@ietf.org] *On Behalf Of *EXT
> Ersue, Mehmet (Nokia - DE/Munich)
> *Sent:* Thursday, March 24, 2016 6:06 PM
> *To:* EXT Susan Hares ; i2rs@ietf.org
> *Cc:* 'Joel Halpern Direct' ; ops-dir@ietf.org
> *Subject:* Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24
> to 4/3) Call for opinion
>
> Agree.
>
> Cheers,
> Mehmet
>
> *From:* OPS-DIR [mailto:ops-dir-bounces@ietf.org] *On Behalf Of *EXT
> Susan Hares
> *Sent:* Thursday, March 24, 2016 6:02 PM
> *To:* i2rs@ietf.org 
> *Cc:* 'Joel Halpern Direct'  >; ops-dir@ietf.org
> 
> *Subject:* [OPS-DIR] Ephemeral - Should we use another word - (3/24 to
> 4/3) Call for opinion
>
> Hi all:
>
> 
>
> The draft-ietf-i2rs-architecture document has been approved as an RFC.
> In the review, the OPS-DIR review indicated that “ephemeral” meant more
> than “does not survive a reboot”. They have asked the I2RS working group
> if replacing “ephemeral” with non-persistent (across power on/off or
> reboot cycles) would be a better choice.
>
> What do you think – leave at it at “ephemeral” or change to
> “non-persistent (across power on/off or reboot cycles) ? We will have a
> 1 week call on
>
> This would mean every place that “ephemeral” is listed, the authors
> would replace with “non-persistent”.  In the first instance, we will
> indicate “non-persistent (across power on/off or reboot cycles).
>
> 
>
> As the author, I think we are better to define ephemeral at the
> beginning as “non-persistent (across power on /off or reboot).  Changing
> the definition at this point, I suspect will simply confuse people.
>
> Sue Hares
>
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>


From nobody Fri Mar 25 06:18: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 EEE3A12D832; Fri, 25 Mar 2016 06:18:52 -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 c3oxzXcMPEPL; Fri, 25 Mar 2016 06:18:50 -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 D3C3312D645; Fri, 25 Mar 2016 06:18:49 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; 
From: "Susan Hares" 
To: "'Fred Baker \(fred\)'" , "'Gunter Van De Velde'" 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com>
In-Reply-To: <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com>
Date: Fri, 25 Mar 2016 09:18:19 -0400
Message-ID: <009001d18698$cd08ec00$671ac400$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01D18677.45FA5940"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL1cmQL65XiP+Rc6iRVZO2xGznKbQGRYBXWAUlpc/6dC3ZbIA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: i2rs@ietf.org, ops-dir@ietf.org, 'Joel Halpern Direct' 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 25 Mar 2016 13:18:53 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0091_01D18677.45FA5940
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Fred:=20

=20

Thank you for the review, and your comments here.  I wished I=E2=80=99d =
asked about the word ephemeral earlier.=20

=20

Sue=20

=20

From: Fred Baker (fred) [mailto:fred@cisco.com]=20
Sent: Thursday, March 24, 2016 2:59 PM
To: Gunter Van De Velde
Cc: Susan Hares; i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to =
4/3) Call for opinion

=20

My comment was a review comment, that the word was being used in a way =
that wasn't consistent with its dictionary definition (something with a =
short lifetime, quite irrespective of birth/death processes) or common =
usage (at least in my context). At this point, the draft has been sent =
to the RFC Editor, so to my mind this discussion is mostly moot. If in =
your other drafts you are pointing people to a glossary in the =
architecture document (which I imagine you already are) and the =
architecture document defines the term as you are using it, you have =
probably done enough.

=20

On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde =
 wrote:

=20

I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D, =
although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn=E2=80=99t 100% reflect the =
Webster dictionary intended meaning.

=20

It is only about a year ago i started reading up on i2rs and discovered =
this particular terminology, and at the time a google search on this =
terminology was not very conclusive and resulted to some confusion.=20

I understand very well the confusion at play here from non-native =
english speaker perspective.

=20

Adding text to explain the context in which the term Ephemeral is =
useful/advised. fwiw now that i am used to seeing =E2=80=98Ephemeral' as =
non-permanent config across reboot, i=E2=80=99m adapted its intended =
purpose=E2=80=A6=20

=20

Is the goal to explain the intended meaning in each draft/rfc mentioning =
it?

=20

Be well,

G/

=20

On 24 Mar 2016, at 18:02, Susan Hares  wrote:

=20

Hi all:=20

=20

=20

The draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =
=E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes not survive a =
reboot=E2=80=9D. They have asked the I2RS working group if replacing =
=E2=80=9Cephemeral=E2=80=9D with non-persistent (across power on/off or =
reboot cycles) would be a better choice. =20

=20

What do you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D =
or change to =E2=80=9Cnon-persistent (across power on/off or reboot =
cycles) ? We will have a 1 week call on=20

=20

This would mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, =
the authors would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the =
first instance, we will indicate =E2=80=9Cnon-persistent (across power =
on/off or reboot cycles).

=20

 =20

=20

As the author, I think we are better to define ephemeral at the =
beginning as =E2=80=9Cnon-persistent (across power on /off or reboot).  =
Changing the definition at this point, I suspect will simply confuse =
people.=20

=20

Sue Hares

=20

_______________________________________________
OPS-DIR mailing list
  OPS-DIR@ietf.org
  =
https://www.ietf.org/mailman/listinfo/ops-dir

=20

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

=20


------=_NextPart_000_0091_01D18677.45FA5940
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Fred: 
 
Thank you for the review, and your comments here.=C2=A0 I wished =
I=E2=80=99d asked about the word ephemeral earlier. =

 
Sue 
 
From:=
 =
Fred Baker (fred) [mailto:fred@cisco.com] 
Sent: Thursday, =
March 24, 2016 2:59 PM
To: Gunter Van De Velde
Cc: =
Susan Hares; i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern =
Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use =
another word - (3/24 to 4/3) Call for =
opinion
 
My comment =
was a review comment, that the word was being used in a way that wasn't =
consistent with its dictionary definition (something with a short =
lifetime, quite irrespective of birth/death processes) or common usage =
(at least in my context). At this point, the draft has been sent to the =
RFC Editor, so to my mind this discussion is mostly moot. If in your =
other drafts you are pointing people to a glossary in the architecture =
document (which I imagine you already are) and the architecture document =
defines the term as you are using it, you have probably done =
enough.
 
On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde =
<guntervandeveldecc@icloud.c=
om> wrote:
 
I am ok nowadays with using the terminology =
=E2=80=9CEphemeral=E2=80=9D, although for a non-natve speaker it is =
non-trivial exotic word, particular if the intended usage =
doesn=E2=80=99t 100% reflect the Webster dictionary intended =
meaning.
 
It is only about a year ago i started reading up on =
i2rs and discovered this particular terminology, and at the time a =
google search on this terminology was not very conclusive and resulted =
to some confusion. 
I =
understand very well the confusion at play here from non-native english =
speaker perspective.
 
Adding text to explain the context in which the term =
Ephemeral is useful/advised. fwiw now that i am used to seeing =
=E2=80=98Ephemeral' as non-permanent config across reboot, i=E2=80=99m =
adapted its intended purpose=E2=80=A6 
 
Is the goal to explain the intended meaning in each =
draft/rfc mentioning it?
 
Be well,
G/
 
On 24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> =
wrote:
 
Hi =
all: 
 =

<wg =
chair hat on> 
The =
draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =
=E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes not survive a =
reboot=E2=80=9D. They have asked the I2RS working group if replacing =
=E2=80=9Cephemeral=E2=80=9D with non-persistent (across power on/off or =
reboot cycles) would be a better choice.  
 =

What do =
you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D or change =
to =E2=80=9Cnon-persistent (across power on/off or reboot cycles) ? We =
will have a 1 week call on 
 =

This would =
mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, the authors =
would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the first =
instance, we will indicate =E2=80=9Cnon-persistent (across power on/off =
or reboot cycles).
 =

<wg =
chair hat off>  
 =

As the =
author, I think we are better to define ephemeral at the beginning as =
=E2=80=9Cnon-persistent (across power on /off or reboot).  Changing =
the definition at this point, I suspect will simply confuse people. 
 =

Sue =
Hares
 =

__________=
_____________________________________
OPS-DIR mailing =
list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
 
_______________________________________________
OPS-=
DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/ops-dir
 

------=_NextPart_000_0091_01D18677.45FA5940--


From nobody Fri Mar 25 06:21: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 BB03012D607; Fri, 25 Mar 2016 06:21:28 -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 NbDgPQvDgHPO; Fri, 25 Mar 2016 06:21: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 051F712D7F3; Fri, 25 Mar 2016 06:21:25 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; 
From: "Susan Hares" 
To: "'MORTON, ALFRED C \(AL\)'" , "'Fred Baker \(fred\)'" , "'Gunter Van De Velde'" 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com> , <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <4AF73AA205019A4C8A1DDD32C034631D445ACBE717@NJFPSRVEXG0.research.att.com>
In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D445ACBE717@NJFPSRVEXG0.research.att.com>
Date: Fri, 25 Mar 2016 09:20:55 -0400
Message-ID: <00a001d18699$2a000e20$7e002a60$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01D18677.A2F30200"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL1cmQL65XiP+Rc6iRVZO2xGznKbQGRYBXWAUlpc/4CD0MmRJz6/O8A
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: i2rs@ietf.org, ops-dir@ietf.org, 'Joel Halpern Direct' 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 25 Mar 2016 13:21:28 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00A1_01D18677.A2F30200
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Al:

 

I appreciate your comments and Fred's comments.   In future documents, I
suspect I should get an early review from OPS-DIR on the terms.

 

Sue 

 

From: OPS-DIR [mailto:ops-dir-bounces@ietf.org] On Behalf Of MORTON, ALFRED
C (AL)
Sent: Thursday, March 24, 2016 3:37 PM
To: Fred Baker (fred); Gunter Van De Velde
Cc: i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to
4/3) Call for opinion

 

I agree Fred, i2rs folks seem willing to carry the baggage of explaining a
term

that some of us first-time readers felt was inconsistent with the dictionary

definition.  They can continue explaining their choice in every future talk,
etc.

 

With respect to documents outside the shadow of i2rs, authors should feel

free to use terms that best match the idea or concept. Further, I think we 

have indicated a preference for the term "non-persistent" to describe this

concept in future OPS-DIR reviews and memos from OPS area.

 

regards, and thanks for raising this issue in your review,

Al

 

  _____  

From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Fred Baker (fred)
[fred@cisco.com]
Sent: Thursday, March 24, 2016 2:59 PM
To: Gunter Van De Velde
Cc: i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to
4/3) Call for opinion

My comment was a review comment, that the word was being used in a way that
wasn't consistent with its dictionary definition (something with a short
lifetime, quite irrespective of birth/death processes) or common usage (at
least in my context). At this point, the draft has been sent to the RFC
Editor, so to my mind this discussion is mostly moot. If in your other
drafts you are pointing people to a glossary in the architecture document
(which I imagine you already are) and the architecture document defines the
term as you are using it, you have probably done enough. 

 

On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde
 wrote:

 

I am ok nowadays with using the terminology "Ephemeral", although for a
non-natve speaker it is non-trivial exotic word, particular if the intended
usage doesn't 100% reflect the Webster dictionary intended meaning.

 

It is only about a year ago i started reading up on i2rs and discovered this
particular terminology, and at the time a google search on this terminology
was not very conclusive and resulted to some confusion. 

I understand very well the confusion at play here from non-native english
speaker perspective.

 

Adding text to explain the context in which the term Ephemeral is
useful/advised. fwiw now that i am used to seeing 'Ephemeral' as
non-permanent config across reboot, i'm adapted its intended purpose. 

 

Is the goal to explain the intended meaning in each draft/rfc mentioning it?

 

Be well,

G/

 

On 24 Mar 2016, at 18:02, Susan Hares  wrote:

 

Hi all: 

 

 

The draft-ietf-i2rs-architecture document has been approved as an RFC.  In
the review, the OPS-DIR review indicated that "ephemeral" meant more than
"does not survive a reboot". They have asked the I2RS working group if
replacing "ephemeral" with non-persistent (across power on/off or reboot
cycles) would be a better choice.  

 

What do you think - leave at it at "ephemeral" or change to "non-persistent
(across power on/off or reboot cycles) ? We will have a 1 week call on 

 

This would mean every place that "ephemeral" is listed, the authors would
replace with "non-persistent".  In the first instance, we will indicate
"non-persistent (across power on/off or reboot cycles).

 

  

 

As the author, I think we are better to define ephemeral at the beginning as
"non-persistent (across power on /off or reboot).  Changing the definition
at this point, I suspect will simply confuse people. 

 

Sue Hares

 

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

 

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

 


------=_NextPart_000_00A1_01D18677.A2F30200
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Al:
 
I appreciate your comments and Fred’s comments.   In =
future documents, I suspect I should get an early review from OPS-DIR on =
the terms.
 
Sue 
 
From:=
 =
OPS-DIR [mailto:ops-dir-bounces@ietf.org] On Behalf Of MORTON, =
ALFRED C (AL)
Sent: Thursday, March 24, 2016 3:37 =
PM
To: Fred Baker (fred); Gunter Van De Velde
Cc: =
i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern Direct
Subject: =
Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) =
Call for opinion
 
=
I agree Fred, i2rs folks seem willing to carry the baggage of explaining =
a term
=
that some of us first-time readers felt was inconsistent with the =
dictionary
=
definition.  They can continue explaining their choice in =
every future talk, etc.
=
 
=
With respect to documents outside the shadow of i2rs, authors should =
feel
=
free to use terms that best match the idea or concept. Further, I think =
we 
=
have indicated a preference for the term "non-persistent" =
to describe this
=
concept in future OPS-DIR reviews and memos from OPS =
area.
=
 
=
regards, and thanks for raising this issue in your =
review,
=
Al
=
 
=

=
From:=
 OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of Fred Baker (fred) =
[fred@cisco.com]
Sent: Thursday, March 24, 2016 2:59 =
PM
To: Gunter Van De Velde
Cc: i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern =
Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use =
another word - (3/24 to 4/3) Call for =
opinion
=
My comment was a review comment, that the word was being used in a way =
that wasn't consistent with its dictionary definition (something with a =
short lifetime, quite irrespective of birth/death processes) or common =
usage (at least in my context). At this point, the draft has been sent =
to the RFC Editor, so to my mind this discussion is mostly moot. If in =
your other drafts you are pointing people to a glossary in the =
architecture document (which I imagine you already are) and the =
architecture document defines the term as you are using it, you have =
probably done enough. 
=
 
=
On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde <guntervandeveldecc@icloud.c=
om> wrote:
=
 
=
I am ok nowadays with using the terminology “Ephemeral”, =
although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn’t 100% reflect the Webster =
dictionary intended meaning.
=
 
=
It is only about a year ago i started reading up on i2rs and discovered =
this particular terminology, and at the time a google search on this =
terminology was not very conclusive and resulted to some =
confusion. 
=
I understand very well the confusion at play here from non-native =
english speaker perspective.
=
 
=
Adding text to explain the context in which the term Ephemeral is =
useful/advised. fwiw now that i am used to seeing ‘Ephemeral' as =
non-permanent config across reboot, i’m adapted its intended =
purpose… 
=
 
=
Is the goal to explain the intended meaning in each draft/rfc mentioning =
it?
=
 
=
Be well,
=
G/
=
 
=
On 24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> =
wrote:
=
 
Hi all: 
 
<wg chair hat on> 
The draft-ietf-i2rs-architecture document has been approved as an =
RFC.  In the review, the OPS-DIR review indicated that =
“ephemeral” meant more than “does not survive a =
reboot”. They have asked the I2RS working group if replacing =
“ephemeral” with non-persistent (across power on/off or =
reboot cycles) would be a better choice.  
 
What do you think – leave at it at “ephemeral” or =
change to “non-persistent (across power on/off or reboot cycles) ? =
We will have a 1 week call on 
 
This would mean every place that “ephemeral” is listed, the =
authors would replace with “non-persistent”.  In the =
first instance, we will indicate “non-persistent (across power =
on/off or reboot cycles).
 
<wg chair hat off>  
 
As the author, I think we are better to define ephemeral at the =
beginning as “non-persistent (across power on /off or =
reboot).  Changing the definition at this point, I suspect will =
simply confuse people. 
 
Sue Hares
 
=
_______________________________________________
OPS-DIR mailing =
list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir<=
/o:p>
=
 
=
_______________________________________________
OPS-DIR mailing =
list
OPS-DIR@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/ops-dir
<=
/div>
=
 

------=_NextPart_000_00A1_01D18677.A2F30200--


From nobody Fri Mar 25 06:25: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 874D412D69E for ; Fri, 25 Mar 2016 06:25:49 -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 osJv9JGaQnGX for ; Fri, 25 Mar 2016 06:25:48 -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 2348112D7F9 for ; Fri, 25 Mar 2016 06:25:48 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; 
From: "Susan Hares" 
To: "'Jeffrey Haas'" 
References: <01aa01d18052$788dd650$69a982f0$@ndzh.com> <20160325010748.GA19701@pfrc.org>
In-Reply-To: <20160325010748.GA19701@pfrc.org>
Date: Fri, 25 Mar 2016 09:25:15 -0400
Message-ID: <00c801d18699$c4c41c80$4e4c5580$@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: AQJf6qeVguc/EjogVBI9yJ6cJmZS7AEJBDNpnkUV5XA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: i2rs@ietf.org, 'Daniel Migault' , "'Joel M. Halpern'" , 'Alia Atlas' 
Subject: Re: [i2rs] 2 week WG last call on draft-ietf-i2rs-security-environment-reqs - WG LC 3/17 to 4/7
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, 25 Mar 2016 13:25:49 -0000

Jeff and Russ: 

Thank you for detailed "Nits".  We'll post another draft on 4/4/2016. 

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfrc.org] 
Sent: Thursday, March 24, 2016 9:08 PM
To: Susan Hares
Cc: i2rs@ietf.org; 'Daniel Migault'; 'Joel M. Halpern'; 'Alia Atlas'
Subject: Re: [i2rs] 2 week WG last call on
draft-ietf-i2rs-security-environment-reqs - WG LC 3/17 to 4/7

On Thu, Mar 17, 2016 at 09:39:45AM -0400, Susan Hares wrote:
> We have not received any input on the
> draft-ietf-i2rs-security-environment-reqs document.  The security 
> environments is part of the package of requirements, the WG chairs 
> wish to send to the IESG.
> 
> Please take time to review  this document prior to IETF, and send 
> comments to the list including whether it is ready for publication.

I have reviewed draft-ietf-i2rs-protocol-security-requirements-03.  It
addresses the comments formerly given as part of my shepherd review.

(The shepherd report is here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme
nts/shepherdwriteup/)

I noted in my review of -03 that there are a few spelling nits that should
be addressed before a request for publication.  Russ White, however, did a
much more thorough review than I did and in two messages recently to the
list gave some suggested edits:

https://mailarchive.ietf.org/arch/msg/i2rs/4ES9UUPEUQ4kSAnL7-riShMJee8
https://mailarchive.ietf.org/arch/msg/i2rs/P6QZNAidn5Azye1dNAOTtxt_BuA

I would suggest to the authors to do a quick update and once these edits are
complete we can send the document to the IESG.

The pending edits do not impact my prior shepherd report.

-- Jeff


From nobody Fri Mar 25 06:30: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 4909D12D971; Fri, 25 Mar 2016 06:30:06 -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 S7rEh-2mbW0l; Fri, 25 Mar 2016 06:30: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 0D08912D856; Fri, 25 Mar 2016 06:30:03 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; 
From: "Susan Hares" 
To: "'Steve Braaten \(sbraaten\)'" , "'Fedyk, Don'" , 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  
In-Reply-To: 
Date: Fri, 25 Mar 2016 09:29:31 -0400
Message-ID: <00ca01d1869a$5db9fa90$192defb0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01D18678.D6AB67D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL1cmQL65XiP+Rc6iRVZO2xGznKbQGv5Qn+AcjfpCSdBoYfYA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: 'Joel Halpern Direct' , ops-dir@ietf.org, "'Fred Baker \(fred\)'" 
Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 25 Mar 2016 13:30:06 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00CB_01D18678.D6AB67D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve:

 

Thank you for your comments.  It was useful to hear from people who are
coming into I2RS. 

 

Sue 

 

From: Steve Braaten (sbraaten) [mailto:sbraaten@cisco.com] 
Sent: Thursday, March 24, 2016 3:31 PM
To: Fedyk, Don; Susan Hares; i2rs@ietf.org
Cc: 'Joel Halpern Direct'; ops-dir@ietf.org; Fred Baker (fred)
Subject: RE: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3)
Call for opinion

 

All -

 

While I am not actively involved in i2rs, I have been watching it from the
beginning and will admit the group's use of the term "ephemeral" has always
been confusing to me.  So from an "outsider's" point of view:

 

While the dictionary will define "ephemeral" as "short-lived," in my 25+
years in networking it has meant "constantly changing."  I wouldn't bother
with the semantic, except there is nothing to stop an implementation from
storing ephemeral state persistently, such that when a box or software
module dies or restarts, it can return to its last known state.  And in this
way, I feel like term is actually being used technically incorrectly by
i2rs.

 

I am not suggesting you change your proposed course of action, just pointing
out what it looks like to someone who is not in the i2rs weeds.

 

Steve

 

 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Fedyk, Don
Sent: Thursday, March 24, 2016 11:33 AM
To: Susan Hares ; i2rs@ietf.org
Cc: 'Joel Halpern Direct' ; ops-dir@ietf.org;
Fred Baker (fred) 
Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3)
Call for opinion

 

Hi 

 

Sue I like maintaining the use of the term ephemeral and defining it as you
indicated.  By defining the time scope of reboot cycles etc. I think the use
is clear.  (I think if we used another term at this point we would have to
similarly define that term too.) 

 

Cheers

Don 

 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 24, 2016 1:02 PM
To: i2rs@ietf.org
Cc: 'Joel Halpern Direct' ; ops-dir@ietf.org;
'Fred Baker (fred)' 
Subject: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call
for opinion

 

Hi all: 

 

 

The draft-ietf-i2rs-architecture document has been approved as an RFC.  In
the review, the OPS-DIR review indicated that "ephemeral" meant more than
"does not survive a reboot". They have asked the I2RS working group if
replacing "ephemeral" with non-persistent (across power on/off or reboot
cycles) would be a better choice.  

 

What do you think - leave at it at "ephemeral" or change to "non-persistent
(across power on/off or reboot cycles) ? We will have a 1 week call on 

 

This would mean every place that "ephemeral" is listed, the authors would
replace with "non-persistent".  In the first instance, we will indicate
"non-persistent (across power on/off or reboot cycles).

 

  

 

As the author, I think we are better to define ephemeral at the beginning as
"non-persistent (across power on /off or reboot).  Changing the definition
at this point, I suspect will simply confuse people. 

 

Sue Hares

 


------=_NextPart_000_00CB_01D18678.D6AB67D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Steve:
 
Thank you for your =
comments.  It was useful to hear from people who are coming into =
I2RS. 
 
Sue =

 
From:=
 =
Steve Braaten (sbraaten) [mailto:sbraaten@cisco.com] 
Sent: =
Thursday, March 24, 2016 3:31 PM
To: Fedyk, Don; Susan Hares; =
i2rs@ietf.org
Cc: 'Joel Halpern Direct'; ops-dir@ietf.org; =
Fred Baker (fred)
Subject: RE: [i2rs] Ephemeral - Should we =
use another word - (3/24 to 4/3) Call for =
opinion
 
All =
–
 
While I am not actively involved in i2rs, I have been =
watching it from the beginning and will admit the group’s use of =
the term “ephemeral” has always been confusing to me.  =
So from an “outsider’s” point of =
view:
 
While the dictionary will define =
“ephemeral” as “short-lived,” in my 25+ years in =
networking it has meant “constantly changing.”  I =
wouldn’t bother with the semantic, except there is nothing to stop =
an implementation from storing ephemeral state persistently, such that =
when a box or software module dies or restarts, it can return to its =
last known state.  And in this way, I feel like term is actually =
being used technically incorrectly by i2rs.
 
I am not =
suggesting you change your proposed course of action, just pointing out =
what it looks like to someone who is not in the i2rs =
weeds.
 
Steve
 
 
From: i2rs [mailto:i2rs-bounces@ietf.org] =
On Behalf Of Fedyk, Don
Sent: Thursday, March 24, 2016 =
11:33 AM
To: Susan Hares <shares@ndzh.com>; i2rs@ietf.org
Cc: 'Joel =
Halpern Direct' <jmh.direct@joelhalpern.com=
>; ops-dir@ietf.org; Fred =
Baker (fred) <fred@cisco.com>
Subject: =
Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call =
for opinion
 
Hi 
 
Sue I like maintaining =
the use of the term ephemeral and defining it as you indicated.  By =
defining the time scope of reboot cycles etc. I think the use is clear. =
 (I think if we used another term at this point we would have to =
similarly define that term too.) 
 
Cheers
Don =

 
From: i2rs =
[mailto:i2rs-bounces@ietf.org] =
On Behalf Of Susan Hares
Sent: Thursday, March 24, 2016 =
1:02 PM
To: i2rs@ietf.org
Cc: 'Joel =
Halpern Direct' <jmh.direct@joelhalpern.com=
>; ops-dir@ietf.org; 'Fred =
Baker (fred)' <fred@cisco.com>
Subject: =
[i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for =
opinion
 
Hi all: =

 
<wg chair hat on> 
The draft-ietf-i2rs-architecture document has been =
approved as an RFC.  In the review, the OPS-DIR review indicated =
that “ephemeral” meant more than “does not survive a =
reboot”. They have asked the I2RS working group if replacing =
“ephemeral” with non-persistent (across power on/off or =
reboot cycles) would be a better choice.  
 
What do you =
think – leave at it at “ephemeral” or change to =
“non-persistent (across power on/off or reboot cycles) ? We will =
have a 1 week call on 
 
This would =
mean every place that “ephemeral” is listed, the authors =
would replace with “non-persistent”.  In the first =
instance, we will indicate “non-persistent (across power on/off or =
reboot cycles).
 
<wg chair =
hat off>  
 
As the =
author, I think we are better to define ephemeral at the beginning as =
“non-persistent (across power on /off or reboot).  Changing =
the definition at this point, I suspect will simply confuse people. =

 
Sue Hares
 

------=_NextPart_000_00CB_01D18678.D6AB67D0--


From nobody Fri Mar 25 07:02: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 413A812DA49; Fri, 25 Mar 2016 07:02:33 -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 8IA4WDsY3tMl; Fri, 25 Mar 2016 07:02: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 98EE412DA54; Fri, 25 Mar 2016 07:02:29 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; 
From: "Susan Hares" 
To: "'BRUNGARD, DEBORAH A'" , "'Fred Baker \(fred\)'" , "'Gunter Van De Velde'" 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com> 
In-Reply-To: 
Date: Fri, 25 Mar 2016 10:01:49 -0400
Message-ID: <013201d1869e$e46f7700$ad4e6500$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0133_01D1867D.5D63F180"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL1cmQL65XiP+Rc6iRVZO2xGznKbQGRYBXWAUlpc/4BuMMbcgGZxOsnnPDuOmA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: i2rs@ietf.org, ops-dir@ietf.org, 'Joel Halpern Direct' 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 25 Mar 2016 14:02:33 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0133_01D1867D.5D63F180
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Deborah:=20

=20

Section 2 is exactly the place I would put the definition of ephemeral.=20

=20

Sue=20

=20

From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]=20
Sent: Friday, March 25, 2016 9:50 AM
To: Susan Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
Cc: i2rs@ietf.org; ops-dir@ietf.org; 'Joel Halpern Direct'
Subject: RE: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - =
(3/24 to 4/3) Call for opinion

=20

Hi all,

=20

As Alia is a co-author, I was assigned as the responsible AD for this =
document. The document is not with the RFC Editor =E2=80=93 it=E2=80=99s =
been approved by the IESG with a revised ID needed to address comments =
raised by the IESG. And so the current discussion.

=20

I had also raised the concern on needing more clarity on the definition =
of ephemeral during my AD review. The authors added some information. =
That clearly was not enough. As the term is used multiple times in the =
document and is the basis for another draft on requirements =
(draft-ietf-i2rs-ephemeral-state) which refers extensively to the =
architecture document, I agree the authors need to add more definition. =
Fred has a good suggestion =E2=80=93 the term should be visible in a =
glossary section early in the document. It=E2=80=99s not currently =
included in Section 2=E2=80=99s Terminology =E2=80=93 Sue, how about =
adding it to that section?

=20

I think the authors know what is needed and thank everyone for the =
discussion and their time reviewing.

=20

Thanks,

Deborah

=20

=20

=20

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, March 25, 2016 9:18 AM
To: 'Fred Baker (fred)' ; 'Gunter Van De Velde' =

Cc: i2rs@ietf.org; ops-dir@ietf.org; 'Joel Halpern Direct' =

Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - =
(3/24 to 4/3) Call for opinion

=20

Fred:=20

=20

Thank you for the review, and your comments here.  I wished I=E2=80=99d =
asked about the word ephemeral earlier.=20

=20

Sue=20

=20

From: Fred Baker (fred) [mailto:fred@cisco.com]=20
Sent: Thursday, March 24, 2016 2:59 PM
To: Gunter Van De Velde
Cc: Susan Hares; i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to =
4/3) Call for opinion

=20

My comment was a review comment, that the word was being used in a way =
that wasn't consistent with its dictionary definition (something with a =
short lifetime, quite irrespective of birth/death processes) or common =
usage (at least in my context). At this point, the draft has been sent =
to the RFC Editor, so to my mind this discussion is mostly moot. If in =
your other drafts you are pointing people to a glossary in the =
architecture document (which I imagine you already are) and the =
architecture document defines the term as you are using it, you have =
probably done enough.

=20

On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde =
 wrote:

=20

I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D, =
although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn=E2=80=99t 100% reflect the =
Webster dictionary intended meaning.

=20

It is only about a year ago i started reading up on i2rs and discovered =
this particular terminology, and at the time a google search on this =
terminology was not very conclusive and resulted to some confusion.=20

I understand very well the confusion at play here from non-native =
english speaker perspective.

=20

Adding text to explain the context in which the term Ephemeral is =
useful/advised. fwiw now that i am used to seeing =E2=80=98Ephemeral' as =
non-permanent config across reboot, i=E2=80=99m adapted its intended =
purpose=E2=80=A6=20

=20

Is the goal to explain the intended meaning in each draft/rfc mentioning =
it?

=20

Be well,

G/

=20

On 24 Mar 2016, at 18:02, Susan Hares  wrote:

=20

Hi all:=20

=20

=20

The draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =
=E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes not survive a =
reboot=E2=80=9D. They have asked the I2RS working group if replacing =
=E2=80=9Cephemeral=E2=80=9D with non-persistent (across power on/off or =
reboot cycles) would be a better choice. =20

=20

What do you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D =
or change to =E2=80=9Cnon-persistent (across power on/off or reboot =
cycles) ? We will have a 1 week call on=20

=20

This would mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, =
the authors would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the =
first instance, we will indicate =E2=80=9Cnon-persistent (across power =
on/off or reboot cycles).

=20

 =20

=20

As the author, I think we are better to define ephemeral at the =
beginning as =E2=80=9Cnon-persistent (across power on /off or reboot).  =
Changing the definition at this point, I suspect will simply confuse =
people.=20

=20

Sue Hares

=20

_______________________________________________
OPS-DIR mailing list
  OPS-DIR@ietf.org
  =
https://www.ietf.org/mailman/listinfo/ops-dir

=20

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

=20


------=_NextPart_000_0133_01D1867D.5D63F180
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Deborah: 
 
Section 2 is exactly the place I would put the definition of =
ephemeral. 
 
Sue 
 
From:=
 =
BRUNGARD, DEBORAH A [mailto:db3546@att.com] 
Sent: Friday, =
March 25, 2016 9:50 AM
To: Susan Hares; 'Fred Baker (fred)'; =
'Gunter Van De Velde'
Cc: i2rs@ietf.org; ops-dir@ietf.org; =
'Joel Halpern Direct'
Subject: RE: [i2rs] [OPS-DIR] Ephemeral =
- Should we use another word - (3/24 to 4/3) Call for =
opinion
 
Hi all,
 
As Alia is a co-author, I was assigned as the responsible AD for this =
document. The document is not with the RFC Editor =E2=80=93 it=E2=80=99s =
been approved by the IESG with a revised ID needed to address comments =
raised by the IESG. And so the current =
discussion.
 
I had also raised the concern on needing more clarity on the =
definition of ephemeral during my AD review. The authors added some =
information. That clearly was not enough. As the term is used multiple =
times in the document and is the basis for another draft on requirements =
(draft-ietf-i2rs-ephemeral-state) which refers extensively to the =
architecture document, I agree the authors need to add more definition. =
Fred has a good suggestion =E2=80=93 the term should be visible in a =
glossary section early in the document. It=E2=80=99s not currently =
included in Section 2=E2=80=99s Terminology =E2=80=93 Sue, how about =
adding it to that section?
 
I think the authors know what is needed and thank everyone for the =
discussion and their time reviewing.
 
Thanks,
Deborah
 
 
 
From: i2rs [mailto:i2rs-bounces@ietf.org] =
On Behalf Of Susan Hares
Sent: Friday, March 25, 2016 =
9:18 AM
To: 'Fred Baker (fred)' <fred@cisco.com>; 'Gunter Van De =
Velde' <guntervandeveldecc@icloud.c=
om>
Cc: i2rs@ietf.org; ops-dir@ietf.org; 'Joel Halpern =
Direct' <jmh.direct@joelhalpern.com=
>
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use =
another word - (3/24 to 4/3) Call for =
opinion
 
Fred: 
 
Thank you for the review, and your comments here.  I wished =
I=E2=80=99d asked about the word ephemeral earlier. =

 
Sue 
 
From:=
 =
Fred Baker (fred) [mailto:fred@cisco.com] =

Sent: Thursday, March 24, 2016 2:59 PM
To: Gunter =
Van De Velde
Cc: Susan Hares; i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern =
Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use =
another word - (3/24 to 4/3) Call for =
opinion
 
My comment =
was a review comment, that the word was being used in a way that wasn't =
consistent with its dictionary definition (something with a short =
lifetime, quite irrespective of birth/death processes) or common usage =
(at least in my context). At this point, the draft has been sent to the =
RFC Editor, so to my mind this discussion is mostly moot. If in your =
other drafts you are pointing people to a glossary in the architecture =
document (which I imagine you already are) and the architecture document =
defines the term as you are using it, you have probably done =
enough.
 
On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde =
<guntervandeveldecc@icloud.c=
om> wrote:
 
I am ok nowadays with using the terminology =
=E2=80=9CEphemeral=E2=80=9D, although for a non-natve speaker it is =
non-trivial exotic word, particular if the intended usage =
doesn=E2=80=99t 100% reflect the Webster dictionary intended =
meaning.
 
It is only about a year ago i started reading up on =
i2rs and discovered this particular terminology, and at the time a =
google search on this terminology was not very conclusive and resulted =
to some confusion. 
I =
understand very well the confusion at play here from non-native english =
speaker perspective.
 
Adding text to explain the context in which the term =
Ephemeral is useful/advised. fwiw now that i am used to seeing =
=E2=80=98Ephemeral' as non-permanent config across reboot, i=E2=80=99m =
adapted its intended purpose=E2=80=A6 
 
Is the goal to explain the intended meaning in each =
draft/rfc mentioning it?
 
Be well,
G/
 
On 24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> =
wrote:
 
Hi =
all: 
 =

<wg =
chair hat on> 
The =
draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =
=E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes not survive a =
reboot=E2=80=9D. They have asked the I2RS working group if replacing =
=E2=80=9Cephemeral=E2=80=9D with non-persistent (across power on/off or =
reboot cycles) would be a better choice.  
 =

What do =
you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D or change =
to =E2=80=9Cnon-persistent (across power on/off or reboot cycles) ? We =
will have a 1 week call on 
 =

This would =
mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, the authors =
would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the first =
instance, we will indicate =E2=80=9Cnon-persistent (across power on/off =
or reboot cycles).
 =

<wg =
chair hat off>  
 =

As the =
author, I think we are better to define ephemeral at the beginning as =
=E2=80=9Cnon-persistent (across power on /off or reboot).  Changing =
the definition at this point, I suspect will simply confuse people. 
 =

Sue =
Hares
 =

__________=
_____________________________________
OPS-DIR mailing =
list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
 
_______________________________________________
OPS-=
DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/ops-dir
 

------=_NextPart_000_0133_01D1867D.5D63F180--


From nobody Fri Mar 25 07:16: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 9D27B12DA20; Fri, 25 Mar 2016 06:50: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 Jzvf8Pil26Gx; Fri, 25 Mar 2016 06:50:42 -0700 (PDT)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 8679112D9FE; Fri, 25 Mar 2016 06:50:42 -0700 (PDT)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u2PDoYgt042206; Fri, 25 Mar 2016 09:50:38 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 21w04mgswq-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 25 Mar 2016 09:50:38 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2PDoaUA032101; Fri, 25 Mar 2016 09:50:38 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2PDoMWT031725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Mar 2016 09:50:27 -0400
Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 25 Mar 2016 13:50:12 GMT
Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.49]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0248.002; Fri, 25 Mar 2016 09:50:11 -0400
From: "BRUNGARD, DEBORAH A" 
To: Susan Hares , "'Fred Baker (fred)'" , "'Gunter Van De Velde'" 
Thread-Topic: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AQHRhi0Ns8Z1cJ+0T0yL+1tg5U4+e59qaEyA///AMHA=
Date: Fri, 25 Mar 2016 13:50:11 +0000
Message-ID: 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com>
In-Reply-To: <009001d18698$cd08ec00$671ac400$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.10.206.169]
Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C85285AB2CMISOUT7MSGUSRDE_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-25_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603250213
Archived-At: 
X-Mailman-Approved-At: Fri, 25 Mar 2016 07:16:53 -0700
Cc: "i2rs@ietf.org" , "ops-dir@ietf.org" , 'Joel Halpern Direct' 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 25 Mar 2016 13:50:45 -0000

--_000_F64C10EAA68C8044B33656FA214632C85285AB2CMISOUT7MSGUSRDE_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQpBcyBBbGlhIGlzIGEgY28tYXV0aG9yLCBJIHdhcyBhc3NpZ25lZCBhcyB0aGUg
cmVzcG9uc2libGUgQUQgZm9yIHRoaXMgZG9jdW1lbnQuIFRoZSBkb2N1bWVudCBpcyBub3Qgd2l0
aCB0aGUgUkZDIEVkaXRvciDigJMgaXTigJlzIGJlZW4gYXBwcm92ZWQgYnkgdGhlIElFU0cgd2l0
aCBhIHJldmlzZWQgSUQgbmVlZGVkIHRvIGFkZHJlc3MgY29tbWVudHMgcmFpc2VkIGJ5IHRoZSBJ
RVNHLiBBbmQgc28gdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbi4NCg0KSSBoYWQgYWxzbyByYWlzZWQg
dGhlIGNvbmNlcm4gb24gbmVlZGluZyBtb3JlIGNsYXJpdHkgb24gdGhlIGRlZmluaXRpb24gb2Yg
ZXBoZW1lcmFsIGR1cmluZyBteSBBRCByZXZpZXcuIFRoZSBhdXRob3JzIGFkZGVkIHNvbWUgaW5m
b3JtYXRpb24uIFRoYXQgY2xlYXJseSB3YXMgbm90IGVub3VnaC4gQXMgdGhlIHRlcm0gaXMgdXNl
ZCBtdWx0aXBsZSB0aW1lcyBpbiB0aGUgZG9jdW1lbnQgYW5kIGlzIHRoZSBiYXNpcyBmb3IgYW5v
dGhlciBkcmFmdCBvbiByZXF1aXJlbWVudHMgKGRyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3Rh
dGUpIHdoaWNoIHJlZmVycyBleHRlbnNpdmVseSB0byB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50
LCBJIGFncmVlIHRoZSBhdXRob3JzIG5lZWQgdG8gYWRkIG1vcmUgZGVmaW5pdGlvbi4gRnJlZCBo
YXMgYSBnb29kIHN1Z2dlc3Rpb24g4oCTIHRoZSB0ZXJtIHNob3VsZCBiZSB2aXNpYmxlIGluIGEg
Z2xvc3Nhcnkgc2VjdGlvbiBlYXJseSBpbiB0aGUgZG9jdW1lbnQuIEl04oCZcyBub3QgY3VycmVu
dGx5IGluY2x1ZGVkIGluIFNlY3Rpb24gMuKAmXMgVGVybWlub2xvZ3kg4oCTIFN1ZSwgaG93IGFi
b3V0IGFkZGluZyBpdCB0byB0aGF0IHNlY3Rpb24/DQoNCkkgdGhpbmsgdGhlIGF1dGhvcnMga25v
dyB3aGF0IGlzIG5lZWRlZCBhbmQgdGhhbmsgZXZlcnlvbmUgZm9yIHRoZSBkaXNjdXNzaW9uIGFu
ZCB0aGVpciB0aW1lIHJldmlld2luZy4NCg0KVGhhbmtzLA0KRGVib3JhaA0KDQoNCg0KRnJvbTog
aTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1c2FuIEhh
cmVzDQpTZW50OiBGcmlkYXksIE1hcmNoIDI1LCAyMDE2IDk6MTggQU0NClRvOiAnRnJlZCBCYWtl
ciAoZnJlZCknIDxmcmVkQGNpc2NvLmNvbT47ICdHdW50ZXIgVmFuIERlIFZlbGRlJyA8Z3VudGVy
dmFuZGV2ZWxkZWNjQGljbG91ZC5jb20+DQpDYzogaTJyc0BpZXRmLm9yZzsgb3BzLWRpckBpZXRm
Lm9yZzsgJ0pvZWwgSGFscGVybiBEaXJlY3QnIDxqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4N
ClN1YmplY3Q6IFJlOiBbaTJyc10gW09QUy1ESVJdIEVwaGVtZXJhbCAtIFNob3VsZCB3ZSB1c2Ug
YW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uDQoNCkZyZWQ6DQoN
ClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldywgYW5kIHlvdXIgY29tbWVudHMgaGVyZS4gIEkgd2lz
aGVkIEnigJlkIGFza2VkIGFib3V0IHRoZSB3b3JkIGVwaGVtZXJhbCBlYXJsaWVyLg0KDQpTdWUN
Cg0KRnJvbTogRnJlZCBCYWtlciAoZnJlZCkgW21haWx0bzpmcmVkQGNpc2NvLmNvbV0NClNlbnQ6
IFRodXJzZGF5LCBNYXJjaCAyNCwgMjAxNiAyOjU5IFBNDQpUbzogR3VudGVyIFZhbiBEZSBWZWxk
ZQ0KQ2M6IFN1c2FuIEhhcmVzOyBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsg
b3BzLWRpckBpZXRmLm9yZzxtYWlsdG86b3BzLWRpckBpZXRmLm9yZz47IEpvZWwgSGFscGVybiBE
aXJlY3QNClN1YmplY3Q6IFJlOiBbT1BTLURJUl0gRXBoZW1lcmFsIC0gU2hvdWxkIHdlIHVzZSBh
bm90aGVyIHdvcmQgLSAoMy8yNCB0byA0LzMpIENhbGwgZm9yIG9waW5pb24NCg0KTXkgY29tbWVu
dCB3YXMgYSByZXZpZXcgY29tbWVudCwgdGhhdCB0aGUgd29yZCB3YXMgYmVpbmcgdXNlZCBpbiBh
IHdheSB0aGF0IHdhc24ndCBjb25zaXN0ZW50IHdpdGggaXRzIGRpY3Rpb25hcnkgZGVmaW5pdGlv
biAoc29tZXRoaW5nIHdpdGggYSBzaG9ydCBsaWZldGltZSwgcXVpdGUgaXJyZXNwZWN0aXZlIG9m
IGJpcnRoL2RlYXRoIHByb2Nlc3Nlcykgb3IgY29tbW9uIHVzYWdlIChhdCBsZWFzdCBpbiBteSBj
b250ZXh0KS4gQXQgdGhpcyBwb2ludCwgdGhlIGRyYWZ0IGhhcyBiZWVuIHNlbnQgdG8gdGhlIFJG
QyBFZGl0b3IsIHNvIHRvIG15IG1pbmQgdGhpcyBkaXNjdXNzaW9uIGlzIG1vc3RseSBtb290LiBJ
ZiBpbiB5b3VyIG90aGVyIGRyYWZ0cyB5b3UgYXJlIHBvaW50aW5nIHBlb3BsZSB0byBhIGdsb3Nz
YXJ5IGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgKHdoaWNoIEkgaW1hZ2luZSB5b3UgYWxy
ZWFkeSBhcmUpIGFuZCB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGRlZmluZXMgdGhlIHRlcm0g
YXMgeW91IGFyZSB1c2luZyBpdCwgeW91IGhhdmUgcHJvYmFibHkgZG9uZSBlbm91Z2guDQoNCk9u
IE1hciAyNCwgMjAxNiwgYXQgMTE6MDcgQU0sIEd1bnRlciBWYW4gRGUgVmVsZGUgPGd1bnRlcnZh
bmRldmVsZGVjY0BpY2xvdWQuY29tPG1haWx0bzpndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNv
bT4+IHdyb3RlOg0KDQpJIGFtIG9rIG5vd2FkYXlzIHdpdGggdXNpbmcgdGhlIHRlcm1pbm9sb2d5
IOKAnEVwaGVtZXJhbOKAnSwgYWx0aG91Z2ggZm9yIGEgbm9uLW5hdHZlIHNwZWFrZXIgaXQgaXMg
bm9uLXRyaXZpYWwgZXhvdGljIHdvcmQsIHBhcnRpY3VsYXIgaWYgdGhlIGludGVuZGVkIHVzYWdl
IGRvZXNu4oCZdCAxMDAlIHJlZmxlY3QgdGhlIFdlYnN0ZXIgZGljdGlvbmFyeSBpbnRlbmRlZCBt
ZWFuaW5nLg0KDQpJdCBpcyBvbmx5IGFib3V0IGEgeWVhciBhZ28gaSBzdGFydGVkIHJlYWRpbmcg
dXAgb24gaTJycyBhbmQgZGlzY292ZXJlZCB0aGlzIHBhcnRpY3VsYXIgdGVybWlub2xvZ3ksIGFu
ZCBhdCB0aGUgdGltZSBhIGdvb2dsZSBzZWFyY2ggb24gdGhpcyB0ZXJtaW5vbG9neSB3YXMgbm90
IHZlcnkgY29uY2x1c2l2ZSBhbmQgcmVzdWx0ZWQgdG8gc29tZSBjb25mdXNpb24uDQpJIHVuZGVy
c3RhbmQgdmVyeSB3ZWxsIHRoZSBjb25mdXNpb24gYXQgcGxheSBoZXJlIGZyb20gbm9uLW5hdGl2
ZSBlbmdsaXNoIHNwZWFrZXIgcGVyc3BlY3RpdmUuDQoNCkFkZGluZyB0ZXh0IHRvIGV4cGxhaW4g
dGhlIGNvbnRleHQgaW4gd2hpY2ggdGhlIHRlcm0gRXBoZW1lcmFsIGlzIHVzZWZ1bC9hZHZpc2Vk
LiBmd2l3IG5vdyB0aGF0IGkgYW0gdXNlZCB0byBzZWVpbmcg4oCYRXBoZW1lcmFsJyBhcyBub24t
cGVybWFuZW50IGNvbmZpZyBhY3Jvc3MgcmVib290LCBp4oCZbSBhZGFwdGVkIGl0cyBpbnRlbmRl
ZCBwdXJwb3Nl4oCmDQoNCklzIHRoZSBnb2FsIHRvIGV4cGxhaW4gdGhlIGludGVuZGVkIG1lYW5p
bmcgaW4gZWFjaCBkcmFmdC9yZmMgbWVudGlvbmluZyBpdD8NCg0KQmUgd2VsbCwNCkcvDQoNCk9u
IDI0IE1hciAyMDE2LCBhdCAxODowMiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWls
dG86c2hhcmVzQG5kemguY29tPj4gd3JvdGU6DQoNCkhpIGFsbDoNCg0KPHdnIGNoYWlyIGhhdCBv
bj4NClRoZSBkcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGhhcyBiZWVuIGFw
cHJvdmVkIGFzIGFuIFJGQy4gIEluIHRoZSByZXZpZXcsIHRoZSBPUFMtRElSIHJldmlldyBpbmRp
Y2F0ZWQgdGhhdCDigJxlcGhlbWVyYWzigJ0gbWVhbnQgbW9yZSB0aGFuIOKAnGRvZXMgbm90IHN1
cnZpdmUgYSByZWJvb3TigJ0uIFRoZXkgaGF2ZSBhc2tlZCB0aGUgSTJSUyB3b3JraW5nIGdyb3Vw
IGlmIHJlcGxhY2luZyDigJxlcGhlbWVyYWzigJ0gd2l0aCBub24tcGVyc2lzdGVudCAoYWNyb3Nz
IHBvd2VyIG9uL29mZiBvciByZWJvb3QgY3ljbGVzKSB3b3VsZCBiZSBhIGJldHRlciBjaG9pY2Uu
DQoNCldoYXQgZG8geW91IHRoaW5rIOKAkyBsZWF2ZSBhdCBpdCBhdCDigJxlcGhlbWVyYWzigJ0g
b3IgY2hhbmdlIHRvIOKAnG5vbi1wZXJzaXN0ZW50IChhY3Jvc3MgcG93ZXIgb24vb2ZmIG9yIHJl
Ym9vdCBjeWNsZXMpID8gV2Ugd2lsbCBoYXZlIGEgMSB3ZWVrIGNhbGwgb24NCg0KVGhpcyB3b3Vs
ZCBtZWFuIGV2ZXJ5IHBsYWNlIHRoYXQg4oCcZXBoZW1lcmFs4oCdIGlzIGxpc3RlZCwgdGhlIGF1
dGhvcnMgd291bGQgcmVwbGFjZSB3aXRoIOKAnG5vbi1wZXJzaXN0ZW504oCdLiAgSW4gdGhlIGZp
cnN0IGluc3RhbmNlLCB3ZSB3aWxsIGluZGljYXRlIOKAnG5vbi1wZXJzaXN0ZW50IChhY3Jvc3Mg
cG93ZXIgb24vb2ZmIG9yIHJlYm9vdCBjeWNsZXMpLg0KDQo8d2cgY2hhaXIgaGF0IG9mZj4NCg0K
QXMgdGhlIGF1dGhvciwgSSB0aGluayB3ZSBhcmUgYmV0dGVyIHRvIGRlZmluZSBlcGhlbWVyYWwg
YXQgdGhlIGJlZ2lubmluZyBhcyDigJxub24tcGVyc2lzdGVudCAoYWNyb3NzIHBvd2VyIG9uIC9v
ZmYgb3IgcmVib290KS4gIENoYW5naW5nIHRoZSBkZWZpbml0aW9uIGF0IHRoaXMgcG9pbnQsIEkg
c3VzcGVjdCB3aWxsIHNpbXBseSBjb25mdXNlIHBlb3BsZS4NCg0KU3VlIEhhcmVzDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFMtRElSIG1haWxp
bmcgbGlzdA0KT1BTLURJUkBpZXRmLm9yZzxtYWlsdG86T1BTLURJUkBpZXRmLm9yZz4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzLWRpcg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT1BTLURJUiBtYWlsaW5nIGxpc3QN
Ck9QUy1ESVJAaWV0Zi5vcmc8bWFpbHRvOk9QUy1ESVJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wcy1kaXINCg0K

--_000_F64C10EAA68C8044B33656FA214632C85285AB2CMISOUT7MSGUSRDE_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ
cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBs
ZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG
NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs
eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6
ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h
cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6
V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k
aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp
dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48
L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMgQWxpYSBpcyBhIGNvLWF1dGhv
ciwgSSB3YXMgYXNzaWduZWQgYXMgdGhlIHJlc3BvbnNpYmxlIEFEIGZvciB0aGlzIGRvY3VtZW50
LiBUaGUgZG9jdW1lbnQgaXMgbm90IHdpdGggdGhlIFJGQyBFZGl0b3Ig4oCTIGl04oCZcyBiZWVu
IGFwcHJvdmVkIGJ5IHRoZSBJRVNHIHdpdGgNCiBhIHJldmlzZWQgSUQgbmVlZGVkIHRvIGFkZHJl
c3MgY29tbWVudHMgcmFpc2VkIGJ5IHRoZSBJRVNHLiBBbmQgc28gdGhlIGN1cnJlbnQgZGlzY3Vz
c2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgaGFkIGFs
c28gcmFpc2VkIHRoZSBjb25jZXJuIG9uIG5lZWRpbmcgbW9yZSBjbGFyaXR5IG9uIHRoZSBkZWZp
bml0aW9uIG9mIGVwaGVtZXJhbCBkdXJpbmcgbXkgQUQgcmV2aWV3LiBUaGUgYXV0aG9ycyBhZGRl
ZCBzb21lIGluZm9ybWF0aW9uLiBUaGF0IGNsZWFybHkgd2FzDQogbm90IGVub3VnaC4gQXMgdGhl
IHRlcm0gaXMgdXNlZCBtdWx0aXBsZSB0aW1lcyBpbiB0aGUgZG9jdW1lbnQgYW5kIGlzIHRoZSBi
YXNpcyBmb3IgYW5vdGhlciBkcmFmdCBvbiByZXF1aXJlbWVudHMgKGRyYWZ0LWlldGYtaTJycy1l
cGhlbWVyYWwtc3RhdGUpIHdoaWNoIHJlZmVycyBleHRlbnNpdmVseSB0byB0aGUgYXJjaGl0ZWN0
dXJlIGRvY3VtZW50LCBJIGFncmVlIHRoZSBhdXRob3JzIG5lZWQgdG8gYWRkIG1vcmUgZGVmaW5p
dGlvbi4gRnJlZA0KIGhhcyBhIGdvb2Qgc3VnZ2VzdGlvbiDigJMgdGhlIHRlcm0gc2hvdWxkIGJl
IHZpc2libGUgaW4gYSBnbG9zc2FyeSBzZWN0aW9uIGVhcmx5IGluIHRoZSBkb2N1bWVudC4gSXTi
gJlzIG5vdCBjdXJyZW50bHkgaW5jbHVkZWQgaW4gU2VjdGlvbiAy4oCZcyBUZXJtaW5vbG9neSDi
gJMgU3VlLCBob3cgYWJvdXQgYWRkaW5nIGl0IHRvIHRoYXQgc2VjdGlvbj88bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhlIGF1dGhvcnMga25vdyB3
aGF0IGlzIG5lZWRlZCBhbmQgdGhhbmsgZXZlcnlvbmUgZm9yIHRoZSBkaXNjdXNzaW9uIGFuZCB0
aGVpciB0aW1lIHJldmlld2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RGVib3JhaDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5TdXNhbiBIYXJlczxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks
IE1hcmNoIDI1LCAyMDE2IDk6MTggQU08YnI+DQo8Yj5Ubzo8L2I+ICdGcmVkIEJha2VyIChmcmVk
KScgJmx0O2ZyZWRAY2lzY28uY29tJmd0OzsgJ0d1bnRlciBWYW4gRGUgVmVsZGUnICZsdDtndW50
ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGkycnNAaWV0Zi5v
cmc7IG9wcy1kaXJAaWV0Zi5vcmc7ICdKb2VsIEhhbHBlcm4gRGlyZWN0JyAmbHQ7am1oLmRpcmVj
dEBqb2VsaGFscGVybi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaTJyc10gW09Q
Uy1ESVJdIEVwaGVtZXJhbCAtIFNob3VsZCB3ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMvMjQgdG8g
NC8zKSBDYWxsIGZvciBvcGluaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZyZWQ6DQo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSBmb3IgdGhlIHJl
dmlldywgYW5kIHlvdXIgY29tbWVudHMgaGVyZS4mbmJzcDsgSSB3aXNoZWQgSeKAmWQgYXNrZWQg
YWJvdXQgdGhlIHdvcmQgZXBoZW1lcmFsIGVhcmxpZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlN1ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz
YW5zLXNlcmlmIj4gRnJlZCBCYWtlciAoZnJlZCkgWzxhIGhyZWY9Im1haWx0bzpmcmVkQGNpc2Nv
LmNvbSI+bWFpbHRvOmZyZWRAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy
c2RheSwgTWFyY2ggMjQsIDIwMTYgMjo1OSBQTTxicj4NCjxiPlRvOjwvYj4gR3VudGVyIFZhbiBE
ZSBWZWxkZTxicj4NCjxiPkNjOjwvYj4gU3VzYW4gSGFyZXM7IDxhIGhyZWY9Im1haWx0bzppMnJz
QGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm9wcy1kaXJAaWV0
Zi5vcmciPg0Kb3BzLWRpckBpZXRmLm9yZzwvYT47IEpvZWwgSGFscGVybiBEaXJlY3Q8YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUmU6IFtPUFMtRElSXSBFcGhlbWVyYWwgLSBTaG91bGQgd2UgdXNlIGFu
b3RoZXIgd29yZCAtICgzLzI0IHRvIDQvMykgQ2FsbCBmb3Igb3BpbmlvbjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IGNvbW1lbnQgd2FzIGEgcmV2aWV3
IGNvbW1lbnQsIHRoYXQgdGhlIHdvcmQgd2FzIGJlaW5nIHVzZWQgaW4gYSB3YXkgdGhhdCB3YXNu
J3QgY29uc2lzdGVudCB3aXRoIGl0cyBkaWN0aW9uYXJ5IGRlZmluaXRpb24gKHNvbWV0aGluZyB3
aXRoIGEgc2hvcnQgbGlmZXRpbWUsIHF1aXRlIGlycmVzcGVjdGl2ZSBvZiBiaXJ0aC9kZWF0aCBw
cm9jZXNzZXMpIG9yIGNvbW1vbiB1c2FnZSAoYXQgbGVhc3QgaW4gbXkNCiBjb250ZXh0KS4gQXQg
dGhpcyBwb2ludCwgdGhlIGRyYWZ0IGhhcyBiZWVuIHNlbnQgdG8gdGhlIFJGQyBFZGl0b3IsIHNv
IHRvIG15IG1pbmQgdGhpcyBkaXNjdXNzaW9uIGlzIG1vc3RseSBtb290LiBJZiBpbiB5b3VyIG90
aGVyIGRyYWZ0cyB5b3UgYXJlIHBvaW50aW5nIHBlb3BsZSB0byBhIGdsb3NzYXJ5IGluIHRoZSBh
cmNoaXRlY3R1cmUgZG9jdW1lbnQgKHdoaWNoIEkgaW1hZ2luZSB5b3UgYWxyZWFkeSBhcmUpIGFu
ZCB0aGUgYXJjaGl0ZWN0dXJlDQogZG9jdW1lbnQgZGVmaW5lcyB0aGUgdGVybSBhcyB5b3UgYXJl
IHVzaW5nIGl0LCB5b3UgaGF2ZSBwcm9iYWJseSBkb25lIGVub3VnaC48bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMjQsIDIwMTYsIGF0IDExOjA3
IEFNLCBHdW50ZXIgVmFuIERlIFZlbGRlICZsdDs8YSBocmVmPSJtYWlsdG86Z3VudGVydmFuZGV2
ZWxkZWNjQGljbG91ZC5jb20iPmd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SSBhbSBvayBub3dhZGF5cyB3aXRoIHVzaW5nIHRoZSB0ZXJtaW5vbG9neSDigJxFcGhlbWVy
YWzigJ0sIGFsdGhvdWdoIGZvciBhIG5vbi1uYXR2ZSBzcGVha2VyIGl0IGlzIG5vbi10cml2aWFs
IGV4b3RpYyB3b3JkLCBwYXJ0aWN1bGFyIGlmIHRoZSBpbnRlbmRlZCB1c2FnZSBkb2VzbuKAmXQg
MTAwJSByZWZsZWN0IHRoZSBXZWJzdGVyIGRpY3Rpb25hcnkgaW50ZW5kZWQgbWVhbmluZy48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMg
b25seSBhYm91dCBhIHllYXIgYWdvIGkgc3RhcnRlZCByZWFkaW5nIHVwIG9uIGkycnMgYW5kIGRp
c2NvdmVyZWQgdGhpcyBwYXJ0aWN1bGFyIHRlcm1pbm9sb2d5LCBhbmQgYXQgdGhlIHRpbWUgYSBn
b29nbGUgc2VhcmNoIG9uIHRoaXMgdGVybWlub2xvZ3kgd2FzIG5vdCB2ZXJ5IGNvbmNsdXNpdmUg
YW5kIHJlc3VsdGVkIHRvIHNvbWUgY29uZnVzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB1bmRlcnN0YW5kIHZlcnkgd2VsbCB0
aGUgY29uZnVzaW9uIGF0IHBsYXkgaGVyZSBmcm9tIG5vbi1uYXRpdmUgZW5nbGlzaCBzcGVha2Vy
IHBlcnNwZWN0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5BZGRpbmcgdGV4dCB0byBleHBsYWluIHRoZSBjb250ZXh0IGluIHdoaWNoIHRo
ZSB0ZXJtIEVwaGVtZXJhbCBpcyB1c2VmdWwvYWR2aXNlZC4gZndpdyBub3cgdGhhdCBpIGFtIHVz
ZWQgdG8gc2VlaW5nIOKAmEVwaGVtZXJhbCcgYXMgbm9uLXBlcm1hbmVudCBjb25maWcgYWNyb3Nz
IHJlYm9vdCwgaeKAmW0gYWRhcHRlZCBpdHMgaW50ZW5kZWQgcHVycG9zZeKApiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGUg
Z29hbCB0byBleHBsYWluIHRoZSBpbnRlbmRlZCBtZWFuaW5nIGluIGVhY2ggZHJhZnQvcmZjIG1l
bnRpb25pbmcgaXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkJlIHdlbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5HLzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5PbiAyNCBNYXIgMjAxNiwgYXQgMTg6MDIsIFN1c2FuIEhhcmVzICZsdDs8YSBocmVm
PSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+SGkgYWxsOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0O3dn
IGNoYWlyIGhhdCBvbiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgZHJhZnQtaWV0Zi1pMnJzLWFyY2hpdGVj
dHVyZSBkb2N1bWVudCBoYXMgYmVlbiBhcHByb3ZlZCBhcyBhbiBSRkMuJm5ic3A7IEluIHRoZSBy
ZXZpZXcsIHRoZSBPUFMtRElSIHJldmlldyBpbmRpY2F0ZWQgdGhhdCDigJxlcGhlbWVyYWzigJ0g
bWVhbnQgbW9yZSB0aGFuIOKAnGRvZXMgbm90IHN1cnZpdmUgYSByZWJvb3TigJ0uDQogVGhleSBo
YXZlIGFza2VkIHRoZSBJMlJTIHdvcmtpbmcgZ3JvdXAgaWYgcmVwbGFjaW5nIOKAnGVwaGVtZXJh
bOKAnSB3aXRoIG5vbi1wZXJzaXN0ZW50IChhY3Jvc3MgcG93ZXIgb24vb2ZmIG9yIHJlYm9vdCBj
eWNsZXMpIHdvdWxkIGJlIGEgYmV0dGVyIGNob2ljZS4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgZG8geW91IHRoaW5rIOKAkyBsZWF2ZSBhdCBpdCBhdCDi
gJxlcGhlbWVyYWzigJ0gb3IgY2hhbmdlIHRvIOKAnG5vbi1wZXJzaXN0ZW50IChhY3Jvc3MgcG93
ZXIgb24vb2ZmIG9yIHJlYm9vdCBjeWNsZXMpID8gV2Ugd2lsbCBoYXZlIGEgMSB3ZWVrIGNhbGwg
b248c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgd291bGQgbWVhbiBl
dmVyeSBwbGFjZSB0aGF0IOKAnGVwaGVtZXJhbOKAnSBpcyBsaXN0ZWQsIHRoZSBhdXRob3JzIHdv
dWxkIHJlcGxhY2Ugd2l0aCDigJxub24tcGVyc2lzdGVudOKAnS4mbmJzcDsgSW4gdGhlIGZpcnN0
IGluc3RhbmNlLCB3ZSB3aWxsIGluZGljYXRlIOKAnG5vbi1wZXJzaXN0ZW50IChhY3Jvc3MgcG93
ZXINCiBvbi9vZmYgb3IgcmVib290IGN5Y2xlcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDt3ZyBjaGFpciBoYXQgb2ZmJmd0OyAmbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXMgdGhlIGF1dGhvciwgSSB0
aGluayB3ZSBhcmUgYmV0dGVyIHRvIGRlZmluZSBlcGhlbWVyYWwgYXQgdGhlIGJlZ2lubmluZyBh
cyDigJxub24tcGVyc2lzdGVudCAoYWNyb3NzIHBvd2VyIG9uIC9vZmYgb3IgcmVib290KS4mbmJz
cDsgQ2hhbmdpbmcgdGhlIGRlZmluaXRpb24gYXQgdGhpcyBwb2ludCwgSSBzdXNwZWN0DQogd2ls
bCBzaW1wbHkgY29uZnVzZSBwZW9wbGUuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj5TdWUgSGFyZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPUFMtRElS
IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86T1BTLURJUkBpZXRmLm9y
ZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPk9QUy1ESVJAaWV0Zi5vcmc8L3NwYW4+
PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wcy1kaXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wcy1kaXI8L3Nw
YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCk9QUy1ESVIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9QUy1E
SVJAaWV0Zi5vcmciPk9QUy1ESVJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHMtZGlyIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29wcy1kaXI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_F64C10EAA68C8044B33656FA214632C85285AB2CMISOUT7MSGUSRDE_--


From nobody Fri Mar 25 12: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 0FD2912D57F; Fri, 25 Mar 2016 12:39:31 -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 E5WH4VyELVt7; Fri, 25 Mar 2016 12:39:26 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 BB72F12D637; Fri, 25 Mar 2016 12:39:14 -0700 (PDT)
Received: by mail-ig0-x232.google.com with SMTP id av4so18576140igc.1; Fri, 25 Mar 2016 12:39:14 -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:message-id:references :to; bh=dFYDZ3vyavXEHPFuB0ApKLLfASv6/Hl+FmSBlJU6F0U=; b=GDmsEtKNnSDj8RW7h2raC9yY7lZXYDXoe4A4XEXhCR20bkEMuAfrODAmwFgLUeoNRj AZGpTSVSvUD+r/rnxUNV5c5ywtjF7OmNAamoIKT/Hjj1dtwkKIncFXgD+a4J+Dfj+tCT zZ7pl99HqoSZ8S7TPFqaKX/PvDRoYLRBRnyxx/ub8nVZ2g+6Y7MVlyyb0Hl/6I58t+Ye BwYvBq1YUF9G1bt1wLL7Ce7GGtevfBoxDT169wkP7UVhPjcD7girtUZ4O0jcb3v6PYi8 UFvktdSjvBtTsla53sdzZ09e/T5DtktGKh/kARBxlpF9zNXIBmyjXjA5VDgk5hPOXgwO 4R+g==
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 :message-id:references:to; bh=dFYDZ3vyavXEHPFuB0ApKLLfASv6/Hl+FmSBlJU6F0U=; b=Np/v+AmLm2Xpb/uC6X4EXvc52M8zXyLYB7vwmo0uqjmy/7wqtKEBgj4IY6bJaFRr7d RQp/ww1eZ/19pUw9rB7EC8TO/JgkmM/77CZv9NhxNGCtg3eUXiukJHHOs+x1QdP0kN/t ESWs0ZzrSPpX86nzT7cqn5QPWme/9EO0MsGH/smZyhW5ds04Ek8dj+nbwpRXfI2o7NiF STDOHRzbip+eviu2k2pZbnoW836Ux0rlpbh9PjyLH8dRfoYfJMxjWeDeM9Cxhxbo1DSG YVZpNu+WZ80nQyEvsNxlcF4RTYrny+OammiiMzNbiqF1DV+fk8wQgVDmPaNUfzNKA6yi LCQA==
X-Gm-Message-State: AD7BkJJq2RVcRSXCqceuBeffzVKVfOVprtUnCGu23VTCtpOFXJj8Fz/GqASQ82sGQYP4VA==
X-Received: by 10.50.143.4 with SMTP id sa4mr220466igb.26.1458934754040; Fri, 25 Mar 2016 12:39:14 -0700 (PDT)
Received: from [192.168.128.73] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id t5sm80689igk.8.2016.03.25.12.39.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Mar 2016 12:39:13 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F8D59D7-90FB-4901-AF87-F8B831ED075F"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dean Bogdanovic 
In-Reply-To: <013201d1869e$e46f7700$ad4e6500$@ndzh.com>
Date: Fri, 25 Mar 2016 15:39:20 -0400
Message-Id: <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com>
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com>  <013201d1869e$e46f7700$ad4e6500$@ndzh.com>
To: Susan Hares 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: Joel Halpern Direct , ops-dir@ietf.org, "BRUNGARD, DEBORAH A" , Gunter Van De Velde , "Fred Baker \(fred\)" , i2rs@ietf.org
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 25 Mar 2016 19:39:31 -0000

--Apple-Mail=_0F8D59D7-90FB-4901-AF87-F8B831ED075F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Sue,

IMO, ephemeral has two meaning in i2rs architecture

1. it doesn=E2=80=99t survive reboot
2. you can=E2=80=99t roll back to a previous ephemeral state

Dean

> On Mar 25, 2016, at 10:01 AM, Susan Hares  wrote:
>=20
> Deborah:=20
> =20
> Section 2 is exactly the place I would put the definition of =
ephemeral.=20
> =20
> Sue=20
> =20
> From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]=20
> Sent: Friday, March 25, 2016 9:50 AM
> To: Susan Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
> Cc: i2rs@ietf.org; ops-dir@ietf.org; 'Joel Halpern Direct'
> Subject: RE: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - =
(3/24 to 4/3) Call for opinion
> =20
> Hi all,
> =20
> As Alia is a co-author, I was assigned as the responsible AD for this =
document. The document is not with the RFC Editor =E2=80=93 it=E2=80=99s =
been approved by the IESG with a revised ID needed to address comments =
raised by the IESG. And so the current discussion.
> =20
> I had also raised the concern on needing more clarity on the =
definition of ephemeral during my AD review. The authors added some =
information. That clearly was not enough. As the term is used multiple =
times in the document and is the basis for another draft on requirements =
(draft-ietf-i2rs-ephemeral-state) which refers extensively to the =
architecture document, I agree the authors need to add more definition. =
Fred has a good suggestion =E2=80=93 the term should be visible in a =
glossary section early in the document. It=E2=80=99s not currently =
included in Section 2=E2=80=99s Terminology =E2=80=93 Sue, how about =
adding it to that section?
> =20
> I think the authors know what is needed and thank everyone for the =
discussion and their time reviewing.
> =20
> Thanks,
> Deborah
> =20
> =20
> =20
> From: i2rs [mailto:i2rs-bounces@ietf.org =
] On Behalf Of Susan Hares
> Sent: Friday, March 25, 2016 9:18 AM
> To: 'Fred Baker (fred)' >; =
'Gunter Van De Velde' >
> Cc: i2rs@ietf.org ; ops-dir@ietf.org =
; 'Joel Halpern Direct' =
>
> Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - =
(3/24 to 4/3) Call for opinion
> =20
> Fred:=20
> =20
> Thank you for the review, and your comments here.  I wished I=E2=80=99d =
asked about the word ephemeral earlier.=20
> =20
> Sue=20
> =20
> From: Fred Baker (fred) [mailto:fred@cisco.com =
]=20
> Sent: Thursday, March 24, 2016 2:59 PM
> To: Gunter Van De Velde
> Cc: Susan Hares; i2rs@ietf.org ; =
ops-dir@ietf.org ; Joel Halpern Direct
> Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 =
to 4/3) Call for opinion
> =20
> My comment was a review comment, that the word was being used in a way =
that wasn't consistent with its dictionary definition (something with a =
short lifetime, quite irrespective of birth/death processes) or common =
usage (at least in my context). At this point, the draft has been sent =
to the RFC Editor, so to my mind this discussion is mostly moot. If in =
your other drafts you are pointing people to a glossary in the =
architecture document (which I imagine you already are) and the =
architecture document defines the term as you are using it, you have =
probably done enough.
> =20
>> On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde =
> =
wrote:
>> =20
>> I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D=
, although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn=E2=80=99t 100% reflect the =
Webster dictionary intended meaning.
>> =20
>> It is only about a year ago i started reading up on i2rs and =
discovered this particular terminology, and at the time a google search =
on this terminology was not very conclusive and resulted to some =
confusion.=20
>> I understand very well the confusion at play here from non-native =
english speaker perspective.
>> =20
>> Adding text to explain the context in which the term Ephemeral is =
useful/advised. fwiw now that i am used to seeing =E2=80=98Ephemeral' as =
non-permanent config across reboot, i=E2=80=99m adapted its intended =
purpose=E2=80=A6=20
>> =20
>> Is the goal to explain the intended meaning in each draft/rfc =
mentioning it?
>> =20
>> Be well,
>> G/
>> =20
>>> On 24 Mar 2016, at 18:02, Susan Hares > wrote:
>>> =20
>>> Hi all:=20
>>> =20
>>> =20
>>> The draft-ietf-i2rs-architecture document has been approved as an =
RFC.  In the review, the OPS-DIR review indicated that =E2=80=9Cephemeral=E2=
=80=9D meant more than =E2=80=9Cdoes not survive a reboot=E2=80=9D. They =
have asked the I2RS working group if replacing =E2=80=9Cephemeral=E2=80=9D=
 with non-persistent (across power on/off or reboot cycles) would be a =
better choice. =20
>>> =20
>>> What do you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D=
 or change to =E2=80=9Cnon-persistent (across power on/off or reboot =
cycles) ? We will have a 1 week call on=20
>>> =20
>>> This would mean every place that =E2=80=9Cephemeral=E2=80=9D is =
listed, the authors would replace with =E2=80=9Cnon-persistent=E2=80=9D. =
 In the first instance, we will indicate =E2=80=9Cnon-persistent (across =
power on/off or reboot cycles).
>>> =20
>>>  =20
>>> =20
>>> As the author, I think we are better to define ephemeral at the =
beginning as =E2=80=9Cnon-persistent (across power on /off or reboot).  =
Changing the definition at this point, I suspect will simply confuse =
people.=20
>>> =20
>>> Sue Hares
>>> =20
>>> _______________________________________________
>>> OPS-DIR mailing list
>>> OPS-DIR@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/ops-dir =

>> =20
>> _______________________________________________
>> OPS-DIR mailing list
>> OPS-DIR@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ops-dir =

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


--Apple-Mail=_0F8D59D7-90FB-4901-AF87-F8B831ED075F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Sue,

IMO, =
ephemeral has two meaning in i2rs architecture

1. it doesn=E2=80=99t survive =
reboot
2. you can=E2=80=99t roll back to a previous =
ephemeral state

Dean

On =
Mar 25, 2016, at 10:01 AM, Susan Hares <shares@ndzh.com> =
wrote:

Deborah: 
 
Section 2 is exactly =
the place I would put the definition of ephemeral. 
 
Sue 
 
From: BRUNGARD, =
DEBORAH A [mailto:db3546@att.com] 
Sent: Friday, March 25, 2016 9:50 =
AM
To: Susan Hares; 'Fred Baker =
(fred)'; 'Gunter Van De Velde'
Cc: i2rs@ietf.org; ops-dir@ietf.org; 'Joel =
Halpern Direct'
Subject: RE: [i2rs] [OPS-DIR] =
Ephemeral - Should we use another word - (3/24 to 4/3) Call for =
opinion
 
Hi =
all,
 
As Alia is a co-author, =
I was assigned as the responsible AD for this document. The document is =
not with the RFC Editor =E2=80=93 it=E2=80=99s been approved by the IESG =
with a revised ID needed to address comments raised by the IESG. And so =
the current discussion.
 
I had also raised the =
concern on needing more clarity on the definition of ephemeral during my =
AD review. The authors added some information. That clearly was not =
enough. As the term is used multiple times in the document and is the =
basis for another draft on requirements =
(draft-ietf-i2rs-ephemeral-state) which refers extensively to the =
architecture document, I agree the authors need to add more definition. =
Fred has a good suggestion =E2=80=93 the term should be visible in a =
glossary section early in the document. It=E2=80=99s not currently =
included in Section 2=E2=80=99s Terminology =E2=80=93 Sue, how about =
adding it to that section?
 
I think the authors =
know what is needed and thank everyone for the discussion and their time =
reviewing.
 
Thanks,
Deborah
 
 
 
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf =
Of Susan Hares
Sent: Friday, March 25, 2016 9:18 =
AM
To: 'Fred Baker (fred)' <fred@cisco.com>; 'Gunter Van De Velde' =
<guntervandeveldecc@icloud.com>
Cc: i2rs@ietf.org; ops-dir@ietf.org; 'Joel =
Halpern Direct' <jmh.direct@joelhalpern.com>
Subject: Re: [i2rs] [OPS-DIR] =
Ephemeral - Should we use another word - (3/24 to 4/3) Call for =
opinion
 
Fred: 
 
Thank you for the =
review, and your comments here.  I wished I=E2=80=99d asked about =
the word ephemeral earlier. 
 
Sue 
 
From: Fred Baker =
(fred) [mailto:fred@cisco.com] 
Sent: Thursday, March 24, 2016 =
2:59 PM
To: Gunter Van De Velde
Cc: Susan Hares; i2rs@ietf.org; ops-dir@ietf.org; Joel =
Halpern Direct
Subject: Re: [OPS-DIR] Ephemeral - =
Should we use another word - (3/24 to 4/3) Call for opinion
 
My comment was a review comment, that the word was being used =
in a way that wasn't consistent with its dictionary definition =
(something with a short lifetime, quite irrespective of birth/death =
processes) or common usage (at least in my context). At this point, the =
draft has been sent to the RFC Editor, so to my mind this discussion is =
mostly moot. If in your other drafts you are pointing people to a =
glossary in the architecture document (which I imagine you already are) =
and the architecture document defines the term as you are using it, you =
have probably done enough.
 
On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde <guntervandeveldecc@icloud.com> wrote:
 
I am ok nowadays with =
using the terminology =E2=80=9CEphemeral=E2=80=9D, although for a =
non-natve speaker it is non-trivial exotic word, particular if the =
intended usage doesn=E2=80=99t 100% reflect the Webster dictionary =
intended meaning.
 
It is only about a year ago i started reading up on =
i2rs and discovered this particular terminology, and at the time a =
google search on this terminology was not very conclusive and resulted =
to some confusion. 
I understand very =
well the confusion at play here from non-native english speaker =
perspective.
 
Adding text to explain the context in which the term =
Ephemeral is useful/advised. fwiw now that i am used to seeing =
=E2=80=98Ephemeral' as non-permanent config across reboot, i=E2=80=99m =
adapted its intended purpose=E2=80=A6 
 
Is the goal to explain the intended =
meaning in each draft/rfc mentioning it?
 
Be well,
G/
 
On =
24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> wrote:
 
Hi all: 
 
<wg chair hat on> 
The draft-ietf-i2rs-architecture document has =
been approved as an RFC.  In the review, the OPS-DIR review =
indicated that =E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes =
not survive a reboot=E2=80=9D. They have asked the I2RS working group if =
replacing =E2=80=9Cephemeral=E2=80=9D with non-persistent (across power =
on/off or reboot cycles) would be a better choice.  
 
What do you think =E2=80=93 leave at it at =
=E2=80=9Cephemeral=E2=80=9D or change to =E2=80=9Cnon-persistent (across =
power on/off or reboot cycles) ? We will have a 1 week call on 
 
This would mean every place that =E2=80=9Cephemera=
l=E2=80=9D is listed, the authors would replace with =
=E2=80=9Cnon-persistent=E2=80=9D.  In the first instance, we will =
indicate =E2=80=9Cnon-persistent (across power on/off or reboot =
cycles).
 
<wg chair hat off>  
 
As the author, I think we are better to define =
ephemeral at the beginning as =E2=80=9Cnon-persistent (across power on =
/off or reboot).  Changing the definition at this point, I suspect =
will simply confuse people. 
 
Sue Hares
 
_______________________________________________OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
 
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
 
_______________________________________________
i2rs mailing =
list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

=

--Apple-Mail=_0F8D59D7-90FB-4901-AF87-F8B831ED075F--


From nobody Sat Mar 26 05:08: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 54E8712D141; Sat, 26 Mar 2016 05:08:36 -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 1hyg6jOw-AA6; Sat, 26 Mar 2016 05:08:33 -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 6B78F12D094; Sat, 26 Mar 2016 05:08:33 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; 
From: "Susan Hares" 
To: "'Dean Bogdanovic'" 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com>  <013201d1869e$e46f7700$ad4e6500$@ndzh.com> <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com>
In-Reply-To: <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com>
Date: Sat, 26 Mar 2016 08:08:04 -0400
Message-ID: <00fd01d18758$26ddffd0$7499ff70$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FE_01D18736.9FD27A50"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL1cmQL65XiP+Rc6iRVZO2xGznKbQGRYBXWAUlpc/4BuMMbcgGZxOsnA57JmYYBkX3185zI3qMA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: 'Joel Halpern Direct' , ops-dir@ietf.org, "'BRUNGARD, DEBORAH A'" , 'Gunter Van De Velde' , "'Fred Baker \(fred\)'" , i2rs@ietf.org
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 26 Mar 2016 12:08:37 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00FE_01D18736.9FD27A50
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Dean:=20

=20

This is an excellent point.  I will include this in the architecture =
document.=20

=20

Sue=20

=20

From: Dean Bogdanovic [mailto:ivandean@gmail.com]=20
Sent: Friday, March 25, 2016 3:39 PM
To: Susan Hares
Cc: BRUNGARD, DEBORAH A; Fred Baker (fred); Gunter Van De Velde; =
i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern Direct
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - =
(3/24 to 4/3) Call for opinion

=20

Sue,

=20

IMO, ephemeral has two meaning in i2rs architecture

=20

1. it doesn=E2=80=99t survive reboot

2. you can=E2=80=99t roll back to a previous ephemeral state

=20

Dean

=20

On Mar 25, 2016, at 10:01 AM, Susan Hares  wrote:

=20

Deborah:=20

=20

Section 2 is exactly the place I would put the definition of ephemeral.=20

=20

Sue=20

=20

From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]=20
Sent: Friday, March 25, 2016 9:50 AM
To: Susan Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
Cc: i2rs@ietf.org; ops-dir@ietf.org; 'Joel Halpern Direct'
Subject: RE: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - =
(3/24 to 4/3) Call for opinion

=20

Hi all,

=20

As Alia is a co-author, I was assigned as the responsible AD for this =
document. The document is not with the RFC Editor =E2=80=93 it=E2=80=99s =
been approved by the IESG with a revised ID needed to address comments =
raised by the IESG. And so the current discussion.

=20

I had also raised the concern on needing more clarity on the definition =
of ephemeral during my AD review. The authors added some information. =
That clearly was not enough. As the term is used multiple times in the =
document and is the basis for another draft on requirements =
(draft-ietf-i2rs-ephemeral-state) which refers extensively to the =
architecture document, I agree the authors need to add more definition. =
Fred has a good suggestion =E2=80=93 the term should be visible in a =
glossary section early in the document. It=E2=80=99s not currently =
included in Section 2=E2=80=99s Terminology =E2=80=93 Sue, how about =
adding it to that section?

=20

I think the authors know what is needed and thank everyone for the =
discussion and their time reviewing.

=20

Thanks,

Deborah

=20

=20

=20

From: i2rs [  =
mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, March 25, 2016 9:18 AM
To: 'Fred Baker (fred)' <  fred@cisco.com>; =
'Gunter Van De Velde' <  =
guntervandeveldecc@icloud.com>
Cc:   i2rs@ietf.org;   =
ops-dir@ietf.org; 'Joel Halpern Direct' < =
 jmh.direct@joelhalpern.com>
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - =
(3/24 to 4/3) Call for opinion

=20

Fred:=20

=20

Thank you for the review, and your comments here.  I wished I=E2=80=99d =
asked about the word ephemeral earlier.=20

=20

Sue=20

=20

From: Fred Baker (fred) [  mailto:fred@cisco.com] =

Sent: Thursday, March 24, 2016 2:59 PM
To: Gunter Van De Velde
Cc: Susan Hares;   i2rs@ietf.org;  =
 ops-dir@ietf.org; Joel Halpern Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to =
4/3) Call for opinion

=20

My comment was a review comment, that the word was being used in a way =
that wasn't consistent with its dictionary definition (something with a =
short lifetime, quite irrespective of birth/death processes) or common =
usage (at least in my context). At this point, the draft has been sent =
to the RFC Editor, so to my mind this discussion is mostly moot. If in =
your other drafts you are pointing people to a glossary in the =
architecture document (which I imagine you already are) and the =
architecture document defines the term as you are using it, you have =
probably done enough.

=20

On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde < =
 guntervandeveldecc@icloud.com> =
wrote:

=20

I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D, =
although for a non-natve speaker it is non-trivial exotic word, =
particular if the intended usage doesn=E2=80=99t 100% reflect the =
Webster dictionary intended meaning.

=20

It is only about a year ago i started reading up on i2rs and discovered =
this particular terminology, and at the time a google search on this =
terminology was not very conclusive and resulted to some confusion.=20

I understand very well the confusion at play here from non-native =
english speaker perspective.

=20

Adding text to explain the context in which the term Ephemeral is =
useful/advised. fwiw now that i am used to seeing =E2=80=98Ephemeral' as =
non-permanent config across reboot, i=E2=80=99m adapted its intended =
purpose=E2=80=A6=20

=20

Is the goal to explain the intended meaning in each draft/rfc mentioning =
it?

=20

Be well,

G/

=20

On 24 Mar 2016, at 18:02, Susan Hares <  =
shares@ndzh.com> wrote:

=20

Hi all:=20

=20

=20

The draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =
=E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes not survive a =
reboot=E2=80=9D. They have asked the I2RS working group if replacing =
=E2=80=9Cephemeral=E2=80=9D with non-persistent (across power on/off or =
reboot cycles) would be a better choice. =20

=20

What do you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D =
or change to =E2=80=9Cnon-persistent (across power on/off or reboot =
cycles) ? We will have a 1 week call on=20

=20

This would mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, =
the authors would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the =
first instance, we will indicate =E2=80=9Cnon-persistent (across power =
on/off or reboot cycles).

=20

 =20

=20

As the author, I think we are better to define ephemeral at the =
beginning as =E2=80=9Cnon-persistent (across power on /off or reboot).  =
Changing the definition at this point, I suspect will simply confuse =
people.=20

=20

Sue Hares

=20

_______________________________________________
OPS-DIR mailing list
  OPS-DIR@ietf.org
  =
https://www.ietf.org/mailman/listinfo/ops-dir

=20

_______________________________________________
OPS-DIR mailing list
  OPS-DIR@ietf.org
  =
https://www.ietf.org/mailman/listinfo/ops-dir

=20

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

=20


------=_NextPart_000_00FE_01D18736.9FD27A50
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Dean: 
 
This is an excellent point.=C2=A0 I will include this in the =
architecture document. 
 
Sue 
 
From:=
 =
Dean Bogdanovic [mailto:ivandean@gmail.com] 
Sent: Friday, =
March 25, 2016 3:39 PM
To: Susan Hares
Cc: BRUNGARD, =
DEBORAH A; Fred Baker (fred); Gunter Van De Velde; i2rs@ietf.org; =
ops-dir@ietf.org; Joel Halpern Direct
Subject: Re: [i2rs] =
[OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call =
for opinion
 
Sue,
 
IMO, ephemeral has two meaning in i2rs =
architecture
 
1. it doesn=E2=80=99t survive =
reboot
2. you =
can=E2=80=99t roll back to a previous ephemeral =
state
 
Dean
 
On Mar 25, 2016, at 10:01 AM, Susan Hares <shares@ndzh.com> =
wrote:
 
Deborah: 
 
Section 2 is exactly the place I would put the definition of =
ephemeral. 
 
Sue 
 
From:=
 BRUNGARD, =
DEBORAH A [mailto:db3546@att.com] 
Sent: Friday, March 25, 2016 9:50 =
AM
To: Susan =
Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
Cc: i2rs@ietf.org; ops-dir@ietf.org; 'Joel Halpern =
Direct'
Subject: RE: [i2rs] [OPS-DIR] =
Ephemeral - Should we use another word - (3/24 to 4/3) Call for =
opinion
 
Hi all,
 
As Alia is a co-author, I was assigned as the responsible AD for this =
document. The document is not with the RFC Editor =E2=80=93 it=E2=80=99s =
been approved by the IESG with a revised ID needed to address comments =
raised by the IESG. And so the current =
discussion.
 
I had also raised the concern on needing more clarity on the =
definition of ephemeral during my AD review. The authors added some =
information. That clearly was not enough. As the term is used multiple =
times in the document and is the basis for another draft on requirements =
(draft-ietf-i2rs-ephemeral-state) which refers extensively to the =
architecture document, I agree the authors need to add more definition. =
Fred has a good suggestion =E2=80=93 the term should be visible in a =
glossary section early in the document. It=E2=80=99s not currently =
included in Section 2=E2=80=99s Terminology =E2=80=93 Sue, how about =
adding it to that section?
 
I think the authors know what is needed and thank everyone for the =
discussion and their time reviewing.
 
Thanks,
Deborah
 
 
 
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan =
Hares
Sent: Friday, March 25, 2016 9:18 =
AM
To: 'Fred =
Baker (fred)' <fred@cisco.com>; 'Gunter Van De =
Velde' <guntervandeveldecc@icloud.com>
Cc: i2rs@ietf.org; ops-dir@ietf.org; 'Joel Halpern =
Direct' <jmh.direct@joelhalpern.com>
Su=
bject: Re: [i2rs] =
[OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call =
for opinion
 
Fred: 
 
Thank you for the review, and your comments here.  I wished =
I=E2=80=99d asked about the word ephemeral earlier. 
 
Sue 
 
From:=
 Fred Baker =
(fred) [mailto:fred@cisco.com] 
Sent: Thursday, March 24, 2016 2:59 =
PM
To: Gunter =
Van De Velde
Cc: Susan Hares; i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern =
Direct
Subject: Re: [OPS-DIR] Ephemeral - =
Should we use another word - (3/24 to 4/3) Call for =
opinion
 
My comment was a review comment, that the word was =
being used in a way that wasn't consistent with its dictionary =
definition (something with a short lifetime, quite irrespective of =
birth/death processes) or common usage (at least in my context). At this =
point, the draft has been sent to the RFC Editor, so to my mind this =
discussion is mostly moot. If in your other drafts you are pointing =
people to a glossary in the architecture document (which I imagine you =
already are) and the architecture document defines the term as you are =
using it, you have probably done =
enough.
 
On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde =
<guntervandeveldecc@icloud.com> =
wrote:
 
I am ok nowadays with using the terminology =
=E2=80=9CEphemeral=E2=80=9D, although for a non-natve speaker it is =
non-trivial exotic word, particular if the intended usage =
doesn=E2=80=99t 100% reflect the Webster dictionary intended =
meaning.
 
It is only about a year ago i started reading up on =
i2rs and discovered this particular terminology, and at the time a =
google search on this terminology was not very conclusive and resulted =
to some confusion. 
I understand very well the confusion at play here from =
non-native english speaker =
perspective.
 
Adding text to explain the context in which the term =
Ephemeral is useful/advised. fwiw now that i am used to seeing =
=E2=80=98Ephemeral' as non-permanent config across reboot, i=E2=80=99m =
adapted its intended =
purpose=E2=80=A6 
 
Is the goal to explain the intended meaning in each =
draft/rfc mentioning it?
 
Be well,
G/
 
On 24 Mar 2016, at 18:02, Susan Hares <shares@ndzh.com> =
wrote:
 
Hi =
all: 
 
<wg =
chair hat on> 
The =
draft-ietf-i2rs-architecture document has been approved as an RFC.  =
In the review, the OPS-DIR review indicated that =
=E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes not survive a =
reboot=E2=80=9D. They have asked the I2RS working group if replacing =
=E2=80=9Cephemeral=E2=80=9D with non-persistent (across power on/off or =
reboot cycles) would be a better choice.  
 
What do =
you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D or change =
to =E2=80=9Cnon-persistent (across power on/off or reboot cycles) ? We =
will have a 1 week call on 
 
This would =
mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, the authors =
would replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the first =
instance, we will indicate =E2=80=9Cnon-persistent (across power on/off =
or reboot cycles).
 
<wg =
chair hat off>  
 
As the =
author, I think we are better to define ephemeral at the beginning as =
=E2=80=9Cnon-persistent (across power on /off or reboot).  Changing =
the definition at this point, I suspect will simply confuse people. 
 
Sue =
Hares
 
__________=
_____________________________________
OPS-DIR mailing =
list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
 
_______________________________________________
OPS-=
DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
 
__________=
_____________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/=
mailman/listinfo/i2rs
<=
p class=3DMsoNormal> 

------=_NextPart_000_00FE_01D18736.9FD27A50--


From nobody Sat Mar 26 06:02: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 1A1C712D1B6; Sat, 26 Mar 2016 06:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 GnhrpprNVbXD; Sat, 26 Mar 2016 06:01:28 -0700 (PDT)
Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9681712D198; Sat, 26 Mar 2016 06:01:27 -0700 (PDT)
Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id ad1N1s00B3vXPcr01d1PYa; Sat, 26 Mar 2016 14:01:25 +0100
To: Dean Bogdanovic , Susan Hares 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com>  <013201d1869e$e46f7700$ad4e6500$@ndzh.com> <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com>
From: "Bert Wijnen (IETF)" 
Message-ID: <56F68822.3060400@bwijnen.net>
Date: Sat, 26 Mar 2016 14:01:22 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Sat, 26 Mar 2016 06:02:00 -0700
Cc: Joel Halpern Direct , ops-dir@ietf.org, i2rs@ietf.org, "BRUNGARD, DEBORAH A" , Gunter Van De Velde 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 26 Mar 2016 13:01:31 -0000

Mmmmm... in this discussion between Ed Snowden, Gleen Greenwald and
Norm Chomskey, Ed uses the word ephemral many times.

http://livestream.com/azpm/events/4958510

worth watching I think. Two hours though.

Bert

  On 25/03/16 20:39, Dean Bogdanovic wrote:
> Sue,
>
> IMO, ephemeral has two meaning in i2rs architecture
>
> 1. it doesn’t survive reboot
> 2. you can’t roll back to a previous ephemeral state
>
> Dean
>
>> On Mar 25, 2016, at 10:01 AM, Susan Hares > wrote:
>>
>> Deborah:
>> Section 2 is exactly the place I would put the definition of ephemeral.
>> Sue
>> *From:*BRUNGARD, DEBORAH A [mailto:db3546@att.com]
>> *Sent:*Friday, March 25, 2016 9:50 AM
>> *To:*Susan Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
>> *Cc:*i2rs@ietf.org ; ops-dir@ietf.org ; 'Joel Halpern Direct'
>> *Subject:*RE: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
>> Hi all,
>> As Alia is a co-author, I was assigned as the responsible AD for this document. The document is not with the RFC Editor – it’s 
>> been approved by the IESG with a revised ID needed to address comments raised by the IESG. And so the current discussion.
>> I had also raised the concern on needing more clarity on the definition of ephemeral during my AD review. The authors added some 
>> information. That clearly was not enough. As the term is used multiple times in the document and is the basis for another draft 
>> on requirements (draft-ietf-i2rs-ephemeral-state) which refers extensively to the architecture document, I agree the authors need 
>> to add more definition. Fred has a good suggestion – the term should be visible in a glossary section early in the document. It’s 
>> not currently included in Section 2’s Terminology – Sue, how about adding it to that section?
>> I think the authors know what is needed and thank everyone for the discussion and their time reviewing.
>> Thanks,
>> Deborah
>> *From:*i2rs [mailto:i2rs-bounces@ietf.org]*On Behalf Of*Susan Hares
>> *Sent:*Friday, March 25, 2016 9:18 AM
>> *To:*'Fred Baker (fred)' >; 'Gunter Van De Velde' > >
>> *Cc:*i2rs@ietf.org ;ops-dir@ietf.org ; 'Joel Halpern Direct' 
>> >
>> *Subject:*Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
>> Fred:
>> Thank you for the review, and your comments here.  I wished I’d asked about the word ephemeral earlier.
>> Sue
>> *From:*Fred Baker (fred) [mailto:fred@cisco.com]
>> *Sent:*Thursday, March 24, 2016 2:59 PM
>> *To:*Gunter Van De Velde
>> *Cc:*Susan Hares;i2rs@ietf.org ;ops-dir@ietf.org ; Joel Halpern Direct
>> *Subject:*Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
>> My comment was a review comment, that the word was being used in a way that wasn't consistent with its dictionary definition 
>> (something with a short lifetime, quite irrespective of birth/death processes) or common usage (at least in my context). At this 
>> point, the draft has been sent to the RFC Editor, so to my mind this discussion is mostly moot. If in your other drafts you are 
>> pointing people to a glossary in the architecture document (which I imagine you already are) and the architecture document 
>> defines the term as you are using it, you have probably done enough.
>>> On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde > wrote:
>>> I am ok nowadays with using the terminology “Ephemeral”, although for a non-natve speaker it is non-trivial exotic word, 
>>> particular if the intended usage doesn’t 100% reflect the Webster dictionary intended meaning.
>>> It is only about a year ago i started reading up on i2rs and discovered this particular terminology, and at the time a google 
>>> search on this terminology was not very conclusive and resulted to some confusion.
>>> I understand very well the confusion at play here from non-native english speaker perspective.
>>> Adding text to explain the context in which the term Ephemeral is useful/advised. fwiw now that i am used to seeing ‘Ephemeral' 
>>> as non-permanent config across reboot, i’m adapted its intended purpose…
>>> Is the goal to explain the intended meaning in each draft/rfc mentioning it?
>>> Be well,
>>> G/
>>>> On 24 Mar 2016, at 18:02, Susan Hares > wrote:
>>>> Hi all:
>>>> 
>>>> The draft-ietf-i2rs-architecture document has been approved as an RFC.  In the review, the OPS-DIR review indicated that 
>>>> “ephemeral” meant more than “does not survive a reboot”. They have asked the I2RS working group if replacing “ephemeral” with 
>>>> non-persistent (across power on/off or reboot cycles) would be a better choice.
>>>> What do you think – leave at it at “ephemeral” or change to “non-persistent (across power on/off or reboot cycles) ? We will 
>>>> have a 1 week call on
>>>> This would mean every place that “ephemeral” is listed, the authors would replace with “non-persistent”.  In the first 
>>>> instance, we will indicate “non-persistent (across power on/off or reboot cycles).
>>>> 
>>>> As the author, I think we are better to define ephemeral at the beginning as “non-persistent (across power on /off or reboot). 
>>>> Changing the definition at this point, I suspect will simply confuse people.
>>>> Sue Hares
>>>> _______________________________________________
>>>> OPS-DIR mailing list
>>>> OPS-DIR@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/ops-dir
>>> _______________________________________________
>>> OPS-DIR mailing list
>>> OPS-DIR@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/ops-dir
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org 
>> https://www.ietf.org/mailman/listinfo/i2rs
>
>
>
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir


From nobody Wed Mar 30 01:02: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 A540912DE0F; Wed, 30 Mar 2016 01:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.229
X-Spam-Level: 
X-Spam-Status: No, score=-4.229 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, T_RP_MATCHES_RCVD=-0.01] 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 bT6_qM50zb-f; Wed, 30 Mar 2016 01:02:34 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92AF12DDDF; Wed, 30 Mar 2016 01:02:23 -0700 (PDT)
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 30 Mar 2016 10:02:01 +0200
X-IronPort-AV: E=Sophos;i="5.24,415,1454972400";  d="scan'208,217";a="1033249092"
Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 30 Mar 2016 09:58:52 +0200
Received: from HE113606.emea1.cds.t-internal.com ([10.125.65.129]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi;  Wed, 30 Mar 2016 09:58:51 +0200
From: 
To: , 
Date: Wed, 30 Mar 2016 09:58:48 +0200
Thread-Topic: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AdGF7u3xjBynKRvjQdyb5YDZuMHPDwEaYbRQ
Message-ID: 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>
In-Reply-To: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_AC2379C712D44F4B91E4AEF1D3A5B25D09C2A00BA6DDHE113606eme_"
MIME-Version: 1.0
Archived-At: 
Cc: jmh.direct@joelhalpern.com, ops-dir@ietf.org, fred@cisco.com
Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 30 Mar 2016 08:02:37 -0000

--_000_AC2379C712D44F4B91E4AEF1D3A5B25D09C2A00BA6DDHE113606eme_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I think it's a good idea to give a definition in the beginning of the docum=
ent. The i2rs definition matches also my definition which we are using to d=
escribe the fact, that a customer specific service "configuration" on a ser=
vice node does not survive a reboot.

Just my 2 cents

Nic

Von: i2rs [mailto:i2rs-bounces@ietf.org] Im Auftrag von Susan Hares
Gesendet: Donnerstag, 24. M=E4rz 2016 18:02
An: i2rs@ietf.org
Cc: 'Joel Halpern Direct'; ops-dir@ietf.org; 'Fred Baker (fred)'
Betreff: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call=
 for opinion

Hi all:


The draft-ietf-i2rs-architecture document has been approved as an RFC.  In =
the review, the OPS-DIR review indicated that "ephemeral" meant more than "=
does not survive a reboot". They have asked the I2RS working group if repla=
cing "ephemeral" with non-persistent (across power on/off or reboot cycles)=
 would be a better choice.

What do you think - leave at it at "ephemeral" or change to "non-persistent=
 (across power on/off or reboot cycles) ? We will have a 1 week call on

This would mean every place that "ephemeral" is listed, the authors would r=
eplace with "non-persistent".  In the first instance, we will indicate "non=
-persistent (across power on/off or reboot cycles).



As the author, I think we are better to define ephemeral at the beginning a=
s "non-persistent (across power on /off or reboot).  Changing the definitio=
n at this point, I suspect will simply confuse people.

Sue Hares


--_000_AC2379C712D44F4B91E4AEF1D3A5B25D09C2A00BA6DDHE113606eme_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi,
 
I think it’s a good idea to give a defi=
nition in the beginning of the document. The i2rs definition matches also m=
y definition which we are using to describe the fact, that a customer speci=
fic service “configuration” on a service node does not survive =
a reboot.
 
Just my 2 cents 
 
Nic
 
Von: i2rs [mailto:i2rs-bounces@ietf.org] I=
m Auftrag von Susan Hares
Gesendet: Donnerstag, 24. M=E4rz 20=
16 18:02
An: i2rs@ietf.org
Cc: 'Joel Halpern Direct'; o=
ps-dir@ietf.org; 'Fred Baker (fred)'
Betreff: [i2rs] Ephemeral - =
Should we use another word - (3/24 to 4/3) Call for opinion
 
Hi all: 
 
<wg chair hat on> 
The draft-ietf-i2rs-architecture document has been =
approved as an RFC.  In the review, the OPS-DIR review indicated that =
“ephemeral” meant more than “does not survive a reboot=
221;. They have asked the I2RS working group if replacing “ephemeral&=
#8221; with non-persistent (across power on/off or reboot cycles) would be =
a better choice.  
 
What do you think – leave at it at “ephemeral” or chan=
ge to “non-persistent (across power on/off or reboot cycles) ? We wil=
l have a 1 week call on 
 
This would mean every place that “ephemeral” is listed, the=
 authors would replace with “non-persistent”.  In the firs=
t instance, we will indicate “non-persistent (across power on/off or =
reboot cycles).
 
<w=
g chair hat off>  
 
As the author, I think we are better to define ephemeral at the begin=
ning as “non-persistent (across power on /off or reboot).  Chang=
ing the definition at this point, I suspect will simply confuse people. 
 
Sue Hares
 =

--_000_AC2379C712D44F4B91E4AEF1D3A5B25D09C2A00BA6DDHE113606eme_--


From nobody Wed Mar 30 08:33: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 0AAC612D799 for ; Wed, 30 Mar 2016 08:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 2F1VwlhTD63Q for ; Wed, 30 Mar 2016 08:33:19 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F6912D760 for ; Wed, 30 Mar 2016 08:33:13 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id 20so76584591wmh.1 for ; Wed, 30 Mar 2016 08:33:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:from:date:message-id:subject:to; bh=k42zIYHZ2NiV2F9qiIc7Wr/M46Wjsjhhp+gJ1zTgnTg=; b=oy1Eb7l/XN4KHoCmTuMQFYalV+aH7enJWcR7epLPqCENed3HTsV16mbqnamV+LxcHy rRe0tT16SAZElOprLJWSsIUKkb2uPG6Q1nR0Ut9Xoy4zK4r8r4dSumeIB8el1Tk0vtGc uGWS1pjkt/65y9mVpnkzYGmNMOXyWKCDhafdaiwqm1fFSkHHtu8k5nIhkEAmMQOaorm8 sTmZV6LXHusEgKAY1XAl7g2Va/Cz9m/4c5Eu0yOpiEGD79KId5OkjUvB50zoGEyZ+JNa w8qHmH46WkxeTuxRCpb2Vjel4qFeD4fLxOfESJLhuPOrLelzvXqJjgVunVHXMtvr1lnu rWfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=k42zIYHZ2NiV2F9qiIc7Wr/M46Wjsjhhp+gJ1zTgnTg=; b=KUwJ0RKhwA5ovx2G34V8skc/ofbSK48418G8TGqax7Z0vLkrhTw6yOmBNl1CaVwimj OdMFbJH+uV9Qi6sLdrd9aE9Gsbr9uHvQRD5Jv2pVBv9pZNnS9/hZwvBUFQ46G/Wa1Zy5 Eg0k//Txn7HfPIe863/DR6zCJAE50G6UPzGbiVzh4W45ZY6P1f8ews8YtmvpVmliMTeT SKegSJIkg35O5UDyeLcUQvjD9Gd2PEugxH81EJt/fn4JwuuC5d4IjzNu4uwQVwt3t/2H ToBbO2Qa5iZ/raqS+r3R8UoYu1oxYic6qiAWREyM09MInXomXjHtIUO209qv9N+J3dUx ZnHA==
X-Gm-Message-State: AD7BkJL/t3WdEz19jJCUA/xPXcD2sE1obNx4jS/dP68YOIo+Wka2CXVviVVoOKSp5Zb/jmJD+CagoDHKxyAMUw==
X-Received: by 10.194.239.99 with SMTP id vr3mr10319462wjc.135.1459351991609;  Wed, 30 Mar 2016 08:33:11 -0700 (PDT)
MIME-Version: 1.0
Sender: edwinsc@gmail.com
Received: by 10.28.3.87 with HTTP; Wed, 30 Mar 2016 08:32:42 -0700 (PDT)
From: Edwin Cordeiro 
Date: Wed, 30 Mar 2016 17:32:42 +0200
X-Google-Sender-Auth: KYFygAko2Qa9sotmJe1oULj5tsk
Message-ID: 
To: i2rs@ietf.org
Content-Type: multipart/alternative; boundary=001a11c1b7420ff003052f45ddb2
Archived-At: 
Subject: [i2rs] I2RS Hackathon
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, 30 Mar 2016 15:33:21 -0000

--001a11c1b7420ff003052f45ddb2
Content-Type: text/plain; charset=UTF-8

Hi all,

As we are trying to make an I2RS implementation here at TU Munich, we
created a VM that is running Mininet (to emulate a network), MininExt (to
implement virtual routers) and OpenDayLight (that we trying to use as I2RS
agent), the I2RS client we are trying to make using Zebra. The I2RS agent
is the NETCONF + YANG modules of ODL, but it needs the YANG models to be
written. The I2RS client is not present as it is not yet ready for sharing.

On the previous Hackathon, one of the difficulties for the I2RS was the
lack of an environment where it could be developed, so we decided to share
this VM and a basic tutorial to get this network running in the hope it
could be useful for the approaching Hackathon in Buenos Aires.

The tutorial and VM are available at:
http://www.net.in.tum.de/pub/i2rs/
http://www.net.in.tum.de/pub/i2rs/I2RS-Dev-VM.ova -
md5: af70741cd12b39a9644b0881df516a55

Unfortunately we will not be able to attend this next meeting in person,
but if you have any question, let us know. We hope the VM to be useful.

Best Regards,

Edwin Cordeiro

--001a11c1b7420ff003052f45ddb2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi all,

As=
 we are trying to make an I2RS implementation here at TU Munich, we created=
 a VM that is running Mininet (to emulate a network), MininExt (to implemen=
t virtual routers) and OpenDayLight (that we trying to use as I2RS agent), =
the I2RS client we are trying to make using Zebra. The I2RS agent is the NE=
TCONF + YANG modules of ODL, but it needs the YANG models to be written. Th=
e I2RS client is not present as it is not yet ready for sharing.
<=
div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;font-si=
ze:small">
On the previous Hackathon, one of the diffic=
ulties for the I2RS was the lack of an environment where it could be develo=
ped, so we decided to share this VM and a basic tutorial to get this networ=
k running in the hope it could be useful for the approaching Hackathon in B=
uenos Aires.

The tutorial and VM a=
re available at:=C2=A0
=
http://www.net.in.tum.de/pub/i2rs/
http://www.net.in.tum.de/pub/i2rs=
/I2RS-Dev-VM.ova - md5:=C2=A0af70741cd12b39a9644b0881df516a55

Unfortunately we will not be able to=
 attend this next meeting in person, but if you have any question, let us k=
now. We hope the VM to be useful.

Be=
st Regards,
=C2=A0
=
Edwin Cordeiro



--001a11c1b7420ff003052f45ddb2--


From nobody Wed Mar 30 10:30:03 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 060C112D81B; Wed, 30 Mar 2016 10:30:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS9eqb-2HHDk; Wed, 30 Mar 2016 10:29:59 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAC612D818; Wed, 30 Mar 2016 10:29:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WCxzfomdozMQ4SdAh7h7Ila8hkrmtJoi4COiSv1ASns=; b=DtXkwNzKw6dFnkXZolB2iJEEv3c/3cPRlLKh9mxCukIJL/kssZzvM0AuBjBW0oID5I7H6Pa1rrkT+u1egd4OnvJ8w2AynGavOP+WxhD7uZHJ9PWxUa7vsj7n9MWD5Oig4aWOHMtuRxkvJZmAnu8gHOqEe988M2bYCiG983s7oGg=
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1612.namprd05.prod.outlook.com (10.161.162.140) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 30 Mar 2016 17:29:55 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0447.024; Wed, 30 Mar 2016 17:29:56 +0000
From: Gert Grammel 
To: "N.Leymann@telekom.de" 
Thread-Topic: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AdGF7u3xjBynKRvjQdyb5YDZuMHPDwEaYbRQABRBloA=
Date: Wed, 30 Mar 2016 17:29:56 +0000
Message-ID: <6AD31E82-8B37-4BA0-8CE3-CCA68632D45B@juniper.net>
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-originating-ip: [95.112.9.50]
x-ms-office365-filtering-correlation-id: 5fe3812c-6e21-4b36-badf-08d358c0e96b
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 5:zd7L01RgT/YxUWD7qVzATYSgKeKXnNX4MN8JgYciSMgzwuHJhUL2EOcfSpSGjLQcJJdSDLMOu5jkYIIPbzzx1kLC1RNTSk64O0xcN/9GXnrVnVkzbhDoSUaIxd5i9ESVETvx48LmNFcP5G7Pz43Yyw==; 24:pAq/EodgXM7R7/mS9gNQkzbZ+yPmsfDUoyLikMP7CbAxNRMRfOYJQycm1RxX3TP/j0tVlROpmLIt+2l3zRvNmfe8ze6d9YkFa4gKeMTYz9c=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1612;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612; 
x-forefront-prvs: 08978A8F5C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(76104003)(53754006)(24454002)(19580395003)(19580405001)(82746002)(83716003)(92566002)(189998001)(87936001)(19617315012)(19625215002)(66066001)(5008740100001)(50986999)(10400500002)(18717965001)(2906002)(81166005)(122556002)(5640700001)(4326007)(97736004)(3280700002)(3660700001)(99286002)(5002640100001)(36756003)(5630700001)(2501003)(76176999)(16236675004)(54356999)(1096002)(6116002)(3846002)(102836003)(790700001)(5004730100002)(586003)(86362001)(2351001)(110136002)(15975445007)(77096005)(2900100001)(1220700001)(2950100001)(33656002)(104396002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_6AD31E828B374BA08CE3CCA68632D45Bjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2016 17:29:56.0926 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1612
Archived-At: 
Cc: "i2rs@ietf.org" , "ops-dir@ietf.org" , "fred@cisco.com" , "shares@ndzh.com" , "jmh.direct@joelhalpern.com" 
Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 30 Mar 2016 17:30:02 -0000

--_000_6AD31E828B374BA08CE3CCA68632D45Bjunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXMgYSBsb25nIHRpbWUgb2JzZXJ2ZXIgSSBhbHNvIGFkbWl0IHRvIGJlIGEgYml0IGF0IG9kZHMg
d2l0aCByZXNwZWN0IHRvIHRoZSB0ZXJtIGVwaGVtZXJhbC4gRGVmaW5pbmcgZXBoZW1lcmFsIGFz
IHRoZSBzZXQgb2YgZGF0YSB0aGF0IGRvZXNuJ3Qgc3Vydml2ZSBhIHJlYm9vdCAoaS5lLiBQb3dl
ciBjeWNsZSkgbG9va3MgYSBiaXQgcm91Z2guDQoNClRoZXJlIHNlZW0gdG8gYmUgMyBjYXNlcyBm
b3Igc3RhdGUgaW5mbyBhZnRlciByZWJvb3Q6DQoxKSB0aGUgc2VydmVyIGlzIGFibGUgdG8gcmVj
b3ZlciBsb3N0IGRhdGEgYnkgbG9jYWwgbWVhbnMuIFRoaXMgaXMgdXN1YWxseSByZWZlcnJlZCB0
byBhcyBwZXJzaXN0ZW50LiAoQWdlbnQgbm90IGludm9sdmVkLCBkYXRhIGlzIHRoZSBzYW1lIGFz
IGJlZm9yZSByZWJvb3QpDQoyKSBhbiBpMnJzIGFnZW50IG5lZWRzIHRvIHJlcHJvdmlzaW9uIGRh
dGEgYWZ0ZXIgcmVib290IChBZ2VudCBpbnZvbHZlZCwgZGF0YSBpcyBjb250cm9sbGVkIGJ5IGFn
ZW50KQ0KMykgdGhlIHNlcnZlciByZWNvbnN0cnVjdHMgZGF0YSBmcm9tIGV4dGVybmFsIHNvdXJj
ZXMgb3RoZXIgdGhhbiBpMnJzIGNsaWVudHMuIChBZ2VudCBub3QgaW52b2x2ZWQsIGRhdGEgbm90
IGNvbnRyb2xsZWQpDQoNClRoZSB0ZXJtICdub24tcGVyc2lzdGVudCcgY292ZXJzIDImMy4NClRo
ZSBjdXJyZW50IGRyYWZ0IHRleHQgdGFsa3MgaW4gc2VjdGlvbiAxLjIgYWJvdXQgImVwaGVtZXJh
bCBzdGF0aWMgc3RhdGUiIHdoaWNoIEkgaW50ZXJwcmV0IGFzIDIpIG9ubHkuIEhvd2V2ZXIgaXQg
aXMgbm90IHNvIGNsZWFyIHdoeSBpdCBpcyBjb25zaWRlcmVkIHN0YXRpYy4NClRoYXQgd291bGQg
bWVhbiBjYXNlIDMpIGlzIGVwaGVtZXJhbCBkeW5hbWljIHN0YXRlLCBidXQgdGhhdCBpc24ndCBk
ZWZpbmVkIHlldCBhbmQgaXQgY291bGQgYmUgYXMgc3RhdGljIGFzIDIpLg0KDQpJIGFkbWl0IGhh
dmluZyB1c2VkIHRoZSB0ZXJtICJlcGhlbWVyYWwiIG1lYW5pbmcgY2FzZSAyKSBvbmx5LCB3aGlj
aCBvY2Nhc2lvbmFsbHkgY2F1c2VzIGNvbmZ1c2lvbi4NCg0KU28geWVzLCBJIGFtIGluIGZhdm9y
IG9mIGFkZGluZyBhIGRlZmluaXRpb24gdG8gdGhlIGFyY2hpdGVjdHVyZS4gQXQgdGhpcyBwb2lu
dCBJIGFtIHVuZGVjaWRlZCBpZiB3ZSBuZWVkIG5ldyB0ZXJtaW5vbG9neSBvciBpZiBhICBuYXJy
b3dlciBkZWZpbml0aW9uIHdvdWxkIGJlIHN1ZmZpY2llbnQuDQoNCkdlcnQNCg0KU2VudCBmcm9t
IG15IEFwcGxlIF1bDQoNCk9uIDMwIE1hciAyMDE2LCBhdCAxMDowMiwgIk4uTGV5bWFubkB0ZWxl
a29tLmRlPG1haWx0bzpOLkxleW1hbm5AdGVsZWtvbS5kZT4iIDxOLkxleW1hbm5AdGVsZWtvbS5k
ZTxtYWlsdG86Ti5MZXltYW5uQHRlbGVrb20uZGU+PiB3cm90ZToNCg0KSGksDQoNCkkgdGhpbmsg
aXTigJlzIGEgZ29vZCBpZGVhIHRvIGdpdmUgYSBkZWZpbml0aW9uIGluIHRoZSBiZWdpbm5pbmcg
b2YgdGhlIGRvY3VtZW50LiBUaGUgaTJycyBkZWZpbml0aW9uIG1hdGNoZXMgYWxzbyBteSBkZWZp
bml0aW9uIHdoaWNoIHdlIGFyZSB1c2luZyB0byBkZXNjcmliZSB0aGUgZmFjdCwgdGhhdCBhIGN1
c3RvbWVyIHNwZWNpZmljIHNlcnZpY2Ug4oCcY29uZmlndXJhdGlvbuKAnSBvbiBhIHNlcnZpY2Ug
bm9kZSBkb2VzIG5vdCBzdXJ2aXZlIGEgcmVib290Lg0KDQpKdXN0IG15IDIgY2VudHMNCg0KTmlj
DQoNClZvbjogaTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2
b24gU3VzYW4gSGFyZXMNCkdlc2VuZGV0OiBEb25uZXJzdGFnLCAyNC4gTcOkcnogMjAxNiAxODow
Mg0KQW46IGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+DQpDYzogJ0pvZWwgSGFs
cGVybiBEaXJlY3QnOyBvcHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPjsg
J0ZyZWQgQmFrZXIgKGZyZWQpJw0KQmV0cmVmZjogW2kycnNdIEVwaGVtZXJhbCAtIFNob3VsZCB3
ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uDQoNCkhp
IGFsbDoNCg0KPHdnIGNoYWlyIGhhdCBvbj4NClRoZSBkcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0
dXJlIGRvY3VtZW50IGhhcyBiZWVuIGFwcHJvdmVkIGFzIGFuIFJGQy4gIEluIHRoZSByZXZpZXcs
IHRoZSBPUFMtRElSIHJldmlldyBpbmRpY2F0ZWQgdGhhdCDigJxlcGhlbWVyYWzigJ0gbWVhbnQg
bW9yZSB0aGFuIOKAnGRvZXMgbm90IHN1cnZpdmUgYSByZWJvb3TigJ0uIFRoZXkgaGF2ZSBhc2tl
ZCB0aGUgSTJSUyB3b3JraW5nIGdyb3VwIGlmIHJlcGxhY2luZyDigJxlcGhlbWVyYWzigJ0gd2l0
aCBub24tcGVyc2lzdGVudCAoYWNyb3NzIHBvd2VyIG9uL29mZiBvciByZWJvb3QgY3ljbGVzKSB3
b3VsZCBiZSBhIGJldHRlciBjaG9pY2UuDQoNCldoYXQgZG8geW91IHRoaW5rIOKAkyBsZWF2ZSBh
dCBpdCBhdCDigJxlcGhlbWVyYWzigJ0gb3IgY2hhbmdlIHRvIOKAnG5vbi1wZXJzaXN0ZW50IChh
Y3Jvc3MgcG93ZXIgb24vb2ZmIG9yIHJlYm9vdCBjeWNsZXMpID8gV2Ugd2lsbCBoYXZlIGEgMSB3
ZWVrIGNhbGwgb24NCg0KVGhpcyB3b3VsZCBtZWFuIGV2ZXJ5IHBsYWNlIHRoYXQg4oCcZXBoZW1l
cmFs4oCdIGlzIGxpc3RlZCwgdGhlIGF1dGhvcnMgd291bGQgcmVwbGFjZSB3aXRoIOKAnG5vbi1w
ZXJzaXN0ZW504oCdLiAgSW4gdGhlIGZpcnN0IGluc3RhbmNlLCB3ZSB3aWxsIGluZGljYXRlIOKA
nG5vbi1wZXJzaXN0ZW50IChhY3Jvc3MgcG93ZXIgb24vb2ZmIG9yIHJlYm9vdCBjeWNsZXMpLg0K
DQo8d2cgY2hhaXIgaGF0IG9mZj4NCg0KQXMgdGhlIGF1dGhvciwgSSB0aGluayB3ZSBhcmUgYmV0
dGVyIHRvIGRlZmluZSBlcGhlbWVyYWwgYXQgdGhlIGJlZ2lubmluZyBhcyDigJxub24tcGVyc2lz
dGVudCAoYWNyb3NzIHBvd2VyIG9uIC9vZmYgb3IgcmVib290KS4gIENoYW5naW5nIHRoZSBkZWZp
bml0aW9uIGF0IHRoaXMgcG9pbnQsIEkgc3VzcGVjdCB3aWxsIHNpbXBseSBjb25mdXNlIHBlb3Bs
ZS4NCg0KU3VlIEhhcmVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQppMnJzIG1haWxpbmcgbGlzdA0KaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0Bp
ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0K

--_000_6AD31E828B374BA08CE3CCA68632D45Bjunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <97B5141106B8374EBAF4D3C6CC449B49@junipernetworks.onmicrosoft.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2PkFzIGEgbG9uZyB0aW1lIG9ic2Vy
dmVyIEkgYWxzbyBhZG1pdCB0byBiZSBhIGJpdCBhdCBvZGRzIHdpdGggcmVzcGVjdCB0byB0aGUg
dGVybSBlcGhlbWVyYWwuIERlZmluaW5nIGVwaGVtZXJhbCBhcyB0aGUgc2V0IG9mIGRhdGEgdGhh
dCBkb2Vzbid0IHN1cnZpdmUgYSByZWJvb3QgKGkuZS4gUG93ZXIgY3ljbGUpIGxvb2tzIGEgYml0
IHJvdWdoLjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rpdj4N
CjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+VGhlcmUgc2VlbSB0byBiZSAzIGNhc2VzIGZv
ciBzdGF0ZSBpbmZvIGFmdGVyIHJlYm9vdDo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h
dHVyZSI+MSkgdGhlIHNlcnZlciBpcyBhYmxlIHRvIHJlY292ZXIgbG9zdCBkYXRhIGJ5IGxvY2Fs
IG1lYW5zLiBUaGlzIGlzIHVzdWFsbHkgcmVmZXJyZWQgdG8gYXMgcGVyc2lzdGVudC4gKEFnZW50
IG5vdCBpbnZvbHZlZCwgZGF0YSBpcyB0aGUgc2FtZSBhcyBiZWZvcmUgcmVib290KTwvZGl2Pg0K
PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4yKSBhbiBpMnJzIGFnZW50IG5lZWRzIHRvIHJl
cHJvdmlzaW9uIGRhdGEgYWZ0ZXIgcmVib290IChBZ2VudCBpbnZvbHZlZCwgZGF0YSBpcyBjb250
cm9sbGVkIGJ5IGFnZW50KTwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4zKSB0
aGUgc2VydmVyIHJlY29uc3RydWN0cyBkYXRhIGZyb20gZXh0ZXJuYWwgc291cmNlcyBvdGhlciB0
aGFuIGkycnMgY2xpZW50cy4gKEFnZW50IG5vdCBpbnZvbHZlZCwgZGF0YSBub3QgY29udHJvbGxl
ZCk8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPg0KPC9kaXY+DQo8ZGl2
IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlRoZSB0ZXJtICdub24tcGVyc2lzdGVudCcgY292ZXJz
IDImYW1wOzMuJm5ic3A7PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlRoZSBj
dXJyZW50IGRyYWZ0IHRleHQgdGFsa3MgaW4gc2VjdGlvbiAxLjIgYWJvdXQgJnF1b3Q7ZXBoZW1l
cmFsIHN0YXRpYyBzdGF0ZSZxdW90OyB3aGljaCBJIGludGVycHJldCBhcyAyKSBvbmx5LiBIb3dl
dmVyIGl0IGlzIG5vdCBzbyBjbGVhciB3aHkgaXQgaXMgY29uc2lkZXJlZCBzdGF0aWMuJm5ic3A7
PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlRoYXQgd291bGQgbWVhbiBjYXNl
IDMpIGlzIGVwaGVtZXJhbCBkeW5hbWljIHN0YXRlLCBidXQgdGhhdCBpc24ndCBkZWZpbmVkIHll
dCBhbmQgaXQgY291bGQgYmUgYXMgc3RhdGljIGFzIDIpLjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVN
YWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+
SSBhZG1pdCBoYXZpbmcgdXNlZCB0aGUgdGVybSAmcXVvdDtlcGhlbWVyYWwmcXVvdDsgbWVhbmlu
ZyBjYXNlIDIpIG9ubHksIHdoaWNoIG9jY2FzaW9uYWxseSBjYXVzZXMgY29uZnVzaW9uLiZuYnNw
OzwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rpdj4NCjxkaXYg
aWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+U28geWVzLCBJIGFtIGluIGZhdm9yIG9mIGFkZGluZyBh
IGRlZmluaXRpb24gdG8gdGhlIGFyY2hpdGVjdHVyZS4gQXQgdGhpcyBwb2ludCBJIGFtIHVuZGVj
aWRlZCBpZiB3ZSBuZWVkIG5ldyB0ZXJtaW5vbG9neSBvciBpZiBhICZuYnNwO25hcnJvd2VyIGRl
ZmluaXRpb24gd291bGQgYmUgc3VmZmljaWVudC48L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNp
Z25hdHVyZSI+PGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPkdlcnQ8
L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPg0KU2VudCBmcm9tIG15IEFw
cGxlIF1bPC9kaXY+DQo8ZGl2Pjxicj4NCk9uIDMwIE1hciAyMDE2LCBhdCAxMDowMiwgJnF1b3Q7
PGEgaHJlZj0ibWFpbHRvOk4uTGV5bWFubkB0ZWxla29tLmRlIj5OLkxleW1hbm5AdGVsZWtvbS5k
ZTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpOLkxleW1hbm5AdGVsZWtvbS5kZSI+Ti5M
ZXltYW5uQHRlbGVrb20uZGU8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu
dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q
IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEg
TWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv
bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg
NCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt
YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRS1NYWlsRm9ybWF0
dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkUtTWFpbEZvcm1h
dHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw
dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSB0aGluayBpdOKAmXMgYSBnb29kIGlkZWEg
dG8gZ2l2ZSBhIGRlZmluaXRpb24gaW4gdGhlIGJlZ2lubmluZyBvZiB0aGUgZG9jdW1lbnQuIFRo
ZSBpMnJzIGRlZmluaXRpb24gbWF0Y2hlcyBhbHNvIG15IGRlZmluaXRpb24gd2hpY2ggd2UgYXJl
IHVzaW5nIHRvIGRlc2NyaWJlIHRoZSBmYWN0LCB0aGF0IGEgY3VzdG9tZXIgc3BlY2lmaWMgc2Vy
dmljZQ0KIOKAnGNvbmZpZ3VyYXRpb27igJ0gb24gYSBzZXJ2aWNlIG5vZGUgZG9lcyBub3Qgc3Vy
dml2ZSBhIHJlYm9vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MUY0OTdEIj5KdXN0IG15IDIgY2VudHMgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj5OaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Wb246PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+IGkycnMgWzxhIGhyZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmci
Pm1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+SW0gQXVmdHJhZyB2b24gPC9i
PlN1c2FuIEhhcmVzPGJyPg0KPGI+R2VzZW5kZXQ6PC9iPiBEb25uZXJzdGFnLCAyNC4gTcOkcnog
MjAxNiAxODowMjxicj4NCjxiPkFuOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmci
PmkycnNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiAnSm9lbCBIYWxwZXJuIERpcmVjdCc7
IDxhIGhyZWY9Im1haWx0bzpvcHMtZGlyQGlldGYub3JnIj5vcHMtZGlyQGlldGYub3JnPC9hPjsg
J0ZyZWQgQmFrZXIgKGZyZWQpJzxicj4NCjxiPkJldHJlZmY6PC9iPiBbaTJyc10gRXBoZW1lcmFs
IC0gU2hvdWxkIHdlIHVzZSBhbm90aGVyIHdvcmQgLSAoMy8yNCB0byA0LzMpIENhbGwgZm9yIG9w
aW5pb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+SGkgYWxsOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZsdDt3ZyBjaGFpciBo
YXQgb24mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj5UaGUgZHJhZnQtaWV0Zi1pMnJzLWFyY2hpdGVjdHVyZSBkb2N1bWVu
dCBoYXMgYmVlbiBhcHByb3ZlZCBhcyBhbiBSRkMuJm5ic3A7IEluIHRoZSByZXZpZXcsIHRoZSBP
UFMtRElSIHJldmlldyBpbmRpY2F0ZWQgdGhhdCDigJxlcGhlbWVyYWzigJ0gbWVhbnQgbW9yZSB0
aGFuIOKAnGRvZXMgbm90IHN1cnZpdmUgYSByZWJvb3TigJ0uIFRoZXkgaGF2ZSBhc2tlZCB0aGUg
STJSUyB3b3JraW5nIGdyb3VwDQogaWYgcmVwbGFjaW5nIOKAnGVwaGVtZXJhbOKAnSB3aXRoIG5v
bi1wZXJzaXN0ZW50IChhY3Jvc3MgcG93ZXIgb24vb2ZmIG9yIHJlYm9vdCBjeWNsZXMpIHdvdWxk
IGJlIGEgYmV0dGVyIGNob2ljZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBkbyB5
b3UgdGhpbmsg4oCTIGxlYXZlIGF0IGl0IGF0IOKAnGVwaGVtZXJhbOKAnSBvciBjaGFuZ2UgdG8g
4oCcbm9uLXBlcnNpc3RlbnQgKGFjcm9zcyBwb3dlciBvbi9vZmYgb3IgcmVib290IGN5Y2xlcykg
PyBXZSB3aWxsIGhhdmUgYSAxIHdlZWsgY2FsbCBvbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlz
IHdvdWxkIG1lYW4gZXZlcnkgcGxhY2UgdGhhdCDigJxlcGhlbWVyYWzigJ0gaXMgbGlzdGVkLCB0
aGUgYXV0aG9ycyB3b3VsZCByZXBsYWNlIHdpdGgg4oCcbm9uLXBlcnNpc3RlbnTigJ0uJm5ic3A7
IEluIHRoZSBmaXJzdCBpbnN0YW5jZSwgd2Ugd2lsbCBpbmRpY2F0ZSDigJxub24tcGVyc2lzdGVu
dCAoYWNyb3NzIHBvd2VyIG9uL29mZiBvciByZWJvb3QgY3ljbGVzKS48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZsdDt3ZyBjaGFpciBoYXQgb2ZmJmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFz
IHRoZSBhdXRob3IsIEkgdGhpbmsgd2UgYXJlIGJldHRlciB0byBkZWZpbmUgZXBoZW1lcmFsIGF0
IHRoZSBiZWdpbm5pbmcgYXMg4oCcbm9uLXBlcnNpc3RlbnQgKGFjcm9zcyBwb3dlciBvbiAvb2Zm
IG9yIHJlYm9vdCkuJm5ic3A7IENoYW5naW5nIHRoZSBkZWZpbml0aW9uIGF0IHRoaXMgcG9pbnQs
IEkgc3VzcGVjdCB3aWxsIHNpbXBseSBjb25mdXNlIHBlb3BsZS4NCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyI+U3VlIEhhcmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNw
YW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+
PGJyPg0KPHNwYW4+aTJycyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0i
bWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFu
PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycyI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPC9hPjwvc3Bhbj48YnI+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_6AD31E828B374BA08CE3CCA68632D45Bjunipernet_--


From nobody Wed Mar 30 17:16: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 0DFF112D519 for ; Wed, 30 Mar 2016 17:16:11 -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 DwgLCwBKcjie for ; Wed, 30 Mar 2016 17:16:09 -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 9744C12D0E0 for ; Wed, 30 Mar 2016 17:16:09 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.134.184.94; 
From: "Susan Hares" 
To: "'Edwin Cordeiro'" , 
References: 
In-Reply-To: 
Date: Wed, 30 Mar 2016 20:15:19 -0400
Message-ID: <000001d18ae2$691ac8a0$3b5059e0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D18AC0.E20928A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJlV1e0/q3iH29oklFKK5yB49q7Up5LFdbg
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: Re: [i2rs] I2RS Hackathon
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, 31 Mar 2016 00:16:11 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0001_01D18AC0.E20928A0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Edwin:

=20

Thank you for the client.  Do you think it would work on unbuntu?  =
I=E2=80=99ve got an ODL environment in oracle Box and running native on =
the unbuntu laptops.=20

=20

Sue=20

=20

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Edwin Cordeiro
Sent: Wednesday, March 30, 2016 11:33 AM
To: i2rs@ietf.org
Subject: [i2rs] I2RS Hackathon

=20

Hi all,

=20

As we are trying to make an I2RS implementation here at TU Munich, we =
created a VM that is running Mininet (to emulate a network), MininExt =
(to implement virtual routers) and OpenDayLight (that we trying to use =
as I2RS agent), the I2RS client we are trying to make using Zebra. The =
I2RS agent is the NETCONF + YANG modules of ODL, but it needs the YANG =
models to be written. The I2RS client is not present as it is not yet =
ready for sharing.

=20

On the previous Hackathon, one of the difficulties for the I2RS was the =
lack of an environment where it could be developed, so we decided to =
share this VM and a basic tutorial to get this network running in the =
hope it could be useful for the approaching Hackathon in Buenos Aires.

=20

The tutorial and VM are available at:=20

http://www.net.in.tum.de/pub/i2rs/

http://www.net.in.tum.de/pub/i2rs/I2RS-Dev-VM.ova - md5: =
af70741cd12b39a9644b0881df516a55

=20

Unfortunately we will not be able to attend this next meeting in person, =
but if you have any question, let us know. We hope the VM to be useful.

=20

Best Regards,

=20

Edwin Cordeiro


------=_NextPart_000_0001_01D18AC0.E20928A0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Edwin:
 
Thank you for the client.=C2=A0 Do you think it would work on =
unbuntu?=C2=A0 I=E2=80=99ve got an ODL environment in oracle Box and =
running native on the unbuntu laptops. 
 
Sue 
 
From:=
 =
i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Edwin =
Cordeiro
Sent: Wednesday, March 30, 2016 11:33 =
AM
To: i2rs@ietf.org
Subject: [i2rs] I2RS =
Hackathon
 
Hi =
all,
 
=

As we are trying to make an =
I2RS implementation here at TU Munich, we created a VM that is running =
Mininet (to emulate a network), MininExt (to implement virtual routers) =
and OpenDayLight (that we trying to use as I2RS agent), the I2RS client =
we are trying to make using Zebra. The I2RS agent is the NETCONF + YANG =
modules of ODL, but it needs the YANG models to be written. The I2RS =
client is not present as it is not yet ready for =
sharing.
 
=

On the previous Hackathon, =
one of the difficulties for the I2RS was the lack of an environment =
where it could be developed, so we decided to share this VM and a basic =
tutorial to get this network running in the hope it could be useful for =
the approaching Hackathon in Buenos =
Aires.
 
=

The tutorial and VM are =
available at: 
http://www.net=
.in.tum.de/pub/i2rs/I2RS-Dev-VM.ova - =
md5: af70741cd12b39a9644b0881df516a55
 
=

Unfortunately we will not =
be able to attend this next meeting in person, but if you have any =
question, let us know. We hope the VM to be =
useful.
 
=

Best =
Regards,
 
=

Edwin =
Cordeiro
<=
/body>
------=_NextPart_000_0001_01D18AC0.E20928A0--


From nobody Thu Mar 31 00:36: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 8C5C612D1B9 for ; Thu, 31 Mar 2016 00:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 hUXoltLZY44U for ; Thu, 31 Mar 2016 00:36:47 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 CFF4412D14C for ; Thu, 31 Mar 2016 00:36:45 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id 20so101513767wmh.1 for ; Thu, 31 Mar 2016 00:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eHRLDSZbiuUdCsxssV1+zcScrFy8BZJb6FBp+PUH4eQ=; b=u+NqBHanDi7/A3mgpRvzoKH0tnBaffy+QUv2vXx8tRMnSCW1A03KqmC4HZLoN51aCw H0KkXQZTTHRYnMTQHLBI8XyOtBq9HkL+9Kre9wbJbK5gGWHGrt6QrT6wWXMLcZt6lJB5 5yj5zax7zsF87TON2FMj7SFG5Rr+BMmJikD4JGv6gU/M17/nyX7ehxmfyPt9A8dmQkDR 5OZRlY0kx5mZ/Njpm6gY1kdzHHOUegkee7bTtAU/aj+xJM8QB31qsbNGVoxBu+jWFCkI II6LSnLYSJmfGRcxp5RMIV0NQIJgwO5zuk27HIqbmGssofv5W4PK5b30rHKR9YLmNgA4 gl1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eHRLDSZbiuUdCsxssV1+zcScrFy8BZJb6FBp+PUH4eQ=; b=X5DQHVppqZ9ESOuU/AS5Cp9Q+SuDm8/jcntBk4lSD2yUDPZIMQ0DRSZvbfXsdxvrAr FugWkhIIIWpPLAPUUEHE3LYNwAr1z+KXCuLXiatMPP63pxWjKYF6iv8t/K8PKgIhWWfr jGNtjr69M/i1dHv3hSew0x5Yp5QOlM3remLViKnAcnNUN1bYB+0NVgeTpzgptqynvvet KQYFdHZ7yUjyKfADSP/iOLiNwAh2CjA/20aRN0fRf87qxbNALv2lIB1QQsEP7E16yPgj 5cGWm0IQyAF0NM7rlxEuoNqYKChkeCNpgYd0r9LkGxY6iZ8SkrsX8LIcKlPY7k4f6C0C WpOQ==
X-Gm-Message-State: AD7BkJIJtSdyHG6m0xq4jBho6nGSR+Fnz3x0uUOTc3n52Sn6Z6jxngu0UeG/18jlxRhobKd6T99LRO55mkUpqg==
X-Received: by 10.28.179.84 with SMTP id c81mr27427478wmf.13.1459409804330; Thu, 31 Mar 2016 00:36:44 -0700 (PDT)
MIME-Version: 1.0
Sender: edwinsc@gmail.com
Received: by 10.28.3.87 with HTTP; Thu, 31 Mar 2016 00:36:14 -0700 (PDT)
In-Reply-To: <000001d18ae2$691ac8a0$3b5059e0$@ndzh.com>
References:  <000001d18ae2$691ac8a0$3b5059e0$@ndzh.com>
From: Edwin Cordeiro 
Date: Thu, 31 Mar 2016 09:36:14 +0200
X-Google-Sender-Auth: btd6iS7yG8FhtbC9E54JiAAxTGU
Message-ID: 
To: Susan Hares 
Content-Type: multipart/alternative; boundary=001a1145392cf80d69052f5352b1
Archived-At: 
Cc: i2rs@ietf.org
Subject: Re: [i2rs] I2RS Hackathon
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, 31 Mar 2016 07:36:49 -0000

--001a1145392cf80d69052f5352b1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Susan,

The VM is a Ubuntu so it is possible to run this emulated network in a
native Ubuntu laptop. The only special requirement is for MiniNExT (
https://github.com/USC-NSL/miniNExT), that does not currently support the
latest version of Mininet, you must use Mininet version 2.1.0. I will add
to the webpage a file with the config files used for Mininet and MiniNExT.

Another option is to run the VM and configure the Virtualbox or VMware
Player to make the network interface of the VM to be in bridge mode or in
internal network with the host machine, that way you may use any program
installed in the host machine to interact with the VM.

BR

Edwin Cordeiro

On Thu, Mar 31, 2016 at 2:15 AM, Susan Hares  wrote:

> Edwin:
>
>
>
> Thank you for the client.  Do you think it would work on unbuntu?  I=E2=
=80=99ve
> got an ODL environment in oracle Box and running native on the unbuntu
> laptops.
>
>
>
> Sue
>
>
>
> *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Edwin Cordeiro
> *Sent:* Wednesday, March 30, 2016 11:33 AM
> *To:* i2rs@ietf.org
> *Subject:* [i2rs] I2RS Hackathon
>
>
>
> Hi all,
>
>
>
> As we are trying to make an I2RS implementation here at TU Munich, we
> created a VM that is running Mininet (to emulate a network), MininExt (to
> implement virtual routers) and OpenDayLight (that we trying to use as I2R=
S
> agent), the I2RS client we are trying to make using Zebra. The I2RS agent
> is the NETCONF + YANG modules of ODL, but it needs the YANG models to be
> written. The I2RS client is not present as it is not yet ready for sharin=
g.
>
>
>
> On the previous Hackathon, one of the difficulties for the I2RS was the
> lack of an environment where it could be developed, so we decided to shar=
e
> this VM and a basic tutorial to get this network running in the hope it
> could be useful for the approaching Hackathon in Buenos Aires.
>
>
>
> The tutorial and VM are available at:
>
> http://www.net.in.tum.de/pub/i2rs/
>
> http://www.net.in.tum.de/pub/i2rs/I2RS-Dev-VM.ova -
> md5: af70741cd12b39a9644b0881df516a55
>
>
>
> Unfortunately we will not be able to attend this next meeting in person,
> but if you have any question, let us know. We hope the VM to be useful.
>
>
>
> Best Regards,
>
>
>
> Edwin Cordeiro
>

--001a1145392cf80d69052f5352b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Susan,

The VM is a Ubuntu so it is possible to run this emulated=
 network in a native Ubuntu laptop. The only special requirement is for MiniNExT (https://github.com/USC-NSL/miniNExT), that does not currently support =
the latest version of Mininet, you must use Mininet version 2.1.0. I will a=
dd to the webpage a file with the config files used for Mininet and=C2=A0MiniNExT.
<=
div class=3D"gmail_default" style=3D""><=
br>
Another option is to run the VM and configure the Virtualbo=
x or VMware Player to make the network interface of the VM to be in bridge =
mode or in internal network with the host machine, that way you may use any=
 program installed in the host machine to interact with the VM.

BR

Edwin Cordeiro
=



On Thu, Mar 31, 2016 at 2:15 AM, Susan Hares=
 <shares@ndzh.com> wrote:
Edwin:
=C2=A0
Thank you for the client.=C2=A0 D=
o you think it would work on unbuntu?=C2=A0 I=E2=80=99ve got an ODL environ=
ment in oracle Box and running native on the unbuntu laptops. 
=C2=A0=

Sue =

=
=C2=A0
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Edwin Corde=
iro
Sent: Wednesday, March 30, 2016 11:33 AM
To: i2rs@ietf.org
Subjec=
t: [i2rs] I2RS Hackathon
=C2=A0
Hi all,
=C2=
=A0
As we are trying to make=
 an I2RS implementation here at TU Munich, we created a VM that is running =
Mininet (to emulate a network), MininExt (to implement virtual routers) and=
 OpenDayLight (that we trying to use as I2RS agent), the I2RS client we are=
 trying to make using Zebra. The I2RS agent is the NETCONF + YANG modules o=
f ODL, but it needs the YANG models to be written. The I2RS client is not p=
resent as it is not yet ready for sharing.
=C2=A0
On the previous Hackathon, one of the difficulties for the I2RS was=
 the lack of an environment where it could be developed, so we decided to s=
hare this VM and a basic tutorial to get this network running in the hope i=
t could be useful for the approaching Hackathon in Buenos Aires.<=
/u>
=C2=A0
=

The tutorial and VM are available at:=C2=A0
http://ww=
w.net.in.tum.de/pub/i2rs/I2RS-Dev-VM.ova - md5:=C2=A0af70741cd12b39a964=
4b0881df516a55
=C2=A0
Unfortunately we wil=
l not be able to attend this next meeting in person, but if you have any qu=
estion, let us know. We hope the VM to be useful.
<=
/div>
=C2=A0
Best Regards,
=C2=A0
Edwin Cordeiro



--001a1145392cf80d69052f5352b1--


From nobody Thu Mar 31 13:09: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 1668C12D0AC; Thu, 31 Mar 2016 13:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level: 
X-Spam-Status: No, score=-4.23 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GUwgLBkcWEPl; Thu, 31 Mar 2016 13:09:34 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562B012D7F1; Thu, 31 Mar 2016 13:09:34 -0700 (PDT)
Received: from 172.18.9.243 (EHLO lhreml706-cah.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXP36817; Thu, 31 Mar 2016 15:09:32 -0500 (CDT)
Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 31 Mar 2016 21:09:31 +0100
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Thu, 31 Mar 2016 13:09:20 -0700
From: Linda Dunbar 
To: Dean Bogdanovic , Susan Hares 
Thread-Topic: [OPS-DIR] [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AQHRhp1eAa7Yh7K2QUSWcGl/MyaSl59qpd2AgABeTQCACP/8kA==
Date: Thu, 31 Mar 2016 20:09:20 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E65FB4@dfweml501-mbb>
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com>  <013201d1869e$e46f7700$ad4e6500$@ndzh.com> <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com>
In-Reply-To: <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.224]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E65FB4dfweml501mbb_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.56FD83FD.00D0, 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: a33ec7e6db64814df9b9be8156b6fec5
Archived-At: 
Cc: Joel Halpern Direct , "ops-dir@ietf.org" , "i2rs@ietf.org" , "BRUNGARD, DEBORAH A" , Gunter Van De Velde 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 31 Mar 2016 20:09:38 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F657E65FB4dfweml501mbb_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXMg4oCcZXBoZW1lcmFs4oCdIHNhbWUgYXMg4oCcdm9sYXRpbGXigJ0gKHdob3NlIG9wcG9zaXRl
IHN0YXRlIGlzIOKAnW5vbi12b2xhdGlsZeKAnSk/DQoNCklzIOKAnG5vbi0gZXBoZW1lcmFs4oCd
ICBzYW1lIGFzIOKAnHBlcnNpc3RlbnTigJ0gIG9yIOKAnCBub24tdm9sYXRpbGXigJ0/DQpMaW5k
YQ0KDQpGcm9tOiBPUFMtRElSIFttYWlsdG86b3BzLWRpci1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgRGVhbiBCb2dkYW5vdmljDQpTZW50OiBGcmlkYXksIE1hcmNoIDI1LCAyMDE2IDI6
MzkgUE0NClRvOiBTdXNhbiBIYXJlcw0KQ2M6IEpvZWwgSGFscGVybiBEaXJlY3Q7IG9wcy1kaXJA
aWV0Zi5vcmc7IEJSVU5HQVJELCBERUJPUkFIIEE7IEd1bnRlciBWYW4gRGUgVmVsZGU7IGkycnNA
aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT1BTLURJUl0gW2kycnNdIEVwaGVtZXJhbCAtIFNob3Vs
ZCB3ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uDQoN
ClN1ZSwNCg0KSU1PLCBlcGhlbWVyYWwgaGFzIHR3byBtZWFuaW5nIGluIGkycnMgYXJjaGl0ZWN0
dXJlDQoNCjEuIGl0IGRvZXNu4oCZdCBzdXJ2aXZlIHJlYm9vdA0KMi4geW91IGNhbuKAmXQgcm9s
bCBiYWNrIHRvIGEgcHJldmlvdXMgZXBoZW1lcmFsIHN0YXRlDQoNCkRlYW4NCg0KT24gTWFyIDI1
LCAyMDE2LCBhdCAxMDowMSBBTSwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86
c2hhcmVzQG5kemguY29tPj4gd3JvdGU6DQoNCkRlYm9yYWg6DQoNClNlY3Rpb24gMiBpcyBleGFj
dGx5IHRoZSBwbGFjZSBJIHdvdWxkIHB1dCB0aGUgZGVmaW5pdGlvbiBvZiBlcGhlbWVyYWwuDQoN
ClN1ZQ0KDQpGcm9tOiBCUlVOR0FSRCwgREVCT1JBSCBBIFttYWlsdG86ZGIzNTQ2QGF0dC5jb21d
DQpTZW50OiBGcmlkYXksIE1hcmNoIDI1LCAyMDE2IDk6NTAgQU0NClRvOiBTdXNhbiBIYXJlczsg
J0ZyZWQgQmFrZXIgKGZyZWQpJzsgJ0d1bnRlciBWYW4gRGUgVmVsZGUnDQpDYzogaTJyc0BpZXRm
Lm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz47IG9wcy1kaXJAaWV0Zi5vcmc8bWFpbHRvOm9wcy1k
aXJAaWV0Zi5vcmc+OyAnSm9lbCBIYWxwZXJuIERpcmVjdCcNClN1YmplY3Q6IFJFOiBbaTJyc10g
W09QUy1ESVJdIEVwaGVtZXJhbCAtIFNob3VsZCB3ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMvMjQg
dG8gNC8zKSBDYWxsIGZvciBvcGluaW9uDQoNCkhpIGFsbCwNCg0KQXMgQWxpYSBpcyBhIGNvLWF1
dGhvciwgSSB3YXMgYXNzaWduZWQgYXMgdGhlIHJlc3BvbnNpYmxlIEFEIGZvciB0aGlzIGRvY3Vt
ZW50LiBUaGUgZG9jdW1lbnQgaXMgbm90IHdpdGggdGhlIFJGQyBFZGl0b3Ig4oCTIGl04oCZcyBi
ZWVuIGFwcHJvdmVkIGJ5IHRoZSBJRVNHIHdpdGggYSByZXZpc2VkIElEIG5lZWRlZCB0byBhZGRy
ZXNzIGNvbW1lbnRzIHJhaXNlZCBieSB0aGUgSUVTRy4gQW5kIHNvIHRoZSBjdXJyZW50IGRpc2N1
c3Npb24uDQoNCkkgaGFkIGFsc28gcmFpc2VkIHRoZSBjb25jZXJuIG9uIG5lZWRpbmcgbW9yZSBj
bGFyaXR5IG9uIHRoZSBkZWZpbml0aW9uIG9mIGVwaGVtZXJhbCBkdXJpbmcgbXkgQUQgcmV2aWV3
LiBUaGUgYXV0aG9ycyBhZGRlZCBzb21lIGluZm9ybWF0aW9uLiBUaGF0IGNsZWFybHkgd2FzIG5v
dCBlbm91Z2guIEFzIHRoZSB0ZXJtIGlzIHVzZWQgbXVsdGlwbGUgdGltZXMgaW4gdGhlIGRvY3Vt
ZW50IGFuZCBpcyB0aGUgYmFzaXMgZm9yIGFub3RoZXIgZHJhZnQgb24gcmVxdWlyZW1lbnRzIChk
cmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlKSB3aGljaCByZWZlcnMgZXh0ZW5zaXZlbHkg
dG8gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCwgSSBhZ3JlZSB0aGUgYXV0aG9ycyBuZWVkIHRv
IGFkZCBtb3JlIGRlZmluaXRpb24uIEZyZWQgaGFzIGEgZ29vZCBzdWdnZXN0aW9uIOKAkyB0aGUg
dGVybSBzaG91bGQgYmUgdmlzaWJsZSBpbiBhIGdsb3NzYXJ5IHNlY3Rpb24gZWFybHkgaW4gdGhl
IGRvY3VtZW50LiBJdOKAmXMgbm90IGN1cnJlbnRseSBpbmNsdWRlZCBpbiBTZWN0aW9uIDLigJlz
IFRlcm1pbm9sb2d5IOKAkyBTdWUsIGhvdyBhYm91dCBhZGRpbmcgaXQgdG8gdGhhdCBzZWN0aW9u
Pw0KDQpJIHRoaW5rIHRoZSBhdXRob3JzIGtub3cgd2hhdCBpcyBuZWVkZWQgYW5kIHRoYW5rIGV2
ZXJ5b25lIGZvciB0aGUgZGlzY3Vzc2lvbiBhbmQgdGhlaXIgdGltZSByZXZpZXdpbmcuDQoNClRo
YW5rcywNCkRlYm9yYWgNCg0KDQoNCkZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXNhbiBIYXJlcw0KU2VudDogRnJpZGF5LCBNYXJjaCAyNSwg
MjAxNiA5OjE4IEFNDQpUbzogJ0ZyZWQgQmFrZXIgKGZyZWQpJyA8ZnJlZEBjaXNjby5jb208bWFp
bHRvOmZyZWRAY2lzY28uY29tPj47ICdHdW50ZXIgVmFuIERlIFZlbGRlJyA8Z3VudGVydmFuZGV2
ZWxkZWNjQGljbG91ZC5jb208bWFpbHRvOmd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPj4N
CkNjOiBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsgb3BzLWRpckBpZXRmLm9y
ZzxtYWlsdG86b3BzLWRpckBpZXRmLm9yZz47ICdKb2VsIEhhbHBlcm4gRGlyZWN0JyA8am1oLmRp
cmVjdEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPj4N
ClN1YmplY3Q6IFJlOiBbaTJyc10gW09QUy1ESVJdIEVwaGVtZXJhbCAtIFNob3VsZCB3ZSB1c2Ug
YW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uDQoNCkZyZWQ6DQoN
ClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldywgYW5kIHlvdXIgY29tbWVudHMgaGVyZS4gIEkgd2lz
aGVkIEnigJlkIGFza2VkIGFib3V0IHRoZSB3b3JkIGVwaGVtZXJhbCBlYXJsaWVyLg0KDQpTdWUN
Cg0KRnJvbTogRnJlZCBCYWtlciAoZnJlZCkgW21haWx0bzpmcmVkQGNpc2NvLmNvbV0NClNlbnQ6
IFRodXJzZGF5LCBNYXJjaCAyNCwgMjAxNiAyOjU5IFBNDQpUbzogR3VudGVyIFZhbiBEZSBWZWxk
ZQ0KQ2M6IFN1c2FuIEhhcmVzOyBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsg
b3BzLWRpckBpZXRmLm9yZzxtYWlsdG86b3BzLWRpckBpZXRmLm9yZz47IEpvZWwgSGFscGVybiBE
aXJlY3QNClN1YmplY3Q6IFJlOiBbT1BTLURJUl0gRXBoZW1lcmFsIC0gU2hvdWxkIHdlIHVzZSBh
bm90aGVyIHdvcmQgLSAoMy8yNCB0byA0LzMpIENhbGwgZm9yIG9waW5pb24NCg0KTXkgY29tbWVu
dCB3YXMgYSByZXZpZXcgY29tbWVudCwgdGhhdCB0aGUgd29yZCB3YXMgYmVpbmcgdXNlZCBpbiBh
IHdheSB0aGF0IHdhc24ndCBjb25zaXN0ZW50IHdpdGggaXRzIGRpY3Rpb25hcnkgZGVmaW5pdGlv
biAoc29tZXRoaW5nIHdpdGggYSBzaG9ydCBsaWZldGltZSwgcXVpdGUgaXJyZXNwZWN0aXZlIG9m
IGJpcnRoL2RlYXRoIHByb2Nlc3Nlcykgb3IgY29tbW9uIHVzYWdlIChhdCBsZWFzdCBpbiBteSBj
b250ZXh0KS4gQXQgdGhpcyBwb2ludCwgdGhlIGRyYWZ0IGhhcyBiZWVuIHNlbnQgdG8gdGhlIFJG
QyBFZGl0b3IsIHNvIHRvIG15IG1pbmQgdGhpcyBkaXNjdXNzaW9uIGlzIG1vc3RseSBtb290LiBJ
ZiBpbiB5b3VyIG90aGVyIGRyYWZ0cyB5b3UgYXJlIHBvaW50aW5nIHBlb3BsZSB0byBhIGdsb3Nz
YXJ5IGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgKHdoaWNoIEkgaW1hZ2luZSB5b3UgYWxy
ZWFkeSBhcmUpIGFuZCB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGRlZmluZXMgdGhlIHRlcm0g
YXMgeW91IGFyZSB1c2luZyBpdCwgeW91IGhhdmUgcHJvYmFibHkgZG9uZSBlbm91Z2guDQoNCk9u
IE1hciAyNCwgMjAxNiwgYXQgMTE6MDcgQU0sIEd1bnRlciBWYW4gRGUgVmVsZGUgPGd1bnRlcnZh
bmRldmVsZGVjY0BpY2xvdWQuY29tPG1haWx0bzpndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNv
bT4+IHdyb3RlOg0KDQpJIGFtIG9rIG5vd2FkYXlzIHdpdGggdXNpbmcgdGhlIHRlcm1pbm9sb2d5
IOKAnEVwaGVtZXJhbOKAnSwgYWx0aG91Z2ggZm9yIGEgbm9uLW5hdHZlIHNwZWFrZXIgaXQgaXMg
bm9uLXRyaXZpYWwgZXhvdGljIHdvcmQsIHBhcnRpY3VsYXIgaWYgdGhlIGludGVuZGVkIHVzYWdl
IGRvZXNu4oCZdCAxMDAlIHJlZmxlY3QgdGhlIFdlYnN0ZXIgZGljdGlvbmFyeSBpbnRlbmRlZCBt
ZWFuaW5nLg0KDQpJdCBpcyBvbmx5IGFib3V0IGEgeWVhciBhZ28gaSBzdGFydGVkIHJlYWRpbmcg
dXAgb24gaTJycyBhbmQgZGlzY292ZXJlZCB0aGlzIHBhcnRpY3VsYXIgdGVybWlub2xvZ3ksIGFu
ZCBhdCB0aGUgdGltZSBhIGdvb2dsZSBzZWFyY2ggb24gdGhpcyB0ZXJtaW5vbG9neSB3YXMgbm90
IHZlcnkgY29uY2x1c2l2ZSBhbmQgcmVzdWx0ZWQgdG8gc29tZSBjb25mdXNpb24uDQpJIHVuZGVy
c3RhbmQgdmVyeSB3ZWxsIHRoZSBjb25mdXNpb24gYXQgcGxheSBoZXJlIGZyb20gbm9uLW5hdGl2
ZSBlbmdsaXNoIHNwZWFrZXIgcGVyc3BlY3RpdmUuDQoNCkFkZGluZyB0ZXh0IHRvIGV4cGxhaW4g
dGhlIGNvbnRleHQgaW4gd2hpY2ggdGhlIHRlcm0gRXBoZW1lcmFsIGlzIHVzZWZ1bC9hZHZpc2Vk
LiBmd2l3IG5vdyB0aGF0IGkgYW0gdXNlZCB0byBzZWVpbmcg4oCYRXBoZW1lcmFsJyBhcyBub24t
cGVybWFuZW50IGNvbmZpZyBhY3Jvc3MgcmVib290LCBp4oCZbSBhZGFwdGVkIGl0cyBpbnRlbmRl
ZCBwdXJwb3Nl4oCmDQoNCklzIHRoZSBnb2FsIHRvIGV4cGxhaW4gdGhlIGludGVuZGVkIG1lYW5p
bmcgaW4gZWFjaCBkcmFmdC9yZmMgbWVudGlvbmluZyBpdD8NCg0KQmUgd2VsbCwNCkcvDQoNCk9u
IDI0IE1hciAyMDE2LCBhdCAxODowMiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWls
dG86c2hhcmVzQG5kemguY29tPj4gd3JvdGU6DQoNCkhpIGFsbDoNCg0KPHdnIGNoYWlyIGhhdCBv
bj4NClRoZSBkcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGhhcyBiZWVuIGFw
cHJvdmVkIGFzIGFuIFJGQy4gIEluIHRoZSByZXZpZXcsIHRoZSBPUFMtRElSIHJldmlldyBpbmRp
Y2F0ZWQgdGhhdCDigJxlcGhlbWVyYWzigJ0gbWVhbnQgbW9yZSB0aGFuIOKAnGRvZXMgbm90IHN1
cnZpdmUgYSByZWJvb3TigJ0uIFRoZXkgaGF2ZSBhc2tlZCB0aGUgSTJSUyB3b3JraW5nIGdyb3Vw
IGlmIHJlcGxhY2luZyDigJxlcGhlbWVyYWzigJ0gd2l0aCBub24tcGVyc2lzdGVudCAoYWNyb3Nz
IHBvd2VyIG9uL29mZiBvciByZWJvb3QgY3ljbGVzKSB3b3VsZCBiZSBhIGJldHRlciBjaG9pY2Uu
DQoNCldoYXQgZG8geW91IHRoaW5rIOKAkyBsZWF2ZSBhdCBpdCBhdCDigJxlcGhlbWVyYWzigJ0g
b3IgY2hhbmdlIHRvIOKAnG5vbi1wZXJzaXN0ZW50IChhY3Jvc3MgcG93ZXIgb24vb2ZmIG9yIHJl
Ym9vdCBjeWNsZXMpID8gV2Ugd2lsbCBoYXZlIGEgMSB3ZWVrIGNhbGwgb24NCg0KVGhpcyB3b3Vs
ZCBtZWFuIGV2ZXJ5IHBsYWNlIHRoYXQg4oCcZXBoZW1lcmFs4oCdIGlzIGxpc3RlZCwgdGhlIGF1
dGhvcnMgd291bGQgcmVwbGFjZSB3aXRoIOKAnG5vbi1wZXJzaXN0ZW504oCdLiAgSW4gdGhlIGZp
cnN0IGluc3RhbmNlLCB3ZSB3aWxsIGluZGljYXRlIOKAnG5vbi1wZXJzaXN0ZW50IChhY3Jvc3Mg
cG93ZXIgb24vb2ZmIG9yIHJlYm9vdCBjeWNsZXMpLg0KDQo8d2cgY2hhaXIgaGF0IG9mZj4NCg0K
QXMgdGhlIGF1dGhvciwgSSB0aGluayB3ZSBhcmUgYmV0dGVyIHRvIGRlZmluZSBlcGhlbWVyYWwg
YXQgdGhlIGJlZ2lubmluZyBhcyDigJxub24tcGVyc2lzdGVudCAoYWNyb3NzIHBvd2VyIG9uIC9v
ZmYgb3IgcmVib290KS4gIENoYW5naW5nIHRoZSBkZWZpbml0aW9uIGF0IHRoaXMgcG9pbnQsIEkg
c3VzcGVjdCB3aWxsIHNpbXBseSBjb25mdXNlIHBlb3BsZS4NCg0KU3VlIEhhcmVzDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFMtRElSIG1haWxp
bmcgbGlzdA0KT1BTLURJUkBpZXRmLm9yZzxtYWlsdG86T1BTLURJUkBpZXRmLm9yZz4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzLWRpcg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT1BTLURJUiBtYWlsaW5nIGxpc3QN
Ck9QUy1ESVJAaWV0Zi5vcmc8bWFpbHRvOk9QUy1ESVJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wcy1kaXINCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCmkycnMgbWFpbGluZyBsaXN0DQppMnJzQGlldGYu
b3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9pMnJzDQoNCg==

--_000_4A95BA014132FF49AE685FAB4B9F17F657E65FB4dfweml501mbb_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K
YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s
b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N
c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy
cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B
Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh
bnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l
OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h
bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy
aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu
Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ
e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+
PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4
dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh
eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r
PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+SXMg4oCcZXBoZW1lcmFs4oCdIHNhbWUgYXMg4oCcdm9sYXRpbGXigJ0gKHdob3NlIG9wcG9z
aXRlIHN0YXRlIGlzIOKAnW5vbi12b2xhdGlsZeKAnSk/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIOKAnG5vbi0g
ZXBoZW1lcmFs4oCdICZuYnNwO3NhbWUgYXMg4oCccGVyc2lzdGVudOKAnSAmbmJzcDtvciDigJwg
bm9uLXZvbGF0aWxl4oCdPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpbmRhPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg
MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4gT1BTLURJUiBbbWFpbHRvOm9wcy1kaXItYm91bmNlc0BpZXRmLm9y
Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGVhbiBCb2dkYW5vdmljPGJyPg0KPGI+U2VudDo8L2I+
IEZyaWRheSwgTWFyY2ggMjUsIDIwMTYgMjozOSBQTTxicj4NCjxiPlRvOjwvYj4gU3VzYW4gSGFy
ZXM8YnI+DQo8Yj5DYzo8L2I+IEpvZWwgSGFscGVybiBEaXJlY3Q7IG9wcy1kaXJAaWV0Zi5vcmc7
IEJSVU5HQVJELCBERUJPUkFIIEE7IEd1bnRlciBWYW4gRGUgVmVsZGU7IGkycnNAaWV0Zi5vcmc8
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPUFMtRElSXSBbaTJyc10gRXBoZW1lcmFsIC0gU2hv
dWxkIHdlIHVzZSBhbm90aGVyIHdvcmQgLSAoMy8yNCB0byA0LzMpIENhbGwgZm9yIG9waW5pb248
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWUsPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8sIGVwaGVtZXJhbCBo
YXMgdHdvIG1lYW5pbmcgaW4gaTJycyBhcmNoaXRlY3R1cmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gaXQgZG9lc27igJl0IHN1cnZpdmUg
cmVib290PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4yLiB5b3UgY2Fu4oCZdCByb2xsIGJhY2sgdG8gYSBwcmV2aW91cyBlcGhlbWVyYWwgc3RhdGU8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVh
bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gTWFyIDI1LCAyMDE2LCBhdCAxMDowMSBBTSwgU3VzYW4gSGFyZXMg
Jmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYm9yYWg6PHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiAyIGlzIGV4YWN0bHkgdGhlIHBsYWNl
IEkgd291bGQgcHV0IHRoZSBkZWZpbml0aW9uIG9mIGVwaGVtZXJhbC48c3BhbiBjbGFzcz0iYXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5TdWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CUlVOR0FSRCwNCiBERUJPUkFIIEEgWzxh
IGhyZWY9Im1haWx0bzpkYjM1NDZAYXR0LmNvbSI+bWFpbHRvOmRiMzU0NkBhdHQuY29tPC9hPl08
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+
U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PkZyaWRheSwgTWFyY2ggMjUsIDIwMTYgOTo1MCBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFz
cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U3VzYW4gSGFyZXM7ICdGcmVk
IEJha2VyIChmcmVkKSc7ICdHdW50ZXIgVmFuIERlIFZlbGRlJzxicj4NCjxiPkNjOjwvYj48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp
bHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm9w
cy1kaXJAaWV0Zi5vcmciPm9wcy1kaXJAaWV0Zi5vcmc8L2E+OyAnSm9lbCBIYWxwZXJuIERpcmVj
dCc8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+UkU6IFtpMnJzXSBbT1BTLURJUl0gRXBoZW1lcmFsIC0gU2hvdWxkIHdl
IHVzZSBhbm90aGVyIHdvcmQgLSAoMy8yNCB0byA0LzMpIENhbGwgZm9yIG9waW5pb248L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
SGkgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgQWxpYSBp
cyBhIGNvLWF1dGhvciwgSSB3YXMgYXNzaWduZWQgYXMgdGhlIHJlc3BvbnNpYmxlIEFEIGZvciB0
aGlzIGRvY3VtZW50LiBUaGUgZG9jdW1lbnQgaXMgbm90IHdpdGggdGhlIFJGQyBFZGl0b3Ig4oCT
IGl04oCZcyBiZWVuIGFwcHJvdmVkIGJ5IHRoZSBJRVNHIHdpdGgNCiBhIHJldmlzZWQgSUQgbmVl
ZGVkIHRvIGFkZHJlc3MgY29tbWVudHMgcmFpc2VkIGJ5IHRoZSBJRVNHLiBBbmQgc28gdGhlIGN1
cnJlbnQgZGlzY3Vzc2lvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkkgaGFkIGFsc28gcmFpc2VkIHRoZSBjb25jZXJuIG9uIG5lZWRpbmcgbW9yZSBjbGFyaXR5IG9u
IHRoZSBkZWZpbml0aW9uIG9mIGVwaGVtZXJhbCBkdXJpbmcgbXkgQUQgcmV2aWV3LiBUaGUgYXV0
aG9ycyBhZGRlZCBzb21lIGluZm9ybWF0aW9uLiBUaGF0IGNsZWFybHkgd2FzDQogbm90IGVub3Vn
aC4gQXMgdGhlIHRlcm0gaXMgdXNlZCBtdWx0aXBsZSB0aW1lcyBpbiB0aGUgZG9jdW1lbnQgYW5k
IGlzIHRoZSBiYXNpcyBmb3IgYW5vdGhlciBkcmFmdCBvbiByZXF1aXJlbWVudHMgKGRyYWZ0LWll
dGYtaTJycy1lcGhlbWVyYWwtc3RhdGUpIHdoaWNoIHJlZmVycyBleHRlbnNpdmVseSB0byB0aGUg
YXJjaGl0ZWN0dXJlIGRvY3VtZW50LCBJIGFncmVlIHRoZSBhdXRob3JzIG5lZWQgdG8gYWRkIG1v
cmUgZGVmaW5pdGlvbi4gRnJlZA0KIGhhcyBhIGdvb2Qgc3VnZ2VzdGlvbiDigJMgdGhlIHRlcm0g
c2hvdWxkIGJlIHZpc2libGUgaW4gYSBnbG9zc2FyeSBzZWN0aW9uIGVhcmx5IGluIHRoZSBkb2N1
bWVudC4gSXTigJlzIG5vdCBjdXJyZW50bHkgaW5jbHVkZWQgaW4gU2VjdGlvbiAy4oCZcyBUZXJt
aW5vbG9neSDigJMgU3VlLCBob3cgYWJvdXQgYWRkaW5nIGl0IHRvIHRoYXQgc2VjdGlvbj88L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhlIGF1dGhvcnMg
a25vdyB3aGF0IGlzIG5lZWRlZCBhbmQgdGhhbmsgZXZlcnlvbmUgZm9yIHRoZSBkaXNjdXNzaW9u
IGFuZCB0aGVpciB0aW1lIHJldmlld2luZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+RGVib3JhaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5pMnJzDQogWzxhIGhyZWY9Im1haWx0bzppMnJzLWJv
dW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppMnJzLWJv
dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5TdXNhbiBIYXJlczxicj4NCjxiPlNlbnQ6PC9i
PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GcmlkYXks
IE1hcmNoIDI1LCAyMDE2IDk6MTggQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPidGcmVkIEJha2VyIChmcmVkKScgJmx0Ozxh
IGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
ZnJlZEBjaXNjby5jb208L3NwYW4+PC9hPiZndDs7ICdHdW50ZXIgVmFuIERlIFZlbGRlJyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tIj48c3BhbiBzdHls
ZT0iY29sb3I6cHVycGxlIj5ndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbTwvc3Bhbj48L2E+
Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPmkycnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9wcy1kaXJAaWV0
Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm9wcy1kaXJAaWV0Zi5vcmc8L3NwYW4+
PC9hPjsNCiAnSm9lbCBIYWxwZXJuIERpcmVjdCcgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWguZGly
ZWN0QGpvZWxoYWxwZXJuLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+am1oLmRpcmVj
dEBqb2VsaGFscGVybi5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtpMnJzXSBb
T1BTLURJUl0gRXBoZW1lcmFsIC0gU2hvdWxkIHdlIHVzZSBhbm90aGVyIHdvcmQgLSAoMy8yNCB0
byA0LzMpIENhbGwgZm9yIG9waW5pb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RnJlZDo8c3BhbiBjbGFzcz0iYXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHRoZSByZXZpZXcsIGFuZCB5b3VyIGNvbW1lbnRzIGhl
cmUuJm5ic3A7IEkgd2lzaGVkIEnigJlkIGFza2VkIGFib3V0IHRoZSB3b3JkIGVwaGVtZXJhbCBl
YXJsaWVyLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1ZTxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD
NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy
ZWQNCiBCYWtlciAoZnJlZCkgWzxhIGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOmZyZWRAY2lzY28uY29tPC9zcGFuPjwvYT5dPHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNl
bnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5U
aHVyc2RheSwgTWFyY2ggMjQsIDIwMTYgMjo1OSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFz
cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+R3VudGVyIFZhbiBEZSBWZWxk
ZTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+U3VzYW4gSGFyZXM7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj5pMnJzQGlldGYub3JnPC9zcGFuPjwvYT47PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpvcHMtZGlyQGll
dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5vcHMtZGlyQGlldGYub3JnPC9zcGFu
PjwvYT47DQogSm9lbCBIYWxwZXJuIERpcmVjdDxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW09QUy1ESVJdIEVw
aGVtZXJhbCAtIFNob3VsZCB3ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxs
IGZvciBvcGluaW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgY29tbWVudCB3YXMgYSByZXZpZXcg
Y29tbWVudCwgdGhhdCB0aGUgd29yZCB3YXMgYmVpbmcgdXNlZCBpbiBhIHdheSB0aGF0IHdhc24n
dCBjb25zaXN0ZW50IHdpdGggaXRzIGRpY3Rpb25hcnkgZGVmaW5pdGlvbiAoc29tZXRoaW5nIHdp
dGggYSBzaG9ydCBsaWZldGltZSwgcXVpdGUgaXJyZXNwZWN0aXZlIG9mIGJpcnRoL2RlYXRoIHBy
b2Nlc3Nlcykgb3IgY29tbW9uIHVzYWdlIChhdCBsZWFzdCBpbiBteQ0KIGNvbnRleHQpLiBBdCB0
aGlzIHBvaW50LCB0aGUgZHJhZnQgaGFzIGJlZW4gc2VudCB0byB0aGUgUkZDIEVkaXRvciwgc28g
dG8gbXkgbWluZCB0aGlzIGRpc2N1c3Npb24gaXMgbW9zdGx5IG1vb3QuIElmIGluIHlvdXIgb3Ro
ZXIgZHJhZnRzIHlvdSBhcmUgcG9pbnRpbmcgcGVvcGxlIHRvIGEgZ2xvc3NhcnkgaW4gdGhlIGFy
Y2hpdGVjdHVyZSBkb2N1bWVudCAod2hpY2ggSSBpbWFnaW5lIHlvdSBhbHJlYWR5IGFyZSkgYW5k
IHRoZSBhcmNoaXRlY3R1cmUNCiBkb2N1bWVudCBkZWZpbmVzIHRoZSB0ZXJtIGFzIHlvdSBhcmUg
dXNpbmcgaXQsIHlvdSBoYXZlIHByb2JhYmx5IGRvbmUgZW5vdWdoLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uIE1hciAyNCwgMjAxNiwgYXQgMTE6MDcgQU0sIEd1bnRlciBWYW4gRGUgVmVsZGUgJmx0
OzxhIGhyZWY9Im1haWx0bzpndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbSI+PHNwYW4gc3R5
bGU9ImNvbG9yOnB1cnBsZSI+Z3VudGVydmFuZGV2ZWxkZWNjQGljbG91ZC5jb208L3NwYW4+PC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBvayBub3dhZGF5cyB3
aXRoIHVzaW5nIHRoZSB0ZXJtaW5vbG9neSDigJxFcGhlbWVyYWzigJ0sIGFsdGhvdWdoIGZvciBh
IG5vbi1uYXR2ZSBzcGVha2VyIGl0IGlzIG5vbi10cml2aWFsIGV4b3RpYyB3b3JkLCBwYXJ0aWN1
bGFyIGlmIHRoZSBpbnRlbmRlZCB1c2FnZSBkb2VzbuKAmXQgMTAwJSByZWZsZWN0IHRoZSBXZWJz
dGVyIGRpY3Rpb25hcnkgaW50ZW5kZWQgbWVhbmluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SXQgaXMgb25seSBhYm91dCBhIHllYXIgYWdvIGkgc3RhcnRlZCByZWFkaW5nIHVwIG9uIGky
cnMgYW5kIGRpc2NvdmVyZWQgdGhpcyBwYXJ0aWN1bGFyIHRlcm1pbm9sb2d5LCBhbmQgYXQgdGhl
IHRpbWUgYSBnb29nbGUgc2VhcmNoIG9uIHRoaXMgdGVybWlub2xvZ3kgd2FzIG5vdCB2ZXJ5IGNv
bmNsdXNpdmUgYW5kIHJlc3VsdGVkIHRvIHNvbWUgY29uZnVzaW9uLiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSB1bmRlcnN0YW5kIHZlcnkgd2VsbCB0aGUgY29uZnVzaW9uIGF0IHBsYXkgaGVyZSBmcm9tIG5v
bi1uYXRpdmUgZW5nbGlzaCBzcGVha2VyIHBlcnNwZWN0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5BZGRpbmcgdGV4dCB0byBleHBsYWluIHRoZSBjb250ZXh0IGluIHdoaWNoIHRoZSB0
ZXJtIEVwaGVtZXJhbCBpcyB1c2VmdWwvYWR2aXNlZC4gZndpdyBub3cgdGhhdCBpIGFtIHVzZWQg
dG8gc2VlaW5nIOKAmEVwaGVtZXJhbCcgYXMgbm9uLXBlcm1hbmVudCBjb25maWcgYWNyb3NzIHJl
Ym9vdCwgaeKAmW0gYWRhcHRlZCBpdHMgaW50ZW5kZWQgcHVycG9zZeKApiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGUgZ29hbCB0byBleHBsYWluIHRoZSBpbnRlbmRlZCBt
ZWFuaW5nIGluIGVhY2ggZHJhZnQvcmZjIG1lbnRpb25pbmcgaXQ/PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkJlIHdlbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HLzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAy
NCBNYXIgMjAxNiwgYXQgMTg6MDIsIFN1c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hh
cmVzQG5kemguY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zaGFyZXNAbmR6aC5jb208
L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkhpIGFsbDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZs
dDt3ZyBjaGFpciBoYXQgb24mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+VGhlIGRyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUgZG9jdW1lbnQgaGFzIGJlZW4gYXBw
cm92ZWQgYXMgYW4gUkZDLiZuYnNwOyBJbiB0aGUgcmV2aWV3LCB0aGUgT1BTLURJUiByZXZpZXcg
aW5kaWNhdGVkIHRoYXQg4oCcZXBoZW1lcmFs4oCdIG1lYW50IG1vcmUgdGhhbiDigJxkb2VzIG5v
dCBzdXJ2aXZlIGEgcmVib2904oCdLg0KIFRoZXkgaGF2ZSBhc2tlZCB0aGUgSTJSUyB3b3JraW5n
IGdyb3VwIGlmIHJlcGxhY2luZyDigJxlcGhlbWVyYWzigJ0gd2l0aCBub24tcGVyc2lzdGVudCAo
YWNyb3NzIHBvd2VyIG9uL29mZiBvciByZWJvb3QgY3ljbGVzKSB3b3VsZCBiZSBhIGJldHRlciBj
aG9pY2UuJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGF0IGRvIHlv
dSB0aGluayDigJMgbGVhdmUgYXQgaXQgYXQg4oCcZXBoZW1lcmFs4oCdIG9yIGNoYW5nZSB0byDi
gJxub24tcGVyc2lzdGVudCAoYWNyb3NzIHBvd2VyIG9uL29mZiBvciByZWJvb3QgY3ljbGVzKSA/
IFdlIHdpbGwgaGF2ZSBhIDEgd2VlayBjYWxsIG9uPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5UaGlzIHdvdWxkIG1lYW4gZXZlcnkgcGxhY2UgdGhhdCDigJxlcGhlbWVyYWzigJ0g
aXMgbGlzdGVkLCB0aGUgYXV0aG9ycyB3b3VsZCByZXBsYWNlIHdpdGgg4oCcbm9uLXBlcnNpc3Rl
bnTigJ0uJm5ic3A7IEluIHRoZSBmaXJzdCBpbnN0YW5jZSwgd2Ugd2lsbCBpbmRpY2F0ZSDigJxu
b24tcGVyc2lzdGVudCAoYWNyb3NzDQogcG93ZXIgb24vb2ZmIG9yIHJlYm9vdCBjeWNsZXMpLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbHQ7d2cgY2hhaXIgaGF0
IG9mZiZndDsgJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkFzIHRoZSBhdXRob3IsIEkgdGhpbmsgd2UgYXJlIGJldHRlciB0byBkZWZpbmUgZXBoZW1lcmFs
IGF0IHRoZSBiZWdpbm5pbmcgYXMg4oCcbm9uLXBlcnNpc3RlbnQgKGFjcm9zcyBwb3dlciBvbiAv
b2ZmIG9yIHJlYm9vdCkuJm5ic3A7IENoYW5naW5nIHRoZSBkZWZpbml0aW9uIGF0IHRoaXMgcG9p
bnQsIEkgc3VzcGVjdA0KIHdpbGwgc2ltcGx5IGNvbmZ1c2UgcGVvcGxlLjxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3VlIEhhcmVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KT1BTLURJUiBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9Q
Uy1ESVJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cHVycGxl
Ij5PUFMtRElSQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vcHMtZGlyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnB1cnBsZSI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHMtZGlyPC9zcGFuPjwvYT48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPUFMtRElSIG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzpPUFMtRElSQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy
cGxlIj5PUFMtRElSQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wcy1kaXIiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzLWRpcjwvc3Bh
bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQppMnJzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3Jn
Ij5pMnJzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vaTJycyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9pMnJzPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_4A95BA014132FF49AE685FAB4B9F17F657E65FB4dfweml501mbb_--



From nobody Thu Mar 31 13:16: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 1FF9F12D804; Thu, 31 Mar 2016 13:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Y5im-ScEFUFd; Thu, 31 Mar 2016 13:16:35 -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 AFB6E12D7FE; Thu, 31 Mar 2016 13:16:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44890; q=dns/txt; s=iport; t=1459455394; x=1460664994; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=21n4iCLAL7TCJvV9wNUleL7dlD2IIXE//hZMmDmpTms=; b=aqMw3GODKXgJIsWssoMDw4+WAhZ3YprCooslxvuproZGJCou2hb1H3yb 8NByxZtgHZN0cQYOANev/oNtAg50IJVpN7YALiAmmN5W68mqjIm6ptv8/ e3mbhh3CPPE5hNqrc8WR1F+gLbhwvkJn5N5wmt30pk2JqTYqJW8UEoBTN U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgAahf1W/4QNJK1dgmdMU30GrzuLU?= =?us-ascii?q?gENgW8DFwEJhWwCHIErOBQBAQEBAQEBZSeEQQEBAQQBAQEaBgpBCxACAQgRAQM?= =?us-ascii?q?BASEBBgMCAgIfBgsUAwYIAgQBDQUIiAoDEg6yJYwPDYRtAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBEQSGHoRGgkCBYkkJgkqCVgWISIpJhDAxAYwSgW6PFIdBh1MBHgE?= =?us-ascii?q?BQoIygTVsh29+AQEB?=
X-IronPort-AV: E=Sophos;i="5.24,424,1454976000";  d="scan'208,217";a="256016708"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Mar 2016 20:16:33 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u2VKGXvX022457 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Mar 2016 20:16:33 GMT
Received: from xch-aln-012.cisco.com (173.36.7.22) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 31 Mar 2016 15:16:32 -0500
Received: from xch-aln-012.cisco.com ([173.36.7.22]) by XCH-ALN-012.cisco.com ([173.36.7.22]) with mapi id 15.00.1104.009; Thu, 31 Mar 2016 15:16:32 -0500
From: "Steve Braaten (sbraaten)" 
To: Linda Dunbar , Dean Bogdanovic , Susan Hares 
Thread-Topic: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
Thread-Index: AQHRhi0Poz247/H79UOW0MOuz5MYpp9qpd2AgABeTQCACP/8kIAAAvsA
Date: Thu, 31 Mar 2016 20:16:32 +0000
Message-ID: <9f4ce7959f84493cbcf2babcc1597049@XCH-ALN-012.cisco.com>
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com>  <013201d1869e$e46f7700$ad4e6500$@ndzh.com> <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657E65FB4@dfweml501-mbb>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E65FB4@dfweml501-mbb>
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.128.4.28]
Content-Type: multipart/alternative; boundary="_000_9f4ce7959f84493cbcf2babcc1597049XCHALN012ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: Joel Halpern Direct , "ops-dir@ietf.org" , Gunter Van De Velde , "BRUNGARD, DEBORAH A" , "i2rs@ietf.org" 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 31 Mar 2016 20:16:38 -0000

--_000_9f4ce7959f84493cbcf2babcc1597049XCHALN012ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RXBoZW1lcmFsID0g4oCcc2hvcnQtbGl2ZWTigJ0gb3Ig4oCcY2hhbmdlcyBmcmVxdWVudGx54oCd
DQoNClRoZXJlIGlzIG5vdGhpbmcgdG8gc3RvcCBhbiBpbXBsZW1lbnRhdGlvbiBmcm9tIHN0b3Jp
bmcgdGhlIGxhdGVzdCDigJxlcGhlbWVyYWzigJ0gc3RhdGUgaW4gYSDigJxwZXJzaXN0ZW504oCd
IHdheSBzdWNoIHRoYXQgaXQgcmV0dXJucyB0byB0aGF0IHN0YXRlICh0aGUgbGFzdCBrbm93biBz
dGF0ZSkgaWYgaXQgcmVzdGFydHMgZm9yIGFueSByZWFzb24gKHBsYW5uZWQgb3IgdW4tcGxhbm5l
ZCkuDQoNCk15IGh1bWJsZSBvcGluaW9uLg0KDQpTdGV2ZQ0KDQoNCkZyb206IGkycnMgW21haWx0
bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaW5kYSBEdW5iYXINClNlbnQ6
IFRodXJzZGF5LCBNYXJjaCAzMSwgMjAxNiAxOjA5IFBNDQpUbzogRGVhbiBCb2dkYW5vdmljIDxp
dmFuZGVhbkBnbWFpbC5jb20+OyBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KQ2M6IEpv
ZWwgSGFscGVybiBEaXJlY3QgPGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPjsgb3BzLWRpckBp
ZXRmLm9yZzsgaTJyc0BpZXRmLm9yZzsgQlJVTkdBUkQsIERFQk9SQUggQSA8ZGIzNTQ2QGF0dC5j
b20+OyBHdW50ZXIgVmFuIERlIFZlbGRlIDxndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbT4N
ClN1YmplY3Q6IFJlOiBbaTJyc10gW09QUy1ESVJdIEVwaGVtZXJhbCAtIFNob3VsZCB3ZSB1c2Ug
YW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uDQoNCklzIOKAnGVw
aGVtZXJhbOKAnSBzYW1lIGFzIOKAnHZvbGF0aWxl4oCdICh3aG9zZSBvcHBvc2l0ZSBzdGF0ZSBp
cyDigJ1ub24tdm9sYXRpbGXigJ0pPw0KDQpJcyDigJxub24tIGVwaGVtZXJhbOKAnSAgc2FtZSBh
cyDigJxwZXJzaXN0ZW504oCdICBvciDigJwgbm9uLXZvbGF0aWxl4oCdPw0KTGluZGENCg0KRnJv
bTogT1BTLURJUiBbbWFpbHRvOm9wcy1kaXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IERlYW4gQm9nZGFub3ZpYw0KU2VudDogRnJpZGF5LCBNYXJjaCAyNSwgMjAxNiAyOjM5IFBNDQpU
bzogU3VzYW4gSGFyZXMNCkNjOiBKb2VsIEhhbHBlcm4gRGlyZWN0OyBvcHMtZGlyQGlldGYub3Jn
PG1haWx0bzpvcHMtZGlyQGlldGYub3JnPjsgQlJVTkdBUkQsIERFQk9SQUggQTsgR3VudGVyIFZh
biBEZSBWZWxkZTsgaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NClN1YmplY3Q6
IFJlOiBbT1BTLURJUl0gW2kycnNdIEVwaGVtZXJhbCAtIFNob3VsZCB3ZSB1c2UgYW5vdGhlciB3
b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uDQoNClN1ZSwNCg0KSU1PLCBlcGhl
bWVyYWwgaGFzIHR3byBtZWFuaW5nIGluIGkycnMgYXJjaGl0ZWN0dXJlDQoNCjEuIGl0IGRvZXNu
4oCZdCBzdXJ2aXZlIHJlYm9vdA0KMi4geW91IGNhbuKAmXQgcm9sbCBiYWNrIHRvIGEgcHJldmlv
dXMgZXBoZW1lcmFsIHN0YXRlDQoNCkRlYW4NCg0KT24gTWFyIDI1LCAyMDE2LCBhdCAxMDowMSBB
TSwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4g
d3JvdGU6DQoNCkRlYm9yYWg6DQoNClNlY3Rpb24gMiBpcyBleGFjdGx5IHRoZSBwbGFjZSBJIHdv
dWxkIHB1dCB0aGUgZGVmaW5pdGlvbiBvZiBlcGhlbWVyYWwuDQoNClN1ZQ0KDQpGcm9tOiBCUlVO
R0FSRCwgREVCT1JBSCBBIFttYWlsdG86ZGIzNTQ2QGF0dC5jb21dDQpTZW50OiBGcmlkYXksIE1h
cmNoIDI1LCAyMDE2IDk6NTAgQU0NClRvOiBTdXNhbiBIYXJlczsgJ0ZyZWQgQmFrZXIgKGZyZWQp
JzsgJ0d1bnRlciBWYW4gRGUgVmVsZGUnDQpDYzogaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0Bp
ZXRmLm9yZz47IG9wcy1kaXJAaWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyAnSm9l
bCBIYWxwZXJuIERpcmVjdCcNClN1YmplY3Q6IFJFOiBbaTJyc10gW09QUy1ESVJdIEVwaGVtZXJh
bCAtIFNob3VsZCB3ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBv
cGluaW9uDQoNCkhpIGFsbCwNCg0KQXMgQWxpYSBpcyBhIGNvLWF1dGhvciwgSSB3YXMgYXNzaWdu
ZWQgYXMgdGhlIHJlc3BvbnNpYmxlIEFEIGZvciB0aGlzIGRvY3VtZW50LiBUaGUgZG9jdW1lbnQg
aXMgbm90IHdpdGggdGhlIFJGQyBFZGl0b3Ig4oCTIGl04oCZcyBiZWVuIGFwcHJvdmVkIGJ5IHRo
ZSBJRVNHIHdpdGggYSByZXZpc2VkIElEIG5lZWRlZCB0byBhZGRyZXNzIGNvbW1lbnRzIHJhaXNl
ZCBieSB0aGUgSUVTRy4gQW5kIHNvIHRoZSBjdXJyZW50IGRpc2N1c3Npb24uDQoNCkkgaGFkIGFs
c28gcmFpc2VkIHRoZSBjb25jZXJuIG9uIG5lZWRpbmcgbW9yZSBjbGFyaXR5IG9uIHRoZSBkZWZp
bml0aW9uIG9mIGVwaGVtZXJhbCBkdXJpbmcgbXkgQUQgcmV2aWV3LiBUaGUgYXV0aG9ycyBhZGRl
ZCBzb21lIGluZm9ybWF0aW9uLiBUaGF0IGNsZWFybHkgd2FzIG5vdCBlbm91Z2guIEFzIHRoZSB0
ZXJtIGlzIHVzZWQgbXVsdGlwbGUgdGltZXMgaW4gdGhlIGRvY3VtZW50IGFuZCBpcyB0aGUgYmFz
aXMgZm9yIGFub3RoZXIgZHJhZnQgb24gcmVxdWlyZW1lbnRzIChkcmFmdC1pZXRmLWkycnMtZXBo
ZW1lcmFsLXN0YXRlKSB3aGljaCByZWZlcnMgZXh0ZW5zaXZlbHkgdG8gdGhlIGFyY2hpdGVjdHVy
ZSBkb2N1bWVudCwgSSBhZ3JlZSB0aGUgYXV0aG9ycyBuZWVkIHRvIGFkZCBtb3JlIGRlZmluaXRp
b24uIEZyZWQgaGFzIGEgZ29vZCBzdWdnZXN0aW9uIOKAkyB0aGUgdGVybSBzaG91bGQgYmUgdmlz
aWJsZSBpbiBhIGdsb3NzYXJ5IHNlY3Rpb24gZWFybHkgaW4gdGhlIGRvY3VtZW50LiBJdOKAmXMg
bm90IGN1cnJlbnRseSBpbmNsdWRlZCBpbiBTZWN0aW9uIDLigJlzIFRlcm1pbm9sb2d5IOKAkyBT
dWUsIGhvdyBhYm91dCBhZGRpbmcgaXQgdG8gdGhhdCBzZWN0aW9uPw0KDQpJIHRoaW5rIHRoZSBh
dXRob3JzIGtub3cgd2hhdCBpcyBuZWVkZWQgYW5kIHRoYW5rIGV2ZXJ5b25lIGZvciB0aGUgZGlz
Y3Vzc2lvbiBhbmQgdGhlaXIgdGltZSByZXZpZXdpbmcuDQoNClRoYW5rcywNCkRlYm9yYWgNCg0K
DQoNCkZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBTdXNhbiBIYXJlcw0KU2VudDogRnJpZGF5LCBNYXJjaCAyNSwgMjAxNiA5OjE4IEFNDQpUbzog
J0ZyZWQgQmFrZXIgKGZyZWQpJyA8ZnJlZEBjaXNjby5jb208bWFpbHRvOmZyZWRAY2lzY28uY29t
Pj47ICdHdW50ZXIgVmFuIERlIFZlbGRlJyA8Z3VudGVydmFuZGV2ZWxkZWNjQGljbG91ZC5jb208
bWFpbHRvOmd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPj4NCkNjOiBpMnJzQGlldGYub3Jn
PG1haWx0bzppMnJzQGlldGYub3JnPjsgb3BzLWRpckBpZXRmLm9yZzxtYWlsdG86b3BzLWRpckBp
ZXRmLm9yZz47ICdKb2VsIEhhbHBlcm4gRGlyZWN0JyA8am1oLmRpcmVjdEBqb2VsaGFscGVybi5j
b208bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPj4NClN1YmplY3Q6IFJlOiBbaTJy
c10gW09QUy1ESVJdIEVwaGVtZXJhbCAtIFNob3VsZCB3ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMv
MjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uDQoNCkZyZWQ6DQoNClRoYW5rIHlvdSBmb3IgdGhl
IHJldmlldywgYW5kIHlvdXIgY29tbWVudHMgaGVyZS4gIEkgd2lzaGVkIEnigJlkIGFza2VkIGFi
b3V0IHRoZSB3b3JkIGVwaGVtZXJhbCBlYXJsaWVyLg0KDQpTdWUNCg0KRnJvbTogRnJlZCBCYWtl
ciAoZnJlZCkgW21haWx0bzpmcmVkQGNpc2NvLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAy
NCwgMjAxNiAyOjU5IFBNDQpUbzogR3VudGVyIFZhbiBEZSBWZWxkZQ0KQ2M6IFN1c2FuIEhhcmVz
OyBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsgb3BzLWRpckBpZXRmLm9yZzxt
YWlsdG86b3BzLWRpckBpZXRmLm9yZz47IEpvZWwgSGFscGVybiBEaXJlY3QNClN1YmplY3Q6IFJl
OiBbT1BTLURJUl0gRXBoZW1lcmFsIC0gU2hvdWxkIHdlIHVzZSBhbm90aGVyIHdvcmQgLSAoMy8y
NCB0byA0LzMpIENhbGwgZm9yIG9waW5pb24NCg0KTXkgY29tbWVudCB3YXMgYSByZXZpZXcgY29t
bWVudCwgdGhhdCB0aGUgd29yZCB3YXMgYmVpbmcgdXNlZCBpbiBhIHdheSB0aGF0IHdhc24ndCBj
b25zaXN0ZW50IHdpdGggaXRzIGRpY3Rpb25hcnkgZGVmaW5pdGlvbiAoc29tZXRoaW5nIHdpdGgg
YSBzaG9ydCBsaWZldGltZSwgcXVpdGUgaXJyZXNwZWN0aXZlIG9mIGJpcnRoL2RlYXRoIHByb2Nl
c3Nlcykgb3IgY29tbW9uIHVzYWdlIChhdCBsZWFzdCBpbiBteSBjb250ZXh0KS4gQXQgdGhpcyBw
b2ludCwgdGhlIGRyYWZ0IGhhcyBiZWVuIHNlbnQgdG8gdGhlIFJGQyBFZGl0b3IsIHNvIHRvIG15
IG1pbmQgdGhpcyBkaXNjdXNzaW9uIGlzIG1vc3RseSBtb290LiBJZiBpbiB5b3VyIG90aGVyIGRy
YWZ0cyB5b3UgYXJlIHBvaW50aW5nIHBlb3BsZSB0byBhIGdsb3NzYXJ5IGluIHRoZSBhcmNoaXRl
Y3R1cmUgZG9jdW1lbnQgKHdoaWNoIEkgaW1hZ2luZSB5b3UgYWxyZWFkeSBhcmUpIGFuZCB0aGUg
YXJjaGl0ZWN0dXJlIGRvY3VtZW50IGRlZmluZXMgdGhlIHRlcm0gYXMgeW91IGFyZSB1c2luZyBp
dCwgeW91IGhhdmUgcHJvYmFibHkgZG9uZSBlbm91Z2guDQoNCk9uIE1hciAyNCwgMjAxNiwgYXQg
MTE6MDcgQU0sIEd1bnRlciBWYW4gRGUgVmVsZGUgPGd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQu
Y29tPG1haWx0bzpndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbT4+IHdyb3RlOg0KDQpJIGFt
IG9rIG5vd2FkYXlzIHdpdGggdXNpbmcgdGhlIHRlcm1pbm9sb2d5IOKAnEVwaGVtZXJhbOKAnSwg
YWx0aG91Z2ggZm9yIGEgbm9uLW5hdHZlIHNwZWFrZXIgaXQgaXMgbm9uLXRyaXZpYWwgZXhvdGlj
IHdvcmQsIHBhcnRpY3VsYXIgaWYgdGhlIGludGVuZGVkIHVzYWdlIGRvZXNu4oCZdCAxMDAlIHJl
ZmxlY3QgdGhlIFdlYnN0ZXIgZGljdGlvbmFyeSBpbnRlbmRlZCBtZWFuaW5nLg0KDQpJdCBpcyBv
bmx5IGFib3V0IGEgeWVhciBhZ28gaSBzdGFydGVkIHJlYWRpbmcgdXAgb24gaTJycyBhbmQgZGlz
Y292ZXJlZCB0aGlzIHBhcnRpY3VsYXIgdGVybWlub2xvZ3ksIGFuZCBhdCB0aGUgdGltZSBhIGdv
b2dsZSBzZWFyY2ggb24gdGhpcyB0ZXJtaW5vbG9neSB3YXMgbm90IHZlcnkgY29uY2x1c2l2ZSBh
bmQgcmVzdWx0ZWQgdG8gc29tZSBjb25mdXNpb24uDQpJIHVuZGVyc3RhbmQgdmVyeSB3ZWxsIHRo
ZSBjb25mdXNpb24gYXQgcGxheSBoZXJlIGZyb20gbm9uLW5hdGl2ZSBlbmdsaXNoIHNwZWFrZXIg
cGVyc3BlY3RpdmUuDQoNCkFkZGluZyB0ZXh0IHRvIGV4cGxhaW4gdGhlIGNvbnRleHQgaW4gd2hp
Y2ggdGhlIHRlcm0gRXBoZW1lcmFsIGlzIHVzZWZ1bC9hZHZpc2VkLiBmd2l3IG5vdyB0aGF0IGkg
YW0gdXNlZCB0byBzZWVpbmcg4oCYRXBoZW1lcmFsJyBhcyBub24tcGVybWFuZW50IGNvbmZpZyBh
Y3Jvc3MgcmVib290LCBp4oCZbSBhZGFwdGVkIGl0cyBpbnRlbmRlZCBwdXJwb3Nl4oCmDQoNCklz
IHRoZSBnb2FsIHRvIGV4cGxhaW4gdGhlIGludGVuZGVkIG1lYW5pbmcgaW4gZWFjaCBkcmFmdC9y
ZmMgbWVudGlvbmluZyBpdD8NCg0KQmUgd2VsbCwNCkcvDQoNCk9uIDI0IE1hciAyMDE2LCBhdCAx
ODowMiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29t
Pj4gd3JvdGU6DQoNCkhpIGFsbDoNCg0KPHdnIGNoYWlyIGhhdCBvbj4NClRoZSBkcmFmdC1pZXRm
LWkycnMtYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGhhcyBiZWVuIGFwcHJvdmVkIGFzIGFuIFJGQy4g
IEluIHRoZSByZXZpZXcsIHRoZSBPUFMtRElSIHJldmlldyBpbmRpY2F0ZWQgdGhhdCDigJxlcGhl
bWVyYWzigJ0gbWVhbnQgbW9yZSB0aGFuIOKAnGRvZXMgbm90IHN1cnZpdmUgYSByZWJvb3TigJ0u
IFRoZXkgaGF2ZSBhc2tlZCB0aGUgSTJSUyB3b3JraW5nIGdyb3VwIGlmIHJlcGxhY2luZyDigJxl
cGhlbWVyYWzigJ0gd2l0aCBub24tcGVyc2lzdGVudCAoYWNyb3NzIHBvd2VyIG9uL29mZiBvciBy
ZWJvb3QgY3ljbGVzKSB3b3VsZCBiZSBhIGJldHRlciBjaG9pY2UuDQoNCldoYXQgZG8geW91IHRo
aW5rIOKAkyBsZWF2ZSBhdCBpdCBhdCDigJxlcGhlbWVyYWzigJ0gb3IgY2hhbmdlIHRvIOKAnG5v
bi1wZXJzaXN0ZW50IChhY3Jvc3MgcG93ZXIgb24vb2ZmIG9yIHJlYm9vdCBjeWNsZXMpID8gV2Ug
d2lsbCBoYXZlIGEgMSB3ZWVrIGNhbGwgb24NCg0KVGhpcyB3b3VsZCBtZWFuIGV2ZXJ5IHBsYWNl
IHRoYXQg4oCcZXBoZW1lcmFs4oCdIGlzIGxpc3RlZCwgdGhlIGF1dGhvcnMgd291bGQgcmVwbGFj
ZSB3aXRoIOKAnG5vbi1wZXJzaXN0ZW504oCdLiAgSW4gdGhlIGZpcnN0IGluc3RhbmNlLCB3ZSB3
aWxsIGluZGljYXRlIOKAnG5vbi1wZXJzaXN0ZW50IChhY3Jvc3MgcG93ZXIgb24vb2ZmIG9yIHJl
Ym9vdCBjeWNsZXMpLg0KDQo8d2cgY2hhaXIgaGF0IG9mZj4NCg0KQXMgdGhlIGF1dGhvciwgSSB0
aGluayB3ZSBhcmUgYmV0dGVyIHRvIGRlZmluZSBlcGhlbWVyYWwgYXQgdGhlIGJlZ2lubmluZyBh
cyDigJxub24tcGVyc2lzdGVudCAoYWNyb3NzIHBvd2VyIG9uIC9vZmYgb3IgcmVib290KS4gIENo
YW5naW5nIHRoZSBkZWZpbml0aW9uIGF0IHRoaXMgcG9pbnQsIEkgc3VzcGVjdCB3aWxsIHNpbXBs
eSBjb25mdXNlIHBlb3BsZS4NCg0KU3VlIEhhcmVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpPUFMtRElSIG1haWxpbmcgbGlzdA0KT1BTLURJUkBp
ZXRmLm9yZzxtYWlsdG86T1BTLURJUkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb3BzLWRpcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KT1BTLURJUiBtYWlsaW5nIGxpc3QNCk9QUy1ESVJAaWV0Zi5vcmc8
bWFpbHRvOk9QUy1ESVJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29wcy1kaXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCmkycnMgbWFpbGluZyBsaXN0DQppMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGll
dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQoNCg==

--_000_9f4ce7959f84493cbcf2babcc1597049XCHALN012ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ
cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi
Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw
dDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGku
bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K
CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5CYWxsb29uVGV4
dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p
bHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXtt
c28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVwaGVtZXJh
bCA9IOKAnHNob3J0LWxpdmVk4oCdIG9yIOKAnGNoYW5nZXMgZnJlcXVlbnRseeKAnTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5UaGVyZSBpcyBub3RoaW5nIHRvIHN0b3AgYW4gaW1wbGVtZW50YXRpb24gZnJvbSBz
dG9yaW5nIHRoZSBsYXRlc3Qg4oCcZXBoZW1lcmFs4oCdIHN0YXRlIGluIGEg4oCccGVyc2lzdGVu
dOKAnSB3YXkgc3VjaCB0aGF0IGl0IHJldHVybnMgdG8gdGhhdCBzdGF0ZSAodGhlIGxhc3Qga25v
d24gc3RhdGUpIGlmIGl0IHJlc3RhcnRzDQogZm9yIGFueSByZWFzb24gKHBsYW5uZWQgb3IgdW4t
cGxhbm5lZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGh1bWJsZSBvcGluaW9uLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5TdGV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj4gaTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10N
CjxiPk9uIEJlaGFsZiBPZiA8L2I+TGluZGEgRHVuYmFyPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz
ZGF5LCBNYXJjaCAzMSwgMjAxNiAxOjA5IFBNPGJyPg0KPGI+VG86PC9iPiBEZWFuIEJvZ2Rhbm92
aWMgJmx0O2l2YW5kZWFuQGdtYWlsLmNvbSZndDs7IFN1c2FuIEhhcmVzICZsdDtzaGFyZXNAbmR6
aC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb2VsIEhhbHBlcm4gRGlyZWN0ICZsdDtqbWguZGly
ZWN0QGpvZWxoYWxwZXJuLmNvbSZndDs7IG9wcy1kaXJAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc7
IEJSVU5HQVJELCBERUJPUkFIIEEgJmx0O2RiMzU0NkBhdHQuY29tJmd0OzsgR3VudGVyIFZhbiBE
ZSBWZWxkZSAmbHQ7Z3VudGVydmFuZGV2ZWxkZWNjQGljbG91ZC5jb20mZ3Q7PGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbaTJyc10gW09QUy1ESVJdIEVwaGVtZXJhbCAtIFNob3VsZCB3ZSB1c2Ug
YW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPklzIOKAnGVwaGVtZXJhbOKAnSBzYW1lIGFzIOKAnHZvbGF0aWxl4oCdICh3aG9z
ZSBvcHBvc2l0ZSBzdGF0ZSBpcyDigJ1ub24tdm9sYXRpbGXigJ0pPw0KPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JcyDigJxub24tIGVwaGVtZXJhbOKAnSAmbmJz
cDtzYW1lIGFzIOKAnHBlcnNpc3RlbnTigJ0gJm5ic3A7b3Ig4oCcIG5vbi12b2xhdGlsZeKAnT8N
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5MaW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu
cy1zZXJpZiI+IE9QUy1ESVIgWzxhIGhyZWY9Im1haWx0bzpvcHMtZGlyLWJvdW5jZXNAaWV0Zi5v
cmciPm1haWx0bzpvcHMtZGlyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m
IDwvYj5EZWFuIEJvZ2Rhbm92aWM8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAyNSwg
MjAxNiAyOjM5IFBNPGJyPg0KPGI+VG86PC9iPiBTdXNhbiBIYXJlczxicj4NCjxiPkNjOjwvYj4g
Sm9lbCBIYWxwZXJuIERpcmVjdDsgPGEgaHJlZj0ibWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmciPm9w
cy1kaXJAaWV0Zi5vcmc8L2E+OyBCUlVOR0FSRCwgREVCT1JBSCBBOyBHdW50ZXIgVmFuIERlIFZl
bGRlOw0KPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+PGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT1BTLURJUl0gW2kycnNdIEVwaGVtZXJhbCAtIFNob3Vs
ZCB3ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VlLDxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1PLCBlcGhlbWVyYWwgaGFz
IHR3byBtZWFuaW5nIGluIGkycnMgYXJjaGl0ZWN0dXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIGl0IGRvZXNu4oCZdCBzdXJ2aXZlIHJl
Ym9vdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Mi4geW91IGNhbuKAmXQgcm9sbCBiYWNrIHRvIGEgcHJldmlvdXMgZXBoZW1lcmFsIHN0YXRlPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYW48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIE1hciAyNSwgMjAxNiwgYXQgMTA6MDEgQU0sIFN1c2FuIEhhcmVzICZs
dDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EZWJvcmFoOjxzcGFuIGNsYXNzPSJhcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMiBp
cyBleGFjdGx5IHRoZSBwbGFjZSBJIHdvdWxkIHB1dCB0aGUgZGVmaW5pdGlvbiBvZiBlcGhlbWVy
YWwuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+U3VlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+QlJVTkdBUkQsDQogREVCT1JBSCBB
IFs8YSBocmVmPSJtYWlsdG86ZGIzNTQ2QGF0dC5jb20iPm1haWx0bzpkYjM1NDZAYXR0LmNvbTwv
YT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N
CjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj5GcmlkYXksIE1hcmNoIDI1LCAyMDE2IDk6NTAgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlN1c2FuIEhhcmVzOyAn
RnJlZCBCYWtlciAoZnJlZCknOyAnR3VudGVyIFZhbiBEZSBWZWxkZSc8YnI+DQo8Yj5DYzo8L2I+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9
Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0
bzpvcHMtZGlyQGlldGYub3JnIj5vcHMtZGlyQGlldGYub3JnPC9hPjsgJ0pvZWwgSGFscGVybiBE
aXJlY3QnPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBbaTJyc10gW09QUy1ESVJdIEVwaGVtZXJhbCAtIFNob3Vs
ZCB3ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBvcGluaW9uPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPkFzIEFsaWEgaXMgYSBjby1hdXRob3IsIEkgd2FzIGFzc2lnbmVkIGFz
IHRoZSByZXNwb25zaWJsZSBBRCBmb3IgdGhpcyBkb2N1bWVudC4gVGhlIGRvY3VtZW50IGlzIG5v
dCB3aXRoIHRoZSBSRkMgRWRpdG9yIOKAkyBpdOKAmXMgYmVlbiBhcHByb3ZlZCBieSB0aGUgSUVT
RyB3aXRoDQogYSByZXZpc2VkIElEIG5lZWRlZCB0byBhZGRyZXNzIGNvbW1lbnRzIHJhaXNlZCBi
eSB0aGUgSUVTRy4gQW5kIHNvIHRoZSBjdXJyZW50IGRpc2N1c3Npb24uPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5JIGhhZCBhbHNvIHJhaXNlZCB0aGUgY29uY2VybiBvbiBuZWVkaW5nIG1vcmUgY2xhcml0eSBv
biB0aGUgZGVmaW5pdGlvbiBvZiBlcGhlbWVyYWwgZHVyaW5nIG15IEFEIHJldmlldy4gVGhlIGF1
dGhvcnMgYWRkZWQgc29tZSBpbmZvcm1hdGlvbi4gVGhhdCBjbGVhcmx5IHdhcw0KIG5vdCBlbm91
Z2guIEFzIHRoZSB0ZXJtIGlzIHVzZWQgbXVsdGlwbGUgdGltZXMgaW4gdGhlIGRvY3VtZW50IGFu
ZCBpcyB0aGUgYmFzaXMgZm9yIGFub3RoZXIgZHJhZnQgb24gcmVxdWlyZW1lbnRzIChkcmFmdC1p
ZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlKSB3aGljaCByZWZlcnMgZXh0ZW5zaXZlbHkgdG8gdGhl
IGFyY2hpdGVjdHVyZSBkb2N1bWVudCwgSSBhZ3JlZSB0aGUgYXV0aG9ycyBuZWVkIHRvIGFkZCBt
b3JlIGRlZmluaXRpb24uIEZyZWQNCiBoYXMgYSBnb29kIHN1Z2dlc3Rpb24g4oCTIHRoZSB0ZXJt
IHNob3VsZCBiZSB2aXNpYmxlIGluIGEgZ2xvc3Nhcnkgc2VjdGlvbiBlYXJseSBpbiB0aGUgZG9j
dW1lbnQuIEl04oCZcyBub3QgY3VycmVudGx5IGluY2x1ZGVkIGluIFNlY3Rpb24gMuKAmXMgVGVy
bWlub2xvZ3kg4oCTIFN1ZSwgaG93IGFib3V0IGFkZGluZyBpdCB0byB0aGF0IHNlY3Rpb24/PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZSBhdXRob3JzIGtub3cgd2hhdCBpcyBuZWVkZWQgYW5k
IHRoYW5rIGV2ZXJ5b25lIGZvciB0aGUgZGlzY3Vzc2lvbiBhbmQgdGhlaXIgdGltZSByZXZpZXdp
bmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPkRlYm9yYWg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+aTJycw0KIFs8YSBocmVmPSJtYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnPC9z
cGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L2I+U3VzYW4gSGFyZXM8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5LCBNYXJjaCAyNSwgMjAxNiA5
OjE4IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj4nRnJlZCBCYWtlciAoZnJlZCknICZsdDs8YSBocmVmPSJtYWlsdG86ZnJl
ZEBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmZyZWRAY2lzY28uY29tPC9z
cGFuPjwvYT4mZ3Q7OyAnR3VudGVyIFZhbiBEZSBWZWxkZScgJmx0OzxhIGhyZWY9Im1haWx0bzpn
dW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
Z3VudGVydmFuZGV2ZWxkZWNjQGljbG91ZC5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8
L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy
ZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pMnJz
QGlldGYub3JnPC9zcGFuPjwvYT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpvcHMtZGlyQGlldGYub3JnIj48c3BhbiBzdHls
ZT0iY29sb3I6cHVycGxlIj5vcHMtZGlyQGlldGYub3JnPC9zcGFuPjwvYT47DQogJ0pvZWwgSGFs
cGVybiBEaXJlY3QnICZsdDs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5j
b20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29t
PC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbaTJyc10gW09QUy1ESVJdIEVwaGVtZXJh
bCAtIFNob3VsZCB3ZSB1c2UgYW5vdGhlciB3b3JkIC0gKDMvMjQgdG8gNC8zKSBDYWxsIGZvciBv
cGluaW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PkZyZWQ6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LCBhbmQgeW91ciBjb21tZW50
cyBoZXJlLiZuYnNwOyBJIHdpc2hlZCBJ4oCZZCBhc2tlZCBhYm91dCB0aGUgd29yZCBlcGhlbWVy
YWwgZWFybGllci48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5TdWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z
LXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5GcmVkDQogQmFrZXIg
KGZyZWQpIFs8YSBocmVmPSJtYWlsdG86ZnJlZEBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPm1haWx0bzpmcmVkQGNpc2NvLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIE1h
cmNoIDI0LCAyMDE2IDI6NTkgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkd1bnRlciBWYW4gRGUgVmVsZGU8YnI+DQo8Yj5D
Yzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlN1
c2FuIEhhcmVzOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+aTJyc0BpZXRmLm9yZzwvc3Bhbj48L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRmLm9yZyI+PHNw
YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+b3BzLWRpckBpZXRmLm9yZzwvc3Bhbj48L2E+Ow0KIEpv
ZWwgSGFscGVybiBEaXJlY3Q8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtPUFMtRElSXSBFcGhlbWVyYWwgLSBT
aG91bGQgd2UgdXNlIGFub3RoZXIgd29yZCAtICgzLzI0IHRvIDQvMykgQ2FsbCBmb3Igb3Bpbmlv
bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IGNvbW1lbnQgd2FzIGEgcmV2aWV3IGNvbW1lbnQsIHRo
YXQgdGhlIHdvcmQgd2FzIGJlaW5nIHVzZWQgaW4gYSB3YXkgdGhhdCB3YXNuJ3QgY29uc2lzdGVu
dCB3aXRoIGl0cyBkaWN0aW9uYXJ5IGRlZmluaXRpb24gKHNvbWV0aGluZyB3aXRoIGEgc2hvcnQg
bGlmZXRpbWUsIHF1aXRlIGlycmVzcGVjdGl2ZSBvZiBiaXJ0aC9kZWF0aCBwcm9jZXNzZXMpIG9y
IGNvbW1vbiB1c2FnZSAoYXQgbGVhc3QgaW4gbXkNCiBjb250ZXh0KS4gQXQgdGhpcyBwb2ludCwg
dGhlIGRyYWZ0IGhhcyBiZWVuIHNlbnQgdG8gdGhlIFJGQyBFZGl0b3IsIHNvIHRvIG15IG1pbmQg
dGhpcyBkaXNjdXNzaW9uIGlzIG1vc3RseSBtb290LiBJZiBpbiB5b3VyIG90aGVyIGRyYWZ0cyB5
b3UgYXJlIHBvaW50aW5nIHBlb3BsZSB0byBhIGdsb3NzYXJ5IGluIHRoZSBhcmNoaXRlY3R1cmUg
ZG9jdW1lbnQgKHdoaWNoIEkgaW1hZ2luZSB5b3UgYWxyZWFkeSBhcmUpIGFuZCB0aGUgYXJjaGl0
ZWN0dXJlDQogZG9jdW1lbnQgZGVmaW5lcyB0aGUgdGVybSBhcyB5b3UgYXJlIHVzaW5nIGl0LCB5
b3UgaGF2ZSBwcm9iYWJseSBkb25lIGVub3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIg
MjQsIDIwMTYsIGF0IDExOjA3IEFNLCBHdW50ZXIgVmFuIERlIFZlbGRlICZsdDs8YSBocmVmPSJt
YWlsdG86Z3VudGVydmFuZGV2ZWxkZWNjQGljbG91ZC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPmd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gb2sgbm93YWRheXMgd2l0aCB1c2luZyB0
aGUgdGVybWlub2xvZ3kg4oCcRXBoZW1lcmFs4oCdLCBhbHRob3VnaCBmb3IgYSBub24tbmF0dmUg
c3BlYWtlciBpdCBpcyBub24tdHJpdmlhbCBleG90aWMgd29yZCwgcGFydGljdWxhciBpZiB0aGUg
aW50ZW5kZWQgdXNhZ2UgZG9lc27igJl0IDEwMCUgcmVmbGVjdCB0aGUgV2Vic3RlciBkaWN0aW9u
YXJ5IGludGVuZGVkIG1lYW5pbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIG9u
bHkgYWJvdXQgYSB5ZWFyIGFnbyBpIHN0YXJ0ZWQgcmVhZGluZyB1cCBvbiBpMnJzIGFuZCBkaXNj
b3ZlcmVkIHRoaXMgcGFydGljdWxhciB0ZXJtaW5vbG9neSwgYW5kIGF0IHRoZSB0aW1lIGEgZ29v
Z2xlIHNlYXJjaCBvbiB0aGlzIHRlcm1pbm9sb2d5IHdhcyBub3QgdmVyeSBjb25jbHVzaXZlIGFu
ZCByZXN1bHRlZCB0byBzb21lIGNvbmZ1c2lvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdW5kZXJzdGFu
ZCB2ZXJ5IHdlbGwgdGhlIGNvbmZ1c2lvbiBhdCBwbGF5IGhlcmUgZnJvbSBub24tbmF0aXZlIGVu
Z2xpc2ggc3BlYWtlciBwZXJzcGVjdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRk
aW5nIHRleHQgdG8gZXhwbGFpbiB0aGUgY29udGV4dCBpbiB3aGljaCB0aGUgdGVybSBFcGhlbWVy
YWwgaXMgdXNlZnVsL2FkdmlzZWQuIGZ3aXcgbm93IHRoYXQgaSBhbSB1c2VkIHRvIHNlZWluZyDi
gJhFcGhlbWVyYWwnIGFzIG5vbi1wZXJtYW5lbnQgY29uZmlnIGFjcm9zcyByZWJvb3QsIGnigJlt
IGFkYXB0ZWQgaXRzIGludGVuZGVkIHB1cnBvc2XigKYmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SXMgdGhlIGdvYWwgdG8gZXhwbGFpbiB0aGUgaW50ZW5kZWQgbWVhbmluZyBpbiBl
YWNoIGRyYWZ0L3JmYyBtZW50aW9uaW5nIGl0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C
ZSB3ZWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Ry88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjQgTWFyIDIwMTYs
IGF0IDE4OjAyLCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNv
bSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2hhcmVzQG5kemguY29tPC9zcGFuPjwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBhbGw6PHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj4mbHQ7d2cgY2hhaXIgaGF0IG9uJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PlRoZSBkcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGhhcyBiZWVuIGFwcHJv
dmVkIGFzIGFuIFJGQy4mbmJzcDsgSW4gdGhlIHJldmlldywgdGhlIE9QUy1ESVIgcmV2aWV3IGlu
ZGljYXRlZCB0aGF0IOKAnGVwaGVtZXJhbOKAnSBtZWFudCBtb3JlIHRoYW4g4oCcZG9lcyBub3Qg
c3Vydml2ZSBhIHJlYm9vdOKAnS4NCiBUaGV5IGhhdmUgYXNrZWQgdGhlIEkyUlMgd29ya2luZyBn
cm91cCBpZiByZXBsYWNpbmcg4oCcZXBoZW1lcmFs4oCdIHdpdGggbm9uLXBlcnNpc3RlbnQgKGFj
cm9zcyBwb3dlciBvbi9vZmYgb3IgcmVib290IGN5Y2xlcykgd291bGQgYmUgYSBiZXR0ZXIgY2hv
aWNlLiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+V2hhdCBkbyB5b3UgdGhpbmsg4oCTIGxlYXZlIGF0IGl0IGF0
IOKAnGVwaGVtZXJhbOKAnSBvciBjaGFuZ2UgdG8g4oCcbm9uLXBlcnNpc3RlbnQgKGFjcm9zcyBw
b3dlciBvbi9vZmYgb3IgcmVib290IGN5Y2xlcykgPyBXZSB3aWxsIGhhdmUgYSAxIHdlZWsgY2Fs
bCBvbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+VGhpcyB3b3VsZCBtZWFuIGV2ZXJ5IHBsYWNlIHRoYXQg4oCcZXBoZW1l
cmFs4oCdIGlzIGxpc3RlZCwgdGhlIGF1dGhvcnMgd291bGQgcmVwbGFjZSB3aXRoIOKAnG5vbi1w
ZXJzaXN0ZW504oCdLiZuYnNwOyBJbiB0aGUgZmlyc3QgaW5zdGFuY2UsIHdlIHdpbGwgaW5kaWNh
dGUg4oCcbm9uLXBlcnNpc3RlbnQgKGFjcm9zcyBwb3dlcg0KIG9uL29mZiBvciByZWJvb3QgY3lj
bGVzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0O3dnIGNoYWlyIGhhdCBvZmYmZ3Q7ICZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj5BcyB0aGUgYXV0aG9yLCBJIHRoaW5rIHdlIGFyZSBiZXR0ZXIgdG8g
ZGVmaW5lIGVwaGVtZXJhbCBhdCB0aGUgYmVnaW5uaW5nIGFzIOKAnG5vbi1wZXJzaXN0ZW50IChh
Y3Jvc3MgcG93ZXIgb24gL29mZiBvciByZWJvb3QpLiZuYnNwOyBDaGFuZ2luZyB0aGUgZGVmaW5p
dGlvbiBhdCB0aGlzIHBvaW50LCBJIHN1c3BlY3QNCiB3aWxsIHNpbXBseSBjb25mdXNlIHBlb3Bs
ZS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPlN1ZSBIYXJlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9QUy1ESVIgbWFpbGluZyBsaXN0PGJyPg0K
PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPUFMtRElSQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOnB1cnBsZSI+T1BTLURJUkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb3BzLWRpciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzLWRpcjwvc3Bhbj48L2E+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KT1BTLURJUiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt
YWlsdG86T1BTLURJUkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T1BTLURJ
UkBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vcHMtZGlyIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wcy1kaXI8L3NwYW4+PC9hPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KaTJycyBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT48YnI+
DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczwvYT48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_9f4ce7959f84493cbcf2babcc1597049XCHALN012ciscocom_--


From nobody Thu Mar 31 13:24: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 BCC5012D7F8; Thu, 31 Mar 2016 13:23:56 -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 YSHjF31-cm9i; Thu, 31 Mar 2016 13:23:54 -0700 (PDT)
Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5657B12D1BC; Thu, 31 Mar 2016 13:23:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 11E8F36EF8A; Thu, 31 Mar 2016 13:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459455834; bh=bt+87bWnBH3NGLYBs/AuhZtbtjTn36DadIF0Y/68WRc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=bn5Dphs8X0A7VEOtrZVwIHgr1VkgDC2kIxIcAXtz5fPDm2xOeP1gTz2KttOPCm5cl OIuHCzMo47nqDUFOZhTMoF3IhhBRg5jEMhD8r+8XCPtvKZpQ2AzvMaZ0GFzKmfBQXr 3TED5ev2IKSrC5lq2wW80Sp4C03XcicOagTgVbyM=
X-Virus-Scanned: Debian amavisd-new at maila1.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 maila1.tigertech.net (Postfix) with ESMTPSA id CC36A361398; Thu, 31 Mar 2016 13:23:52 -0700 (PDT)
To: "Steve Braaten (sbraaten)" , Linda Dunbar , Dean Bogdanovic , Susan Hares 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com>  <013201d1869e$e46f7700$ad4e6500$@ndzh.com> <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657E65FB4@dfweml501-mbb> <9f4ce7959f84493cbcf2babcc1597049@XCH-ALN-012.cisco.com>
From: "Joel M. Halpern" 
Message-ID: <56FD8755.4090908@joelhalpern.com>
Date: Thu, 31 Mar 2016 16:23:49 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <9f4ce7959f84493cbcf2babcc1597049@XCH-ALN-012.cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Joel Halpern Direct , "ops-dir@ietf.org" , "i2rs@ietf.org" , "BRUNGARD, DEBORAH A" , Gunter Van De Velde 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 31 Mar 2016 20:23:57 -0000

As used for I2RS, and as will be clarified in the definition Sue is 
adding, "ephemeral" refers to not being preserved across restarts.

Yes, the word has multiple meanings.  Almost all English words do.

Yours,
Joel

On 3/31/16 4:16 PM, Steve Braaten (sbraaten) wrote:
> Ephemeral = “short-lived” or “changes frequently”
>
> There is nothing to stop an implementation from storing the latest
> “ephemeral” state in a “persistent” way such that it returns to that
> state (the last known state) if it restarts for any reason (planned or
> un-planned).
>
> My humble opinion.
>
> Steve
>
> *From:*i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Linda Dunbar
> *Sent:* Thursday, March 31, 2016 1:09 PM
> *To:* Dean Bogdanovic ; Susan Hares 
> *Cc:* Joel Halpern Direct ;
> ops-dir@ietf.org; i2rs@ietf.org; BRUNGARD, DEBORAH A ;
> Gunter Van De Velde 
> *Subject:* Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
> Is “ephemeral” same as “volatile” (whose opposite state is ”non-volatile”)?
>
> Is “non- ephemeral”  same as “persistent”  or “ non-volatile”?
>
> Linda
>
> *From:*OPS-DIR [mailto:ops-dir-bounces@ietf.org] *On Behalf Of *Dean
> Bogdanovic
> *Sent:* Friday, March 25, 2016 2:39 PM
> *To:* Susan Hares
> *Cc:* Joel Halpern Direct; ops-dir@ietf.org ;
> BRUNGARD, DEBORAH A; Gunter Van De Velde; i2rs@ietf.org
> 
> *Subject:* Re: [OPS-DIR] [i2rs] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
> Sue,
>
> IMO, ephemeral has two meaning in i2rs architecture
>
> 1. it doesn’t survive reboot
>
> 2. you can’t roll back to a previous ephemeral state
>
> Dean
>
>     On Mar 25, 2016, at 10:01 AM, Susan Hares      > wrote:
>
>     Deborah:
>
>     Section 2 is exactly the place I would put the definition of ephemeral.
>
>     Sue
>
>     *From:*BRUNGARD, DEBORAH A [mailto:db3546@att.com]
>     *Sent:*Friday, March 25, 2016 9:50 AM
>     *To:*Susan Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
>     *Cc:*i2rs@ietf.org ; ops-dir@ietf.org
>     ; 'Joel Halpern Direct'
>     *Subject:*RE: [i2rs] [OPS-DIR] Ephemeral - Should we use another
>     word - (3/24 to 4/3) Call for opinion
>
>     Hi all,
>
>     As Alia is a co-author, I was assigned as the responsible AD for
>     this document. The document is not with the RFC Editor – it’s been
>     approved by the IESG with a revised ID needed to address comments
>     raised by the IESG. And so the current discussion.
>
>     I had also raised the concern on needing more clarity on the
>     definition of ephemeral during my AD review. The authors added some
>     information. That clearly was not enough. As the term is used
>     multiple times in the document and is the basis for another draft on
>     requirements (draft-ietf-i2rs-ephemeral-state) which refers
>     extensively to the architecture document, I agree the authors need
>     to add more definition. Fred has a good suggestion – the term should
>     be visible in a glossary section early in the document. It’s not
>     currently included in Section 2’s Terminology – Sue, how about
>     adding it to that section?
>
>     I think the authors know what is needed and thank everyone for the
>     discussion and their time reviewing.
>
>     Thanks,
>
>     Deborah
>
>     *From:*i2rs [mailto:i2rs-bounces@ietf.org]*On Behalf Of*Susan Hares
>     *Sent:*Friday, March 25, 2016 9:18 AM
>     *To:*'Fred Baker (fred)' >;
>     'Gunter Van De Velde'      >
>     *Cc:*i2rs@ietf.org ;ops-dir@ietf.org
>     ; 'Joel Halpern Direct'
>     >
>     *Subject:*Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another
>     word - (3/24 to 4/3) Call for opinion
>
>     Fred:
>
>     Thank you for the review, and your comments here.  I wished I’d
>     asked about the word ephemeral earlier.
>
>     Sue
>
>     *From:*Fred Baker (fred) [mailto:fred@cisco.com]
>     *Sent:*Thursday, March 24, 2016 2:59 PM
>     *To:*Gunter Van De Velde
>     *Cc:*Susan Hares;i2rs@ietf.org
>     ;ops-dir@ietf.org ;
>     Joel Halpern Direct
>     *Subject:*Re: [OPS-DIR] Ephemeral - Should we use another word -
>     (3/24 to 4/3) Call for opinion
>
>     My comment was a review comment, that the word was being used in a
>     way that wasn't consistent with its dictionary definition (something
>     with a short lifetime, quite irrespective of birth/death processes)
>     or common usage (at least in my context). At this point, the draft
>     has been sent to the RFC Editor, so to my mind this discussion is
>     mostly moot. If in your other drafts you are pointing people to a
>     glossary in the architecture document (which I imagine you already
>     are) and the architecture document defines the term as you are using
>     it, you have probably done enough.
>
>         On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde
>                  > wrote:
>
>         I am ok nowadays with using the terminology “Ephemeral”,
>         although for a non-natve speaker it is non-trivial exotic word,
>         particular if the intended usage doesn’t 100% reflect the
>         Webster dictionary intended meaning.
>
>         It is only about a year ago i started reading up on i2rs and
>         discovered this particular terminology, and at the time a google
>         search on this terminology was not very conclusive and resulted
>         to some confusion.
>
>         I understand very well the confusion at play here from
>         non-native english speaker perspective.
>
>         Adding text to explain the context in which the term Ephemeral
>         is useful/advised. fwiw now that i am used to seeing ‘Ephemeral'
>         as non-permanent config across reboot, i’m adapted its intended
>         purpose…
>
>         Is the goal to explain the intended meaning in each draft/rfc
>         mentioning it?
>
>         Be well,
>
>         G/
>
>             On 24 Mar 2016, at 18:02, Susan Hares              > wrote:
>
>             Hi all:
>
>             
>
>             The draft-ietf-i2rs-architecture document has been approved
>             as an RFC.  In the review, the OPS-DIR review indicated that
>             “ephemeral” meant more than “does not survive a reboot”.
>             They have asked the I2RS working group if replacing
>             “ephemeral” with non-persistent (across power on/off or
>             reboot cycles) would be a better choice.
>
>             What do you think – leave at it at “ephemeral” or change to
>             “non-persistent (across power on/off or reboot cycles) ? We
>             will have a 1 week call on
>
>             This would mean every place that “ephemeral” is listed, the
>             authors would replace with “non-persistent”.  In the first
>             instance, we will indicate “non-persistent (across power
>             on/off or reboot cycles).
>
>             
>
>             As the author, I think we are better to define ephemeral at
>             the beginning as “non-persistent (across power on /off or
>             reboot).  Changing the definition at this point, I suspect
>             will simply confuse people.
>
>             Sue Hares
>
>             _______________________________________________
>             OPS-DIR mailing list
>             OPS-DIR@ietf.org 
>             https://www.ietf.org/mailman/listinfo/ops-dir
>
>         _______________________________________________
>         OPS-DIR mailing list
>         OPS-DIR@ietf.org 
>         https://www.ietf.org/mailman/listinfo/ops-dir
>
>     _______________________________________________
>     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 Mar 31 14:17: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 D8A1512D572 for ; Thu, 31 Mar 2016 14:17:52 -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 OVtD691-kDKU for ; Thu, 31 Mar 2016 14:17:49 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 4F92412D6A4 for ; Thu, 31 Mar 2016 14:17:48 -0700 (PDT)
Received: by mail-lb0-x22b.google.com with SMTP id qe11so60138306lbc.3 for ; Thu, 31 Mar 2016 14:17: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=MjHtyz3N6HW8ymIw/dKUfTND2k1qMvMrm0Fl1Kxlpsw=; b=aIZ4WsdrLsl/HzMEJCT6eUGDqK+rUVBg7Mnx4lsu1G3ldEntOcIf7SV/V+PyC6sKcC EFVm6shAwAKzhboLfhCNPYqVB0AcO5fW6xqBbFElriq4nfdJa8QnbswhGcDma1UDIhVx kyo2N9F5Ok4MDjS5p/6Dl6o7Wsv2cRLbRvzKbaPsNKKy2yj8LDjSslMPd95aWU+52t1C bRmY2KjW3yqTNlueAS6/dZAtmC3b2m7DXllDSZQC9l0hc7xmlU9V+vTQyOcJ5ME0uPRd o7YLVU7UN2zIjyuyLl8HGQSsfzedPu9J5grrAs29AhMM7boYLdenlKrfwxq3Bls5UEh3 kqNA==
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=MjHtyz3N6HW8ymIw/dKUfTND2k1qMvMrm0Fl1Kxlpsw=; b=OySVlIhEZLGDqO6aq2/Dgub106rQVeMrNQphJ/g23iDJSUCEorb1MpG7Tf/GgBZ7Qy 1oFz6lTsjs0StV4H2HPj/j7DPXqp86A7NNOFwVGmXuDuxs8w3fOE+mk5caKC5hYGQ3PP F8xg+eQlayp5o6+QlKJjlvp9tdUHY2zF7KVM7/wmb2ODvN04keENaSMceqrpBn+ynxK1 mUSrYdRa5B7J7EbK5v7oDB44Z4Iv105k1//aTo/e9z0M17QtzBviQ/0tbzdCQGtyPL/B LFMQh1brGUz7K9VonTWGP4ZfeRras86DF6k4wgOPZNK5NZp05kkGkVzFtvFGHuyWeuTU 05+Q==
X-Gm-Message-State: AD7BkJKzp1DpGizKH+Ahq4fLHJ/tauk1QSBfJcjovd7Kve1YxAkyp8WT23a054bPsTjeKhOBneCvYG0L5Me9cA==
MIME-Version: 1.0
X-Received: by 10.112.147.101 with SMTP id tj5mr941348lbb.119.1459459065915; Thu, 31 Mar 2016 14:17:45 -0700 (PDT)
Received: by 10.112.135.97 with HTTP; Thu, 31 Mar 2016 14:17:45 -0700 (PDT)
In-Reply-To: <9f4ce7959f84493cbcf2babcc1597049@XCH-ALN-012.cisco.com>
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com>  <013201d1869e$e46f7700$ad4e6500$@ndzh.com> <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657E65FB4@dfweml501-mbb> <9f4ce7959f84493cbcf2babcc1597049@XCH-ALN-012.cisco.com>
Date: Thu, 31 Mar 2016 14:17:45 -0700
Message-ID: 
From: Andy Bierman 
To: "Steve Braaten (sbraaten)" 
Content-Type: multipart/alternative; boundary=047d7b3a8bd230445f052f5ecb2d
Archived-At: 
Cc: Joel Halpern Direct , "ops-dir@ietf.org" , "BRUNGARD, DEBORAH A" , Gunter Van De Velde , Linda Dunbar , Dean Bogdanovic , "i2rs@ietf.org" , Susan Hares 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 31 Mar 2016 21:17:53 -0000

--047d7b3a8bd230445f052f5ecb2d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 31, 2016 at 1:16 PM, Steve Braaten (sbraaten) <
sbraaten@cisco.com> wrote:

> Ephemeral =3D =E2=80=9Cshort-lived=E2=80=9D or =E2=80=9Cchanges frequentl=
y=E2=80=9D
>
>
>
> There is nothing to stop an implementation from storing the latest
> =E2=80=9Cephemeral=E2=80=9D state in a =E2=80=9Cpersistent=E2=80=9D way s=
uch that it returns to that state
> (the last known state) if it restarts for any reason (planned or
> un-planned).
>
>
>
> My humble opinion.
>

There is little (or no) difference between a NETCONF server that
boots and gets its startup config from a configuration server,
and an I2RS agent that boots and gets its ephemeral state from an I2RS
client.

In NETCONF, NV-storage is mostly an implementation detail.
In I2RS, the architecture says its data MUST NOT persist across a reboot.
(No explanation why interoperability is harmed if an agent persisted its
I2RS data).



>
>
> Steve
>
>
>

Andy


>
>
> *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Linda Dunbar
> *Sent:* Thursday, March 31, 2016 1:09 PM
> *To:* Dean Bogdanovic ; Susan Hares 
> *Cc:* Joel Halpern Direct ; ops-dir@ietf.org;
> i2rs@ietf.org; BRUNGARD, DEBORAH A ; Gunter Van De Velde =
<
> guntervandeveldecc@icloud.com>
> *Subject:* Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
>
>
> Is =E2=80=9Cephemeral=E2=80=9D same as =E2=80=9Cvolatile=E2=80=9D (whose =
opposite state is
> =E2=80=9Dnon-volatile=E2=80=9D)?
>
>
>
> Is =E2=80=9Cnon- ephemeral=E2=80=9D  same as =E2=80=9Cpersistent=E2=80=9D=
  or =E2=80=9C non-volatile=E2=80=9D?
>
> Linda
>
>
>
> *From:* OPS-DIR [mailto:ops-dir-bounces@ietf.org
> ] *On Behalf Of *Dean Bogdanovic
> *Sent:* Friday, March 25, 2016 2:39 PM
> *To:* Susan Hares
> *Cc:* Joel Halpern Direct; ops-dir@ietf.org; BRUNGARD, DEBORAH A; Gunter
> Van De Velde; i2rs@ietf.org
> *Subject:* Re: [OPS-DIR] [i2rs] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
>
>
> Sue,
>
>
>
> IMO, ephemeral has two meaning in i2rs architecture
>
>
>
> 1. it doesn=E2=80=99t survive reboot
>
> 2. you can=E2=80=99t roll back to a previous ephemeral state
>
>
>
> Dean
>
>
>
> On Mar 25, 2016, at 10:01 AM, Susan Hares  wrote:
>
>
>
> Deborah:
>
>
>
> Section 2 is exactly the place I would put the definition of ephemeral.
>
>
>
> Sue
>
>
>
> *From:* BRUNGARD, DEBORAH A [mailto:db3546@att.com ]
> *Sent:* Friday, March 25, 2016 9:50 AM
> *To:* Susan Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
> *Cc:* i2rs@ietf.org; ops-dir@ietf.org; 'Joel Halpern Direct'
> *Subject:* RE: [i2rs] [OPS-DIR] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
>
>
> Hi all,
>
>
>
> As Alia is a co-author, I was assigned as the responsible AD for this
> document. The document is not with the RFC Editor =E2=80=93 it=E2=80=99s =
been approved by
> the IESG with a revised ID needed to address comments raised by the IESG.
> And so the current discussion.
>
>
>
> I had also raised the concern on needing more clarity on the definition o=
f
> ephemeral during my AD review. The authors added some information. That
> clearly was not enough. As the term is used multiple times in the documen=
t
> and is the basis for another draft on requirements
> (draft-ietf-i2rs-ephemeral-state) which refers extensively to the
> architecture document, I agree the authors need to add more definition.
> Fred has a good suggestion =E2=80=93 the term should be visible in a glos=
sary
> section early in the document. It=E2=80=99s not currently included in Sec=
tion 2=E2=80=99s
> Terminology =E2=80=93 Sue, how about adding it to that section?
>
>
>
> I think the authors know what is needed and thank everyone for the
> discussion and their time reviewing.
>
>
>
> Thanks,
>
> Deborah
>
>
>
>
>
>
>
> *From:* i2rs [mailto:i2rs-bounces@ietf.org ] *On
> Behalf Of *Susan Hares
> *Sent:* Friday, March 25, 2016 9:18 AM
> *To:* 'Fred Baker (fred)' ; 'Gunter Van De Velde' <
> guntervandeveldecc@icloud.com>
> *Cc:* i2rs@ietf.org; ops-dir@ietf.org; 'Joel Halpern Direct' <
> jmh.direct@joelhalpern.com>
> *Subject:* Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
>
>
> Fred:
>
>
>
> Thank you for the review, and your comments here.  I wished I=E2=80=99d a=
sked
> about the word ephemeral earlier.
>
>
>
> Sue
>
>
>
> *From:* Fred Baker (fred) [mailto:fred@cisco.com ]
> *Sent:* Thursday, March 24, 2016 2:59 PM
> *To:* Gunter Van De Velde
> *Cc:* Susan Hares; i2rs@ietf.org; ops-dir@ietf.org; Joel Halpern Direct
> *Subject:* Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24
> to 4/3) Call for opinion
>
>
>
> My comment was a review comment, that the word was being used in a way
> that wasn't consistent with its dictionary definition (something with a
> short lifetime, quite irrespective of birth/death processes) or common
> usage (at least in my context). At this point, the draft has been sent to
> the RFC Editor, so to my mind this discussion is mostly moot. If in your
> other drafts you are pointing people to a glossary in the architecture
> document (which I imagine you already are) and the architecture document
> defines the term as you are using it, you have probably done enough.
>
>
>
> On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde <
> guntervandeveldecc@icloud.com> wrote:
>
>
>
> I am ok nowadays with using the terminology =E2=80=9CEphemeral=E2=80=9D, =
although for a
> non-natve speaker it is non-trivial exotic word, particular if the intend=
ed
> usage doesn=E2=80=99t 100% reflect the Webster dictionary intended meanin=
g.
>
>
>
> It is only about a year ago i started reading up on i2rs and discovered
> this particular terminology, and at the time a google search on this
> terminology was not very conclusive and resulted to some confusion.
>
> I understand very well the confusion at play here from non-native english
> speaker perspective.
>
>
>
> Adding text to explain the context in which the term Ephemeral is
> useful/advised. fwiw now that i am used to seeing =E2=80=98Ephemeral' as
> non-permanent config across reboot, i=E2=80=99m adapted its intended purp=
ose=E2=80=A6
>
>
>
> Is the goal to explain the intended meaning in each draft/rfc mentioning
> it?
>
>
>
> Be well,
>
> G/
>
>
>
> On 24 Mar 2016, at 18:02, Susan Hares  wrote:
>
>
>
> Hi all:
>
>
>
> 
>
> The draft-ietf-i2rs-architecture document has been approved as an RFC.  I=
n
> the review, the OPS-DIR review indicated that =E2=80=9Cephemeral=E2=80=9D=
 meant more than
> =E2=80=9Cdoes not survive a reboot=E2=80=9D. They have asked the I2RS wor=
king group if
> replacing =E2=80=9Cephemeral=E2=80=9D with non-persistent (across power o=
n/off or reboot
> cycles) would be a better choice.
>
>
>
> What do you think =E2=80=93 leave at it at =E2=80=9Cephemeral=E2=80=9D or=
 change to
> =E2=80=9Cnon-persistent (across power on/off or reboot cycles) ? We will =
have a 1
> week call on
>
>
>
> This would mean every place that =E2=80=9Cephemeral=E2=80=9D is listed, t=
he authors would
> replace with =E2=80=9Cnon-persistent=E2=80=9D.  In the first instance, we=
 will indicate
> =E2=80=9Cnon-persistent (across power on/off or reboot cycles).
>
>
>
> 
>
>
>
> As the author, I think we are better to define ephemeral at the beginning
> as =E2=80=9Cnon-persistent (across power on /off or reboot).  Changing th=
e
> definition at this point, I suspect will simply confuse people.
>
>
>
> Sue Hares
>
>
>
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
>
>
>
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
>
>
>
> _______________________________________________
> 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
>
>

--047d7b3a8bd230445f052f5ecb2d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Mar 31, 2016 at 1:16 PM, Steve Braaten (sbraaten) <sbraaten@c=
isco.com> wrote:











Ephemeral =3D =E2=80=9Cshort-lived=E2=80=9D or =E2=
=80=9Cchanges frequently=E2=80=9D


=C2=A0


There is nothing to stop an implementation from sto=
ring the latest =E2=80=9Cephemeral=E2=80=9D state in a =E2=80=9Cpersistent=
=E2=80=9D way such that it returns to that state (the last known state) if =
it restarts
 for any reason (planned or un-planned).


=C2=A0


My humble opinion.

There is little (or no) difference between a NETCONF=
 server that
boots and gets its startup config from a configurati=
on server,
and an I2RS agent that boots and gets its ephemeral st=
ate from an I2RS client.

In NETCONF, NV-storage is=
 mostly an implementation detail.
In I2RS, the architecture says =
its data MUST NOT persist across a reboot.
(No explanation why in=
teroperability is harmed if an agent persisted its I2RS data).
=C2=A0
=



=C2=A0


Steve


=C2=A0

Andy
=C2=A0


<=
u>=C2=A0






From: i2rs [mailto:i2rs-bounces@ietf.org]
On Behalf Of Linda Dunbar

Sent: Thursday, March 31, 2016 1:09 PM

To: Dean Bogdanovic <ivandean@gmail.com>; Susan Hares <shares@ndzh.com>

Cc: Joel Halpern Direct <jmh.direct@joelhalpern.com>; ops-dir@ietf.org; i2rs@ietf.org; BRUNGARD, DEBORAH A=
 <db3546@att.com=
>; Gunter Van De Velde <guntervandeveldecc@icloud.com>

Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word=
 - (3/24 to 4/3) Call for opinion






=C2=A0


Is =E2=80=9Cephemeral=E2=80=9D same a=
s =E2=80=9Cvolatile=E2=80=9D (whose opposite state is =E2=80=9Dnon-volatile=
=E2=80=9D)?



=C2=A0


Is =E2=80=9Cnon- ephemeral=E2=80=9D =
=C2=A0same as =E2=80=9Cpersistent=E2=80=9D =C2=A0or =E2=80=9C non-volatile=
=E2=80=9D?



Linda


=C2=A0






From: OPS-DIR [mailto:ops-dir-bounces@ietf.org]
On Behalf Of Dean Bogdanovic

Sent: Friday, March 25, 2016 2:39 PM

To: Susan Hares

Cc: Joel Halpern Direct; ops-dir@ietf.org; BRUNGARD, DEBORAH A; Gunter Van De Velde;
i2rs@ietf.org

Subject: Re: [OPS-DIR] [i2rs] Ephemeral - Should we use another word=
 - (3/24 to 4/3) Call for opinion






=C2=A0


Sue,




=C2=A0






IMO, ephemeral has two meaning in i2rs architecture<=
u>






=C2=A0






1. it doesn=E2=80=99t survive reboot





2. you can=E2=80=99t roll back to a previous ephemer=
al state






=C2=A0






Dean






=C2=A0












On Mar 25, 2016, at 10:01 AM, Susan Hares <shares@ndzh.com> wrot=
e:




=C2=A0






Deborah:=C2=A0=







=C2=A0






Section 2 is exactly the place I woul=
d put the definition of ephemeral.=C2=A0<=
/p>





=C2=A0






Sue=C2=A0<=
u>






=C2=A0










From:=C2=A0BRUNGAR=
D,
 DEBORAH A [mailto:db35=
46@att.com]=C2=A0

Sent:=C2=A0Friday, March 25, 2016 9:50 AM

To:=C2=A0Susan Hares; 'Fred Baker (fred)'; '=
;Gunter Van De Velde'

Cc:=C2=A0i2rs@ietf.org;
ops-dir@ietf.org;=
 'Joel Halpern Direct'

Subject:=C2=A0RE: [i2rs] [OPS-DIR] Ephemeral - Should w=
e use another word - (3/24 to 4/3) Call for opinion









=C2=A0






Hi all,






=C2=A0






As Alia is a co-author, I was assigne=
d as the responsible AD for this document. The document is not with the RFC=
 Editor =E2=80=93 it=E2=80=99s been approved by the IESG with
 a revised ID needed to address comments raised by the IESG. And so the cur=
rent discussion.






=C2=A0






I had also raised the concern on need=
ing more clarity on the definition of ephemeral during my AD review. The au=
thors added some information. That clearly was
 not enough. As the term is used multiple times in the document and is the =
basis for another draft on requirements (draft-ietf-i2rs-ephemeral-state) w=
hich refers extensively to the architecture document, I agree the authors n=
eed to add more definition. Fred
 has a good suggestion =E2=80=93 the term should be visible in a glossary s=
ection early in the document. It=E2=80=99s not currently included in Sectio=
n 2=E2=80=99s Terminology =E2=80=93 Sue, how about adding it to that sectio=
n?






=C2=A0






I think the authors know what is need=
ed and thank everyone for the discussion and their time reviewing.






=C2=A0






Thanks,






Deborah






=C2=A0






=C2=A0






=C2=A0










From:=C2=A0i2rs
 [mailto:i2rs-bounces@ietf.org]=C2=A0<=
b>On Behalf Of=C2=A0Susan Hares

Sent:=C2=A0Friday, March 25, 2016 9:18 AM

To:=C2=A0'Fred Baker (fred)' <fred@cis=
co.com>; 'Gunter Van De Velde' <guntervandeveldecc@icloud.com>

Cc:=C2=A0i2rs@ietf.org;=C2=A0ops-dir@ietf.org;
 'Joel Halpern Direct' <jmh.direct@joelhalpern=
.com>

Subject:=C2=A0Re: [i2rs] [OPS-DIR] Ephemeral - Should w=
e use another word - (3/24 to 4/3) Call for opinion









=C2=A0






Fred:=C2=A0






=C2=A0






Thank you for the review, and your co=
mments here.=C2=A0 I wished I=E2=80=99d asked about the word ephemeral earl=
ier.=C2=A0






=C2=A0






Sue=C2=A0<=
u>






=C2=A0










From:=C2=A0Fred
 Baker (fred) [mailto:fred@cisco.com]=C2=A0
Sent:=C2=A0Thursday, March 24, 2016 2:59 PM

To:=C2=A0Gunter Van De Velde

Cc:=C2=A0Susan Hares;=C2=A0i2rs@ietf.=
org;=C2=A0ops-dir@ietf.org;
 Joel Halpern Direct

Subject:=C2=A0Re: [OPS-DIR] Ephemeral - Should we use a=
nother word - (3/24 to 4/3) Call for opinion










=C2=A0






My comment was a review comment, that the word was b=
eing used in a way that wasn't consistent with its dictionary definitio=
n (something with a short lifetime, quite irrespective of birth/death proce=
sses) or common usage (at least in my
 context). At this point, the draft has been sent to the RFC Editor, so to =
my mind this discussion is mostly moot. If in your other drafts you are poi=
nting people to a glossary in the architecture document (which I imagine yo=
u already are) and the architecture
 document defines the term as you are using it, you have probably done enou=
gh.








=C2=A0












On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde &l=
t;guntervandeveldecc@icloud.com> wrote:<=
u>








=C2=A0












I am ok nowadays with using the terminology =E2=80=
=9CEphemeral=E2=80=9D, although for a non-natve speaker it is non-trivial e=
xotic word, particular if the intended usage doesn=E2=80=99t 100% reflect t=
he Webster dictionary intended meaning.










=C2=A0










It is only about a year ago i started reading up on =
i2rs and discovered this particular terminology, and at the time a google s=
earch on this terminology was not very conclusive and resulted to some conf=
usion.=C2=A0










I understand very well the confusion at play here fr=
om non-native english speaker perspective.










=C2=A0










Adding text to explain the context in which the term=
 Ephemeral is useful/advised. fwiw now that i am used to seeing =E2=80=98Ep=
hemeral' as non-permanent config across reboot, i=E2=80=99m adapted its=
 intended purpose=E2=80=A6=C2=A0










=C2=A0










Is the goal to explain the intended meaning in each =
draft/rfc mentioning it?










=C2=A0










Be well,










G/








=C2=A0












On 24 Mar 2016, at 18:02, Susan Hares <sha=
res@ndzh.com> wrote:








=C2=A0










Hi all:=C2=A0










=C2=A0










<wg chair hat on>=C2=A0










The draft-ietf-i2rs-architecture document has been =
approved as an RFC.=C2=A0 In the review, the OPS-DIR review indicated that =
=E2=80=9Cephemeral=E2=80=9D meant more than =E2=80=9Cdoes not survive a reb=
oot=E2=80=9D.
 They have asked the I2RS working group if replacing =E2=80=9Cephemeral=E2=
=80=9D with non-persistent (across power on/off or reboot cycles) would be =
a better choice.=C2=A0=C2=A0










=C2=A0










What do you think =E2=80=93 leave at it at =E2=80=
=9Cephemeral=E2=80=9D or change to =E2=80=9Cnon-persistent (across power on=
/off or reboot cycles) ? We will have a 1 week call on=C2=A0










=C2=A0










This would mean every place that =E2=80=9Cephemeral=
=E2=80=9D is listed, the authors would replace with =E2=80=9Cnon-persistent=
=E2=80=9D.=C2=A0 In the first instance, we will indicate =E2=80=9Cnon-persi=
stent (across power
 on/off or reboot cycles).










=C2=A0










<wg chair hat off> =C2=A0










=C2=A0










As the author, I think we are better to define ephe=
meral at the beginning as =E2=80=9Cnon-persistent (across power on /off or =
reboot).=C2=A0 Changing the definition at this point, I suspect
 will simply confuse people.=C2=A0










=C2=A0










Sue Hares










=C2=A0








_______________________________________________
OPS-DIR mailing list

OPS-DIR@ietf.org

https://www.ietf.org/mailman/listinfo/ops-dir=













=C2=A0








_______________________________________________

OPS-DIR mailing list

OPS-DIR@ietf.org

https://www.ietf.org/mailman/listinfo/ops-dir=













=C2=A0






_______________________________________________
i2rs mailing list

i2rs@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/i2rs








=C2=A0









_______________________________________________

i2rs mailing list

i2rs@ietf.org

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





--047d7b3a8bd230445f052f5ecb2d--


From nobody Thu Mar 31 14:25: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 75B5D12D869; Thu, 31 Mar 2016 14:25:07 -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 Z7jFJZlr6K30; Thu, 31 Mar 2016 14:25:04 -0700 (PDT)
Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D0212D572; Thu, 31 Mar 2016 14:25:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 379D536F044; Thu, 31 Mar 2016 14:25:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459459504; bh=q1Ox+lL04fxC2LBFwn2ImnFYq0KlTH/hOvk31WyIvBE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gxGewr9v2Mr0M+PY7yRsuSnc4yjdR8Dis/6lUbuXvv31fgCJxfRrkeYhOK2UXWXYd qsN9zplcOfQAoTLpc6o230ugcS/1pF86T2dvdsQQh989pVFeM/p/bMoXOFLYY9gS+a mh2KTg1fg44IDsUUvoUaCi3kYbrpgiQCTYG4sF6A=
X-Virus-Scanned: Debian amavisd-new at maila1.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 maila1.tigertech.net (Postfix) with ESMTPSA id 056C736EEF0; Thu, 31 Mar 2016 14:25:02 -0700 (PDT)
To: Andy Bierman , "Steve Braaten (sbraaten)" 
References: <01d701d185ee$f20157e0$d60407a0$@ndzh.com>  <15B8315D-17D9-4D81-8766-D499A0463029@cisco.com> <009001d18698$cd08ec00$671ac400$@ndzh.com>  <013201d1869e$e46f7700$ad4e6500$@ndzh.com> <8204F7D1-69A8-4F33-8442-05CCD65AD6F2@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657E65FB4@dfweml501-mbb> <9f4ce7959f84493cbcf2babcc1597049@XCH-ALN-012.cisco.com> 
From: "Joel M. Halpern" 
Message-ID: <56FD95AB.1000106@joelhalpern.com>
Date: Thu, 31 Mar 2016 17:24:59 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Gunter Van De Velde , "ops-dir@ietf.org" , "BRUNGARD, DEBORAH A" , "i2rs@ietf.org" , Linda Dunbar , Dean Bogdanovic , Susan Hares 
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion
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, 31 Mar 2016 21:25:07 -0000

The harm from persisting the data is in terms of robustness, not in 
terms of interoperability.  With multiple interacting clients, and 
allowance for lowered error checking, things can go wrong.

The fallback in the case of I2RS is that reboot will drop all the state, 
so no persistent harm can be caused.

Yours,
Joel

On 3/31/16 5:17 PM, Andy Bierman wrote:
>
>
> On Thu, Mar 31, 2016 at 1:16 PM, Steve Braaten (sbraaten)
> > wrote:
>
>     Ephemeral = “short-lived” or “changes frequently”____
>
>     __ __
>
>     There is nothing to stop an implementation from storing the latest
>     “ephemeral” state in a “persistent” way such that it returns to that
>     state (the last known state) if it restarts for any reason (planned
>     or un-planned).____
>
>     __ __
>
>     My humble opinion.
>
>
> There is little (or no) difference between a NETCONF server that
> boots and gets its startup config from a configuration server,
> and an I2RS agent that boots and gets its ephemeral state from an I2RS
> client.
>
> In NETCONF, NV-storage is mostly an implementation detail.
> In I2RS, the architecture says its data MUST NOT persist across a reboot.
> (No explanation why interoperability is harmed if an agent persisted its
> I2RS data).
>
>     ____
>
>     __ __
>
>     Steve____
>
>     __
>
>
> Andy
>
>     __
>
>     __ __
>
>     *From:*i2rs [mailto:i2rs-bounces@ietf.org
>     ] *On Behalf Of *Linda Dunbar
>     *Sent:* Thursday, March 31, 2016 1:09 PM
>     *To:* Dean Bogdanovic      >; Susan Hares      >
>     *Cc:* Joel Halpern Direct      >; ops-dir@ietf.org
>     ; i2rs@ietf.org ;
>     BRUNGARD, DEBORAH A >; Gunter
>     Van De Velde      >
>     *Subject:* Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another
>     word - (3/24 to 4/3) Call for opinion____
>
>     __ __
>
>     Is “ephemeral” same as “volatile” (whose opposite state is
>     ”non-volatile”)? ____
>
>     __ __
>
>     Is “non- ephemeral”  same as “persistent”  or “ non-volatile”? ____
>
>     Linda____
>
>     __ __
>
>     *From:*OPS-DIR [mailto:ops-dir-bounces@ietf.org] *On Behalf Of *Dean
>     Bogdanovic
>     *Sent:* Friday, March 25, 2016 2:39 PM
>     *To:* Susan Hares
>     *Cc:* Joel Halpern Direct; ops-dir@ietf.org
>     ; BRUNGARD, DEBORAH A; Gunter Van De Velde;
>     i2rs@ietf.org 
>     *Subject:* Re: [OPS-DIR] [i2rs] Ephemeral - Should we use another
>     word - (3/24 to 4/3) Call for opinion____
>
>     __ __
>
>     Sue,____
>
>     __ __
>
>     IMO, ephemeral has two meaning in i2rs architecture____
>
>     __ __
>
>     1. it doesn’t survive reboot____
>
>     2. you can’t roll back to a previous ephemeral state____
>
>     __ __
>
>     Dean____
>
>     __ __
>
>         On Mar 25, 2016, at 10:01 AM, Susan Hares          > wrote:____
>
>         __ __
>
>         Deborah:____
>
>         ____
>
>         Section 2 is exactly the place I would put the definition of
>         ephemeral.____
>
>         ____
>
>         Sue____
>
>         ____
>
>         *From:*BRUNGARD, DEBORAH A [mailto:db3546@att.com]
>         *Sent:*Friday, March 25, 2016 9:50 AM
>         *To:*Susan Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
>         *Cc:*i2rs@ietf.org ; ops-dir@ietf.org
>         ; 'Joel Halpern Direct'
>         *Subject:*RE: [i2rs] [OPS-DIR] Ephemeral - Should we use another
>         word - (3/24 to 4/3) Call for opinion____
>
>         ____
>
>         Hi all,____
>
>         ____
>
>         As Alia is a co-author, I was assigned as the responsible AD for
>         this document. The document is not with the RFC Editor – it’s
>         been approved by the IESG with a revised ID needed to address
>         comments raised by the IESG. And so the current discussion.____
>
>         ____
>
>         I had also raised the concern on needing more clarity on the
>         definition of ephemeral during my AD review. The authors added
>         some information. That clearly was not enough. As the term is
>         used multiple times in the document and is the basis for another
>         draft on requirements (draft-ietf-i2rs-ephemeral-state) which
>         refers extensively to the architecture document, I agree the
>         authors need to add more definition. Fred has a good suggestion
>         – the term should be visible in a glossary section early in the
>         document. It’s not currently included in Section 2’s Terminology
>         – Sue, how about adding it to that section?____
>
>         ____
>
>         I think the authors know what is needed and thank everyone for
>         the discussion and their time reviewing.____
>
>         ____
>
>         Thanks,____
>
>         Deborah____
>
>         ____
>
>         ____
>
>         ____
>
>         *From:*i2rs [mailto:i2rs-bounces@ietf.org]*On Behalf Of*Susan Hares
>         *Sent:*Friday, March 25, 2016 9:18 AM
>         *To:*'Fred Baker (fred)'          >; 'Gunter Van De Velde'
>                  >
>         *Cc:*i2rs@ietf.org ;ops-dir@ietf.org
>         ; 'Joel Halpern Direct'
>         >
>         *Subject:*Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another
>         word - (3/24 to 4/3) Call for opinion____
>
>         ____
>
>         Fred:____
>
>         ____
>
>         Thank you for the review, and your comments here.  I wished I’d
>         asked about the word ephemeral earlier.____
>
>         ____
>
>         Sue____
>
>         ____
>
>         *From:*Fred Baker (fred) [mailto:fred@cisco.com]
>         *Sent:*Thursday, March 24, 2016 2:59 PM
>         *To:*Gunter Van De Velde
>         *Cc:*Susan Hares;i2rs@ietf.org
>         ;ops-dir@ietf.org
>         ; Joel Halpern Direct
>         *Subject:*Re: [OPS-DIR] Ephemeral - Should we use another word -
>         (3/24 to 4/3) Call for opinion____
>
>         ____
>
>         My comment was a review comment, that the word was being used in
>         a way that wasn't consistent with its dictionary definition
>         (something with a short lifetime, quite irrespective of
>         birth/death processes) or common usage (at least in my context).
>         At this point, the draft has been sent to the RFC Editor, so to
>         my mind this discussion is mostly moot. If in your other drafts
>         you are pointing people to a glossary in the architecture
>         document (which I imagine you already are) and the architecture
>         document defines the term as you are using it, you have probably
>         done enough.____
>
>         ____
>
>             On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde
>                          > wrote:____
>
>             ____
>
>             I am ok nowadays with using the terminology “Ephemeral”,
>             although for a non-natve speaker it is non-trivial exotic
>             word, particular if the intended usage doesn’t 100% reflect
>             the Webster dictionary intended meaning.____
>
>             ____
>
>             It is only about a year ago i started reading up on i2rs and
>             discovered this particular terminology, and at the time a
>             google search on this terminology was not very conclusive
>             and resulted to some confusion. ____
>
>             I understand very well the confusion at play here from
>             non-native english speaker perspective.____
>
>             ____
>
>             Adding text to explain the context in which the term
>             Ephemeral is useful/advised. fwiw now that i am used to
>             seeing ‘Ephemeral' as non-permanent config across reboot,
>             i’m adapted its intended purpose… ____
>
>             ____
>
>             Is the goal to explain the intended meaning in each
>             draft/rfc mentioning it?____
>
>             ____
>
>             Be well,____
>
>             G/____
>
>             ____
>
>                 On 24 Mar 2016, at 18:02, Susan Hares                  > wrote:____
>
>                 ____
>
>                 Hi all:____
>
>                 ____
>
>                 ____
>
>                 The draft-ietf-i2rs-architecture document has been
>                 approved as an RFC.  In the review, the OPS-DIR review
>                 indicated that “ephemeral” meant more than “does not
>                 survive a reboot”. They have asked the I2RS working
>                 group if replacing “ephemeral” with non-persistent
>                 (across power on/off or reboot cycles) would be a better
>                 choice. ____
>
>                 ____
>
>                 What do you think – leave at it at “ephemeral” or change
>                 to “non-persistent (across power on/off or reboot
>                 cycles) ? We will have a 1 week call on____
>
>                 ____
>
>                 This would mean every place that “ephemeral” is listed,
>                 the authors would replace with “non-persistent”.  In the
>                 first instance, we will indicate “non-persistent (across
>                 power on/off or reboot cycles).____
>
>                 ____
>
>                  ____
>
>                 ____
>
>                 As the author, I think we are better to define ephemeral
>                 at the beginning as “non-persistent (across power on
>                 /off or reboot).  Changing the definition at this point,
>                 I suspect will simply confuse people.____
>
>                 ____
>
>                 Sue Hares____
>
>                 ____
>
>                 _______________________________________________
>                 OPS-DIR mailing list
>                 OPS-DIR@ietf.org 
>                 https://www.ietf.org/mailman/listinfo/ops-dir____
>
>             ____
>
>             _______________________________________________
>             OPS-DIR mailing list
>             OPS-DIR@ietf.org 
>             https://www.ietf.org/mailman/listinfo/ops-dir____
>
>         ____
>
>         _______________________________________________
>         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
>